www.hndit.com
IT2005
System Analysis &
Design
Week 5 & 6 -Major Components of Systems Development
1
www.hndit.com
Major components of system
development
1. Methodology
2. Modeling Methods or Techniques
3. Tools
2
www.hndit.com
Methodology
• A very formal and accurate system
development process that defines a set of
– Activities
– Methods
– Best practices
– Deliverables
– Automated tools
Methodology
Methods
Tools
Or Techniques
3
www.hndit.com
Methodology..
Provides the framework
1. Has a predefined set of steps
2. Ensures that systems are built in the most
effective way
Eg:
SSADM (structured methodologies)
STRADIS (Structured Analysis, Design and
Implementation of Information Systems)
YSM (Yourdon Systems Method)
4
www.hndit.com
Methodology
Modeling Methods
Or Techniques
Tools
Eg: Rational rose
Eg: Class diagram,
usecase diagram
5
www.hndit.com
Modeling method
• A set of techniques used to implement a Methodology.
• Data Flow Diagrams
– A process model
– Depict the flow of data through a system and the work
performed by the system
• Entity Relationship Diagrams
– A data model
– Depict data in terms of entities and relationships described
by the data
– Consists of several notations
• Structure Charts etc.
6
Tools
www.hndit.com
Tools are Software systems and they assist analysts
and designers to build information systems.
General Aim :
– Decrease the human effort required to develop
the software
– Increase the quality of software
– Tools will support methodologies but will not
replace system analysts.
e.g. Easy Case, Rational Rose
7
www.hndit.com
Underlying Principles for System
Development methodology
P1: Get the system users involved
P2: Use a problem-solving approach
P3: Establish phases and activities.
P4 : Document through out Development
P5: Establish standards
P6 :Manage the process and Projects
P7:Justify systems as Capital Investments.
P8:Don’t be afraid to cancel or revise scope.
P9:Divide and conquer
P10: Design systems for growth and change.
8
www.hndit.com
What is a Software Process?
• A set of ordered tasks involving activities ,
constraints and resources that produce a
software system.
9
www.hndit.com
Software process models
•
•
•
•
•
•
•
•
•
•
Waterfall model
Prototyping models
Evolutionary models
The spiral model
Formal development
Incremental development
Rapid Application Development
Unified Process
Agile Process
Extreme Programming (XP)
10
www.hndit.com
•
The
Waterfall
model
Separate and distinct phases of specification
and development
• A linear sequential model
requirements
analysis & spec
software
design
coding
testing
Maintenance
11
www.hndit.com
Software Life Cycle Models
• Waterfall lifecycle
12
www.hndit.com
Waterfall Strengths
 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 more important
than cost or schedule
13
www.hndit.com
Problems with Waterfall Development
Approach
14
www.hndit.com
Problems with Waterfall Development
Approach……
There are several problems with this approach.
1.
2.
3.
4.
It has a rigid design
Inflexible
It has a top-down procedure
One phase must be completed before the next
phase starts
5. No phase can be repeated
6. Time consuming
There are several criticisms of the Waterfall
development approach
15
www.hndit.com
Modified Waterfall Development
Approach
• Uses the same phases as the pure waterfall development approach.
• Allow some of the stages to overlap, such as the requirements stage
and the design stage.
• Another common modification is to incorporate prototyping into the
requirements phases.
• Overlapping stages make it possible to integrate feedback from the
design phase into the requirements.
• Progress is more difficult to track.
16
www.hndit.com
When to use the Waterfall Model
 The linear cycles are usually best suited to
problems which are well understood and highly
structured.
 Attractive for large problems.
 Projects which have clear and stable
