sys dev lifecycle

7/31/2019 Sys Dev Lifecycle

1/33

System

Development LifeCycleLecture 3ByMamoon Al RasheedDepartment of CSE, SUB


2/33

System Development LifeCycle Every system has a life cycle.

An information system is born when a problem isrecognized.

After the system is developed, it grows until it reaches

maturity. Eventually, a change in the nature of the problem or

increasing maintenance costs degrade the value of thesystem, so it dies and a new or replacement systemis born to take its place.


3/33

System Development LifeCycle

System Development Life Cycle is amethodology.

A key purpose of a methodology isensuring that nothing is overlooked in the

process of solving a complex problem(such as developing a complex informationsystem).

A methodology is a body of practices,procedures, and rules used by those whowork in a discipline or engage in aninquiry.

Often, a methodology is implemented as a-


4/33

Impetus for change

New employment compensation may make itnecessary to change the reporting procedure, or filestructures.

An organization acquires another organization.

A local bank branches into the suburbs. A Department spends 80% of its budget in one month.

Two departments are doing essentially the same work,and each department head insists that the otherdepartment should be eliminated.


5/33

Impetus for change

A request for a new form discloses the use of bootlegforms.

Top management suspects various report

( suspicion of transparency ).

Heads of different departments inquire about thedelays in service delivery.

Documentation of various activities cannot be found.


6/33

System Development LifeCycleMotivation behind the feasibility study:

The risks and potential returns.

Managements bias toward the user.

Financial cost and the funds available for system work.

Priorities of other projects in the firm.

The persuasive ability of the user.


7/33

The feasibility study

It is a test of a system proposal accordingto its

workability, impact on the organization,ability to

meet user needs and effective use ofresources. It

Focuses on three major questions:

What are the users demonstrable needsand how does a candidate system meetthem?

What resources are available for given

candidate systems? Is the problem worth


8/33

The result of the feasibilitystudyIt is a proposal summarizing what is known and

what is going to be done. It consists :

Statement of the problem- a carefully wordedstatement of the problem that led to analysis.

Summary of findings and recommendations- a list of

major findings and recommendations of the study. Details of findings.

Recommendations and conclusions.


9/33

System Development LifeCycle Problem definition The first step in the system

development life cycle during which the problem isidentified, its cause determined, and a strategy forsolving it developed.

Analysis To attack a problem by breaking it into

sub-problems. The second step in the systemdevelopment life cycle (following problem definition)during which the responsible people determine exactlywhat must be done to solve the problem.


10/33

System Development LifeCycle Problem definition The first step in the

system development life cycle duringwhich the problem is identified, its causedetermined, and a strategy for solving itdeveloped.

Problem may include the duplication ofeffort, bottlenecks, inefficient existingprocedures, or whether parts of theexisting system would be candidates for

computerization.The analysts first task is to prepare astatement specifying the scope andobjective of the problem. S/he thenreviews it with the user. This may be


11/33

System Development LifeCycle

Design The third step in the system developmentlife cycle (following analysis and precedingdevelopment) during which the responsible peopledetermine how the problem will be solved by specifyingthe systems physical components.

Development The fourth step in the systemdevelopment life cycle (following design and precedingtesting) during which the system is created.

S l if


12/33

System Development LifeCycleTestingTesting The fifth step in the systemdevelopment life cycle (followingdevelopment and precedingimplementation) intended to ensure that

the system does what it was designed todo.

ImplementationImplementation The sixth step in thesystem development life cycle (following

testing and preceding maintenance)during which the system is installed andreleased to the user.

MaintenanceMaintenance The final step in thes stem develo ment life c cle followin


13/33

Question

1. Recognition of Need:

Preliminary survey/initialInvestigation

What is theproblem oropportunity ?

a. Statement ofscope andobjectives

b. Performancecriteria

2. Feasibility Studya. Evaluation of existing

system or procedure

b. Analysis of

alternative candidatesystems

c. Cost Estimates

a. What areusers

demonstrable

need?

b. Is theproblem

worth solving?

c. How can the

problem be

a. Technical/Behavioural

Feasibility

b. Cost/benefit

analysis


14/33

Stages KeyQuestion

Result

3. Analysis:

Detailed evaluation ofpresent system.

Data collection

What must be

done to solvethe problems?

Facts?

Logical model of

the system (DataFlow diagram,

Data

dictionary etc.)

4. Design (general anddetailed

specification)

a) Output b) Input

c) Files d) Procedures

How mustproblem besolved? What

is the systemflow?

Design ofalternative

Solutions

Final cost/benefit

Analysis

Hardware

specification

Cost estimates


15/33

Stages Key Question Result

5. Testing

a. Unit testingb. Combined module

testing

c. User acceptance

testing

How well do the

program/moduletest out?

How ready are

Programs for

acceptance test?

Testing plans

Security, audit andoperating

procedures

Actual hardware

useFormal system

Test

6. Implementation

User training

File/System

conversion

What is the

actualoperation?

Are the user

manual ready?

Training program

User-friendly

documentation


16/33

Stages Key Question Result

6. Post-Implementationand Maintenance

a. Problem Solvingb. Enhancements

a) Is the systemrunningproperly?

b) Should thesystem bemodified?

User requirementsmet

Satisfied User


