SE - Unit 2

Software Engineering: A Practitioner’s Approach, 6/e
Chapter 2
Prescriptive Process Models
1
Definitions
■ Software Engg. is the establishment and use of sound
engineering principles in order to obtain economically
software that is reliable and works efficiently on real
machines ……
2
A Layered Technology
Software Engineering
tools
methods
process model
a “quality” focus
3
Process, Method, Tools
■ Process defines framework
■ Process forms basis for management control.
■ Process establishes context for methods to be applied ,
Work product, milestones, quality ensured, Change
Managed
■ Method provide Technical “How To”
■ Tools provide support for methods & processes
4
A Process Framework
Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities
5
Framework Activities
■ Communication
■ Planning
■ Modeling
■ Analysis of requirements
■ Design
■ Construction
■ Code generation
■ Testing
■ Deployment
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
Umbrella Activities
■ Software project tracking and control
■ Formal technical reviews
■ Software quality assurance
■ Software configuration management
■ Work product preparation and production
■ Reusability management
■ Measurement
■ Risk management
7
The Capability Maturity Model
Integration (CMMI)
■ The Capability Maturity Model Integration (CMMI) is a process model

framework.
■ It is a structured and systematic collection of best practices, which can
be used as a tool within your organization’s management system to
guide process improvement.
■ Under the CMMI methodology, processes are rated according to their
maturity levels, which are defined as: Initial, Repeatable, Defined,
Quantitatively Managed and Optimizing.
■ Improved performance means decreased costs, improved on-time
delivery, improved productivity, improved quality, and improved
customer satisfaction.
8
CMMI
■ Capability levels :
Level 1 : Initial
Level 2 : Managed
Level 3 : Defined
Level 4 : Quantitatively managed
Level 5 : Optimized
9
Maturity Level 1 - Initial
■ CMMI Maturity Level 1 is typically an unstable environment, where an organization is

highly reactive and putting out fires.
■ In this setting, processes are typically adhoc and the business is relying on specific
individuals to keep things afloat.
■ Processes are new and often undocumented
■ Businesses are unable to reliably repeat processes.
■ Maturity level 1 organizations are characterized by a tendency to over commit, abandon
processes in the time of crisis, and not be able to repeat their past successes.
■ Lowest quality and highest risk
10
Maturity Level 2 - Managed
■ An organization has achieved all the specific and generic goals of the process areas
assigned to maturity levels 1
■ At Maturity Level 2, an organization’s development processes are repeatable and produce
consistent and measurable results.
■ At this stage, all business projects are managed so that processes are “planned,
performed, measured and controlled.
■ The focus is on the management of requirements, processes, work products and services.
You want to ensure all stakeholders are established and given ownership over specific
tasks.
■ The status of the work products and the delivery of services are visible to management at
defined points.
■ Commitments are established among relevant stakeholders and are revised as needed.
Work products are reviewed with stakeholders and are controlled.
■ Progress is starting to show and there is a full set of practices in place that specifically
address improvement in the practice area.
■ This risk involved is lower than Initial level, but still exists. Quality is better than Initial level
11
Maturity Level 3 - Defined
■ Maturity Level 3 is when your organization has processes that are well characterized and
understood and are described in standards, procedures, tools and methods.
■ Processes should be well-defined and documented, and they should be continually
improved to some extent over time.
■ This level brings more organization and standardization to your process by establishing
reliability and efficiency.
■ Medium quality and medium risk involved.
■ There’s a focus on achieving project and organizational performance objectives and there
are clear organizational standards in place for addressing projects in that practice area.
12
Maturity Level 4 - Quantitatively Managed and capable
■ Maturity Level 4 is reserved for processes that have reached a stage where they can be
measured using defined metrics that demonstrate how the process is beneficial to
business operations.
■ These processes have been repeatedly tested, refined and adapted in multiple conditions
across the organization.
■ All key stakeholders and process users are competent in the established process and
comfortable deploying it in various environments.
■ By now, your process should easily adapt to suit other projects in the organization and to
stand as a template for future process development.
■ high quality is achieved and risks are lower
13
Maturity Level 5 - Optimizing
■ The final level of maturity describes processes that are continually monitored and
improved as needed.
■ Your processes should always remain flexible enough to accommodate new technologies
and innovation in the organization.
■ Development processes aren’t meant to be static and the fifth and final level of maturity
isn’t an end-point. Organizations still need to maintain a constant focus on process
performance to maintain that appraisal level.
■
14
Prescriptive Models
■ Prescriptive process models advocate an orderly approach to
software engineering
■ “prescriptive” because they prescribe a set of process
elements—framework activities, software engineering actions, tasks,
work products, quality assurance, and change control mechanisms
for each project. Each process model also prescribes a process flow
(also called a work flow)—that is, the manner in which the process
elements are interrelated to one another.
The Waterfall Model / Linear Sequential
model / Classic lifecycle model
Real proj rarely follow sequential flow.

