Pembangunan Sistem Maklumat dalam Organisasi

Pengenalan kepada pembangunan sistem, Sistem bersepadu, Pembangunan sistem inter-

organisasi, Sistem berasaskan internet

Model Pembangunan Sistem MaklumatSDLC ModelWaterfall ModelV-Shaped ModelPrototypingRapid Application DevelopmentSpiral ModelConclusion

SDLC Model A framework that describes the activities

performed at each stage of a software development project.

SDLC Phases Preliminary Investigation

System Operation & Maintenance

System Analysis

SystemImplementationn

System Design

System Development

Classifications of SDLC Model

SDLC Model

Sequential Iterative

WaterfallV Model

Progressive

Sequential ModelThe models used for the software development

lifecycle have been sequential, with the development progressing through a number of well defined phases.

The sequential phases are usually represented V Model Waterfall Model.

V-Shaped SDLC ModelA 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

V-Shaped Steps Project and Requirements

Planning – allocate resources

Product Requirements and Specification Analysis – complete specification of the software system

Architecture or High-Level Design – defines how software functions fulfill the design

Detailed Design – develop algorithms for each architectural component

Coding – transform algorithms into software

Unit testing – check that each module acts as expected

Integration and Testing – check that modules interconnect correctly

System and acceptance testing – check the entire software system in its environment

Production, operation and maintenance – provide for enhancement and corrections

V-Shaped StrengthsEmphasize planning for verification and

validation of the product in early stages of product development

Each deliverable must be testableProject management can track progress by

milestonesEasy to use

V-Shaped WeaknessesDoes not easily handle concurrent eventsDoes not handle iterations or phasesDoes not easily handle dynamic changes in

requirements

When to use the V-Shaped ModelExcellent choice for systems requiring high

reliability – hospital patient control applications

All requirements are known up-frontWhen design is stable Solution and technology are known

Waterfall ModelRequirements – defines

needed information, function, behavior, performance and interfaces.

Design – data structures, software architecture, interface representations, algorithmic details.

Implementation – source code, database, user documentation, testing.

Waterfall ModelTest – check if all code

modules work together and if the system as a whole behaves as per the specifications.

Installation – deployment of system, user-training.

Maintenance – bug fixes, added functionality (an on-going process).

Deliverables of the SDLC

Begin buildingnew system

System convertedUsers trained

Coded and Tested System

Design Specifications

Preliminary Investigation

System Analysis

SystemDesign

System Implementation

System

Development

SystemMaintenance

Approved Feasibility Study

Operational System Documentation completed

Abort Project Goto next phase Goto Previous phase Problem

Specifications

Waterfall StrengthsEasy to understand, easy to useProvides structure to inexperienced staffMilestones are well understoodSets requirements stabilityGood for management control (plan, staff,

track)

Waterfall DeficienciesAll requirements must be known upfrontDeliverables created for each phase are

considered frozen – inhibits flexibilityDoes not reflect problem-solving nature of

software 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)

When to use the Waterfall ModelRequirements are very well knownWhen it is possible to produce a stable

designE.g. a new version of an existing productE.g. porting an existing product to a new

platform.

Progressive ModelA common problem with software development is that software is

needed quickly, but it will take a long time to fully develop. The solution is to form a compromise between timescales and

functionality, providing "interim" deliveries of software, with reduced functionality, but serving as a stepping stones towards the fully functional software. It is also possible to use such a stepping stone approach as a means of reducing risk.

The usual names given to this approach to software development are progressive development or phased implementation.

Within a progressive development lifecycle, each individual phase of development will follow its own software development lifecycle, typically using a V or waterfall model.

Progressive Model - Structure

Phase 1 Development

Phase 2 Development

Final Phase

Interim Delivery 1

Interim Delivery 2

Final Delivery 2

Iterative ModelRequirements Design

Implementation and Test

Review

An iterative lifecycle model does not attempt to start with a full specification of requirements.

Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements.

This process is then repeated, producing a new version of the software for each cycle of the model.

Iterative Model - Phases Requirements phase, in which the requirements for the

software are gathered and analyzed. Iteration should eventually result in a requirements phase which produces a complete and final specification of requirements.

Design phase, in which a software solution to meet the requirements is designed. This may be a new design, or an extension of an earlier design.

Implementation and Test phase, when the software is coded, integrated and tested.

Review phase - in which the software is evaluated, the current requirements are reviewed, and changes and additions to requirements proposed

Prototyping ModelDevelopers build a prototype during the

requirements phasePrototype is evaluated by end usersUsers give corrective feedback Developers further refine the prototypeWhen the user is satisfied, the prototype code

is brought up to the standards needed for a final product.

Prototyping StepsA preliminary project plan is developedAn partial high-level paper model is createdThe model is source for a partial requirements

specificationA prototype is built with basic and critical

functionsThe designer builds

the database user interface algorithmic functions

The designer demonstrates the prototype, the user evaluates for problems and suggests improvements.

This loop continues until the user is satisfied

Prototyping Strengths

Customers can “see” the system requirements as they are being gathered

Developers learn from customers A more accurate end productUnexpected requirements accommodatedAllows for flexible design and developmentSteady, visible signs of progress producedInteraction with the prototype stimulates

awareness of additional needed functionality

Prototyping WeaknessesTendency to abandon structured program

development for “code-and-fix” development

Bad reputation for “quick-and-dirty” methods

Overall maintainability may be overlookedProcess may continue forever (scope

creep)

When to use PrototypingRequirements are unstable or have to be

clarified As the requirements clarification stage of

a waterfall modelDevelop user interfacesNew, original development

Rapid Application Development Model (RAD)Requirements planning phase (a

workshop utilizing structured discussion of business problems)

User design phase – users to participate in the nontechnical design of the system

