SDLC PHASE - DESIGN

SYSTEM DESIGN

Objective : To formulate alternatives about how the problem should be solved

Input is SRS from previous step Consider several technical alternatives based

on type of technology, automation boundaries, type of solutions (batch/on-line), including make or buy

Propose a range of alternatives : low-cost, medium cost and comprehensive high cost solutions

ALTERNATIVES For each alternative, prepare high-level

system design (in terms of architecture, DB design, …); prepare implementation schedule, carry out cost-benefit analysis

Prepare for technical and management review Costs rise sharply hereafter Costs can be quantified better at this stage Technical review uncovers errors, checks

consistency, completeness, alternatives, … Phase ends with a clear choice

DESIGN GOALS

Processing component: main alternatives Hierarchical modular structure in functional

approach Object-oriented model and implementation

Different design methodologies for functional and OO

Data component Normalized data base design using ER model De-normalization for performance Physical design : indexes

SYSTEM ARCHITECTURE

Decompose a complex system: Partitions (vertical) Layers (horizontal)

Define subsystems/modules as building blocks Modules make calls on each other

Pass data, obtain results Maximize module independence and minimize

module interdependence Cohesion and coupling characteristics Essential for maintenance

Decompose until manageable units for coding and testing obtained

STRUCTURE CHART

Used in functional methodology to depict modules and their calling relationships

Hierarchical structure: module at level i calls modules at level i+1; control flow not shown

Modules at higher levels generally do coordination and control; modules at lower levels do i/o and computations

Structure chart may show important data passing between modules, and also show main iterations and decision-making without much details

Techniques are available to go from DFD to structure charts

STRUCTURE CHART NOTATION

Modules on level 2 can be decomposed further

NOTATION …

OO APPROACH

Large systems decomposed into packages Design consists of classes

Have structure (properties) Have behavior (methods/operations) Inheritance major feature in OO for re-use

Class diagrams show static structure of the system

Interaction diagrams are used to capture dynamic behavior of classes and objects

DESIGN DOCUMENT FORMAT

1. Introduction2. Problem Specification: include here the data-flow

diagrams, entry-relationship diagrams3. Software structure: give the high-level software

structure chart identifying major modules and major data elements in their interfaces

4. Data Definitions: for major data structure, files and database

5. Module Specifications: indicate inputs, outputs, purpose and subordinate modules for each software module

6. Requirements Tracing: indicate which modules meet which requirements

DETAILED DESIGN

Specific implementation alternative already selected in previous step giving Overall software structure Modules to be coded Database/file design

In this step, each component is defined further for implementation

DETAILED DESIGN …

Deliverables include Program specifications (e.g. psuedo-code) File design (organization, access method…) Hardware specifications (as applicable) Test plans Implementation schedule

Ends in technical review

DESIGN TECHNIQUE AND TOOLS

Study issues and important parameters in design of each component Output design Input design File design Software architecture design

TECHNIQUES AND TOOLS …

Study useful techniques Data Flow Diagrams E-R Diagrams Data Dictionary Program Structure Charts Structured Programming Program Testing

Understand role of CASE tools in software development.

DATA DICTIONARY

It is a repository (i.e., catalog) of information about a system (which gets collected during various phases) Definition of data Structure of data Usage of data (in processing)

DATA DICTIONARY …

It is a very useful tools as it Permits better documentation control and

management of data about data Facilitates standardization in data usage Prevents errors, inconsistencies and redundancy

in data definitions Enables cross-referencing and check for

completeness Acts as a valuable input in analysis and design

activities and reduces development and implementation effort

DATA DICTIONARY …

It stores data about the following : Data element

name, description, synonym, type, length, validation, criteria

Record ( or group of data elements) name, description, content(data elements and/or

groups), optional elements, repeated elements(arrays) File/data store

name, description, associated record(s), volume, access keys, file organization

DATA DICTIONARY …

Data flows (includes inputs and outputs) name, description, record name, source, destinations,

volume) External entities

Programs (or, processes) Name, description, level number, frequency of execution,

programming language, author

