1. Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Assignment 1 due today, 7pm. RAD due next Friday in your Wiki. Presentations week 6. Today: –Continue “Getting started on Design”. –The importance of getting the Design right! –Non-Functional requirements. –More about the RAD.

2. Fall 2015CISC/CMPE320 - Prof. McLeod2 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.

3. Fall 2015CISC/CMPE320 - Prof. McLeod3 Where are the Errors Made?

4. Fall 2015CISC/CMPE320 - Prof. McLeod4 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”:

5. Fall 2015CISC/CMPE320 - Prof. McLeod5 Development Costs

6. Fall 2015CISC/CMPE320 - Prof. McLeod6 Development Times

7. Fall 2015CISC/CMPE320 - Prof. McLeod7 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!

8. Fall 2015CISC/CMPE320 - Prof. McLeod8 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…)

9. 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. McLeod9

10. Fall 2015CISC/CMPE320 - Prof. McLeod10 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.

11. 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. McLeod11

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

13. Fall 2015CISC/CMPE320 - Prof. McLeod13 Last “First” Step Everyone agrees on the non-functional requirements: Not directly related to the functionality of the system. Things like: performance constraints, documentation, resources, security and quality.

14. Fall 2015CISC/CMPE320 - Prof. McLeod14 Non-Functional Requirements This part of the process is more qualitative, but just as important to the final design. It might help to consider several categories: –Usability –Reliability –Performance –Supportability –Implementation –Interface –Operation –Packaging –Legal

15. Fall 2015CISC/CMPE320 - Prof. McLeod15 Non-Functional Requirements, Cont. Usability –What is the ability level of user? –What interface standards are already familiar to the user? –What docs does he need? Paper, pdf, web, CD? –Will he use a help system or documentation is he an engineer…

16. Fall 2015CISC/CMPE320 - Prof. McLeod16 Non-Functional Requirements, Cont. Reliability –How reliable, available and robust? –Can it be restarted after a failure? –How much data can be lost? –How are exceptions handled? –Any safety requirements? –Any security requirements?

17. Fall 2015CISC/CMPE320 - Prof. McLeod17 Non-Functional Requirements, Cont. Performance –How responsive? –What user tasks are time critical? –How many concurrent users (now and in the future)? –How much data? –What is acceptable latency? Supportability –What extensions will be needed? –Who does the maintenance? –Ported to different environments?

18. Fall 2015CISC/CMPE320 - Prof. McLeod18 Non-Functional Requirements, Cont. Implementation –Constraints on the hardware platform? –Constraints imposed by maintenance requirements? –Constraints imposed by testing team? Interface –Required interface with existing system? –How is data imported/exported? –Existing standards already in use by client? Operation –Who will manage the system when it is operating?

19. Fall 2015CISC/CMPE320 - Prof. McLeod19 Non-Functional Requirements, Cont. Packaging –Who does the installation? –How many installations are anticipated? –How long can the installation take? Legal –How is it licensed? –What liability results from system failures? –Does the use of any components incur royalties or licensing fees?

20. Project Deliverable – the RAD: A functional description of what you are planning to build. Consider inputs and outputs and what you are trying to accomplish. A diagram might best describe these concepts. If you are building a game, what parameters are you going to adjust to ensure the playability of the game? A list of functional and non-functional requirements. A least one use case. You must have enough use cases that all of the necessary functionality is described. If you have several use cases, you will need a use case diagram to show how they relate. Fall 2015CISC/CMPE320 - Prof. McLeod20

21. Project Deliverable – the RAD, Cont.: Sketches or prototypes of the GUI interface (all windows) along with a description of how the user will navigate through the interface. A list of the roles assigned to each team member. A project plan, or time-line, for the remaining weeks you have to work on this project. A Glossary of terms used in your functional description. Write and edit the RAD in your Wiki! Create a TOC (consider putting the TOC on each page…) Fall 2015CISC/CMPE320 - Prof. McLeod21