CSU 670 Software Development (4 SH)

Considers software development as a systematic process, involving specification, design, documentation, implementation, testing, and maintenance. Examines software process models; methods for software specification; modularity, abstraction, and software reuse; issues of software quality. Students, possibly working in groups, will design, document, implement, test, and modify software projects.

CSU370, CSU390.

Example of primary textbook that could be used in the course: Andrew Hunt and David Thomas. The Pragmatic Programmer: from journeyman to master. Addison-Wesley. http://www.pragmaticprogrammer.com/ppbook/extracts/rule_list.html Examples of supplementary textbooks: Fred Brooks, The Mythical Man-Month, 20th Anniversary Edition. Addison-Wesley, 1995, ISBN 0201835959. Kent Beck. Extreme Programming Explained. Addison-Wesley, 2000, ISBN 0-201-61641-6. Martin Fowler, UML Distilled, 3rd Edition, Addison-Wesley, 2004, ISBN 0-321-19368-7. Erich Gamma and Kent Beck. Contributing to Eclipse: Principles, Patterns and Plug-Ins. Addison-Wesley. Erich Gamma, Richard Helm, Ralph Johnson, & John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995, ISBN 0-201-63361-2. Craig Larman. Agile and Iterative Development: A Manager's Guide. Addison-Wesley.

Notions of software quality correctness reliability robustness maintainability evolvability People issues focus on customers pair programming the software team Software development processes and their models phases requirements analysis testing design implementation process models (instructors should select the process models they wish to teach; examples of process models include waterfall, iterative, spiral, Unified Process, Extreme Programming, et cetera) Testing test early test often test automatically the roles of unit, integration, and stress testing the roles of black-box and glass-box testing test coverage Abstraction barriers and modularity isolation of clients from details separation of concerns independence of views from models Every instructor must cover all topics listed above. Below are examples of additional topics that some instructors may wish to cover: Other notions of software quality e.g. testability, reusability, utility, performance Technical contributors to software quality simplicity clear specifications standard components verification and model checking assertion and contract checking technical reviews testing Artifact management design history and rationale source code control special problems with code generation logging errors and modifications Aspect-oriented software development Contributing to an open source project How to learn an existing technology (e.g. Eclipse) How to conduct the project in a small team Building or extending components (e.g. Eclipse plug-ins)

Upon completion of this course, a student should Know at least one organized method for developing software and know how to apply it to a set of requirements Know how to design the ontological categories of a program from informal problem descriptions Have experience working with other people to develop software

The course outcomes will be measured and verified by: Programming homeworks Students should work in teams for at least some homeworks. Public reviews of code It is recommended that students be graded on the quality of their reviews of other students' software, but the quality of their own software should be graded by the instructor. Project with a few milestones Electronic portfolio (optional at discretion of instructor)

This course gives students the knowledge and perspective they need to do the software system development they will be asked to do on their co-op assignments. It will also give students an opportunity for critical review of the software systems they have used and developed on previous co-op assignments.