fall 2015cisc/cmpe320 - prof. mcleod1 cisc/cmpe320 assignment 1 due today, 7pm. rad due next friday...

Fall 2015 CISC/CMPE320 - Prof. McLeod 1

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.


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.


Where are the Errors Made?

Relative Numbers of Errors Made

50%

33%

17%

Design

Programming Logic

Programming Syntax


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”:


Development Costs

Relative Costs of Software Development

3% 3% 5%7%

8%

7%67%

Specification

Requirements

Design

Coding

Unit Testing

System Testing

Maintenance


Development Times

Relative Time Consumption

33%

17%25%

25%

Design

Coding

Unit Testing

System Testing


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!


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…)

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.



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.

Use Case Diagram

• One of the simpler UML (“Unified Modeling Language”) diagrams.

• Next slide for an example from the FRIEND system:



FieldOfficer Dispatcher

ReportEmergencyAllocateResources

OpenIncident

<<initiate>>

<<initiate>>

<<initiate>>

<<parti

cipate

>>

ConnectionDown

ViewMap

<<ex

tend

>>

<<

incl

ude>

>

<<include>>


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.


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


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…



• 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?



• 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?



• 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?



• 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?

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.


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. mcleod1 cisc/cmpe320 assignment 1 due today, 7pm. rad due next friday...

Documents