Software Engineering (CS181AA)
(monsters that prey on software projects, and how to vanquish them)Instructor: Mark Kampe
With appologies to Sun Tzu
When the term Software Engineering was coined (over fifty years ago), it was defined as:
Students in this course 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 properly submitted
solutions will available through another URL in the
course schedule.
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 1/31 | 1a. Team, Concept, Plan | Form teams, identify a preliminary concept, write plan for turning it into a proposal. |
| Sun 2/7 | 1b. Competitive Research | Research existing products in this space, position your proposal against this field, and develop a competitive value proposition. |
| Sun 2/14 | 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 2/21 | 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 02/28 | 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. |
| Wed 03/17 | 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 03/21 | 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: Component Specifications, Design and Test Plan | ||
| Sun 03/28 | 3a. Component Selection and Specifications | 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 4. As a team, elaborate the architecture above the chosen pieces to develop detailed specfiications for each. 5. As individuals, write up detailed specifications for your assigned component. |
| Sun 04/04 | 3b. 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 04/11 | 3c. Design Review notes, meeting 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 04/18 | 3d. Final Specification, Design, and Test Plan | 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 | ||
| Fri 05/07 | 4. Final Reports | 1. Each of you will
implement the component
you designed in phase 3. 2. Two of you will spend (at least) one session doing pair-programming and write up a brief report on the experience. 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) and write up a brief report on your experience. 4. (at least) one of you will implement your component and then submit it to code review by other members of your team and produce a report from that review. 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, design a demo that shows your (independently implemented) components working together. 7. As a team, prepare and present a brief sprint review and demo. 8. 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.
For anything you submit as a URL (e.g. Google Docs or Github repos), please ensure that they are publicly accessible to anyone with the URL.
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.