methodologies of software engineering
TRANSCRIPT
Agenda
S Why we need methods of software engineering
S Software development life cycles
S Sequential Approach
S Waterfall model
S Iterative Approach
S Prototype model
S Spiral model
S Agile
Why we need a method of
software engineering
S To manage project with a team
S To make a plane of a project
Software development life
cycle
S Requirement analysis
S System analysis
S System design
S Coding
S Testing
S Implementation
Water Fall
Model Basic Principles
• Divided into sequential
phases
• Tight control is maintained
over the life of the project
• Focus on planning (time,
budget)
• Implementation of an
entire system at one time.
Features of Water Fall Model
Strength
S Generated high-quality
documentations
S Obtains result at the end of
each phases
S Can measure progress of
development
S Well-structured
Weakness
S Difficulty of adaptation to
uncertainty
S Inflexible to respond to change
S Updating documentation is
time-consuming.
S Can not see the working
version of the product until the
end
Appropriate situation
Most Appropriate
S Project has clear objectives and
solution
S Project is large and complicated
S Project requirements are stable
(unchanging)
S Required for formal approvals
at designated milestone
Least Appropriate
S Large Project where its
requirements are not well-
understood or changing for any
reasons
S Event-driven systems
S Real-time system
Prototyping
• Begin with gathering the
user’s basic requirements.
• Focus on the realization of
the software aspects
visible to the user
• Fully-understand the
requirements by continues
refinement
Feature of Prototyping Model
Strength
S Resolving unclear objectives
S Help to identify confusing or
difficult functions
S Have a flexible design
S Provide a quick
implementation(to demonstrate)
Weakness
S Can lead poorly designed
system
S Requirement may change
significantly and frequently
S Incomplete or inadequate
problem analysis may occur
Appropriate situation
Most Appropriate
S User is not fully knowledgeable
S Objectives are unclear
S No strict requirement for
approvals at milestone
Least Appropriate
S Transaction-oriented batch
system
S Future scalability of the design
is critical
S Objectives are very clear
Spiral Model
S Focus on risk
assessment and
minimize project risk
S Each cycle begins with
an identification of
stakeholders and their
win condition
S Each cycle ends with
review and commitment
Feature of Spiral Model
Strength
S Enhances risk avoidance
S Can incorporate waterfall and
prototyping models
Weakness
S No clear termination condition
(so, inherent risk is not meet
time and money)
S Highly customized to each
project => limiting reusability
S No established controls for
moving cycle to cycle
Appropriate Situation
Most Appropriate
S Real time or safety-critical
system
S Risk avoidance is high priority
S Required for strong approval
and documentation control
Least Appropriate
S Minimizing resource
consumption is high priority
S Accuracy is not essential
S Risk avoidance is not essential
Feature of Agile Model
Strength
S Customer satisfaction by rapid
S Continuously delivered of useful
software
S Late changes in requirements
are welcomed
S Get involved business people
and developers
Weakness
S Lack of emphasis on necessary
designing and documentation
S Can easily get taken off if the
customer’s representative is not
clear about their final outcome
Feature of Agile Model
Most Appropriate
S When new changes are
required to be implemented.
S Good for a software relative to
dynamic changes in business
or IT world
S Clients can have a various
options
Least Appropriate
S Clients and developer teams
need to be very close.
Communicate well.