Used when requirements are all understood.
Difficult to state all req explicitly.
Working model will not be available until late
Inappropriate for frequently changing requirements.
The waterfall methodology is composed of seven non-overlapping stages:
1. Requirements: Potential requirements, deadlines and guidelines for the project are analyzed and placed into a
functional specification. This stage handles the defining and planning of the project without mentioning specific
processes.
2. Analysis: The system specifications are analyzed to generate product models and business logic that will guide
production. This is also when financial and technical resources are audited for feasibility.
3. Design: A design specification document is created to outline technical design requirements such as programming
language, hardware, data sources, architecture and services.
4. Coding/Implementation: The source code is developed using the models, logic and requirements designated in
the prior stages. Typically, the system is designed in smaller components, or units, before being implemented
together.
5. Testing: This is when quality assurance, unit, system and beta tests take place to report issues that may need
to be resolved. This may cause a forced repeat of the coding stage for debugging. If the system passes the tests,
the waterfall continues forward.
6. Operation/Deployment: The product or application is deemed fully functional and is deployed to a live
environment.
7. Maintenance: Corrective, adaptive and perfective maintenance is carried out indefinitely to improve, update and
enhance the final product. This could include releasing patch updates or releasing new versions.
18
Some of the major advantages of the Waterfall Model are as follows −
● Simple and easy to understand and use

● Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
● Phases are processed and completed one at a time.
● Works well for smaller projects where requirements are very well understood.
● Clearly defined stages.
● Well understood milestones.
● Easy to arrange tasks.
● Process and results are well documented.
19
Disadvantages of the waterfall model
The disadvantages of the waterfall model typically surround risk associated with a lack of revision,
including:
● Design is not adaptive; often when a flaw is found, the entire process needs to start over.
● Ignores the potential to receive mid-process user or client feedback and make changes based on
results.
● Delays testing until the end of the development life cycle.
● Does not consider error correction.
● Does not handle requests for changes, scope adjustments or updates well.
● Reduces efficiency by not allowing processes to overlap.
● No working product is available until the later stages of the life cycle.
● Not ideal for complex, high risk, ongoing or object-oriented projects.
20
The Incremental Model
■ There are many situations in which initial software requirements are reasonably well
defined but there may be a compelling need to provide a limited set of software
functionality to users quickly and then refine and expand on that functionality in
later software releases. In such cases, you can choose a process model that is designed
to produce the software in increments.
■ When an incremental model is used, the first increment is often a core product. That
is, basic requirements are addressed but many supplementary features (some known,
others unknown) remain undelivered. The core product is used by the customer (or
undergoes detailed evaluation), plan is developed for the next increment. This
process is repeated following the delivery of each increment, until the complete
product is produced.
■ Useful when staffing is unavailable, easy to test and debug, more flexible, better risk
management,not all requirements are gathered up front for the entire software life
cycle
Advantages-
1. Prepares the software fast.
2. Clients have a clear idea of the project.
3. Changes are easy to implement.
4. Easy to test and debug
5. Provides risk handling support, because of its iterations.
Disadvantages-
1. A good team and proper planned execution are required.
2. Because of its continuous iterations the cost increases.
3. Modules should be clearly defined. Well defined module interfaces are needed.
4. Solving a problem in one unit would require correction in all the units and consume a lot of
time. 23
The Rapid Application Development
Model (RAD)
Advantages of RAD
■ Emphasizes on short development cycle
■ It is high speed adaptation of waterfall model.
■ Rapid development is achieved by using component
based construction approach.
Advantage of RAD Model
● This model is flexible for change.

● In this model, changes are adaptable.
● Each phase in RAD brings highest priority functionality to the customer.
● It reduced development time.
● It increases the reusability of features.
■
Drawbacks of RAD
■ For Large (but scalable) projects, RAD requires sufficient resources
to create the right number of RAD teams.
■ Not all applications are compatible for RAD. If a system cannot be
properly modularized, building components for RAD will be
problematic.
■ RAD not appropriate when technical risks are high. This normally
occurs when a new application makes heavy use of new technology
or when the new software requires a high degree of interoperability.
■ It requires equal commitment from both customers and developers.
One sided commitment can be disastrous.
When we use the Incremental Model?
● When the requirements are superior.
● A project has a lengthy development schedule.
● When Software team are not very well skilled or trained.
● When the customer demands a quick release of the product.
● You can develop prioritized requirements first.
When to use RAD Model?

