| Instructor: | Francisco Servant [fservant@vt.edu] |
| Office hours: | After class, or by email appointment |
| Lectures: | MW 2:30-3:45PM, Architectural Annex 7 |
Description
This senior project course integrates software engineering knowledge and skills acquired in previous courses. Having successfully completed this course, students will be able to: design and implement a solution to a significant open-ended problem in software engineering; document and present (using written, oral and visual means) the design process and the results from a solution to a problem in software engineering; evaluate or assess a solution to a problem in software engineering, and compare with alternative approaches; discuss and evaluate their contribution to a team project.
As the focus of this course will be on a software development project, there will be no exams. Instead, coursework will focus on contributing to the project and leading the use of a tool or technology over the course of the semester.
Software Project
The students in the class will collaborate to build a software project. The software project will be GitAnalytics, a smart web-based platform for obtaining, producing, and sharing visualizations for software analytics. The software development project will be open source, with all artifacts, history, and issues publicly available through Github.
Features
Students will split into 4 teams to work on each of the 4 main features of the project:
- Deep history analytics
- Visualization of deep history (every revision) of any set of lines in any set of files.
- Side-by-side mapping of corresponding code among revisions (with multiple diff algorithms)
- Selection, search and filtering within the deep history.
- Authorship analytics
- Visualization of authorship within the deep history of code.
- Summarization of relevant concepts per author / code selection.
- Selection, search and filtering within the expertise visualization.
- Code Review Analytics
- Visualization of code-review authorship within the deep history of code.
- Obtaining and visualizing network of code-reviewer-reviewee relationships and analytics over the network.
- Selection, search and filtering within the code-review visualizations.
- Continuous Integration Analytics
- Visualizing activity over time of builds together with the changes and authors that triggered them.
- Failed build analytics. Which are the factors that could cause a failing build?
- Selection, search and filtering within the build visualizations.
Software Development Tools and Technology
You will use state-of-the-art web development tools and technologies for this project:
| Purpose | Technology | Description |
|---|---|---|
| Communication | Slack | Slack is an industry standard for team messaging in software development teams. It replaces email and IM with a unified channel based communication system. Slack can also be used to upload and share documents and links. We will use Slack for all project-related communication and collaboration. |
| Revision Control & Issue Management | Github | Github is a cloud-hosted Git version control provider. In this course, we will use Github as the version control system, for code reviews, as the issue tracker, and to host Wiki pages. |
| Design Diagrams | Google Drawings | You will use Google Drawings as an online collaborative whiteboard to share design sketches. |
| UML Design | Draw.io | Draw.io is based on Google Drive and it will allow you to create your UML designs and share them with the team. |
| UI Design | Balsamiq | Balsamiq is a tool for creating UI mockups. |
| IDE | Cloud9 | Cloud9 is an online IDE, enabling multiple developers to edit code and interact with a single workspace at the same time. In this course, we will use Cloud9 (together with Slack calls) for distributed pair programming. |
| Unit Testing | Jasmine 2.0 | Jasmine is a unit testing framework for Javascript. |
| Javascript Coding Standard | ES6, (a.k.a. ECMAScript 2015, ES2015) | ES6 is the current version of Javascript, enabled for current browsers. ES6 includes a number of new features, including collection classes and a new syntax for declaring classes. |
| Implementation Framework | Aurelia, Angular | Aurelia and Angular are frameworks that provide scaffolding (like templates and data binding) for implementing your application and are very useful for prototyping, as well as building production systems. |
| UI Framework | Bootstrap 3 | Bootstrap is a UI framework offering UI components and styling. |
| Visualization Framework | D3 | D3 is a framework for creating visualizations. |
| Cloud Database | Firebase | Firebase is a NoSQL cloud database, enabling real-time synchronization and storage of JSON data between between browser clients. We will use Firebase as a backend for storing system data and as a hosting platform for hosting the system itself. |
| Code Editor Module | Ace | Ace is an embeddable code editor written in Javascript, including many of the features of modern code editors and maintained as the editor for Cloud9. In this course, we will use Ace to visualize and interact with the content of code files. |
Software Project Development Practices
You will work with all the other students in the class to develop a single software project. The project experience is designed to be as close to the development of an industrial software project. For that, you will have the opportunity to work with leading tools and technologies, for software development and collaboration. Throughout this course, you will collaborate with your peers to design and develop features to provide value for potential users.
The instructor will serve as the client and will help in crafting the overall vision and requirements of the software project.
Teams
Although you will work to release a single software project, we will form 4 teams that will take care of the main 4 features of the system. The teams will be formed in the first week of class.
Sprints
The project will be organized into two-week sprints and will release a new version of the system at the end of every sprint. You will demonstrate your contributions to the project by giving a demo in class at the end of each sprint. Demos will be informal, offering you an opportunity to give a show and tell of a feature that you built and get comments and feedback from other students.
Class meetings
You will use class meetings for team discussions (although you should also discuss and collaborate outside class meetings). Common discussion topics include: tool and technology best practices, features and requirements, architecture and design, and planning the next sprint. I expect all of you to attend all class sessions. In-person communication will be key for the success of this project. You have reserved the time in your schedule, so I will only consider exceptional circumstances to excuse absence from a class session. Nevertheless, keep in mind that if you only contribute to the project during class sessions, you will not succeed in this class.
Communication
You will use Slack for distributed communication and collaboration. You will establish guidelines with your team members in terms of communication expectations (such as how long it is acceptable to wait for an answer) and stick to them. Setting expectations early improves trust, productivity and eventual success.
Pair programming
To help share knowledge, you will use pair programming in this course. During each programming session, you may pair with a different partner. To find a partner, you can check Slack to see who is online at the moment or to schedule a session. During the session, you will program with your pair using a shared Cloud9 workspace and can chat / talk / video-chat online using Slack.
To help tool and technology experts understand how others are using the tools and technologies within the course, you can record and share programming sessions as screencasts.
Code review
To help ensure the quality and maintainability of the code, all code commits will be code reviewed. After completing work on a change, you will first commit the change to your branch and then create a pull request to merge the commit into the main branch. Before the commit is merged, you will ask another student to review the code. In reviewing the commit, the reviewer should look for potential bugs, ensure the code is adequately tested with unit tests, and ensure the code is adequately documented and follows the best practices for any relevant technologies. After a commit has been reviewed and any discovered issues addressed, it can be merged into the master branch.
Testing
You will be responsible for unit testing all of the functionality you create. The quality of your testing practices and the usage of a unit-testing framework will be a component of your grade.
Technology practices
Each student will be responsible for being the expert in one of the technologies that we will use in the class. Over the course of the semester, the student will become the resident expert, helping other team members get up to speed, answering their questions, and researching and defining best practices. You will create and maintain a Wiki page on Github, explaining the basics of how to get started, addressing frequently asked questions, and documenting best practices. Others will ask questions on the corresponding Slack channel, and you will be responsible for answering their questions.
As owner of the technology, you will ultimately be responsible for making project team members as productive as possible. What this means, and how to do it, will be yours to determine. For tools, this may include making sure students are aware of features and know how to use features to accomplish common activities (e.g., creating a personal branch on Github). For technologies, this may include setting guidelines and coding standards, offering example code snippets, or explaining how something works.
In some cases, the team as a whole may realize they face an important issue related to your tool or technology (e.g., how do we merge branches) and identifying its existence may be easy. In other cases, it may be hard to determine what aspects of a tool or technology are most difficult to use or are having the biggest impact on productivity. In these cases, you may seek additional insight through several forms of data, including looking at commits or watching screencasts to understand how others are using your tool or technology and what problems they might be experiencing.
The technology experts will be assigned in the first week of class.
Grading
Your grade for this class will be based on your contributions to this project. There will be a group component and an individual component to your grade.
You will contribute to the project and demonstrate your contributions in sprints of 2-week duration. At the end of each sprint, you will demonstrate your contributions for that sprint in a demonstration in class. You will also write a report of your progress and an assessment of your peers in your team.
Sprints
At the end of each sprint, you will show your progress in an informal demo and a report. You will also submit a assessment of your peer’s work. You will use these mechanisms to show your progress. Your grade for each sprint will be assessed on the following aspects:
- Value of designed and implemented features contributed to the project
- Quality of code contributed
- Quality and value of code reviews contributed
- Use of pair programming
- Responsiveness and helpfulness in answering questions on your tool or technology on Slack
- Documentation of tool or technology best practices on the Github wiki
Demos (1 per team):
You will give an informal demo on your progress for each sprint. You will show the new features that you have built and explain the improvements contributed to the code and team practices. The format of your demo is informal and flexible, but a good way to think about it is like describing and showing the “Progress and Planning” section of your report.
Reports (1 per team):
Sprint reports will document your progress and achievements for the sprint. The reports should go to the point explaining the main points of your progress in the sprint. Each sprint report will be a slide deck with 6 slides, explaining:
Progress and Planning:
- 1. What the team did since the last sprint,
- 2. What the team plans to achieve for the next sprint,
- 3. Obstacles that the team expects to encounter and how they will solve them,
Reflection:
- 4. What the team did and worked really well,
- 5. What the team tried and didn’t work very well, and
- 6. What the team will do differently for next sprint.
Technology Progress Reports (1 per student):
Technology wikis are live documents that will evolve throughout the semester. You will be expected to make some progress on the wikis for every sprint, as well as regularly answer questions about your technology.
At the end of each sprint, you will submit a technology progress report explaining your progress on your commandment of the technology. The report will be free form and will consist of a single slide. Example of things that you may want to report are: updates on the technology wiki, research done on best practices on your technology, or questions answered to your peers.
This report will not be part of your Sprint Demo.
Peer Assessments (1 per student):
At the end of each sprint, each student will submit a peer assessment, filling in the Peer Assessment Form.
Distribution of points:
| Sprint Progress, Demos and Reports | 60% |
| Technology Wikis and Technology Progress Reports | 20% |
| Peer Assessments | 20% |
Submission guidelines:
Sprint reports, technology reports, and peer assessments will be submitted as follows:
- through Canvas. Use the folder for the corresponding sprint.
- on PDF format.
- before the class meeting time on the due date.
Late submission policy:
Unexcused late assignments will be penalized 2% per 1-hour period.
Grading scale:
| ≥ 93% → A | ≥ 83% → B | ≥ 73% → C | ≥ 63% → D | |||
| ≥ 90% → A- | ≥ 80% → B- | ≥ 70% → C- | ≥ 60% → D- | |||
| ≥ 87% → B+ | ≥ 77% → C+ | ≥ 67% → D+ | ≥ 0% → F |
Schedule (likely to change)
| Week | Date | Topic |
|---|---|---|
| 1 | 2018–08–20 | Class canceled due to medical reasons. |
| 2018–08–22 | Introduction to course. | |
| 2 | 2018–08–27 | Submit group selections and technology selections by class time. |
| 2018–08–29 | ||
| 3 | 2018–09–03 | Labor day. No class. |
| 2018–09–05 | Sprint 1 | |
| 4 | 2018–09–10 | |
| 2018–09–12 | ||
| 5 | 2018–09–17 | |
| 2018–09–19 | Sprint 2 | |
| 6 | 2018–09–24 | |
| 2018–09–26 | ||
| 7 | 2018–10–01 | |
| 2018–10–03 | Sprint 3 | |
| 8 | 2018–10–08 | |
| 2018–10–10 | ||
| 9 | 2018–10–15 | |
| 2018–10–17 | Sprint 4 | |
| 10 | 2018–10–22 | |
| 2018–10–24 | ||
| 11 | 2018–10–29 | |
| 2018–10–31 | Sprint 5 | |
| 12 | 2018–11–05 | |
| 2018–11–07 | ||
| 13 | 2018–11–12 | |
| 2018–11–14 | Sprint 6 | |
| 14 | 2018–11–19 | Thanksgiving. No class. |
| 2018–11–21 | Thanksgiving. No class. |
|
| 15 | 2018–11–26 | |
| 2018–11–28 | Sprint 7 | |
| 16 | 2018–12–03 | |
| 2018–12–05 | Sprint 8 |
Policies
Virginia Tech Honor Code:
The work you turn in must be your own. Consequences of cheating in this class: a letter in your academic file, and the course grade is lowered, most likely to F. Material that is copied from books or Web pages needs to be quoted and the source must be given. If you plagiarize, you run the severe risk of failing the class, in a most disgraceful manner.
Accommodations:
If you need special accommodations, please contact the instructor during the first week of classes.