1. Systems Development Lifecycle
Project Identification & Selection
Project Initiation & Planning
Analysis
Logical Design
Physical Design
Implementation
Maintenance

2. Four parts to a system design
System architecture
Interface design
Database design
Process design

3. Where to start? Two schools of thought:
evolution: start with current system and identify changes
revolution: start from scratch
Either way, there are two approaches to modeling:
data-driven - identify relevant data first
process-driven - identify relevant functions first

4. System Modeling Approaches
Data-driven:
Identify major data entities
Determine structure (attributes) of entities
Identify processes that manipulate data
Define data flows, sources, and sinks
Process-driven:
Identify major tasks
Identify the inputs and outputs to the tasks
Translate to processes and data flows
Identify data stores and external sources and sinks
Design structure of data
End Result: a Data Flow Diagram

5. Data Flow Diagrams
A structured analysis technique that employs a set of visual representations of the data that moves through the organization, the paths through which the data moves, and the processes that produce, use, and transform data.

6. Four Basic Symbols Source/ Sink Data Flow Process # Data Store #
Naming:
entities - noun
data flows - noun
high level process - system name
other processes - verb/adjective/noun
data stores - noun #
Process #
Data Store

7. A Generic Data Flow Diagram
Source A 1
Receive
Data n
Present
Data
Sink D
Output
Input
Output
Input
Source B
Sink E
Input
Data
Data
Output
Source C
Sink F 2
Process
Data 3
Process
Data
...
N-1
Process
Data D1
Data Store

8. ... Elements of the design Entity A Entity D Entity B Entity E1 n
Entity D
Output
Input
Receive
Data
Present
Data
Output
Input
Entity B
Entity E
Data
Data
Input
Output
Entity C
Entity F 2 3
...
N-1
Process
Data
Process
Data
Process
Data
Database
Process
Interface
System Architecture D1
Data Store

9. Developing the Design Elements
System architecture: set of processes in the Level 0 DFD of the proposed system (functional decomposition of system)
Process (software) design: add logic and timing to all processes on DFD (logic models)
Database design: derived from the ER diagram (conceptual data model) and data stores on the DFD
Interface design: determine form and content of all input and output data flows on DFD, as well as overall interface

10. Process Design
Designing the overall structure (architecture) of a software system
Designing small pieces of computation
Designing non-automated processes
Use DFDs as a starting point

11. Standard Hierarchical Architecture

12. Alternative Architectures
Pipeline
Hierarchical
Layered DB
Mediated

13. Modularity Factoring - breaking the system up into modules
Span of control - rule of thumb is that no module should control more than 7 subordinate modules
Reasonable size - a module should fit on a page or a screen

14. Reuse
At the lower levels of decomposition, there are often modules that performs the same function in different parts of the system
These modules can be reused in different parts of the design
Can make diagrams messy

15. Coupling Interdependence of modules 5 types:
data - communication only through well-defined passing of specific data elements
stamp - data passed is of larger granularity
control - modules affect the control flow of other modules
common - modules use common data
content - modules modify each other

16. Cohesion Degree to which a module performs a single cohesive function
7 types:
functional - ideal
sequential - functions form a chain leading from input to output
communicational - functions use the same data
procedural - functions relate through flow of control
temporal - functions happen at same time
logical - functions related by some outside criterion
coincidental - functions not related

17. Program Design
Start with one process on a DFD or module on a structure chart
Continue decomposing
Introduce concept of time
process steps
control flow
Define all decision conditions
Include error and exception conditions

18. Notations for Process Design
Control flow graphs
Decision tables
Decision graphs
Structured English (pseudocode)
4GL Specification Language
Mathematical notation

19. Control Flow Diagram Iteration Decision Control Flow Task Get Info Yes
New
Customer?
Answer
Call
Take
Order No
Get
Record
Decision
Control
Flow
Task

20. Relational Database Design
Start with a conceptual data model
determines the data entities and their structure
Create tables to hold each entity and its attributes
Create additional tables for relationships between entities
Normalize and optimize

21. Interface Design Inputs and outputs User interaction
data flows to and from external sources and sinks
data flows into and out of processes that are manual or not fully automated
User interaction
how the user communicates with the system
mechanisms for navigation, feedback, control, security, etc.

22. Input Accuracy and Efficiency
Layout
top to bottom, left to right
group related items together
separate titles from body from instructions
clear titles and captions
don’t be stingy with white space
Eliminate typing
checkboxes, pull-down menus, icons
default values
Checking accuracy
check reasonableness of combinations
predefined acceptable values
check for proper format
check for missing values

23. Assessing Usability
Can assess an entire system for usability, or just one form or report
User involvement in usability assessment is necessary
Some measures:
learning time
user speed
user accuracy
user’s ability to remember system operation
subjective assessments

24. Interaction Methods
Command language - necessary on some older systems, but pretty much outdated
Menus - most common at this point
drop-down, pop-up
Forms - good if the interaction consists of specific pieces of information
Object-based (icons) - intuitive and space-efficient, but can be designed poorly
Natural language - not there yet

25. Conventions
When designing the overall user interface, you must decide on some conventions to be used throughout the system, e.g.:
what different colors mean
what certain symbols mean
navigation mechanisms
terminology
artwork and logos

26. User Feedback Status Prompts Errors and warnings
always let the user know what’s going on
don’t let “no news be good news”
Prompts
tells the user what is expected of them
convey as much guidance as possible within reason
Errors and warnings
convey importance
suggest resolutions
be careful of jargon