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

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

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

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

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.

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

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

... Elements of the design Entity A Entity D Entity B Entity E 1 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

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

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

Standard Hierarchical Architecture

Alternative Architectures Pipeline Hierarchical Layered DB Mediated

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

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

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

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

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

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

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

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

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.

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

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

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

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

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