sdlc phase - design
TRANSCRIPT
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