1. CS451 Software Engineering II CS451 Software Engineering II Michael Oudshoorn and Ray Babcock

2. Introduction  This course is taught by Michael Oudshoorn and Ray Babcock  Ray’s consulting times are advertised on the web and outside his door.  Michael is available by appointment through Jeannette Radcliffe in the Departmental Office  It is difficult for the Head of Department to set fixed office hours due to various meetings.  Don’t let the need for an appointment stop you from seeking help – if I’m available, I’ll see you immediately.  This course is taught by Michael Oudshoorn and Ray Babcock  Ray’s consulting times are advertised on the web and outside his door.  Michael is available by appointment through Jeannette Radcliffe in the Departmental Office  It is difficult for the Head of Department to set fixed office hours due to various meetings.  Don’t let the need for an appointment stop you from seeking help – if I’m available, I’ll see you immediately.

3. What is your background?  Ideally, you should have completed:  CS351 Software Engineering I  CS221 Data Structures and Algorithms  CS223 Advanced Data Structures and Algorithms  CS324 Programming Paradigms  You will be proficient at coding and the use of data structures and algorithms.  Ideally, you should have completed:  CS351 Software Engineering I  CS221 Data Structures and Algorithms  CS223 Advanced Data Structures and Algorithms  CS324 Programming Paradigms  You will be proficient at coding and the use of data structures and algorithms.

4. What is the subject all about?  CS451 Software Engineering II will build on CS351 Software Engineering I and give you an opportunity to put it into practice.  Topics include:  Requirements gathering  Software design  Functional specification  Cost models  Metrics  Managing software development  Formal methods  Capability Maturity Model/CMMI  Risk analysis  Real-time systems  Safety critical software  Guest lectures from industry  CS451 Software Engineering II will build on CS351 Software Engineering I and give you an opportunity to put it into practice.  Topics include:  Requirements gathering  Software design  Functional specification  Cost models  Metrics  Managing software development  Formal methods  Capability Maturity Model/CMMI  Risk analysis  Real-time systems  Safety critical software  Guest lectures from industry

5. Objectives  The course aims to produce graduates that:  Are able to design, document, build and integrate complex software systems.  Understand the issues involved in industrial software engineering:  Requirements analysis  Functional specification  Effort estimation  Test strategies  Verification and validation  Build and debug a large software system  Communicate and present thoughts and idea in a clear, precise manner  Follow relevant standards  Work in a team environment  Develop efficient and correct code  The course aims to produce graduates that:  Are able to design, document, build and integrate complex software systems.  Understand the issues involved in industrial software engineering:  Requirements analysis  Functional specification  Effort estimation  Test strategies  Verification and validation  Build and debug a large software system  Communicate and present thoughts and idea in a clear, precise manner  Follow relevant standards  Work in a team environment  Develop efficient and correct code

6. Our hopes  By the time students finish this course they should be highly employable.  Students should have a portfolio to show prospective employers to illustrate their abilities.  By the time students finish this course they should be highly employable.  Students should have a portfolio to show prospective employers to illustrate their abilities.

7. Assessment  Assessment is based on:  Project (60%)  Quizzes (5%)  Midterm exam (25%)  Final evaluation (10%)  A serious attempt must be may at each component.  At least 2 of the quizzes must be attempted.  Assessment is based on:  Project (60%)  Quizzes (5%)  Midterm exam (25%)  Final evaluation (10%)  A serious attempt must be may at each component.  At least 2 of the quizzes must be attempted.

8. Resources available  Web pages found at www.cs.montana.edu/courses/current/451.  Visit the web pages often and check for updates.  You will find:  Lecture plan with links to the lecture slides  Assessment criteria  Expectations and Objectives  Web pages found at www.cs.montana.edu/courses/current/451.  Visit the web pages often and check for updates.  You will find:  Lecture plan with links to the lecture slides  Assessment criteria  Expectations and Objectives

9. Textbooks  There are no fixed textbooks for this course.  We recommend the following as good books that cover the majority (but not all) of the lecture material.  Roger Pressman, “Software Engineering. A Practitioner’s Approach”, McGraw-Hill  Ian Sommerville, “Software Engineering”, Addison- Wesley  Stephen Schach, “Classical and Object-Oriented Software Engineering”, McGraw-Hill  Shari Pfleeger, “Software Engineering. Theory and Practice”, Prentice-Hall  Erich Gamma et al, “Design Patterns. Elements of Reusable Object-Oriented Systems”, Addison- Wesley.  There are no fixed textbooks for this course.  We recommend the following as good books that cover the majority (but not all) of the lecture material.  Roger Pressman, “Software Engineering. A Practitioner’s Approach”, McGraw-Hill  Ian Sommerville, “Software Engineering”, Addison- Wesley  Stephen Schach, “Classical and Object-Oriented Software Engineering”, McGraw-Hill  Shari Pfleeger, “Software Engineering. Theory and Practice”, Prentice-Hall  Erich Gamma et al, “Design Patterns. Elements of Reusable Object-Oriented Systems”, Addison- Wesley.