Construction phase – productivity tools, such as code generators, screen generators.

Cutover phase -- installation of the system, user acceptance testing and user training

Rapid Application Development Model (RAD)

Requirements planning phase

User design phase

Construction phase

Cutover phase

Pro

totyp

ing

RAD StrengthsReduced cycle time and improved

productivity with fewer people means lower costs

Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs

Focus moves from documentation to codeUses modeling concepts to capture

information about business, data, and processes.

RAD WeaknessesAccelerated development process must give

quick responses to the userRisk of never achieving closure Hard to use with legacy systemsRequires a system that can be modularizedDevelopers and customers must be committed

to rapid-fire activities in an abbreviated time frame.

May compromises functionality and performance in exchange for faster development and better application maintenance

When to use RADWhen requirements are not fully understood.User involved throughout the life cycleFunctionality delivered in incrementsHigh performance not requiredSystem can be modularized

Incremental SDLC ModelConstruct a partial

implementation of a total system

Then slowly add increased functionality

The incremental model prioritizes requirements of the system and then implements them in groups.

Each subsequent release of the system adds functions to the previous release, until all designed functionality has been implemented.

Incremental Model Strengths Develop high-risk or major functions firstEach release delivers an operational

product Customer can respond to each buildUses “divide and conquer” breakdown of

tasksLowers initial delivery cost Initial product delivery is fasterCustomers get important functionality early

Incremental Model Weaknesses Requires good planning and designRequires early definition of a complete and

fully functional system to allow for the definition of increments

Well-defined module interfaces are required (some will be developed long before others)

Total cost of the complete system is not lower

When to use the Incremental Model Most of the requirements are known up-

front but are expected to evolve over timeA need to get basic functionality to the

market earlyOn projects which have lengthy

development schedules

Spiral SDLC ModelAdds risk analysis,

and 4gl RAD prototyping to the waterfall model

Each cycle involves the same sequence of steps as the waterfall process model

Spiral QuadrantDetermine objectives, alternatives and constraints

Objectives: functionality, performance, hardware/software interface, critical success factors, etc.

Alternatives: build, reuse, buy, sub-contract, etc.Constraints: cost, schedule, man-power,

experience etc.

Spiral QuadrantEvaluate alternatives, identify and resolve risks Study alternatives relative to objectives and

constraintsIdentify risks (lack of experience, new technology,

tight schedules, etc.)Resolve risks

Spiral QuadrantDevelop next-level productTypical activites:

Create a designReview designDevelop codeInspect codeTest product

Spiral QuadrantPlan next phaseTypical activities

Develop project planDevelop a test planDevelop an installation plan

Spiral Model StrengthsProvides early indication of

insurmountable risks, without much costUsers see the system early because of

rapid prototyping toolsCritical high-risk functions are developed

firstUsers can be closely tied to all lifecycle

stepsEarly and frequent feedback from users

Spiral Model WeaknessesTime spent for evaluating risks too large

for small or low-risk projectsTime spent planning, resetting objectives,

doing risk analysis and prototyping may be excessive

The model is complex Risk assessment expertise is requiredSpiral may continue indefinitelyDevelopers must be reassigned during

non-development phase activities

When to use Spiral ModelWhen creation of a prototype is

appropriateWhen costs and risk evaluation is

importantFor medium to high-risk projectsUsers are unsure of their needsRequirements are complexNew product line Significant changes are expected

Tailored SDLC ModelsNo single model fits all projectsIf there is no suitable model for a

particular project, pick a model that comes close and modify it for your needs.If project should consider risk but complete

spiral model is too much – start with spiral and simplify it

If project should be delivered in increments but there are serious reliability issues – combine incremental model with the V-shaped model

Each team must pick or customize a SDLC model to fit its project

Lifecycle Models

Build-and-fixdevelop system

without specs or designmodify until customer is

satisfiedWhy doesn’t build-and-fix scale?

changes during maintenancemost expensive!

Relative Costs of Phases

Maintenance (67%)Requirements (2%)

Specification (5%)

Design (6%)

Module coding (5%)

Module testing (7%)Integration (8%)

Incremental Model

Divide project into builds each adds new functions each build integrated w/ structure &

product tested as a whole Advantages ?

operation product in weeks less traumatic to organization smaller capital outlay

Disadvantages ? need an open architecture

a big advantage come maintenance! too few builds build-and-fix too many builds overhead

Verify

Requirements

phase

Verify

Specification

phase

Verify

Architectural

design

Operations mode

Development

MaintenanceRetirement

Perform detailed

design, imple-

mentation, and

integration. Test.

Deliver to client.

For each build:

Quality – the degree to which the software satisfies stated and implied requirementsAbsence of system crashesCorrespondence between the software and the

users’ expectationsAdherence to specified requirements

Quality must be controlled because it lowers production speed, increases maintenance costs and can adversely affect business

the good enough is enemy of the excellent

Quality Assurance Plan

The plan for quality assurance activities should be in writing so all stakeholders can review it during the lifecycle.

Some elements that should be considered by the plan are: defect tracking, unit testing, source-code tracking, integration testing and system testing.

Quality Assurance PlanDefect tracing – keeps track of each defect found,

its source, when it was detected, when it was resolved, how it was resolved, etc

Unit testing – each individual module is testedSource code tracing – step through source code

line by lineIntegration testing - test new code in

combination with code that already has been integrated

System testing – execution of the software for the purpose of finding defects.

ConclusionSDLC

A framework that describes the activities performed at each stage of a software development project.

Waterfall and V-Shaped and Incremental models need requirements to be known up-front.E.g. when creating new versions of existing systems.

Prototyping, RAD and Spiral models do not need all requirements to be knownE.g. New systems. Uses series of prototypes that evolve into the

finished system.