17/33

Project Termination

A systerm project may be dropped at any time

prior to implementation although it becomes more

difficult and costly when it has passed the design

phase. Reasons may include:

Changing objectives or requirements of the usercannot be met by the existing design.

Benefits realized from the candidate system do notjustify commitment to implementation.


18/33

Project Termination

There is a sudden change in the users budget oran increase in design costs beyond the estimatemade during the feasibility study.

The project greatly exceeds the time and cost

schedule.In each case described above, a system project

may be terminated at the users request.


19/33

System failure


20/33

System failure

There are many reasons a new system does not

meet user requirements:

Users requirements were not clearly defined orunderstood.

The user was not directly involved in the crucialphases of system development.

The analyst, programmer, or both wereinexperienced.


21/33

System failure

The systems analyst (or the project team) had todo the work under stringent time limitations.Consequently, not enough went into the feasibilitystudy and system design.

User training was poor. Existing hardware proved deficient to handle the

new application.

The new system was not user-friendly.


22/33

System failure

The new system left users in other departments out of

touch with information that the old system hadprovided.

Users changed their requirements.

The user staff was hostile.

Besides these, there may be other causes. The

important point is that the analyst, with his latest

software and hardware, still needs experience,

creative ability, knowledge and support from

users.

ons era ons or can a e


23/33

ons era ons or can a esystemsThe basic problem is to match the demands

for serviceswith available resources. How much one

project is

favored over another depends on technical,behavioral

and economic factors.

Technical factors:

is the system departments ability tohandle a project.

It depends on the availability of qualified

analysts, designers and software



24/33

ons era ons or can a esystemsBehavioral factors:

The users past experience with an existing system.

The success record of the analyst.

The influence the user can exert on upper managementto finance a candidate system.

Economic factors:

The systems potential for return on investment.

Cost effectiveness of the proposed system.



25/33

ons era ons or can a esystemsPolitical factors:

Politics is the art of using influence and buildingcoalitions when routine procedures do not achieve

the right results. In developing a system one

should focus on:

convincing the right people to gather support. achieving a collaborative relationship with the end user.

anticipating resistance early and turning into support.


26/33

Prototyping

A preliminary, working, physical model of a

system or a subsystem.

The analysts objective is to gather information aboutthe users requirements from the bottom up byallowing the user to interact with the prototype.

In effect, the prototype serves as a preliminary versionof the system or component from which requirementsare extracted and on which subsequent versions arebased.


27/33

Prototyping

Prototyping is a powerful, bottom upalternative or supplement to logicalmodeling.

The basic idea is to build a reasonably

complete, working, physical model (orprototype) of the system.

As a minimum, the analyst can use screenpainters, menu builders, and reportgenerators to prepare a slide

show of sample screens, dialogues andreports.

In a more complete prototype, preliminary


28/33

Prototyping

The prototyping process can be viewed asa loop.

Following problem definition andpreliminary analysis, a first draft of theprototype is created.

The user then interacts with the prototypeand identifies its strengths andweaknesses.

Assuming that the first draft is less thantotally acceptable, the prototype ismodified to reflect the users suggestionsand the user interacts with the new,improved version.

The refine-and-test c cle continues until


29/33

Prototyping

Prototyping is iterative. The process starts with a

set of partial requirements, and new or expandedrequirements are continuously incorporated intothe system based on user feedback.

During the refine-and-test cycle, the emphasis ison quick turnaround, with changes made on thespot or within at most a few days.

Instead of conceptualizing needs, the users workwith and react to the prototype and the analystobserves and interprets their reactions.

To many people, manipulating a working modelseems more natural than answering questions inan interview or trying to link an abstract model toreality.

Sometimes, the prototyping process continuesuntil a finished system emerges.


30/33

Prototyping

Advantages:

During the analysis stage, prototyping canbe used to replace or supplement logicalmodeling, particularly when the users areuncomfortable with abstract models.

Prototyping is valuable on projects withlong development times because the usergets to see something physical.

Prototyping is an excellent tool when therequirements are highly uncertain or tooabstract to specify, or when nocomparable system has been previouslydeveloped.

Generally, if reaching a solution calls for

simulation, experimentation, or


31/33

Prototyping

Disadvantages:

Creating a large, complex system from the bottom upcan be very difficult, and integrating subsystemprototypes can prove almost impossible because thereis no clear way (short of a parallel top-down logical or

data model) to visualize subsystem relationships. Prototyping is not a good choice for algorithm-drivenprojects that involve heavy calculation.

i


32/33

Prototyping

Disadvantages:

Prototyping can bias the systems analysisprocess in subtle ways.

Because the prototype is developed on acomputer, the system will almost certainly

be implemented on a computer andmanual alternatives are unlikely to beconsidered.

Because it is a working model, people willinevitably think of the prototype as thesolution.

A related danger is that the system willnever be developed properly because theprototype seems too good.

i


33/33

Prototyping

Disadvantages:

Prototypes generally lack security,auditing, and other controls and dataintegrity may be difficult to ensure.

Additionally, prototypes are ofteninefficient and difficult to maintain. Forexample, it is difficult to trace the rippleeffects that result from modifying a

prototype, and that affects maintainability.

Economy of scale is another problem;

prototypes that

sys dev lifecycle

Documents