Professional Documents
Culture Documents
A separate planning step for large applications may be introduced after feasibility
2
Problem Definition
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
Problem Definition
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 next feasibility step Estimate roughly overall project cost to give users a sense of project scope. The estimates become more refined in later steps
Problem Definition
This step is short; lasts a day or two Proper understanding and characterization of problem essential
To discover cause of the problem To plan directed investigation Else, success is unlikely
Problem Definition
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
Do not confuse between problems and solutions e.g., develop computerized payroll cannot be a problem No commitment is implied to preliminary ideas
Feasibility Study
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
Feasibility Study
Make a formal report and present it to management and users; review here confirms the following:
Will alternatives be acceptable Are we solving the right problem Does any solution promise a significant return
10
Types of Feasibility
Economical : will returns justify the investment in the project ? Technical : is technology available to implement the alternative ? Operational : will it be operationally feasible as per rules, regulations, laws, organizational culture, union agreements, etc. ?
11
Costs
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
12
Benefits
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.
13
Benefits
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
14
Estimating Costs
How to estimate costs so early in the project?
Decompose the system and estimate costs of components; this is easier and more accurate than directly 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
15
Financial Analysis
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 of benefit
Take into account life of system: most systems have life of 5-7 years
16
Financial Analysis
Cost is investment in the project, benefits represent return Compute payback period in which we recover initial investment through accumulated benefits Payback period is expected to be less than system life ! Are there better investment alternatives?
17
3.0 Alternatives:
A presentation of alternative system specifications; criteria that were used in selecting the final approach
18
FEASIBILITY STUDY
4.0 System Description
An abbreviated version of information contained in the System-Specification or reference to the specifications
5.0 Cost-Benefit Analysis 6.0 Evaluation of Technical Risk 7.0 Legal Ramifications (if any) 8.0 Other Project-Specific Topics
19
Requirements Analysis
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
20
Requirements Analysis
A very challenging task
Users may not know exactly what is needed or how computers can bring further value to what is being done 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
21
SRS
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 not captured here become 2 to 25 times more costly to remove later
22
SRS
It identifies all functional (inputs, outputs, processing) and performance requirements, and also other important constraints (legal, social, operational) Should be adequately detailed so that Covers what and how at business level; e.g.,
Users can visualize what they will get Design and implementation can be carried out
What: calculate take-home pay How: procedure (allowances, deductions, taxes etc.)
23
Analysis Process
Interviewing clients and users essential to understand their needs from the system Often existing documents and current mode of operations can be studied Long process: needs to be organized systematically
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, business events,
24
Analysis Process
Identify users and important business entities Get functional (domain) knowledge Interview users or get details through questionnaires Examine existing system : study existing forms, outputs, records kept (files, ledgers, computerized systems) Often goes outside in : what outputs needed, which inputs provide data, what processing done, what records kept, how records updated, .. (i.e., go inwards from system boundaries)
25
Interviews
Identify users, their roles and plan interviews in proper order to collect details progressively and systematically Conducting interviews is an art !
Workout scope, durations, purpose Keep records and verify/confirm details Needs to sometimes prompt users in visualizing requirements
26
Organizing Findings
Massive amount of information is collected from interviews, study of existing systems Need to be organized, recorded, classified and conceptualized (at multiple level of details) Tools/repositories available (describe inputs, outputs, files, computations, usages, functions): help in checking consistency and completeness
27
Organizing
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 object models commonly used SRS format is great help in organizing requirements in details
28
Structured Analysis
Focuses on functions/processes and data flowing between them Uses 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 data flows for them Function Decomposition and Data Flow Diagrams (FDD, DFD) very useful
29
Structured Methodology
Study existing system: What is done and how Prepare physical current DFD Convert this DFD to logical DFD
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
30
31
32
33
5. Performance Requirements
Capacity requirements (no of users, no of files), response time, through-put (in measurable terms)
34
7 Other Requirements
Possible future extensions
Note:
All sections are not required for all projects.
35
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
36
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,
37
Design goals
Processing component: main alternatives
Hierarchical modular structure in functional approach Object-oriented model and implementation
38
System Architecture
Decompose a complex system:
Partitions (vertical) Layers (horizontal)
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
40
Notation
42
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
43
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
44
Detailed Design
Specific implementation alternative already selected in previous step giving
Overall software structure Modules to be coded Database/file design
45
Detailed Design
Deliverables include
Program specifications (e.g. psuedo-code) File design (organization, access method) Hardware specifications (as applicable) Test plans Implementation schedule
46
Implementation
Programs are coded, debugged and documented Initial creation of data files and their verification Individual modules as well as whole system is tested Operating procedures are designed User does acceptance of the system System is installed and switch-over affected
47
48
49
50
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)
51
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
52
Data Dictionary
It stores data about the following :
Data element
name, description, synonym, type, length, validation, criteria
File/data store
name, description, associated record(s), volume, access keys, file organization
53
Data Dictionary
Data flows (includes inputs and outputs)
name, description, record name, source, destinations, volume) External entities
54
Data Dictionary
Data Dictionary also stores relationships between above entities (crossreferencing info)
which programs make an application which programs use what files and how
55
CASE Tools
Computer Assisted Software Engineering (CASE) Provides a set of tools for analysis and design tasks Provides a methodology/environment for building software
56
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)
57
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)
58
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
59
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
60
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
61
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
62
63
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)
64
Report design
Report design includes
Content design
Data items, tables, aggregates (control totals), headings, charts,
Exercise: study some familiar outputs: railway ticket, LIC premium notice, Cash Receipt, Library claims,
65
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
66
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
67
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
68
70
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
71