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 costbenefit 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. Introduction 2. Problem Specification: include here the data-flow diagrams, entry-relationship diagrams 3. 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 name, description, content(data elements and/or groups), optional elements, repeated elements(arrays) name, description, associated record(s), volume, access keys, file organization

Record ( or group of data elements)

File/data store

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