Software Engineering (CS121)
(monsters that prey on software projects, and how to vanquish them)Instructor: Mark Kampe
With appologies to Sun Tzu
Students are assumed to have a good understanding of programming and
exploiting the features of programming languages and libraries.
But interesting software is sufficiently subtle and complex that it is not usually
possible to sit down, think about it for a few minutes, and start coding.
Building working software requires tools, discipline, and methodology.
This is a course in software development concepts, issues and methodologies,
whose goal is to develop:
This is a very practical course dealing with real-world problems, the issues that complicate them, and the approaches that have been successfully applied to their solution.
Practical skills will be exercised in the projects. Your mastery of concepts and issues will be assessed in mid-term and final exams.
You will be able to take these exams remotely. When the scheduled exam period begins:
The exams will be converted to pdf
and up-loaded to
Gradescope for grading,
and where you will be able to view the graded results.
After all exams have been confirmed to have been submitted,
solutions will be posted on-line:
Projects follow quickly after the readings and lectures in which the associated principles are presented. Project deliverables are spread (relatively) uniformly throughout the course (one per week). This is done to keep you from getting in trouble when you discover that you cannot complete a three week project in two days.
This course is about software project skills other than programming (e.g. concept development, requirements, architecture and design, reviews, testing, and management). You will be asked to form teams, and come up with a single (large) project concept. Then, over the course of the semester, you will work on different aspects of that one project:
| Due Date1 | Assignment2 | Summary of Activities |
|---|---|---|
| Phase 1: Concept Development, Requirements and Proposal | ||
| Sun 8/30 | 1a. Team, Concept, Plan | Form teams, identify a preliminary concept, write plan for turning it into a proposal. |
| Sun 9/06 | 1b. Competitive Research | Research existing products in this space, position your proposal against this field, and develop a competitive value proposition. |
| Sun 9/13 | 1c. Requirements Development | 1. Create a concept presentation to introduce people to the type of product you are exploring 2. Identify and characterize potential users 3. conduct interviews to gather requirements 4. analyze and report on the results. |
| Sun 9/20 | 1d. Final Proposal | 1. Combine all of the above into a complete project/product proposal
(what will be built, why you will be successful)
suitable to be summitted for funding/approval. 2. Review the processes you followed in this project to see what lessons you can learn for how to do things more effectively in the future. |
| Phase 2: Architecture and Review | ||
| Sun 09/27 | 2a. Plan and Prelimnary Architecture | 1. Develop a plan for this project, dividing the work over
your team members and the available time. 2. Develop and document an architecture and high-level component specifications for your project. This includes doing any required research and prototyping to address critical questions. |
| Sun 10/04 | 2b. Architecture Review | 1. Study another team's architecture, and prepare notes for a design review,
as they will study and pepare for a review of yours. 2. Conduct a design review with that other team, as they will with you. 3. Write up a report of the review 4. Continue to work any issues with the team that raised them. |
| Sun 10/11 | 2c. Final Architecture | 1. Revise your preliminary architecture based on the results of your review and investigations,
and submit a report on the identified issues and their resolutions. 2. Prepare and submit a final architectural proposal. 3. Review the processes you followed in this project to see what lessons you can learn for how to do things more effectively in the future. |
| Phase 3: Planning, Specification, Design and Review | ||
| Sun 10/18 | 3a. Planning | 1. Select the system components to be designed and implmented 2. Select an owner for each component 3. Develop a schedule and assign responsibilities for the remaing phases |
| Sun 10/25 | 3b. Component Specifications | 1. As a team, elaborate the architecture above the chosen pieces to
develop detailed specfiications for each. 2. As individuals, write up detailed specifications for your assigned component. |
| Sun 11/01 | 3c. Component Design and Test Plan | 1. As individuals, prepare a detailed design for your assigned component. 2. As individuals, prepare detailed unit-testing plans for your assigned component. |
| Sun 11/08 | 3d. Design Review notes and report. | 1. As individuals, package your specifications, design and test plans for review. 2. As individuals, read each package and prepare notes. 3. As a group, review each package, and write a report for each review. |
| Sun 11/15 | 3e. Final Design | 1. As individuals, revise your specifications, designs, and test plans
to address all important issues raised in the review. 2. As a team, review the processes you have followed, and write up a post-mortem report. |
| Phase 4: Implementation and Testing Sprint | ||
| Sun 12/06 | 4. Final Reports | 1. Each of you will implement the component you designed in phase 2. 2. Two of you will spend (at least) one session doing pair-programming. 3. (at least) one of you will develop your code in a Test Driven Development fashion (implementing and running tests as you complete each routine or feature). 4. (at least) one of you will implement your component and then submit it to code review by other members of your team. 5. Each of you will implement the component test plan you designed (in phase 3) and use it to validate the correctness of your implementation. 6. As a team, prepare and present a brief sprint review. 7. As a team, review the processes you have followed, and write up a post-mortem report. |
We will in many cases be looking at how plans or specifications have evolved. This can be captured with Github commits, or by enabling history in Google Docs.
Work-products will be considered to have been submitted at the time of the last
update or commit and push.
General comments on project rules and grading can be found at the end of the project descriptions.