Transcript No Slide Title

The Software Development
Life Cycle: An Overview
Presented by
Maxwell Drew
and
Dan Kaiser
Southwest State University
Computer Science Program
Last Time

The Requirements Process

Requirements Types and Characteristics

Expressing Requirements

Schwan’s Requirements

MSF Requirements

RUP Requirements
Session 4: Agenda

The design process and design methods
Design strategies including object-oriented
design and functional decomposition
Design quality attributes

Schwan’s Design Standards

Design in MSF

Design in RUP


Design

The creative process of transforming a
problem into a solution

A description of the solution
Software Design

A software design is an engineering
representation of some software
product that is to be built.

The design is the link between the
requirements specifications and the
implementation.
Stages of design

Problem understanding


Identify one or more solutions


Look at the problem from different angles to
discover the design requirements
Evaluate possible solutions and choose the
most appropriate depending on the designer's
experience and available resources
Describe solution abstractions

Use graphical, formal or other descriptive
notations to describe the components of the
design
From Informal to Formal Design
Informal
design
outline
Informal
design
More
formal
design
Finished
design
Informal or “Conceptual” design


Tells the customer what the system will do
Answers:






Where will the data come from?
What will happen to the data in the system?
What will the system look like to users?
What choices will be offered to users?
What is the timing of events?
What will the reports and screens look like?
Informal or “Conceptual” design

Characteristics of good conceptual
design




in customer language with no technical
jargon
describes system functions
independent of implementation
linked to requirements
Technical design


Tells the programmers what the system will
do
Includes:




major hardware components and their function
hierarchy and function of software components
data structures
data flow
Design phases






Architectural design Identify sub-systems
Abstract specification Specify sub-systems
Interface design Describe sub-system
interfaces
Component design Decompose subsystems into components
Data structure design Design data
structures to hold problem data
Algorithm design Design algorithms for
problem functions
Design Specification Models

Data design


created by transforming the analysis information
model (data dictionary and ERD) into data
structures required to implement the software
Architectural design

defines the relationships among the major
structural elements of the software, it is derived
from the system specification, the analysis model,
and the subsystem interactions defined in the
analysis model (DFD)
Design Specification Models

Interface design


describes how the software elements communicate
with each other, with other systems, and with
human users; the data flow and control flow
diagrams provide much the necessary information
Component-level design

created by transforming the structural elements
defined by the software architecture into
procedural descriptions of software components
Landmark Paper



Wasserman, Anthony I. (1996). “Towards a
discipline of software engineering.” IEEE
Software, 13(6) (November): 23 - 31
How software engineering is different today
then 10 - 20 years ago.
Basis for effective software engineering.
(Chapter 1)
Wasserman’s Five Ways

“Modular” (Functional) decomposition

Assigning functions to components



Data-oriented decomposition

External Data Structures



High Level - Description of Function
Low Level - Organization and relationships
High Level - General Data Structures
Low Level - Data elements and relationships
Event-oriented decomposition

Events and State Changes


High Level - Catalog of events
Low Level - State transformations
Wasserman’s Five Ways

Outside-in design

Black Box



Object-oriented design

Objects and Relationships



High Level - Inputs
Low Level - What system does to input
High Level - Object descriptions
Low Level - Object attributes, actions and relationships
All five involve some form of decomposition
Modular Decomposition


“Modularity is the single attribute of
software that allows a program to be
intellectually manageable.”
Myers, G,. Composite Structured
Design, Van Nostrand, 1978.
Managing Complexity

Let C(x) represent the perceived complexity of
problem x and E(x) represent the effort to solve
problem x.

If C(p1) > C(p2) then E(p1) > E(p2)

However, C(p1+ p2) > C(p1) + C(p2)

Hence E(p1+ p2) > E(p1) + E(p2)
Cost of Modularity
Design strategies

Functional design


The system is designed from a functional
viewpoint. The system state is centralized and
shared between the functions operating on that
state
Object-oriented design

The system is viewed as a collection of
interacting objects. The system state is decentralized and each object manages its own
state. Objects may be instances of an object
class and communicate by exchanging methods
Functional view of a compiler
Source
program
Tokens
Scan
source
Syntax
tree
Tokens
Build
symbol
table
Symbols
Symbol
table
Analyse
Symbols
Object
code
Generate
code
Error
indicator
Output
errors
Error
messages
Object-oriented view of a compiler
Scan
Source
program
Add
Token
stream
Symbol
table
Check
Syntax
tree
Get
Gr ammar
Build
Print
Generate
Object
code
Abstract
code
Generate
Err or
messages
Mixed-strategy design

Although it is sometimes suggested that one
approach to design is superior, in practice,
an object-oriented and a functional-oriented
approach to design can be complementary

Good designers should select the
most appropriate approach for whatever
sub-system is being designed
Characteristics of good design

Functional independence - modules have
high cohesion and low coupling




Cohesion - qualitative indication of the degree to
which a module focuses on just one thing
Coupling - qualitative indication of the degree to
which a module is connected to other modules
and to the outside world
Exception identification and handling
Fault prevention and tolerance


active
passive
Cohesion


