SDLC Phase - Design

1
SDLC Phase - Design
2
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

3
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

4
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

5
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

6
Structure Chart

• Used in functional methodology to depict modules
  and their calling relationships
• Hierarchical structure module at level i calls
  modules at level i1 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

7
Structure Chart Notation

• Modules on level 2 can be decomposed further

8
Notation
9
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

10
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

11
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

12
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

13
Design Technique and Tools

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

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

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

16
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

17
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

18
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

19
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

20
CASE Tools

• Computer Assisted Software Engineering (CASE)
• Provides a set of tools for analysis and design
  tasks
• Provides a methodology/environment for building
  software

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

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

23
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

24
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

25
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

26
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

27
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

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

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

30
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

31
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

32
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

33
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

34
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

35
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