DATA DICTIONARY …

Data Dictionary also stores relationships between above entities (cross-referencing info) which programs make an application which programs use what files and how

DD may be automated or manual Often part of CASE tool

CASE TOOLS

Computer Assisted Software Engineering (CASE) Provides a set of tools for analysis and design

tasks Provides a methodology/environment for

building software

CASE TOOLS … Benefits of CASE

Improves productivity by providing assistance in development activities

Automates tedious tasks (e.g., drawing and editing of diagrams), version management

Permits checks for consistency and completeness in data collected and development steps

Ensures uniform and consistent development methodology

Improves quality of software (as methodology is enforced and quality control can be applied)

CASE TOOLS …

CASE tool typically include: Diagramming tools to support analysis, design

and documentation Data flow diagrams E-R diagrams Program structure charts OO design

Data dictionary for gathering information and for checking consistency and completeness

Design tools (e.g., for database schema design from E-R diagrams)

CASE TOOLS …

Interface generators for defining dialogs (screens), inputs, reports, etc. (useful for prototypes)

Code generators: converting specifications into source code

Management tools: project management facilities for scheduling of activities, allocation of resources and tracking of progress

DESIGN GUIDELINES/APPROACHES

Let us review design techniques for some of the main components of a software system Database design Report design Input design in general and interactive dialogue

design in particular

DATABASE DESIGN

2-step process: logical design and physical design

Logical design: what data to be stored Examine data contained in data stores in DFD Develop thorough understanding of information

domain of the application Represent the domain by E-R diagram which

shows logical data relationships Carry out logical database design from ER

diagram Identity key fields

DATABASE DESIGN …

Physical design: decide how many files, content of each file and file organization Based on how data is accessed/processed Statistical characterization of data

CHOOSING PHYSICAL ORGANIZATION

Influential factors Activity ratio: per-cent of records processed in

one run Volatility: frequency of updates and distribution

of updates over records/fields File size and growth characteristics Access keys: fields which are used for locating

records to be processed Ordering of records for output Processing speed/response time requirement of

application

REPORT DESIGN

Obtain following details Destination: external or internal Nature of report: detailed report, summary

report, exceptional report, periodic or ad hoc report

Information need served by the report and contents of report

When, how often, and volume of output Action to be taken at destination and time-frame

for action Final disposal of report (file, destroy)

REPORT DESIGN …

Report design includes Content design

Data items, tables, aggregates (control totals), headings, charts, …

Content sequencing Content presentation

Format, editing of values, spacing, layout, … Pre-printed forms

Exercise: study some familiar outputs: railway ticket, LIC premium notice, Cash Receipt, Library claims,…

INPUT DESIGN

Objectives Data capture at source to suit the environment and

operational conditions Keep volume minimum: only capture relevant data;

capture static data only once Avoid errors; design data validation and controls

INPUT DESIGN …

Input Design Consists of Identifying input contents based on purpose Sequencing values Layout design: spacing, special boxes, etc. Including controls for validation Developing clear instructions for input

preparation

INPUT DESIGN …

Common validation criteria Type check (numeric or not) Range or limit check Consistent relationships between items Check digit Table look-up for coded items Hash totals (i.e. controls totals) Record count

Ex: study these input forms: railway reservation, IIT JEE application

INTERACTIVE DIALOG (GUI) DESIGN

Required for on-line systems Immediate response expected Dialog may contain command or data Need for security and integrity

Authorization and access control On-line data validation Provide for error correction and undoing an

action Provide on-line help Simplify interaction using special function keys

INTERACTIVE DIALOG DESIGN …

Provide hierarchical ordering of dialogs and permit users to go forwards and backwards

Dialog types: textual commands, menu based (with nested menus, ‘pull-down’ menus), natural language, or voice

This is an area of study by itself

SUMMARY

Each phase has a well defined task and a deliverable

Feasibility establishes alternatives and carries out cost-benefit analysis

Requirements analysis is very challenging and SRS forms the first baseline

Design step consists of architecture, database and interface design

Each phase ends in technical and management review