requirements.
www.hndit.com
Prototyping
It is very difficult for end-users to anticipate how they will use
new software systems to support their work. If the system is
large and complex, it is probably impossible to make this
assessment before the system is built and put into use.
A prototype ( a small version of the system) can be used to clear
the vague requirements. A prototype should be evaluated with
the user participation.
There are two types of Prototyping techniques
* Throw-away Prototyping
* Evolutionary Prototyping
www.hndit.com
Throw-away and Evolutionary Prototyping
Throw-away
Executable prototype +
prototyping
System specification
Outline
Requirements
Evolutionary
prototyping
Delivered system
www.hndit.com
Throw-away Prototyping
establish
outline
specification
develop
prototype
evaluate
prototype
specify
system
components
design and
implement
system
Delivered
validate system
software
system
www.hndit.com
Throw-away Prototyping
The objective is to understand the system
requirements clearly. Starts with poorly understood
requirements. Once the requirements are cleared,
the system will be developed from the beginning.
This model is suitable if the requirements are vague
but stable.
www.hndit.com
Some problems with Throw-away Prototyping
1. Important features may have been left out of the prototype to
simplify rapid implementation. In fact, it may not be possible to
prototype some of the most important parts of the system
such as safety-critical functions.
2. An implementation has no legal standing as a contract
between customer and contractor.
3. Non-functional requirements such as those concerning
reliability, robustness and safety cannot be adequately tested
in a prototype implementation.
Evolutionary Prototyping
Develop abstract
specification
Build prototype
system
NO
YES
Deliver
system
System
Adequate?
www.hndit.com
Evaluate prototype
system
www.hndit.com
Structured Evolutionary Prototyping
Strengths
1. Customers can “see” the system requirements as they are
being gathered
2. Developers learn from customers
3. A more accurate end product
4. Unexpected requirements accommodated
5. Allows for flexible design and development
6. Interaction with the prototype stimulates awareness of
additional needed functionality
24
www.hndit.com
Prototyping Weaknesses
•
•
•
•
•
Prototyping can lead to false expectations.
Prototyping can lead to poorly designed systems.
Overall maintainability may be overlooked
The customer may want the prototype delivered.
Process may continue forever (scope creep)
• Continual change tends to corrupt the structure of
the prototype system. Maintenance is therefore
likely to be difficult and costly.
25
Evolutionary Prototyping (continued)
www.hndit.com
Disadvantages
* Prototype usually evolve so quickly that it is not cost- effective to
produce greater deal of documentation
* Continual change tends to corrupt the structure of the prototype
system. Maintenance is therefore likely to be difficult and costly.
* It is not clear how the range of skills which is normal in software
engineering teams can be used effectively for this mode of
development.
* Languages which are good for prototyping not always best for final
product.
www.hndit.com
The RAD Model
Team 2
Team 1
Team 3
Business
Business
modeling
modeling
Business
Data
modeling
Data
modeling
modeling
Data
modeling
Process
Process
Process
modeling
Application
modeling
generation
modeling
Application
Application
generation
generation
turnover
Testing &
Testing &
turnover
60 –90 days
Testing &
turnover
Processes in the RAD model
www.hndit.com
Business modelling - The information flow in a business system considering its
functionality.
Data Modelling - The information flow defined as part of the business modelling
phase is refined into a set of data objects that are needed to support the business
Process Modelling - The data objects defined in the data modelling phase are
transformed to achieve the information flow necessary to implement business
functions.
Application generation - RAD assumes the use of 4GL or visual tools to generate the
system using reusable components.
Testing and turnover
New components must be tested and all interfaces must be fully exercised
www.hndit.com
Cont. RAD lifecycle
Contract
Requirement
Definition/
Refinement
Design
Feedback
Prototype
Development
Cutomer
Prototype
Review
Deployment
29
www.hndit.com
The RAD model
• Rapid Application Development (RAD) is an
incremental software development process
model that emphasizes an extremely short
development cycle.
• If requirements are well understood and project
scope is constrained, the RAD process enables a
development team to create a ‘fully functional
system’ within very short time periods (eg. 60 to
90 days)
www.hndit.com
Some problems with the RAD model
1. RAD requires sufficient human resources to create
right number of RAD teams
2.
RAD requires developers and customers who are
committed to the rapid-fire activities necessary to get
a system completed in a much abbreviated time
frame.
3. If a system cannot be properly modularized, building
the components necessary for RAD will be
problematic.
4. RAD is not applicable when technical risks are high.
www.hndit.com
Incremental Model
conception
architecture
deliver 1st
Increment
structure
analysis
design
code
test
deliver 2nd
Increment
feedback
analysis
design
code
test
feedback
analysis
design
code
deliver 3rd
Increment
test
www.hndit.com
Incremental Development
• The Incremental development model involves
developing the system in an incremental fashion.
• The most important part of the system is fist
delivered and the other parts of the system are
then delivered according to their importance.
• Incremental development is more manageable
than evolutionary prototyping as the normal
software process standards are followed.
• Plans and documentation must be produced
www.hndit.com
Iterative Development Approach
34
www.hndit.com
Iterative Development Approach
• Iterative development approach completes the entire
IS in successive iterations.
• Each iteration does some
– analysis
– design
– construction
• Allows versions of usable information to be delivered
in regular and shorter time frames.
• The iteration process helps to develop a part of the
new system and place it into operation as quickly as
possible.
35
www.hndit.com
•
Spiral
model
The spiral model (Boehm, 1988) aims at risk reduction by
any means in any phase.
• quadrant 1
– determine objectives of that phase
– alternatives and constraints.
• quadrant 2
– analyzed form the viewpoint of risk
– solutions to minimize these risks are investigated, often using
prototyping.
• quadrant 3
– where the traditional waterfall model phases are put into
practice.
• Quadrant4
– the results of the risk-reduction strategies
36
Spiral model
www.hndit.com
37
Spiral Quadrant
www.hndit.com
Determine objectives, alternatives
and constraints
• Objectives: functionality, performance,
hardware/software interface, critical
success factors, etc.
• Alternatives: build, reuse, buy, subcontract, etc.
• Constraints: cost, schedule, interface,
etc.
38
www.hndit.com
Spiral Quadrant
Evaluate alternatives, identify and resolve risks
• Study alternatives relative to objectives and
constraints
• Identify risks (lack of experience, new
technology, tight schedules, poor process, etc.
• Resolve risks (evaluate if money could be lost
by continuing system development)
39
www.hndit.com
Spiral Quadrant
Develop next-level product
• Typical activates:
– Create a design
– Review design
– Develop code
– Inspect code
– Test product
40
www.hndit.com
Spiral Quadrant
Plan next phase
• Typical activities
– Develop project plan
– Develop configuration management plan
– Develop a test plan
– Develop an installation plan
41
www.hndit.com
Spiral Model Strengths
• Provides early indication of insurmountable
risks, without much cost
• Users see the system early because of rapid
prototyping tools
• Critical high-risk functions are developed first
• The design does not have to be perfect
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users
42
www.hndit.com
Spiral Model Weaknesses
• Time spent for evaluating risks too large for
small or low-risk projects
• The model is complex
• Risk assessment expertise is required
• May be hard to define objective, verifiable
milestones that indicate readiness to proceed
through the next iteration
43
www.hndit.com
When to use Spiral Model
•
•
•
•
•
•
•
•
•
When creation of a prototype is appropriate
When costs and risk evaluation is important
For medium to high-risk projects
Long-term project commitment unwise because of
potential changes to economic priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and exploration)
44
www.hndit.com
V-Shaped SDLC Model
Testing of the product is planned in parallel with a corresponding
phase of development
45
www.hndit.com
46
www.hndit.com
V-Shaped Strengths
• 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
47
www.hndit.com
V-Shaped Weaknesses
• Does not easily handle concurrent events
• Does not handle iterations or phases
• Does not easily handle dynamic changes in
requirements
• Does not contain risk analysis activities
48
Waterfall vs Agile
www.hndit.com
Timeboxing
49
www.hndit.com
RAD: Definition?
• Many Definitions : same philosophy
• Definition 1:
– A software development process that allows
usable systems to be built within a short period
(as little as 2-3 months), often with compromises.
– It is a generic term with the meaning “speedy
development” or “Shorter schedule”
50
www.hndit.com
RAD
• Rapid Application Development (RAD) refers
to a type of software development which uses
“optimal” planning in favor of rapid
prototyping.
• The "planning" of software developed using
RAD is interleaved with writing the software
itself.
• The lack of extensive pre-planning generally
allows software to be written much faster, and
makes it easier to change requirements.
51
www.hndit.com
RAD lifecycle
• RAD compresses the step-by-step
development process into an iterative process.
– User requirements are refined.
– A system is designed.
– A prototype is developed.
– The prototype is reviewed by end-user.
– User provide feedback.
– The process is repeated.
52
www.hndit.com
Review Questions
1.
The following are initial requirements specified by some customers. Identify the
most suitable process models for these software projects.
(a) “ I need to develop a simple library system for my school. I know the
requirements very well”
(b) “I need to develop a management information system for my organization,. I may
use it for all the branches in several location in Sri Lanka. I might use it on the
Internet”.
(c ) “ I need to develop a software system to control a space shuttle”