● When the system should need to create the project that modularizes in a short span time (2-3
months).
● When the requirements are well-known.
● When the technical risk is limited.
● When there's a necessity to make a system, which modularized in 2-3 months of period.
● It should be used only if the budget allows the use of automatic code generating tools. 27
Evolutionary process models
■ Business and product requirements often change as
development proceeds, making a straight line path to an
end product unrealistic; tight market deadlines make
completion of a comprehensive software product
impossible, but a limited version must be introduced to
meet competitive or business pressure; a set of core
product or system requirements is well understood, but
the details of product or system extensions have yet to be
defined.
■ Evolutionary models are iterative. They are
characterized in a manner that enables you to develop
increasingly more complete versions of the software
Evolutionary Models: Prototype
29
A prototype is a toy implementation of the system. A prototype usually turns out to be a
very crude version of the actual system, possible exhibiting limited functional capabilities,
low reliability, and inefficient performance as compared to actual software. In many
instances, the client only has a general view of what is expected from the software
product. In such a scenario where there is an absence of detailed information regarding
the input to the system, the processing needs, and the output requirement, the
prototyping model may be employed.
30
Advantage of Prototype Model
1. This model is flexible in design.
2. It is easy to detect errors.
3. We can find missing functionality easily.
4. There is scope of refinement, it means new requirements can be easily accommodated.
5. It can be reused by the developer for more complicated projects in the future.
6. It ensures a greater level of customer satisfaction and comfort.
7. It helps developers and users both understand the system better.
8. Integration requirements are very well understood and deployment channels are decided at a very early
stage.
9. It can actively involve users in the development phase.
10.
31
Disadvantages of using Prototype Model :
1. This model is costly.
2. It has poor documentation because of continuously changing customer requirements.
3. There may be too much variation in requirements.
4. Customers sometimes demand the actual product to be delivered soon after seeing an early
prototype.
5. There may be sub-optimal solutions because of developers in a hurry to build prototypes.
6. Customers may not be satisfied or interested in the product after seeing the initial prototype.
7. There is certainty in determining the number of iterations.
8. There may be incomplete or inadequate problem analysis.
9. There may increase the complexity of the system.
32
■ Often, a customer defines a set of general objectives for
software, but does not identify detailed requirements for
functions and features. In other cases, the developer may
be unsure of the efficiency of an algorithm, the
adaptability of an operating system
■ In such cases prototyping may offer the best approach.
■ the prototyping paradigm assists you and other
stakeholders to better understand what is to be built
when requirements are fuzzy.
Evolutionary Models: The Spiral
■ The first circuit around the spiral might result in the development of a product
specification; subsequent passes around the spiral might be used to develop a
prototype and then progressively more sophisticated versions of the software.
■ Each pass through the planning region results in adjustments to the project plan. Cost
and schedule are adjusted based on feedback derived from the customer after
delivery. In addition, the project manager adjusts the planned number of iterations
required to complete the software.
■ The spiral model demands a direct consideration of technical risks at all stages of the
project and, if properly applied, should reduce risks before they become problematic.
Advantages of Spiral Model:
Below are some advantages of the Spiral Model.
1. Risk Handling: The projects with many unknown risks that occur as the development proceeds, in
that case, Spiral Model is the best development model to follow due to the risk analysis and risk
handling at every phase.
2. Good for large projects: It is recommended to use the Spiral Model in large and complex projects.
3. Flexibility in Requirements: Change requests in the Requirements at later phase can be
incorporated accurately by using this model.
4. Customer Satisfaction: Customer can see the development of the product at the early phase of the
software development and thus, they habituated with the system by using it before completion of the
total product.
36
Disadvantages of Spiral Model:
Below are some main disadvantages of the spiral model.
1. Complex: The Spiral Model is much more complex than other SDLC models.
2. Expensive: Spiral Model is not suitable for small projects as it is expensive.
3. Too much dependability on Risk Analysis: The successful completion of the project is very much
dependent on Risk Analysis. Without very highly experienced experts, it is going to be a failure to
develop a project using this model.
4. Difficulty in time management: As the number of phases is unknown at the start of the project, so
time estimation is very difficult.
37
38
For Information
39
Evolutionary Models: Concurrent
■ The concurrent process model can be represented schematically as a
series of major technical activities, tasks, and their associated states.
■ Figure 2.10 provides a schematic representation of one activity with
the concurrent process model.
■ All activities exist concurrently but reside in different states. For
example, early in a project the customer communication activity (not
shown in the figure) has completed its first iteration and exists in the
awaiting changes state.
■ The analysis activity now makes a transition into the under
development state. If, however, the customer indicates that changes
in requirements must be made, the analysis activity moves from the
under development state into the awaiting changes state.
■ The concurrent process model defines a series of events that will
trigger transitions from state to state for each of the software
engineering activities.

SE - Unit 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SE - Unit 2

Uploaded by

Copyright:

Available Formats

Software Engineering: A Practitioner’s Approach, 6/e

■ The Capability Maturity Model Integration (CMMI) is a process model

■ CMMI Maturity Level 1 is typically an unstable environment, where an organization is

Real proj rarely follow sequential ﬂow.

language, hardware, data sources, architecture and services.

the waterfall continues forward.

● Simple and easy to understand and use

● Delays testing until the end of the development life cycle.

● Does not consider error correction.

● Reduces efficiency by not allowing processes to overlap.

● Not ideal for complex, high risk, ongoing or object-oriented projects.

● This model is ﬂexible for change.

When to use RAD Model?

You might also like