Notes #3 - Systems (Software) Development Life Cycle

8/9/2019 Notes #3 - Systems (Software) Development Life Cycle

1/7

Systems Development Life Cycle

1. Systems Planninga. Preliminary Investigation

i. Strategic Planningii. Evaluation of systems requests

1. systems review2. evaluation of projects3. determining feasibility

iii. Understanding Problem / Opportunityiv. Define project scope & constraintsv. Perform fact findingvi. Determine feasibilityvii. Estimate time and costviii. Presentation of results and recommendations

2. Systems Analysisa. Requirements modeling

i. Systems requirements checklist1. inputs2. outputs3. processes4. performance5. controls

ii. Scalability and total cost of ownershipiii. Fact finding (interviews)

1. Who2. What

3. How4. When5. Where

b. Data and process modelingi. DFDsii. Data Dictionary data elements, stores, flows etciii. Process descriptionsiv. Logical and physical modeling

c. Object Modelingi. Object orientationii. Relationships

iii. Object flow integrationd. Transition to Systems Design

i. Evaluating software alternativesii. Completion of systems analysisiii. Prototyping strategyiv. Forwarding for coding

3. Systems Designa. User interface and Input/Output designb. Data designc. Application architecture

4. Systems Implementationa. Application Development

i. Coding

Q6 (A) 2009

Q1 (A) 2007

Q7 (A) 2006


2/7

ii. Integratingiii. Lab Testingiv. Quality assurance and warrantiesv. Documentationvi. Approval

b. Installation and Evaluation

i. Trainingii. System Changeover1. Direct Cutover2. Parallel operation3. Pilot operation4. Phased operation

iii. Post-implementation tasks Evaluationiv. Final report generation and presentation

5. Systems Operations and Supporta. Systems Operation and support

i. Maintenance activities

1. corrective2. adoptive3. perfective4. preventive

ii. Managing system performanceiii. System tweakingiv. System obsolescence management

6. Add-on / New requirement monitoring


3/7

Build prototypesystem

Develop abstractspecification

Use prototypesystem

Deliversystem

Systemadequate?

YES

N

System Development methodologies / models

Prototype

The software development team, to clarify requirements and/or designelements, may generate mockups and prototypes of screens, reports, and

processes. Although some of the prototypes may appear to be very substantial,they're generally similar to a movie set: everything looks good from the frontbut there's nothing in the back.When a prototype is generated, the developer produces the minimum amountof code necessary to clarify the requirements or design elements underconsideration. No effort is made to comply with coding standards, providerobust error management, or integrate with other database tables or modules.As a result, it is generally more expensive to retrofit a prototype with thenecessary elements to produce a production module then it is to develop themodule from scratch using the final system design document.For these reasons, prototypes are never intended for business use, and aregenerally crippled in one way or another to prevent them from being mistakenlyused as production modules by end-users.

The objective ofevolutionaryprototyping is to deliver aworking system to end-users. The development starts withthose requirements which arebest understood.

o Must be used for

systems where thespecification cannot bedeveloped in advance

o Based on techniques which allow rapid system iterations

o Verification is impossible as there is no specification. Validationmeans demonstrating the adequacy of the system

o Specification, design and implementation are inter-twined

o The system is developed as a series of increments that are

delivered to the customero Techniques for rapid system development are used such as CASE

tools and 4GLso User interfaces are usually developed using a GUI development

toolkit

The objective ofthrow-awayprototyping is to validate orderive the systemrequirements. The prototypingprocess starts with thoserequirements which are poorlyunderstood

o Used to reducerequirements risk

Outline

requirements

Develop

prototype

Evaluate

prototype

Specify

system

Developsoftware

Validatesystem

Deliveredsoftwaresystem

Reusablecomponents

Q1 (B) 2007

Q7 (B) - 2006


4/7

o The prototype is developed from an initial specification, deliveredfor experiment then discarded

o The throw-away prototype should NOT be considered as a final

system

Some system characteristics may have been left out

There is no specification for long-term maintenance

The system will be poorly structured and difficult to maintainRapid Application Development (RAD) / prototyping Lifecycle

