Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Software Engineering Models and methods: Types, principles and critique
Transcript of Software Engineering Models and methods: Types, principles and critique
Types, principles and critique
What makes a software process
Models and methods
roadmap to building high quality software
products is software process.
Software processes are
adapted to meet the needs of software engineers
and managers as they undertake the development of a software product.
A software process
provides a framework
for managing activities that can very easily get out of control.
software processes must be agile
, demanding only those activities, controls, and work products appropriate for team or product.
Different types of
projects require different
The software engineer's work products (programs, documentation, data) are produced as
consequences of the activities
defined by the software process.
The best indicators of how well a software process has worked are the
quality, timeliness, and long-term viability
of the resulting software product.
Process models aren't good or bad, just suitable or unsuitable for a particular project.
Process Models differ from one another on the following attributes.
Key process elements
Activities: Major workflow elements that are always performed
A process may have many activities
Actions: Important management and technical events that perform a key project function
An activity may have many actions
Tasks: Work that practitioners perform to accomplish an action
An action may have one or many tasks
• Describes how each of the five framework activities, actions, and tasks are organized with respect to sequence and time
• Process flow is either sequential (e.g. linear) or concurrent (e.g. iterative, parallel etc)
process flow executes each of the framework activities in order beginning with communication and ending with deployment
process flow executes the activities in a circular manner creating a more complete version of the software with each circuit or iteration
process flow executes one on more activities in parallel with other activities
Attributes for Comparing Process Models
• Overall flow and level of interdependencies among tasks
• Degree to which work tasks are defined within each framework activity
• Degree to which work products are identified and required
• Manner in which quality assurance activities are applied
• Manner in which project tracking and control activities are applied
• Overall degree of detail and rigor of process description
• Degree to which stakeholders are involved in the project
• Level of autonomy given to project team
• Degree to which team organization and roles are prescribed
Traditional Process Models
Oldest software lifecycle model and best understood by upper management
Used when requirements are well understood and risk is low
Work flow is in a linear (i.e., sequential) fashion Used often with well-defined adaptations or enhancements to current software
Doesnt support iteration, so changes can cause confusion
Difficult for customers to state all requirements explicitly and up front
Requires customer patience because a working version of the program doesnt occur until the final phase
Problems can be somewhat alleviated in the model through the addition of feedback loops (see the next slide)
Reused material from :
Used when requirements are well understood
Multiple independent deliveries are identified
Work flow is in a linear (i.e., sequential) fashion within an increment and is staggered between increments
Iterative in nature; focuses on an operational product with each increment
Provides a needed set of functionality sooner while delivering optional components later
Useful also when staffing is too short for a full-scale development
Follows an evolutionary and iterative approach
Used when requirements are not well understood
Serves as a mechanism for identifying software requirements
Focuses on those aspects of the software that are visible to the customer/user
Feedback is used to refine the prototype
The customer sees a "working version" of the software, wants to stop all development and then buy the prototype after a "few fixes" are made
Developers often make implementation compromises to get the software running quickly (e.g., language choice, user interface, operating system choice, inefficient algorithms)
Lesson learned – Define the rules up front on the final disposition of the prototype before it is built – In most circumstances, plan to discard the prototype and engineer the actual production software with a goal toward quality
Invented by Dr. Barry Boehm in 1988 while working at TRW
Follows an evolutionary approach
Used when requirements are not well understood and risks are high
Inner spirals focus on identifying software requirements and project risks; may also incorporate prototyping
Outer spirals take on a classical waterfall approach after requirements have been defined, but permit iterative growth of the software
Operates as a risk-driven model…a go/no-go decision occurs after each complete spiral in order to react to risk determinations
Requires considerable expertise in risk assessment
Serves as a realistic model for large-scale software development
Prototyping poses a problem to project planning because of the uncertain number of iterations required to construct the product
Evolutionary software processes do not establish the maximum speed of the evolution
If too fast, the process will fall into chaos
If too slow, productivity could be affected
Software processes should focus first on flexibility and extensibility, and second on high quality
We should prioritize the speed of the development over zero defects
Extending the development in order to reach higher quality could result in late delivery
General problems faced with using the evolutionary models
The Unified Process
Iterative and Incremental
Consists of 4+1 phases
Consists of five activities
Inception is the smallest phase in the project, and ideally it should be quite short. If the Inception Phase is long then it may be an indication of excessive up-front specification, which is contrary to the spirit of the Unified Process.
The following are typical goals for the Inception phase.
Establish a justification or business case for the project
Establish the project scope and boundary conditions
Outline the use cases and key requirements that will drive the design tradeoffs
Outline one or more candidate architectures
Prepare a preliminary project schedule and cost estimate
The Lifecycle Objective Milestone marks the end of the Inception phase.
Develop an approximate vision of the system, make the business case, define the scope, and produce rough estimate for cost and schedule.
During the Elaboration phase the project team is expected to capture a healthy majority of the system requirements. However, the primary goals of Elaboration are to
address known risk factors
establish and validate the system architecture
. Common processes undertaken in this phase include the creation of
use case diagrams
(class diagrams with only basic notation) and
The output is a credible and fairly accurate
for the Construction phase.
Construction is the largest phase in the project.
In this phase the remainder of the system is built on the foundation laid in Elaboration.
System features are implemented in a series of short, timeboxed iterations.
Each iteration results in an executable release of the software.
It is customary to write full text use cases during the construction phase and each one becomes the start of a new iteration.
Common UML (Unified Modelling Language) diagrams used during this phase include Activity, Sequence, Collaboration, State (Transition) and Interaction.
The final project phase is Transition.
In this phase the system is deployed to the target users. Feedback received from an initial release (or initial releases) may result in further refinements to be incorporated over the course of several Transition phase iterations.
The Transition phase also includes system conversions and user training.
Iterations are often funner and more satisfying in the end