Cohesion is a desirable design
component attribute as when a change
has to be made, it is localized in a
single cohesive component
Various levels of cohesion have been
identified
Cohesion levels

Coincidental cohesion (weak)


Logical association (weak)


Parts of a component are simply bundled
together
Components which perform similar functions are
grouped
Temporal cohesion (weak)

Components which are activated at the same
time are grouped
Cohesion levels

Procedural cohesion (weak)


Communicational cohesion (medium)


The elements in a component make up a single
control sequence
All the elements of a component operate on the
same input or produce the same output
Sequential cohesion (medium)

The output for one part of a component is the
input to another part
Cohesion Levels

Functional cohesion (strong)


Each part of a component is necessary for the
execution of a single function
Object cohesion (strong)

Each operation provides functionality which
allows object attributes to be modified or
inspected
Coupling

Loose coupling means component changes
are unlikely to affect other components

Shared variables or control information
exchange lead to tight coupling

Loose coupling can be achieved by state
decentralization (as in objects) and
component communication via parameters
or message passing
Tight coupling
Module A
Module C
Module B
Module D
Shared data
area
Loose coupling
Module A
A’s data
Module B
B’s data
Module D
D’s data
Module C
C’s data
Phases in the design process
Require ments
specification
Design acti
vities
Arc hitectura l
design
Abstra ct
specificatio
n
Interface
design
Component
design
Data
structure
design
Algorithm
design
System
arc hitecture
Software
specification
Interface
specification
Component
specification
Data
structure
specification
Algorithm
specification
Design pr
oducts
Design Guidelines

A design should …

exhibit good architectural structure

be modular

contain distinct representations of data, architecture,
interfaces, and components (modules)

lead to data structures that are appropriate for the
objects to be implemented and be drawn from
recognizable design patterns
Design Guidelines

A design should …



lead to components that exhibit independent
functional characteristics
lead to interfaces that reduce the complexity of
connections between modules and with the
external environment
be derived using a reputable method that is
driven by information obtained during software
requirements analysis
Questions?
Schwan’s Design
Standards
Project Design

Objective

The object of the Project Design phase
is to ensure that design alternatives are
studied, the appropriate alternative
selected and the all design issues are
dealt with before development begins.
Package Selection (410)

Objective
The objective of the
Package Selection is to
make a final decision
whether a purchased
package will be purchased
and which package has
been decided on for the
project.
Required: Projects
Optional: Support

Deliverable: Product
Specifications
Deliverable to:
Systems Development
Customer
Responsibility: Joint
Responsibility
Physical Data Model (420)

Objective
The objective of the Physical
Data Model is to produce and
finalize with the DBA’s the
Physical data model for the
proposed system. All elements
should be approved in the data
dictionary during this step.
Platform and replication issues
will be considered during this
step.
Required: Projects
Optional: Support

Deliverable: Physical Data
Model
Deliverable to:
Systems Development
Customer (Optional)
Responsibility: Systems
Development
SAP Tie: 3.2, 3.3
Design Process Structures (430)

Objective
The objective of the Design
Process structures is to design
the applications and logic
needed to meet the
specifications. Conversion plans
may need to be completed
during this step as required by
the project. Final screen designs
and report layouts will need to be
completed as well during this
step.

Deliverable:
Object Model
Structure Chart
Process Logic Specifications
Conversion Specifications
Final Screen Designs
Final Report Designs
Deliverable to: Systems
Development
Responsibility: Systems
Development
Required: Projects
SAP Tie: 2.6–2.8
Optional: Support
Create Test Plan (440)

Objective
The objective of the Test Plan is
to take the Business Test Cases
created by the Business Systems
Planning group during project
analysis and create a system test
plan to be used during the test
phase of the project development
cycle.
Required: ProjectsSupport
Optional: <None>

Deliverable: Test Plan
Deliverable to: Systems
Development
Responsibility: Systems
Development
SAP Tie: 3.1
Design Walkthrough (450)

Objective
The objective of the Design
Walkthrough is to review the
design with Business
Systems Planning and
Systems Development to
verify design meets
customer needs and IS
standards. The customer
may be involved in this
meeting if appropriate.
Required: Projects
Optional: Support

Deliverable: Walkthrough
Form
Deliverable to:
Business Systems Planning
Systems Development
Responsibility: Systems
Development
SAP Tie: 2.10, 3.12-4.1
Finalize Hardware Requirements (460)

Objective
The objective of the
Finalize Hardware
Requirements is to
determine and receive
final approval for
purchase and Installation
of new and/or upgraded
hardware.
Required: <None>
Optional: Projects, Support

Deliverable: Hardware
Authorization forms
Deliverable to:
Business Systems Planning
Systems Development
IS Operations
Responsibility: Joint
Responsibility
Statement of Work (470)

Objective
The objective of the
Statement of Work during
Project Design is to create
the Statement of Work for
coding if not included in
the design SOW.
Required: <None>
Optional: Projects Support

Deliverable:
Statement of Work
Project Plan
Expenditure Form(s) (if needed)
Deliverable to:
Business Systems Planning
Systems Development
Customer
Responsibility: Business Systems
Planning
SAP Tie: 2.9
Questions?