Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start 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

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Software Engineering Models and methods: Types, principles and critique

Session 3, FA-2015
by

Mirza Faraz Beg

on 7 September 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Software Engineering Models and methods: Types, principles and critique

Models and methods
Types, principles and critique
What makes a software process
Process Flow
Software Engineering:
Models and methods

Overview

The
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.
Modern
software processes must be agile
, demanding only those activities, controls, and work products appropriate for team or product.
Different types of
projects require different
software processes.
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)

Linear
process flow executes each of the framework activities in order beginning with communication and ending with deployment

Iterative
process flow executes the activities in a circular manner creating a more complete version of the software with each circuit or iteration

Parallel
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

Process Flow
Traditional Process Models
Waterfall Model
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
Overview
Problems
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 :
http://www.slideshare.net/zeal123123/pressman-ch3prescriptiveprocessmodels-13798335
https://en.wikipedia.org/wiki/Unified_Process

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
Overview
Overview
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

Potential problems
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
Overview
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
Features
Iterative and Incremental
Architecture centric
Risk Focused


Consists of 4+1 phases
:
inception
elaboration
construction
transition
production


Consists of five activities

Communication
Planning
Modeling
Construction
Deployment
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
Identify risks
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.
Inception
Elaboration
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
and to
establish and validate the system architecture
. Common processes undertaken in this phase include the creation of
use case diagrams
,
conceptual diagrams
(class diagrams with only basic notation) and
package diagrams
(architectural diagrams).


The output is a credible and fairly accurate
plan
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.
Construction
Transition
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
Full transcript