session 6 ppt

8/22/2019 Session 6 ppt

1/35


2/35

Preliminary Investigation Assesses feasibility and practicality of system

System Analysis Study old system and identify new requirements

Defines system from user's view

System Design

Design new/alternative system Defines system from technical view


3/35

System Development

New hardware and software is acquired, developed,

and testedSystem Implementation

System installation and training

System Operation & Maintenance Daily operation

Periodic evaluation and updating


4/35

PreliminaryInvestigation

System Operation& Maintenance

SystemAnalysis

SystemImplementationn SystemDesign

SystemDevelopment


5/35

Determine if a new system is needed

Three primary tasks: Define the problem

By observation and interview, determine what information is

needed by whom, when, where and why

Suggest alternative solutions

Prepare a short report


6/35

In depth study of the existing system todetermine what the new system should do.

Expand on data gathered in Phase 1 In addition to observation and interviews,

examine:

Formal lines of authority (org chart)

Standard operating procedures

How information flows

Reasons for any inefficiencies


7/35

Checklists - list of questions

Top-down analysis - start with top levelcomponents, break down into smaller partsthrough each successive level

Grid charts - to show relationship between

inputs and outputsSystem flowcharts - charts flow of input

data, processing, and output which showsystem elements and interactions


8/35

Complete description of current system and its

problems

Requirements for for new system including:

Subject

Scope

Objectives

Benefits

Possible development schedule


9/35

Uses specifications from the systems analysis

to design alternative systems

Evaluate alternatives based upon:

Economic feasibility - Do benefits justify costs?

Technical feasibility - Is reliable technology and

training available?

Operational feasibility - Will the managers and

users support it?


10/35

Computer-Aided Software Engineering (CASE)tools are software-based products designed tohelp automate the production of information

systems. Examples: Diagramming Tools

Data Repositories

Prototyping Tools Test Data Generators

Documentation Tools

Project Management Tools


11/35

System Design Report

Describe Alternatives including:

Inputs/Outputs

Processing

Storage and Backup

Recommend Top Alternative based upon: System Fit into the Organization

Flexibility for the future

Costs vs. benefits


12/35

Build the system to the design specifications

Develop the software

Purchase off-the-shelf software ORWrite custom software

Acquire the hardware

Test the new system

Module (unit) test - tests each part of system

Integration testing - tests system as one unit

Create manuals for users and operators


13/35

Convert from old system to new system

Train usersCompile final documentation

Evaluate the new system


14/35

Direct/plunge/crash approach entire new systemcompletely replaces entire old system, in one step

Parallel approach - both systems are operated side

by side until the new system proves itself Pilot approach - launched new system for only one

group within the business -- once new system isoperating smoothly, implementation goes company-wide

Phased/incremental approach - individual parts ofnew system are gradually phased-in over time, usingeither crash or parallel for each piece.


15/35

User Training

Ease into system, make them comfortable, and gain

their support Most commonly overlooked

Can be commenced before equipment delivery

Outside trainers sometimes used


16/35

Types of changes:

Physical repair of the system

Correction of new bugs found (corrective) System adjustments to environmental changes

Adjustments for users changing needs (adaptive)

Changes to user better techniques when they become

available (perfective)


17/35

Evaluation Methods

Systems audit - performance compared to original

specifications

Periodic evaluation - checkups from time to time,

modifications if necessary


18/35

Begin buildingnew system System converted

Users trained

Coded and

Tested System

Design Specifications

PreliminaryInvestigation

System

AnalysisSystemDesign

SystemImplementation

SystemDevelopment

SystemMaintenance

Approved Feasibility

Study

Operational System

Documentation completed

Abort Project

Goto next phase

Goto Previous phaseProblem

Specifications


19/35

Requirements definesneeded information, function,behavior, performance and

interfaces.

Design data structures,software architecture,

interface representations,

algorithmic details.

Implementation source code,database, user documentation,

testing.


20/35

Easy to understand, easy to use