RAD is, in essence, the try before you buy approach to software development.The theory is that end users can produce better feedback when examining a livesystem, as opposed to working strictly with documentation. RAD-baseddevelopment cycles have resulted in a lower level of rejection when theapplication is placed into production, but this success most often comes at theexpense of a dramatic overruns in project costs and schedule.The RAD approach was made possible with significant advances in softwaredevelopment environments to allow rapid generation and change of screens andother user interface features. The end user is allowed to work with the screensonline, as if in a production environment. This leaves little to the imagination,and a significant number of errors are caught using this process.The down side to RAD is the propensity of the end user to force scope creep intothe development effort. Since it seems so easy for the developer to produce thebasic screen, it must be just as easy to add a widget or two. In most RADlifecycle failures, the end users and developers were caught in an unendingcycle of enhancements, with the users asking for more and more and thedevelopers trying to satisfy them. The participants lost sight of the goal ofproducing a basic, useful system in favor of the siren song of glittering

perfection.For this reason, the software development team does not use a pure RADapproach, but instead blends limited prototyping in with requirements anddesign development during a conventional waterfall lifecycle. The prototypesdeveloped are specifically focused on a subset of the application, and do notprovide an integrated interface. The prototypes are used to validaterequirements and design elements, and the development of additionalrequirements or the addition of user interface options not readily supported bythe development environment is actively discouraged.

Waterfall ModelQ3 2005


5/7


6/7

Spiral LifecycleThe spiral model starts with an initial pass through a standard waterfall lifecycle,using a subset of the total requirements to develop a robust prototype. After anevaluation period, the cycle is initiated again, adding new functionality andreleasing the next prototype. This process continues, with the prototypebecoming larger and larger with each iteration. Hence, the spiral.

The theory is that the set of requirements is hierarchical in nature, withadditional functionality building on the first efforts. This is a sound practice forsystems where the entire problem is well defined from the start, such asmodeling and simulating software. Business-oriented database projects do notenjoy this advantage. Most of the functions in a database solution areessentially independent of one another, although they may make use ofcommon data. As a result, the prototype suffers from the same flaws as theprototyping lifecycle described below. For this reason, the softwaredevelopment team has decided against the use of the spiral lifecycle fordatabase projects.

System Development Initiative

Kickoff ProcessEach stage is initiated by a kickoff meeting, which can be conducted either

in person, or by Web teleconference. The purpose of the kickoff meeting isto review the output of the previous stage, go over any additional inputsrequired by that particular stage, examine the anticipated activities andrequired outputs of the current stage, review the current project schedule,and review any open issues. The PDR is responsible for preparing theagenda and materials to be presented at this meeting. All projectparticipants are invited to attend the kickoff meeting for each stage.

Informal Iteration ProcessMost of the creative work for a stage occurs here. Participants worktogether to gather additional information and refine stage inputs into draftdeliverables. Activities of this stage may include interviews, meetings, the

generation of prototypes, and electronic correspondence. All of thesecommunications are deemed informal, and are not recorded as minutes,documents of record, controlled software, or official memoranda.

Q3 2005


7/7

Formal Iteration ProcessIn this process, draft deliverables are generated for formal review and

comment. Each deliverable was introduced during the kickoff process, andis intended to satisfy one or more outputs for the current stage. Each draftdeliverable is given a version number and placed under configurationmanagement control.

In-Stage Assessment ProcessThis is the formal quality assurance review process for each stage. In asmall software development project, the deliverables for each stage aregenerally small enough that it is not cost effective to review them forcompliance with quality assurance standards before the deliverables havebeen fully developed. As a result, only one in-stage assessment isscheduled for each stage.

Stage Exit Process The stage exit is the vehicle for securing the concurrence of principalproject participants to continue with the project and move forward into thenext stage of development. The purpose of a stage exit is to allow allpersonnel involved with the project to review the current project plan andstage deliverables, provide a forum to raise issues and concerns, and toensure an acceptable action plan exists for all open issues.

Documents

Notes #3 - Systems (Software) Development Life Cycle