10. Our expectations of you  Ask questions  Interact with the instructors  Use each other as a resource  Exchange ideas  Experiment  Contribute to your group  You should take notes in lectures – the slides are merely our notes and may sometime be terse!  Ask questions  Interact with the instructors  Use each other as a resource  Exchange ideas  Experiment  Contribute to your group  You should take notes in lectures – the slides are merely our notes and may sometime be terse!

11. Workload  This is a 4 credit course. It should therefore occupy about 10 hours of your time each week.  Lectures occupy 3 hours/week, which leaves about 7 hours/week on your project.  You should expect to spend about 140 hours on this course over the Spring semester.  This is a 4 credit course. It should therefore occupy about 10 hours of your time each week.  Lectures occupy 3 hours/week, which leaves about 7 hours/week on your project.  You should expect to spend about 140 hours on this course over the Spring semester.

12. Deadlines  The project has a number of deadlines.  These are firm deadlines and significant grades are lost for being late – 20% of the available marks each day or part thereof.  Very much like a penalty clause in a contract.  Deadlines will be at a specific times and late penalties applies from 1 second past the deadline. The system clock on esus will be treated as the official clock for the course.  No excuses will be accepted – including machine failure, busy labs, …  It might sound draconian, but that is the way it often works in the corporate world.  The project has a number of deadlines.  These are firm deadlines and significant grades are lost for being late – 20% of the available marks each day or part thereof.  Very much like a penalty clause in a contract.  Deadlines will be at a specific times and late penalties applies from 1 second past the deadline. The system clock on esus will be treated as the official clock for the course.  No excuses will be accepted – including machine failure, busy labs, …  It might sound draconian, but that is the way it often works in the corporate world.

13. Hint  “Design for change” should be your mantra.  Expect it, plan for it, design for it.  Things are likely to change as you progress through the semester.  Expect the unexpected - prepare and plan for it.  “Design for change” should be your mantra.  Expect it, plan for it, design for it.  Things are likely to change as you progress through the semester.  Expect the unexpected - prepare and plan for it.

14. Drop/Add  We will not take new students into the course after the second week of classes.  If you are going to drop the subject, do it now. You will be assigned to a group shortly and dropping the subject after that time will leave your group short of manpower (and you won’t be popular).  If you plan to drop the subject, please E-mail both Ray (babcock@cs.montana.edu) and Michael (michael@cs.montana.edu) so that we know what is going on.  We will not take new students into the course after the second week of classes.  If you are going to drop the subject, do it now. You will be assigned to a group shortly and dropping the subject after that time will leave your group short of manpower (and you won’t be popular).  If you plan to drop the subject, please E-mail both Ray (babcock@cs.montana.edu) and Michael (michael@cs.montana.edu) so that we know what is going on.

15. Problems for Software Engineers  Dealing with large systems.  Software complexity.  Project complexity.  Interactions with clients.  Coding and management.  Meeting deadlines.  Organizational problems.  Cost overruns.  Deficiencies of current software engineering practice:  Lack of good metrics and measurement tools.  Lack of standards.  You will probably meet all of these in the project!  Dealing with large systems.  Software complexity.  Project complexity.  Interactions with clients.  Coding and management.  Meeting deadlines.  Organizational problems.  Cost overruns.  Deficiencies of current software engineering practice:  Lack of good metrics and measurement tools.  Lack of standards.  You will probably meet all of these in the project!

16. Project  The project is challenging and large.  It is probably almost certainly larger than you should tackle over a semester.  You need to determine what is important and what you can reasonably accomplish.  The project is open-ended.  We expect each solution will be different  It is a group-based project and you will need to cooperate with your group members.  The project is challenging and large.  It is probably almost certainly larger than you should tackle over a semester.  You need to determine what is important and what you can reasonably accomplish.  The project is open-ended.  We expect each solution will be different  It is a group-based project and you will need to cooperate with your group members.

17. Group-based  Everybody has to contribute to all aspects of the project.  You should not let your team down through poor performance on your behalf.  At the end of the project, each group member will need to inform the instructors what the effort distribution was across the group. The group project mark will be distributed across individuals in a manner consistent with the effort each member put into the project.  If you let your group down through lack of performance during the semester, it will be reflected in your grade!  Everybody has to contribute to all aspects of the project.  You should not let your team down through poor performance on your behalf.  At the end of the project, each group member will need to inform the instructors what the effort distribution was across the group. The group project mark will be distributed across individuals in a manner consistent with the effort each member put into the project.  If you let your group down through lack of performance during the semester, it will be reflected in your grade!

18. Project deliverables  This subject involves a substantial project which may require artifacts to be produced:  Requirements document  Functional specification  Demonstration and evaluation  User manual  Minutes of meetings  Complete details and deadlines will be provided at a later date.  This subject involves a substantial project which may require artifacts to be produced:  Requirements document  Functional specification  Demonstration and evaluation  User manual  Minutes of meetings  Complete details and deadlines will be provided at a later date.

