1. The Software Development Life Cycle: An Overview
Presented by
Maxwell Drew
and
Dan Kaiser
Southwest State University
Computer Science Program

2. Last Time The Requirements Process
Requirements Types and Characteristics
Expressing Requirements
Schwan’s Requirements
MSF Requirements
RUP Requirements

3. 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

4. Design The creative process of transforming a problem into a solution
A description of the solution

5. 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.

6. Stages of design Problem understanding Identify one or more solutions
Look at the problem from different angles to discover the design requirements
Identify one or more solutions
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

7. From Informal to Formal Design

8. 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?

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

10. 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

11. Design phases Architectural design Identify sub-systems
Abstract specification Specify sub-systems
Interface design Describe sub-system interfaces
Component design Decompose sub-systems into components
Data structure design Design data structures to hold problem data
Algorithm design Design algorithms for problem functions

12. 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)

13. 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

14. Landmark Paper
Wasserman, Anthony I. (1996). “Towards a discipline of software engineering.” IEEE Software, 13(6) (November):
How software engineering is different today then years ago.
Basis for effective software engineering. (Chapter 1)

15. Wasserman’s Five Ways “Modular” (Functional) decomposition
Assigning functions to components
High Level - Description of Function
Low Level - Organization and relationships
Data-oriented decomposition
External Data Structures
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

16. Wasserman’s Five Ways Outside-in design Object-oriented design
Black Box
High Level - Inputs
Low Level - What system does to input
Object-oriented design
Objects and Relationships
High Level - Object descriptions
Low Level - Object attributes, actions and relationships
All five involve some form of decomposition

17. 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.

18. 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)

19. Cost of Modularity

20. Design strategies Functional design Object-oriented 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 de-centralized and each object manages its own state. Objects may be instances of an object class and communicate by exchanging methods

21. Functional view of a compiler

22. Object-oriented view of a compiler

23. 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

24. 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

25. 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

26. Cohesion levels Coincidental cohesion (weak)
Parts of a component are simply bundled together
Logical association (weak)
Components which perform similar functions are grouped
Temporal cohesion (weak)
Components which are activated at the same time are grouped

27. Cohesion levels Procedural cohesion (weak)
The elements in a component make up a single control sequence
Communicational cohesion (medium)
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

28. Cohesion Levels Functional cohesion (strong) Object 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

29. 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

30. Tight coupling

31. Loose coupling

32. Phases in the design process

33. 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

34. 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

35. Questions?

36. Schwan’s Design Standards

38. 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.

39. 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

40. 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

41. 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. Required: Projects Optional: Support
Deliverable: Object Model Structure Chart Process Logic Specifications Conversion Specifications Final Screen Designs Final Report Designs Deliverable to: Systems Development Responsibility: Systems Development SAP Tie: 2.6–2.8

42. 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

43. 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,

44. 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

45. 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

46. Questions?