Provides structure to inexperienced staff

Milestones are well understood

Sets requirements stability

Good for management control (plan,

staff, track)

Works well when quality is moreimportant than cost or schedule


21/35

All requirements must be known upfront

Deliverables created for each phase are

considered frozen inhibits flexibilityCan give a false impression of progress

Does not reflect problem-solving nature ofsoftware development iterations of phases

Integration is one big bang at the endLittle opportunity for customer to preview the

system (until it may be too late)


22/35

A variant of the Waterfall

that emphasizes the

verification and

validation of the product. Testing of the product is

planned in parallel with a

corresponding phase of

development


23/35

Project and RequirementsPlanning allocate resources

Product Requirements andSpecification Analysis completespecification of the softwaresystem

Architecture or High-Level Design defines how software functions

fulfill the design

Detailed Design developalgorithms for each architecturalcomponent

Production, operation andmaintenance provide forenhancement and corrections

System and acceptance testing check the entire software system

in its environment

Integration and Testing checkthat modules interconnectcorrectly

Unit testing check that eachmodule acts as expected

Coding transform algorithmsinto software


24/35

Emphasize planning for verification and

validation of the product in early stages of

product development

Each deliverable must be testable Project management can track progress by

milestones

Easy to use


25/35

Does not easily handle concurrent events

Does not handle iterations or phases

Does not easily handle dynamic changes in

requirementsDoes not contain risk analysis activities


26/35

Excellent choice for systems requiring highreliability hospital patient controlapplications

All requirements are known up-front

When it can be modified to handle changingrequirements beyond analysis phase

Solution and technology are known


27/35

Developers build a prototype during the

requirements phase

Prototype is evaluated by end users

Users give corrective feedbackDevelopers further refine the prototype

When the user is satisfied, the prototype

code is brought up to the standards needed

for a final product.


28/35

A preliminary project plan is developed

An partial high-level paper model is created

The model is source for a partial requirementsspecification

A prototype is built with basic and criticalattributes

The designer builds the database

user interface

algorithmic functions The designer demonstrates the prototype, the

user evaluates for problems and suggestsimprovements.

This loop continues until the user is satisfied


29/35

Requirements are unstable or have to be

clarified

As the requirements clarification stage ofa waterfall model

Develop user interfaces

Short-lived demonstrations

New, original development

With the analysis and design portions of

object-oriented development.


30/35

Customers can see the systemrequirements as they are being gathered

Developers learn from customers

A more accurate end productUnexpected requirements accommodated

Allows for flexible design anddevelopment

Steady, visible signs of progress produced Interaction with the prototype stimulates

awareness of additional neededfunctionality


31/35

Tendency to abandon structured programdevelopment for code-and-fixdevelopment

Bad reputation for quick-and-dirtymethods

Overall maintainability may beoverlooked

The customer may want the prototypedelivered.

Process may continue forever (scopecreep)


32/35

Requirements planning phase (aworkshop utilizing structured discussion ofbusiness problems)

User description phase automated tools

capture information from usersConstruction phase productivity tools,

such as code generators, screengenerators, etc. inside a time-box. (Dountil done)

Cutover phase -- installation of thesystem, user acceptance testing and usertraining


33/35

Reduced cycle time and improvedproductivity with fewer people meanslower costs

Time-box approach mitigates cost and

schedule riskCustomer involved throughout the

complete cycle minimizes risk of notachieving customer satisfaction andbusiness needs

Focus moves from documentation to code(WYSIWYG).

Uses modeling concepts to captureinformation about business, data, and

processes.


34/35

Accelerated development process mustgive quick responses to the user

Risk of never achieving closure

Hard to use with legacy systemsRequires a system that can be

modularized

Developers and customers must be

committed to rapid-fire activities in anabbreviated time frame.


35/35

Reasonably well-known requirements

User involved throughout the life cycle

Project can be time-boxed

Functionality delivered in incrementsHigh performance not required

Low technical risks

System can be modularized

session 6 ppt

Documents