Unit 4: Software Process Models
Contents
1.0 Introduction
2.0 Intended Learning Outcome (ILOs)
3.0 Main Content
3.1 Software Process Models
3.2 The Waterfall Model
3.3 Problems of the waterfall model
3.4 The V-Model
3.5 application of v- model
3.6 Disadvantages of the V-Model
4.0 Self-Assessment Exercise
5.0 Conclusion
6.0 Summary 7.0
Further Readings
1.0 Introduction
In this unit, you will understand what a software process model is. You will also understand the waterfall
model and V-Model.
2.0 Intended Learning Outcomes (ILOs)
By the end of this unit, you should be able to:
Define software process model
Explain the waterfall model
Distinguish between waterfall model and V-Model
3.0 Main Content
3.1 Software Process Models
A software process model is a simplified representation of a software process or software development
lifecycle, presented from a specific perspective.
Examples of generic process models include:
Waterfall
Evolutionary development
Formal transformation
Integration from reusable components.
3.2 The Waterfall Model
The waterfall model, also referred to as a linear-sequential life cycle model was the first software
process model to be introduced and is. It consists of separate and distinct phases of specification and
development.
Figure 1.4: the waterfall model
The phases of waterfall model include
a. Requirements analysis and
definition b System and software
design
c. Implementation and unit testing
d. Integration and system testing
e. Operation and maintenance.
3.3 Problems of the waterfall model
1. Difficult to accommodate change after the process is underway. One phase has to be complete
before moving onto the next phase.
2. Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing
customer requirements.
3. This model is only appropriate when the requirements are well-understood and changes will be
fairly limited during the
design process.
4. Few business systems have stable requirements.
5. The waterfall model is mostly used for large systems engineering
projects where a system is developed at several sites.
3.4 The V-Model
The V-model is an improvement of the waterfall model. It provides means of testing of software at
each stage in reverse manner. This is an improvement to the waterfall model which only allows you to
move down in a linear way. Just like the waterfall model the process steps follow each other in a
sequential order but V-model allows the parallel execution of activities. On each stage of the software
development process, testing in carried out to validate and verify each stage of the process. This model
is often referred to as verification and validation model
Figure 1.5: the V-Model
3.5 application of v- model
V- Model usually can be applied when;
a. Requirements are well defined, clearly documented and fixed
b. Product definition is stable.
c. Technology is not dynamic and is well understood by the project team.
d. There are no ambiguous or undefined requirements.
e. The project is short.
3.6 Disadvantages of the V-Model
a. High uncertainty and risk.
b. Not a good model for complex and object-oriented projects.
c. unsuitable for long and ongoing projects.
d. unsuitable for the projects where requirements are at a moderate to high risk of changing.
e. Once an application is in the testing stage, it is difficult to go back and change a functionality.
iscussion
Why is V-Model considered an improvement over waterfall model?
cenario
ou are the Chief Operating Officer of a software development company. A client has approached your team to
develop a new software for them. On discussing with their team, you observe they do not have all the system
requirements well documented and would rather prefer an arrangement where they keep adjusting system
requirement until the software product is fully developed and functional. Why will either waterfall model or
V-model be unsuitable for this job?
4.0 Self-Assessment Exercise(s)
1. which of these was the first software process model to be introduced
a. spiral development
b. Evolutionary development
c. waterfall model
d. V - model
2. Which of these is not a phase of the waterfall model
a. Requirements analysis and definition
b Reverse engineering
c. Implementation and unit testing
d. Integration and system testing
5.0 Conclusion
n this unit you have learnt about software process model. You have also learnt some software process models
which include the waterfall model and V-Model.
6.0 Summary
aterfall model and V-model are software process models that require system requirements to be specified and
fully documented before design and implementation can commence.
7.0 Further Readings
rooks, F. P., (1995). The Mythical Man-Month: Essays on Software Engineering (20th Anniversary Edition).
Addison-Wesley Inc.: Reading, MA.
roy, M., Deimel, A., Henn, J., Koskimies, K., Plášil,F., Pomberger,G., Pree,W., Stal,M. and Szyperski, C.,
(1998). What Characterizes a (Software) component? Software – Concepts & Tools, vol. 19, pp. 49-56.
uschmann, F., Meunier, R., Rohnert, H., Sommerlad,P. and Stal, M., (1996). Pattern-Oriented Software
Architecture: A System of Patterns. John Wiley & Sons, Inc.: New York.
alvert, K. L. and Donahoo, M. J., (2002). TCP/IP Sockets in Java: Practical Guide for Programmers.
Morgan Kaufmann Publishers: San Francisco, CA.
aromel, D. and Vayssière, J., (July 2003). “A Security Framework for Reflective Java Applications,” Software –
Practice & Experience. John Wiley & Sons, Inc., vol. 33, no. 9, 821-846.
hellappa, R., Phillips, P. J. and Reynolds, D., (Editors), (November 2006). Special Issue on Biometrics:
Algorithms and Applications of Fingerprint, Iris, Face, Gait, and Multimodal Recognition. Proceedings of the
IEEE, vol. 94, no. 11.
hen, G., and Szymanski, B. K., (December 2001). “Object-oriented Paradigm: Component-oriented Simulation
Architecture: Toward Interoperability and Interchangeability,”. Proceedings of the 2001 Winter Simulation
Conference (WSC 2001), pp. 495-501, Arlington, VA.
Coleman, D., Arnold, P., Bodoff, S., Dollin, C., Gilchrist, H., Hayes,F.,
and Jeremaes, P., (1994). Object-Oriented Development: The Fusion Method, Prentice-Hall, Inc., Englewood
Cliffs, NJ.
Constantine, L. L. and Lockwood, L. A, (1999). Software for Use: A Practical Guide to the Models and
Methods of Usage-Centered Design, Addison-Wesley Professional/ACM Press: Reading, MA.
Grogono, P. (1999). Software Engineering (2nd Edition). New Jersey: Prentice Hall.
Somerville, I. (2016). Software Engineering, (10th Edition). Pearson Education Limited, Edinburgh Gate
Harlow Essex CM20 2JE England
Somerville, I. (2002). Software Engineering Methodology (5th Edition). McGraw-Hill
Online Resources
[Link]
[Link]
[Link]
[Link]#754
[Link]
[Link]
Unit 5: Evolutionary and Incremental Development
Contents
1.0 Introduction
2.0 Intended Learning Outcome (ILOs)
3.0 Main Content
3.1 Evolutionary Development
3.2 Problems of Evolutionary Development
3.3 Application of evolutionary development
3.4 Incremental Development
3.5 Advantages of Incremental Development
4.0 Self-Assessment Exercise
5.0 Conclusion
6.0 Summary 7.0
Further Readings
1.0 Introduction
In this unit, we will look at the evolutionary development and incremental development.
2.0 Intended Learning Outcomes (ILOs)
At the end of this unit, you will be able to:
describe the objective of evolutionary development
problems of evolutionary development
outline the applications of evolutionary development
point out the advantages of incremental development.
3.0 Main Content
3.1 Evolutionary Development
The main objective of the evolutionary development is to work with customers and to evolve a final system
from an initial outline specification. This model starts with well-understood requirements and adds new
features as proposed by the customer. The Evolutionary development model divides the development cycle
into smaller, incremental waterfall models in which users are able to get access to the product at the end of
each cycle. Feedback is provided by the users on the product for the planning of the next cycle with the
development team responding, often by changing the product, plan or process.
Figure 1.6: Evolutionary development
3.2 Problems of Evolutionary Development
a. Lack of process visibility;
b. Systems are often poorly structured
c. Special skills (e.g. in languages for rapid prototyping) may
be required.
3.3 Application of Evolutionary Development
a. In small or medium-size interactive systems
b. In parts of large systems (e.g. the user interface)
c. In short-lifetime systems.
3.4 Incremental Development
In the incremental development rather than deliver the system as a single delivery, the development and
delivery is broken down into increments with each increment delivering part of the required functionality.
User requirements are prioritised and the highest priority requirements are included in early increments. Once
the development of an increment is started, the requirements are frozen though requirements for later
increments can continue to evolve.
Figure 1.7 Incremental development
3.5 Advantages of Incremental Development
1. Customer value can be delivered with each increment so
system functionality is available earlier
2. Early increments act as a prototype to help elicit requirements
for later increments
3. Lower risk of overall project failure
4. The highest priority system services tend to receive the
most testing.
Discussion
Why is evolutionary development unsuitable for big software development projects
Scenario
A small size company with twenty staff has requested for a Human Resource Management system. They have
forecasted that staff strength will not grow beyond thirty persons, and require just a basic product that can
handle the most simple human resource management activities.
If they are unwilling to provide a complete detail of their system requirement, what software methodology
would you recommend for this type of project?
4.0 Self-Assessment Exercise(s)
1. which of the following process models has the objective of working with customers to evolve a final system
from an initial outline specification?
a. evolutionary development
b. waterfall model
c. V-model
d. spiral development
2. Evolutionary development can be applied in all but one of these projects
a. In small or medium-size interactive systems
b. In parts of large systems (e.g. the user interface)
c. In short-lifetime systems
d. Large long-lifetime system
5.0 Conclusion
In this unit you have learnt about evolutionary and incremental development. You have also learnt the
advantages of incremental development and the problems of evolutionary development.
6.0 Summary
Evolutionary and Incremental development are models where the customer and the team developing the
software collaborate throughout the developmental stage of the software product; with the customer providing
the specification throughout this stage until the final product is delivered.
7.0 Further Readings
Brooks, F. P., (1995). The Mythical Man-Month: Essays on Software Engineering (20th Anniversary Edition).
Addison-Wesley Inc.: Reading, MA.
3 3
Broy, M., Deimel, A., Henn, J., Koskimies, K., Plášil,F., Pomberger,G., Pree,W., Stal,M. and Szyperski, C.,
(1998). What Characterizes a (Software) component? Software – Concepts & Tools, vol. 19, pp. 49-56.
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad,P. and Stal, M., (1996). Pattern-Oriented Software
Architecture: A System of Patterns. John Wiley & Sons, Inc.: New York.
Calvert, K. L. and Donahoo, M. J., (2002). TCP/IP Sockets in Java: Practical Guide for Programmers.
Morgan Kaufmann Publishers: San Francisco, CA.
Caromel, D. and Vayssière, J., (July 2003). “A Security Framework for Reflective Java Applications,”
Software – Practice & Experience. John Wiley & Sons, Inc., vol. 33, no. 9, 821-846.
Chellappa, R., Phillips, P. J. and Reynolds, D., (Editors), (November 2006). Special Issue on Biometrics:
Algorithms and Applications of Fingerprint, Iris, Face, Gait, and Multimodal Recognition. Proceedings of the
IEEE, vol. 94, no. 11.
Chen, G., and Szymanski, B. K., (December 2001). “Object-oriented Paradigm: Component-oriented
Simulation Architecture: Toward Interoperability and Interchangeability,”. Proceedings of the 2001 Winter
Simulation Conference (WSC 2001), pp. 495-501, Arlington, VA.
Coleman, D., Arnold, P., Bodoff, S., Dollin, C., Gilchrist, H., Hayes,F.,
and Jeremaes, P., (1994). Object-Oriented Development: The Fusion Method, Prentice-Hall, Inc., Englewood
Cliffs, NJ.
Constantine, L. L. and Lockwood, L. A, (1999). Software for Use: A Practical Guide to the Models and
Methods of Usage-Centered Design, Addison-Wesley Professional/ACM Press: Reading, MA.
Grogono, P. (1999). Software Engineering (2nd Edition). New Jersey: Prentice Hall.
Somerville, I. (2016). Software Engineering, (10th Edition). Pearson Education Limited, Edinburgh Gate
Harlow Essex CM20 2JE England
Somerville, I. (2002). Software Engineering Methodology (5th Edition). McGraw-Hill
Online Resources
[Link]
[Link]
[Link]
[Link]#754
[Link]
3 3
Module 2: Introduction To Software Engineering Methodology
Module
Introduc
tion
This module continues discussion on the different traditional software engineering process models. The
module also discussed agile development methods in software engineering.
Unit 1: Prototyping
Unit 2: Spiral Development
Unit 3: Agile Development Methods
Unit 4: Extreme Programming Unit 5:
The Dynamic System Development Method (DSDM)
Unit 1: Prototyping
Contents
1.0 Introduction
2.0 Intended Learning Outcome (ILOs)
3.0 Main Content
3.1 Prototyping Model
3.2 Types of Prototyping
3.3 Benefits of Prototyping
3.4 Problems of Prototyping
4.0 Self-Assessment Exercise
5.0 Conclusion
6.0 Summary 7.0
Further Readings
1.0 Introduction
In this unit, you will understand the prototyping model, the benefits of prototyping and the problems of
prototyping.
3 3
2.0 Intended Learning Outcomes (ILOs)
By the end of this unit, you will be able to:
describe the prototyping model
understand the benefits of prototyping
understand the problems of prototyping.
3.0 Main Content
3.1 Prototyping Model
A prototyping moves the developer and customer toward a "quick" implementation. It involves the
creating of incomplete versions of the software program being developed. The prototype typically
simulates a few aspects of the proposed system, and may be completely different from, the final
product. Prototyping begins with requirements gathering. Meetings between developer and customer
are conducted to determine overall system objectives and functional and performance requirements.
The developer then applies a set of tools to develop a quick design and build a working model (the
"prototype") of some element(s) of the system. The customer or user "test drives" the prototype,
evaluating its function and recommending changes to better meet customer needs. Iteration occurs as
this process is repeated, and an acceptable model is derived. The developer then moves to "productize"
the prototype by applying many of the steps described for the classic life cycle.
Figure 2.1: The prototyping approach
3.2 Types of Prototyping
1. Throwaway prototyping: this is also known as rapid prototyping, and involves creation of a model
that will eventually be discarded rather than becoming part of the final delivered software system.
3 3
2. Evolutionary prototyping: involves the creation of a very robust prototype in a structured manner.
The developed prototype eventually becomes part of the new software system.
3. Incremental prototyping: here, the final product is built as separate prototypes. The separate
prototypes are merged later in an overall design.
3.3 Benefits of Prototyping
The benefits of prototyping include the following;
1. a working model is provided to the customer/user early in
the process, enabling early assessment and bolstering
confidence,
2. the developer gains experience and insight by building the
model, thereby resulting in a more solid implementation of "the real
thing"
3. the prototype serves to clarify otherwise vague
requirements, reducing ambiguity and improving
communication between developer and user.
4. Increased chances of having high quality functionality with low risks of failure.
3.4 Problems of Prototyping
1. The user sees what appears to be a fully working system (in actuality, it is a partially working
model) and believes that the prototype (a model) can be easily transformed into a production
system. This is rarely the case. Yet many users have pressured developers into releasing prototypes for
production use that have been unreliable, and worse, virtually unmaintainable.
2. The developer often makes technical compromises to build a "quick and dirty" model. Sometimes
these compromises are propagated into the production system, resulting in implementation and
maintenance problems.
3. Budget may increase, as the management cost may go beyond the specified limit.
4. Prototyping is applicable only to a limited class of problems. In general, a prototype is valuable
when heavy human-machine interaction occurs, when complex output is to be produced or when new
or untested algorithms are to be applied. It is far less beneficial for large, batch-oriented processing or
embedded process control applications.
iscussion
escribe the prototyping model
cenario
3 3
As the leader of a team of software engineers for a new software project, you observed that the new system
would involve heavy human-machine interaction. Would you consider prototyping model for this project?
State the reasons for your answer.
4.0 Self-Assessment Exercise(s)
1. one of this is applicable to the prototyping model
a. Projects developed with the prototyping model seldom succeeds
b. There is increased chances of having high quality functionality with low risks of failure.
c. Prototyping model reduces the development cost immensely
d. Projects developed with prototyping model have high risk of failure
2. one disadvantage of prototyping is that
a. most projects developed with prototyping model never succeeds
b. the customers/users run a risk of never understanding how the system operates
c. Budget may increase, as the management cost may go beyond the specified limit.
d. it is often difficult to achieve any meaning design using prototyping model
5.0 Conclusion
In this unit, you have learned about prototyping, the benefits and the challenges.
6.0 Summary
Prototyping is important because it moves the developers and the customers towards a quick implementation
of the desired software project.
7.0 Further Readings
Brooks, F. P., (1995). The Mythical Man-Month: Essays on Software Engineering (20th Anniversary Edition).
Addison-Wesley Inc.: Reading, MA.
3 3
Broy, M., Deimel, A., Henn, J., Koskimies, K., Plášil,F., Pomberger,G.,
Pree,W., Stal,M. and Szyperski, C., (1998). What Characterizes a (Software)
component? Software – Concepts & Tools, vol. 19, pp. 49-56.
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad,P. and Stal, M., (1996).
Pattern-Oriented Software Architecture: A System of Patterns. John Wiley &
Sons, Inc.: New York.
Calvert, K. L. and Donahoo, M. J., (2002). TCP/IP Sockets in Java: Practical Guide for
Programmers.
Morgan Kaufmann Publishers: San Francisco, CA.
Caromel, D. and Vayssière, J., (July 2003). “A Security Framework for
Reflective Java Applications,” Software – Practice & Experience. John Wiley &
Sons, Inc., vol. 33, no. 9, 821-846.
Chellappa, R., Phillips, P. J. and Reynolds, D., (Editors), (November 2006).
Special Issue on Biometrics: Algorithms and Applications of Fingerprint, Iris,
Face, Gait, and Multimodal Recognition. Proceedings of the IEEE, vol. 94, no.
11.
Chen, G., and Szymanski, B. K., (December 2001). “Object-oriented
Paradigm: Component-oriented Simulation Architecture: Toward
Interoperability and Interchangeability,”. Proceedings of the 2001 Winter
Simulation Conference (WSC 2001), pp. 495-501, Arlington, VA.
Coleman, D., Arnold, P., Bodoff, S., Dollin, C., Gilchrist, H., Hayes,F.,
and Jeremaes, P., (1994). Object-Oriented Development: The Fusion Method,
Prentice-Hall, Inc., Englewood Cliffs, NJ.
Constantine, L. L. and Lockwood, L. A, (1999). Software for Use: A Practical
Guide to the Models and Methods of Usage-Centered Design, Addison-Wesley
Professional/ACM Press: Reading, MA.
Grogono, P. (1999). Software Engineering (2nd Edition). New Jersey: Prentice Hall.
Somerville, I. (2016). Software Engineering, (10th Edition). Pearson Education
Limited, Edinburgh Gate Harlow Essex CM20 2JE England
Somerville, I. (2002). Software Engineering Methodology (5th Edition). McGraw-Hill
Online Resources
[Link]
courses/371/[Link]
[Link]
3 3
.html
[Link]
methodology-thewatersluice- [Link]#754.
3 3