1. Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Assignment 1 due tomorrow, 7pm. RAD due next Friday in your Wiki. Presentations week 6. Tomorrow’s lecture will be virtual. Today: –Overview of Software Engineering. –Agile Development. –Continue “Getting started on Design”.

2. Fall 2015CISC/CMPE320 - Prof. McLeod2 Overview of Software Engineering Developing a large program using a team of people is inherently a complex task. Software Engineering is all about reducing the complexity of this task through the application of formal methods to the project. Separate stages can be identified, but they are not always applied and not always applied in a specific order.

3. Fall 2015CISC/CMPE320 - Prof. McLeod3 Stages of Software Engineering Requirements Elicitation Analysis System Design Object Design Implementation Testing As a UML diagram on the next two slides showing logical dependencies: Key: ActionResultUML Tool

4. Fall 2015CISC/CMPE320 - Prof. McLeod4 Subsystem Decomposition System Design Object Model Analysis Object Model Non-functional requirements Requirements Elicitation Problem Statement Functional Model Analysis Dynamic Model System Design Design Goals Use Case Diagram Class Diagram Statechart Diagram Sequence Diagram

5. Fall 2015CISC/CMPE320 - Prof. McLeod5 Deliverable System Object Design Model Object Design Implementation Source Code Testing Class Diagram This is not a flowchart. The stages are not necessarily carried out in this order. No iteration or feedback is shown.

6. Fall 2015CISC/CMPE320 - Prof. McLeod6 Developing Software Various stages are involved: Here is the classic “Waterfall Model”:

7. Fall 2015CISC/CMPE320 - Prof. McLeod7 Developing Software, Cont. You won’t have time (nobody has time!) for the Waterfall Model. How about the “Spiral Model”:

8. Fall 2015CISC/CMPE320 - Prof. McLeod8 Developing Software, Cont. Considering the small size of your team and the short time you have, you will be better off employing Agile Techniques:

9. Fall 2015CISC/CMPE320 - Prof. McLeod9 The Agile “Manifesto” By Kent Beck et al (circa 2001): We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan. That is, while there’s value in the items on the right, we value the items on the left more.

10. Fall 2015CISC/CMPE320 - Prof. McLeod10 Agile Development Processes More specific processes that come under the “Agile Development” umbrella: Extreme Programming or “XP”: –Design and code at the same time. –Keep it simple. –CRC cards, prototyping, refactoring. –Pair programming. –Automated unit testing. –User acceptance testing.

11. Fall 2015CISC/CMPE320 - Prof. McLeod11 Other Agile Processes Adaptive Software Development (ASD) –A cyclic process of speculation, collaboration and learning. –Emphasizes human collaboration and self-organization. Dynamic Systems Development Method (DSDM) Scrum Crystal Feature Driven Development (FDD) Agile Modeling

12. Fall 2015CISC/CMPE320 - Prof. McLeod12 YouTube Videos Why does Agile Software Development pay?: http://www.youtube.com/watch?v=OWvSnYjqOTQ SCRUM: http://www.youtube.com/watch?v=vmGMpME_phg Look up “CrowdInteractive for a decent series on Agile Techniques.

13. Fall 2015CISC/CMPE320 - Prof. McLeod13 Rapid Prototyping Part of “Agile Development”. Show the user how his windows will look and allow him to see how he will navigate from one window to the other. It will make clear to him what information the user must supply at which stages of the operation of the software. Can be done just on paper!

14. Fall 2015CISC/CMPE320 - Prof. McLeod14 Another YouTube Video Paper Prototype Usability Test (Corel software) http://www.youtube.com/watch?v=ppnRQD06ggY

15. Fall 2015CISC/CMPE320 - Prof. McLeod15 Rapid Development Code and test what you know, leave the rest “blank” for now. Demonstrate UI prototypes to the user as soon as possible. Team members have multiple roles, so there is no “idle” time. But still, you must make sure the design is correct and that have you have addressed all possible risks and are not missing anything.

16. Fall 2015CISC/CMPE320 - Prof. McLeod16 Where are the Errors Made?

17. Fall 2015CISC/CMPE320 - Prof. McLeod17 Design Errors Large programs consist of hundreds of thousands of lines of code. A good (almost superhuman!) coder will still introduce a few code logic errors per thousand of lines of code. And, of course, C++ can tolerate errors until code is actually executed. But if the design is flawed in the first place? It costs at least 4 times as much to fix a design error than it does to fix a code logic error. Design errors also increase the “maintenance burden”:

18. Fall 2015CISC/CMPE320 - Prof. McLeod18 Development Costs

19. Fall 2015CISC/CMPE320 - Prof. McLeod19 Development Times

20. Fall 2015CISC/CMPE320 - Prof. McLeod20 Summary of Observations Coding is not the biggest part of the construction process, neither in terms of cost nor time. Design errors will greatly inflate the time for completion, the cost of development and the time and cost of maintenance. So, we should be careful with the design process!

21. Fall 2015CISC/CMPE320 - Prof. McLeod21 Douglas Adams From book 5 of the “Hitch Hiker’s Guide to the Galaxy” trilogy: “The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.” - (A warning label that should be affixed to any device, regardless of size or purpose – for the attention of the designer, not necessarily the user…)

22. Starting the Design Process From last week: –Write an Executive Summary identifying your project. –Identify the actors. –Write and collect scenarios. –Abstract many scenarios into a few Use Cases. Fall 2015CISC/CMPE320 - Prof. McLeod22

23. Fall 2015CISC/CMPE320 - Prof. McLeod23 Next Refine the use cases: –Add detail. –Make sure they are complete. –Add error conditions and exceptional circumstances. Identify relationships between use cases: –Identify dependencies. –Factor out common functionality.

24. Use Case Diagram One of the simpler UML (“Unified Modeling Language”) diagrams. Next slide for an example from the FRIEND system: Fall 2015CISC/CMPE320 - Prof. McLeod24

25. Fall 2015CISC/CMPE320 - Prof. McLeod25 FieldOfficer Dispatcher ReportEmergency AllocateResources OpenIncident > ConnectionDown ViewMap >