let us review the main steps
TRANSCRIPT
-
8/14/2019 Let Us Review the Main Steps
1/71
1
-
8/14/2019 Let Us Review the Main Steps
2/71
2
Let us review the main steps
Problem Definition Feasibility Study
Analysis
System Design Detailed Design
Implementation
Maintenance
A separate planning step for large applicationsmay be introduced after feasibility
-
8/14/2019 Let Us Review the Main Steps
3/71
3
To answer: What is the Problem
Where and by whom is the problem felt?Meet users and Management and obtain their
agreement that there is a problem
If problem exists, and it needs to be solved It becomes a project
Commitment of funds implied
-
8/14/2019 Let Us Review the Main Steps
4/71
4
Prepare a brief statement of problem
Avoids misunderstandings Get concurrence from user/management
Usually short : 1 or 2 pages
Estimate cost and schedule for the nextfeasibility step
Estimate roughly overall project cost to give usersa sense of project scope. The estimates becomemore refined in later steps
-
8/14/2019 Let Us Review the Main Steps
5/71
5
This step is short; lasts a day or two
Proper understanding and characterization ofproblem essential
To discover cause of the problem
To plan directed investigation
Else, success is unlikely
-
8/14/2019 Let Us Review the Main Steps
6/716
Possible initial characterization of problems
Existing system has poor response time, i.e., it is slow
Unable to handle workload
Problem of cost: existing system uneconomical
Problem of accuracy and reliability
Requisite information is not produced by system
Problem of security
-
8/14/2019 Let Us Review the Main Steps
7/717
1. Project Title
2. Problem Statement: Concise statement ofproblem, possibly in a few lines
3. Project Objectives: state objective of the
project defined for the problem4. Preliminary Ideas: possible solutions, if any,
occurring to user and/or analyst could be
stated here.
-
8/14/2019 Let Us Review the Main Steps
8/718
5. Project Scope: give overall cost estimate asballpark figure
6. Feasibility Study: indicate time and cost for thenext step
Notes
Do not confuse between problems and solutions
e.g., develop computerized payroll cannot be aproblem
No commitment is implied to preliminary ideas
-
8/14/2019 Let Us Review the Main Steps
9/719
To get better understanding of problems and
reasons by studying existing system, if available Are there feasible solutions?
Is the problem worth solving?
Consider different alternatives Essentially covers other steps of methodology
(analysis, design, etc.) in a capsule form
Estimate costs and benefits for each alternative
-
8/14/2019 Let Us Review the Main Steps
10/7110
Make a formal report and present it to
management and users; review here confirms thefollowing:
Will alternatives be acceptable
Are we solving the right problem Does any solution promise a significant return
Users/management select an alternative
Many projects die here
-
8/14/2019 Let Us Review the Main Steps
11/71
11
Economical : will returns justify the investmentin the project ?
Technical : is technology available to implementthe alternative ?
Operational : will it be operationally feasible asper rules, regulations, laws, organizational
culture, union agreements, etc. ?
-
8/14/2019 Let Us Review the Main Steps
12/71
12
One-time (initial) costs include equipment,training, software development, consultation,site preparation
Recurring costs include salaries, supplies,maintenance, rentals, depreciation
Fixed and variable costs; vary with volume of
workload
-
8/14/2019 Let Us Review the Main Steps
13/71
13
Benefits could be tangible (i.e. quantifiable) or
intangible
Saving (tangible benefits) could include
Saving in salaries
Saving in material or inventory costs
More production
Reduction in operational costs, etc.
-
8/14/2019 Let Us Review the Main Steps
14/71
14
Intangible benefits may include
Improved customer service
Improved resource utilization
Better control over activities (such as production,inventory, finances, etc.)
Reduction in errors
Ability to handle more workload
-
8/14/2019 Let Us Review the Main Steps
15/71
15
How to estimate costs so early in the project?
Decompose the system and estimate costs ofcomponents; this is easier and more accurate thandirectly estimating cost for the whole system
Use historical data whenever available Use organization's standards for computing overhead
costs (managerial/secretarial support, space,
electricity, etc.) Personnel (for development and operations) costs are
function of time, hence estimate time first
-
8/14/2019 Let Us Review the Main Steps
16/71
16
Consider time-value of money; while investment is
today, benefits are in future!Compute present value P for future benefit F by
P = F/ (1+I)n
where I is prevailing interest rate and n is year ofbenefit
Take into account life of system: most systemshave life of 5-7 years
-
8/14/2019 Let Us Review the Main Steps
17/71
17
Cost is investment in the project, benefits
represent returnCompute payback period in which we recover
initial investment through accumulated benefits
Payback period is expected to be less thansystem life !
Are there better investment alternatives?
-
8/14/2019 Let Us Review the Main Steps
18/71
18
1.0 Introduction:
A brief statement of the problem, the environment inwhich the system is to be implemented, and constraintsthat affect the project
2.0 Management Summary and Recommendations:Important findings and recommendations
3.0 Alternatives:
A presentation of alternative system specifications;criteria that were used in selecting the final approach
FEASIBILITY STUDY
-
8/14/2019 Let Us Review the Main Steps
19/71
19
4.0 System Description
An abbreviated version of information contained inthe System-Specification or reference to thespecifications
5.0 Cost-Benefit Analysis
6.0 Evaluation of Technical Risk
7.0 Legal Ramifications (if any)8.0 Other Project-Specific Topics
-
8/14/2019 Let Us Review the Main Steps
20/71
20
Objective: determine what the system must do to
solve the problem (without describing how)
Done by Analyst (also called Requirements Analyst)
Produce Software Requirements Specifications (SRS)document
Incorrect, incomplete, inconsistent, ambiguous SRS
often cause for project failures and disputes
-
8/14/2019 Let Us Review the Main Steps
21/71
21
A very challenging task
Users may not know exactly what is needed or howcomputers can bring further value to what is beingdone today
Users change their mind over time They may have conflicting demands
They cant differentiate between what is possible and
cost-effective against what is impractical (wish-list) Analyst has no or limited domain knowledge
Often client is different from the users
-
8/14/2019 Let Us Review the Main Steps
22/71
22
SRS is basis for subsequent design and
implementation First and most important baseline
Defines contract with users
Basis for validation and acceptance
Cost increases rapidly after this step; defects notcaptured here become 2 to 25 times more costlyto remove later
-
8/14/2019 Let Us Review the Main Steps
23/71
-
8/14/2019 Let Us Review the Main Steps
24/71
24
Interviewing clients and users essential to
understand their needs from the systemOften existing documents and current mode of
operations can be studied
Long process: needs to be organizedsystematically Interviewing, correlating, identifying gaps, and
iterating again for more details Focus on what gets done or needs to be done
Focus on business entities, their interactions, businessevents,
Analysis Process
-
8/14/2019 Let Us Review the Main Steps
25/71
-
8/14/2019 Let Us Review the Main Steps
26/71
26
Identify users, their roles and plan interviews in
proper order to collect details progressively andsystematically
Conducting interviews is an art !
Workout scope, durations, purpose
Keep records and verify/confirm details
Needs to sometimes prompt users in visualizing
requirements
Need good communication skills, domainknowledge, patience,
-
8/14/2019 Let Us Review the Main Steps
27/71
27
Massive amount of information is collected from
interviews, study of existing systems
Need to be organized, recorded, classified andconceptualized (at multiple level of details)
Tools/repositories available (describe inputs,outputs, files, computations, usages, functions):
help in checking consistency and completeness
-
8/14/2019 Let Us Review the Main Steps
28/71
28
Create models or projections from different
perspectives Way to handle complexity (divide-and-conquer)
Hide unnecessary details
Reduces errors, ensures consistency/completeness
Data-flow diagrams (for processing), entity-
relationship models (for data domain) and objectmodels commonly used
SRS format is great help in organizing requirements in
details
-
8/14/2019 Let Us Review the Main Steps
29/71
29
Focuses on functions/processes and data flowing
between themUses top-down decomposition approach
Initially see the application as a single process and
identify inputs, outputs, users and data sources
Decompose the process into sub processes, show dataflows for them
Function Decomposition and Data Flow Diagrams(FDD, DFD) very useful
-
8/14/2019 Let Us Review the Main Steps
30/71
30
Study existing system: What is done and how
Prepare physical current DFDConvert this DFD to logical DFD Remove physical implementation-specific details
Define boundary for automation (scope) Prepare DFD for proposed system - requires
innovation, experience, vision
Incorporate new needs Improve work flows (BPR: business process
re-engg)
Introduce efficiency/effectiveness
-
8/14/2019 Let Us Review the Main Steps
31/71
31
(Based on IEEE Recommendation)
1. Introduction
1.1 PURPOSE: clearly state purpose of this document
1.2 SCOPE: by whom and how it will be used
1.3 Definitions: Acronyms, Abbreviations asapplicable
1.4 REFRENCES: to other documents
1.5 Overview of Developers Responsibilities: In terms ofdevelopment, installation, training, maintenance, etc.
-
8/14/2019 Let Us Review the Main Steps
32/71
32
2. GENERAL DESCRIPTION
2.1 PRODUCT PERSPECTIVE: relationship with otherproducts and principle interfaces
2.2 PRODUCT FUNCTIONS OVERVIEW: general overview
of tasks; including data flow diagrams2.3 USER CHARACTERISTICS: who they are and
what training they may need
2.4 GENERAL CONSTRAINTS: about schedule,resources, cost, etc.
-
8/14/2019 Let Us Review the Main Steps
33/71
33
3.1 FUNCTIONAL REQUIREMENT
3.1.1 INTRODUCTION
3.1.2 INPUTS
3.1.3 PROCESSING
3.1.4 OUTPUTS
3.2.. (repeat similarly for each function)
-
8/14/2019 Let Us Review the Main Steps
34/71
34
4. External Interface Requirements
4.1 User Interfaces: a preliminary user manualgiving commands, screen formats, outputs,errors messages, etc.
4.2 Hardware Interfaces: with existing as well as newor special purpose hardware
4.3 Software Interfaces: with other software packages,
operating systems, etc.5. Performance Requirements
Capacity requirements (no of users, no of files),
response time, through-put (in measurable terms)
-
8/14/2019 Let Us Review the Main Steps
35/71
35
6. Design Constraints
6.1 Standards Compliance: software developmentstandards as well as organizational standards(e.g., for reports, auditing)
6.2 Hardware Limitations: available machines, `operating systems, storage capacities, etc.
7 Other Requirements
Possible future extensionsNote:
All sections are not required for all projects.
-
8/14/2019 Let Us Review the Main Steps
36/71
36
Objective : To formulate alternatives abouthow the problem should be solved
Input is SRS from previous step
Consider several technical alternatives based
on type of technology, automationboundaries, type of solutions (batch/on-line), including make or buy
Propose a range of alternatives : low-cost,medium cost and comprehensive high costsolutions
-
8/14/2019 Let Us Review the Main Steps
37/71
37
For each alternative, prepare high-levelsystem design (in terms of architecture, DB
design, ); prepare implementationschedule, 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, checksconsistency, completeness, alternatives,
Phase ends with a clear choice
-
8/14/2019 Let Us Review the Main Steps
38/71
38
Processing component: main alternatives
Hierarchical modular structure in functionalapproach
Object-oriented model and implementation
Different design methodologies for functionaland OO
Data component
Normalized data base design using ER model De-normalization for performance
Physical design : indexes
-
8/14/2019 Let Us Review the Main Steps
39/71
39
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 moduleinterdependence Cohesion and coupling characteristics Essential for maintenance
Decompose until manageable units for coding and
testing obtained
-
8/14/2019 Let Us Review the Main Steps
40/71
40
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 andcontrol; modules at lower levels do i/o andcomputations
Structure chart may show important data passing
between modules, and also show main iterations anddecision-making without much details
Techniques are available to go from DFD to structure
charts
-
8/14/2019 Let Us Review the Main Steps
41/71
41
Modules on level 2 can be decomposed further
-
8/14/2019 Let Us Review the Main Steps
42/71
42
-
8/14/2019 Let Us Review the Main Steps
43/71
43
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 thesystem
Interaction diagrams are used to capture dynamicbehavior of classes and objects
-
8/14/2019 Let Us Review the Main Steps
44/71
44
1. Introduction
2. Problem Specification: include here the data-flow diagrams,entry-relationship diagrams
3. Software structure: give the high-level software structurechart identifying major modules and major data elements in
their interfaces4. Data Definitions: for major data structure, files and
database
5. Module Specifications: indicate inputs, outputs, purposeand subordinate modules for each software module
6. Requirements Tracing: indicate which modules meet whichrequirements
-
8/14/2019 Let Us Review the Main Steps
45/71
45
Specific implementation alternative alreadyselected in previous step giving
Overall software structure
Modules to be coded
Database/file design In this step, each component is defined
further for implementation
-
8/14/2019 Let Us Review the Main Steps
46/71
46
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
-
8/14/2019 Let Us Review the Main Steps
47/71
47
Programs are coded, debugged and documented
Initial creation of data files and their verification
Individual modules as well as whole system istested
Operating procedures are designed
User does acceptance of the system
System is installed and switch-over affected
-
8/14/2019 Let Us Review the Main Steps
48/71
48
Systems must continue to serve user needscorrectly and continuously
Maintenance activities consist of Removing errors
Extending present functions
Adding new functions Porting to new platforms
-
8/14/2019 Let Us Review the Main Steps
49/71
49
Study issues and important parameters in design of
each component Output design
Input design
File design Software architecture design
-
8/14/2019 Let Us Review the Main Steps
50/71
50
Study useful techniques
Data Flow Diagrams
E-R Diagrams
Data Dictionary
Program Structure Charts Structured Programming
Program Testing
Understand role of CASE tools in softwaredevelopment.
-
8/14/2019 Let Us Review the Main Steps
51/71
51
It is a repository (i.e., catalog) of information about
a system (which gets collected during variousphases)
Definition of data
Structure of data Usage of data (in processing)
-
8/14/2019 Let Us Review the Main Steps
52/71
52
It is a very useful tools as it
Permits better documentation control andmanagement of data about data
Facilitates standardization in data usage
Prevents errors, inconsistencies and redundancyin data definitions
Enables cross-referencing and check forcompleteness
Acts as a valuable input in analysis and designactivities and reduces development andimplementation effort
-
8/14/2019 Let Us Review the Main Steps
53/71
53
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
-
8/14/2019 Let Us Review the Main Steps
54/71
54
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
-
8/14/2019 Let Us Review the Main Steps
55/71
55
Data Dictionary also stores relationshipsbetween above entities (cross-referencinginfo) which programs make an application
which programs use what files and how
DD may be automated or manual
Often part of CASE tool
-
8/14/2019 Let Us Review the Main Steps
56/71
56
Computer Assisted Software Engineering (CASE)
Provides a set of tools for analysis and designtasks
Provides a methodology/environment for building
software
CASE Tools
-
8/14/2019 Let Us Review the Main Steps
57/71
57
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 completenessin data collected and development steps
Ensures uniform and consistent developmentmethodology
Improves quality of software (as methodology isenforced and quality control can be applied)
-
8/14/2019 Let Us Review the Main Steps
58/71
58
CASE tool typically include:
Diagramming tools to support analysis, designand 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)
-
8/14/2019 Let Us Review the Main Steps
59/71
59
Interface generators for defining dialogs(screens), inputs, reports, etc. (useful for
prototypes) Code generators: converting specifications into
source code
Management tools: project managementfacilities for scheduling of activities, allocationof resources and tracking of progress
-
8/14/2019 Let Us Review the Main Steps
60/71
60
Let us review design techniques for some ofthe main components of a software system
Database design
Report design
Input design in general and interactive dialoguedesign in particular
-
8/14/2019 Let Us Review the Main Steps
61/71
61
2-step process: logical design and physicaldesign
Logical design: what data to be stored
Examine data contained in data stores in DFD
Develop thorough understanding of informationdomain of the application
Represent the domain by E-R diagram whichshows logical data relationships
Carry out logical database design from ERdiagram Identity key fields
-
8/14/2019 Let Us Review the Main Steps
62/71
62
Physical design: decide how many files, content ofeach file and file organization
Based on how data is accessed/processed
Statistical characterization of data
-
8/14/2019 Let Us Review the Main Steps
63/71
63
Influential factors
Activity ratio: per-cent of records processed inone run
Volatility: frequency of updates and distributionof updates over records/fields
File size and growth characteristics
Access keys: fields which are used for locatingrecords to be processed
Ordering of records for output
Processing speed/response time requirement ofapplication
-
8/14/2019 Let Us Review the Main Steps
64/71
64
Obtain following details
Destination: external or internal
Nature of report: detailed report, summaryreport, exceptional report, periodic or ad hocreport
Information need served by the report andcontents of report
When, how often, and volume of output
Action to be taken at destination and time-framefor action
Final disposal of report (file, destroy)
-
8/14/2019 Let Us Review the Main Steps
65/71
65
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, CashReceipt, Library claims,
-
8/14/2019 Let Us Review the Main Steps
66/71
66
Objectives
Data capture at source to suit the environment andoperational conditions
Keep volume minimum: only capture relevant data;capture static data only once
Avoid errors; design data validation and controls
-
8/14/2019 Let Us Review the Main Steps
67/71
67
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 inputpreparation
-
8/14/2019 Let Us Review the Main Steps
68/71
68
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
-
8/14/2019 Let Us Review the Main Steps
69/71
69
Required for on-line systems
Immediate response expectedDialog 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
-
8/14/2019 Let Us Review the Main Steps
70/71
70
Provide hierarchical ordering of dialogs and
permit users to go forwards and backwardsDialog types: textual commands, menu based
(with nested menus, pull-down menus), natural
language, or voice
This is an area of study by itself
-
8/14/2019 Let Us Review the Main Steps
71/71
Each phase has a well defined task and adeliverable
Feasibility establishes alternatives andcarries out cost-benefit analysis
Requirements analysis is very challenging andSRS forms the first baseline
Design step consists of architecture,
database and interface design Each phase ends in technical and
management review