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

From Informal to Formal 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 sub-systems 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 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

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

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

Functional view of a compiler

Object-oriented view of a compiler

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

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

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

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

Loose coupling

Phases in the design process

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

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?