kuliah 7 pembangunan sistem maklumat dalam organisasi.pptx
Post on 20-Dec-2015
13 Views
Preview:
TRANSCRIPT
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.
top related