19. Project Outline  This is an opportunity to discuss the project, to clarify what we intend and to help shape the project description (which will be handed out shortly).  In this project you will work in small groups.  The project is large and challenging.  You will need to decide what is important.  You will need to decide what to tackle.  You will need to work consistently throughout the semester.  You will need to plan.  You will need to put your software engineering skills to use.  This is an opportunity to discuss the project, to clarify what we intend and to help shape the project description (which will be handed out shortly).  In this project you will work in small groups.  The project is large and challenging.  You will need to decide what is important.  You will need to decide what to tackle.  You will need to work consistently throughout the semester.  You will need to plan.  You will need to put your software engineering skills to use.

20. Project Outline  Scenario:  You work for a small company that would like to develop a new product line – a merger of an iPod-like device with a conventional PDA, running linux as its operating system.  The organization intends to target a linux-based platform.  You may not download software for any part of the system since the organization is concerned about the surrounding issues.  You (and your team) have been asked to develop a prototype proof-of-concept system to show that it can be done. This will be used for market research and needs to be “industrial-strength”.  The system is due by mid-April.  Scenario:  You work for a small company that would like to develop a new product line – a merger of an iPod-like device with a conventional PDA, running linux as its operating system.  The organization intends to target a linux-based platform.  You may not download software for any part of the system since the organization is concerned about the surrounding issues.  You (and your team) have been asked to develop a prototype proof-of-concept system to show that it can be done. This will be used for market research and needs to be “industrial-strength”.  The system is due by mid-April.

21. Project Outline  Constraints and restrictions:  You may use any programming language available on esus (the target platform).  You must produce a Makefile which will allow us to build the system (remember to be careful as our PATH may be different to yours).  The system developed must be robust and reliable.  You will need to use assertions, pre-conditions and post-conditions in the code.  Exception handlers should be used where appropriate.  Constraints and restrictions:  You may use any programming language available on esus (the target platform).  You must produce a Makefile which will allow us to build the system (remember to be careful as our PATH may be different to yours).  The system developed must be robust and reliable.  You will need to use assertions, pre-conditions and post-conditions in the code.  Exception handlers should be used where appropriate.

22. Project Outline  Constraints and restrictions:  You (and your team) are new employees and have much to prove during your probationary period.  You will need to meet with the instructors for 30 minutes every 2 weeks to provide progress updates, and clarify any questions you might have.  Constraints and restrictions:  You (and your team) are new employees and have much to prove during your probationary period.  You will need to meet with the instructors for 30 minutes every 2 weeks to provide progress updates, and clarify any questions you might have.

23. Project Outline  You need to follow best practices.  You should make use of appropriate design patterns.  You should make sure your code is extensible and flexible.  The code needs to be efficient.  Portability is not a major issue since the software is being targeted for a specific platform (will the company expand the list of target architectures in the future?).  You have fixed deadlines that need to be met.  You are aiming to produce a useable prototype as a proof of concept, not necessarily the complete product.  The product must be carefully and thoroughly tested.  You need to follow best practices.  You should make use of appropriate design patterns.  You should make sure your code is extensible and flexible.  The code needs to be efficient.  Portability is not a major issue since the software is being targeted for a specific platform (will the company expand the list of target architectures in the future?).  You have fixed deadlines that need to be met.  You are aiming to produce a useable prototype as a proof of concept, not necessarily the complete product.  The product must be carefully and thoroughly tested.

24. Project Outline  The complete project overview (remember that there is more to this than you can achieve in one semester).  The organization wants to build a device with the functionality of a PDA (personal digital assistant) with features such as calendar, TO-DO list, contact list, search facility and an iPod which enables music and MPEG movies to be downloaded and played back later. Music, videos and other calendar elements should be searchable. Users should be able to set an alarm to wake up to their favorite music playlist, or to wake up to random tunes etc.  The complete project overview (remember that there is more to this than you can achieve in one semester).  The organization wants to build a device with the functionality of a PDA (personal digital assistant) with features such as calendar, TO-DO list, contact list, search facility and an iPod which enables music and MPEG movies to be downloaded and played back later. Music, videos and other calendar elements should be searchable. Users should be able to set an alarm to wake up to their favorite music playlist, or to wake up to random tunes etc.

25. Project Outline  Groups are given a lot of flexibility in this project. It provides you with the chance to design a system, document it, work with clients (Ray and Michael) to deliver a robust, correct, and efficient software prototype.  Aim to produce a system that could, if desired, incorporate functionality that would be nice, but you simply do not have time for this semester.  Time management and group-cooperation are important.  Groups are given a lot of flexibility in this project. It provides you with the chance to design a system, document it, work with clients (Ray and Michael) to deliver a robust, correct, and efficient software prototype.  Aim to produce a system that could, if desired, incorporate functionality that would be nice, but you simply do not have time for this semester.  Time management and group-cooperation are important.