MBA management

Software Engineering Process Models topics:


Process models define a distinct set of activities, actions, tasks, milestones, and work products that are required to engineer high quality software. These process models are not perfect, but they do provide a useful roadmap for software engineering work.

Prescriptive process models were originally proposed to bring order to the chaos of software development. History has indicated that these conventional models have brought a certain amount of useful structure to software engineering work and have provided a reasonably effective roadmap for software teams. However, software engineering work and the product that it produces remain on “the edge of chaos”.

In an intriguing paper on the strange relationship between order and chaos in the software world, Nogueira and his colleague’s state:

The edge of chaos is defined as “a natural state between order and chaos, a grand compromise between structure and surprise.” The edge of chaos can be visualized as an unstable, partially structured state…. It is unstable because it is constantly attracted to chaos or to absolute order.

We have the tendency to think that order is the ideal state of nature. This could be a mistake. Research…. Supports the theory that operation away from equilibrium generates creatively, self- organized processes, and increasing returns. Absolute order means the absence of variability, which could be an advantage under unpredictable environments. Change occurs when there I some chaos, on the other hand can make coordination and coherence impossible. Lack of structure does not always mean discover.

The philosophical implications of this argument are significant for software engineering. If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? Yet, if we reject conventional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

There are no easy answers to these questions, but there are alternative available to software engineers. In this chapter we examine the prescriptive process approach in which order and project consistency are dominant issues. We examine the agile process approach in which self- organization, collaboration, communication, and adaptability dominate the process philosophy.

What is it? Prescriptive process models define a distinct set of activities, actions, tasks, milestones, and work products that are required to engineer high-quality software. These process models are not perfect, but they do provide a useful roadmap for software engineering work.

Who does it? Software engineers and their managers adapt a prescriptive process model to their needs and then follow it. In addition, the people who have requested the software have a role to play as the process model is followed.

Why is it important? Because it provides stability, control, and organization to an activity that can, if left uncontrolled, become quite chaotic. Some have referred to prescriptive process models as “rigorous process models” because they often encompass the capabilities suggested by the CMMI. However, every process model must be adapted so that it is used effectively for a specific software project.

What are the steps? The process guide a software team through a set of framework activities that are organized into process flow that may be linear, incremental, or evolutionary. The terminology and details of each process model differ, but the generic framework activities remain reasonably consistent.

What is the work product? From the point of view of a software engineer, the work products are the programs, documents, and data that are produced as a consequence of the activities and tasks defined by the process.

How do I ensure that I’ve done it right? There are a number of software process assessment mechanisms that enable organizations to determine the “maturity” of their software process. However, the quality, timeliness, and long-term viability of the product you build are the best indicators of the efficacy of the process that you use.


The waterfall model, also called the classic life cycle suggests a systematic, sequential approach to software development that begins with customer specification of requirements and progress through planning, modeling, constructions, and deployment, culminating in on-going support of the completed software.

Among the problems that are sometimes encountered when the waterfall model is applied are:

Real projects rarely follow the sequential flow that this model proposes. Although the linear model can accommodate iteration, it does so indirectly. As a result, Changes can cause confusion as the project team proceeds.

Communication Project initiation Requirements gathering   Planning Estimating scheduling tracking   Modeling Analysis design   Construction Code test   Deployment Delivery Support Feedback

1. It is often difficult for the customer to state all requirements explicitly. The waterfall model requires this and has difficulty accommodating thee natural uncertainty that exists at the beginning of many projects.

2. The customer must have patience. A working version of the program(s) will not available until late in the project time-span. A major blunder, if undetected until the working program is reviewed, can be disastrous.

Today, software work is fast-paced and is subject to a never- ending stream of changes (to future, functions, and information content). The waterfall model is often inappropriate for such work. However, it can serve as a useful process model in situations where requirements are fixed and work. However, it can serve as a useful process model in situations where requirements are fixed and work is to proceed to completion in a linear manner.


Every software engineering organization should describe a unique set of framework activities for the software process(es) it adopts. It should populate each framework activity with a set of software engineering actions, and define each action in terms of a task set that identifies the work( and work products) to be accomplished to meet the development goals. It should then adapt the resultant process model to accommodate the specific nature of each product, the people who will do the work, and the environment in which the work will be conducted. Regardless of the process model that is selected, software engineers have traditionally chosen a generic process framework that encompasses the following framework activities- communication, planning, construction and deployment.

Franklin D. Roosevelt: “There are many ways of going forward, but only one way of standing still.”

In the sections that follow, we examine a number of prescriptive software process models. We call them “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 workflow---- that is, the manner in which the process elements are interrelated to one another.

All software process models can accommodate the generic framework activities that have been described, but each applies a different emphasis to these activities and defines a workflow that invokes each framework activity (as well as software engineering actions and tasks) in a different manner.


There are many situations in which initial software requirements are reasonably well-defined, but the overall scope of the development effort precludes a purely linear process. In addition, 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, a process model that is designed to produce a software in increments is chosen.

A) The Incremental Model
The incremental model combines element of the waterfall model applied in an iterative fashion. The incremental model applies linear sequence in a staggered fashion as project calendar time progresses. Each linear sequence produces deliverable “increments” of the software.

When an increment model is used, the first increment is often a core product. That is, basic requirements are addressed, but many supplementary features remain undelivered. The core product is used by the customer. As a result of use and/or evaluation, a plan is developed for next increment. The plan addresses the modification of the core product to better meet the needs of the customer and delivery of additional features and functionality. This process is repeated following the delivery of each increment, until the complete product is produced.

Incremental development is particularly useful when staffing is unavailable for a complete implementation by the business deadline that has been established for the product. Early increments can be implanted the next increment. In addition, increments can be planted to manage technical risks. For example, a major system might require the availability of new hardware that is under development and whose delivery date is uncertain. It might be possible to plan early increments in a way that avoids the use of this hardware, thereby enabling partial functionality to be delivered to end users without inordinate delay.

B) The RAD Model
Rapid Application Development (RAD) is an incremental software process model that emphasizes a short development cycle. The RAD model is a “high-speed” adaption of the waterfall model, in which rapid development is achieved by using a components-based construction approach. If requirements are well understood and project scope is considered, the RAD process enables a developmental team to create a “fully functional system” within a very short time period (e.g., 60 to 90 days).

The RAD approach maps into the generic framework activities presented earlier .Communication works to understand the business problem and the information characteristics that the software must accommodate. Planning is essential because multiple software tam works in parallel on different system functions. Modeling encompasses three major phases- business modeling, data modeling and process modeling and establishes design representations that serve as the basis of RAD‘s construction activity. Construction emphasizes the use of pre-existing software components and the application of automatic code generation. Finally, deployment establishes a basis for subsequent iterations, if required.

Evolutionary Process Models

Business and product requirement 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 extension have yet to be defined. In these and similar situations, software engineers need a process model that has been explicitly designed to accommodate a product that evolve over time.

Evolutionary models are iterative. They are characterized in a manner that enables software engineers to develop increasingly more complete versions of the software.

a) Prototyping

A customer defines a set of general objectives for software, but does not identify detailed input, processing, or output requirements. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human- machine interaction should take. In these, and many other situations, a prototyping paradigm may offer the best approach.

The prototyping paradigm begins with the communication. The software engineer and customer met and define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory. A prototyping iteration is planned quickly and modeling occurs. The quick design leads to construction of a prototype. The prototype is deployed and then evaluated by the customer/ user feedback and is used to refine requirements for the software. Iterations occur as the prototype is tuned to satisfy the needs of the customer, while at the same time enabling the developer to better understand what needs to be done.

Ideally, the prototype serves as a mechanism for identifying software requirements. If a working prototype is built, the developer attempts to make use of existing program fragments or applies tools (e.g., report generators, window managers, etc.) that enable working programs to be generated quickly.

But what do we do with the prototype when it has served the purpose described above? Brooks provides one answer:

In most projects, the first system built is barely usable. It may be too slow, big, and awkward in use or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved… when a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so sure whether to build a pilot system and throw it away, You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers.

The prototype can serve as “the first system,” the one that books recommended we throw away. But this may be an idealized view. It is true that both customers and developers like the prototyping paradigm. Users get a feel for the actual system, and developers get to build something immediately. Yet, prototyping can be problematic for the following reasons:

1. The customer sees what appears to be working gum and balling wire, “unaware that in the rush to get it working we haven’t considered overall software quality or long-term maintainability. When informed that the product must be rebuilt so that high-levels of quality can be maintained, the customer demands that “a few fixes” be applied to make the prototype a working product. Too often, software development management relents.

2. The developer often makes implementation compromises in order to get a prototype to get a prototype working quickly. An inappropriate operating system or programming language may be used simply because it is available and known: an inefficient algorithm may be implemented simply to demonstrate capability. After a time, the developer may become comfortable with these choices and forget all the reasons why they were inappropriate. The less-than-ideal choice has now become an integral part of the system.

Although problems can occur, prototyping can be an effective paradigm for software engineering. The key is to define the rules of the game at the beginning: that is, the customer and developer must both agree that the prototype is built to serve as a mechanism for defining requirements. It is then discarded (at least in part), and the actual software is engineered with an eye towards quality.

b) The Spiral Model

The spiral model, originally proposed by Boehm is an evolutionary software process that couples the iterative nature of prototyping with the controlled and systematic nature of the waterfall model. It provides the potential for rapid development of increasingly more complete versions of the software.

Using a spiral model, software is developed in a series of evolutionary releases. During early iterations, the release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineering systems are produced.

A spiral model is divided into a set of frame work activities defined by the software engineering team. For illustrative purposes, we use the generic framework activities discussed earlier. Each of the framework activities represent one segment of the spiral part. As this evolutionary process begins, the software team performs activities that are implied by a circuit around the spiral in a clock wise direction, beginning at the center.

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 adjustment 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 first circuit around the spiral might represent a “concept developer project” which starts at the core of the spiral and continues for multiple iterations until concept development is complete. If the concept is to be developed into an actual product, the process proceeds outward on the spiral and a “new product development project” commences .The new product will evolve through a number of iterations around the spiral. The spiral, when characterized in this way, remains operative until the software is retired. There are times when the process is dormant, but whenever a change is initiated, the process starts at the appropriate entry point. The spiral model uses prototyping as a risk reduction mechanism but, more importantly enables the developer to apply the prototyping approach at any stage in the evolution of the product.

It may be difficult to convince customer that the evolutionary approach is controllable. It demands considerable risk as assessment expertise and relies on this expertise for success. If a major risk is not uncovered and managed, problems will undoubtedly occur.

c) The Concurrent Development Model

The concurrent development model, also called concurrent engineering, can be represented schematically as a series of framework activities, software engineering actions and tasks, and their associated states. For example, the modeling activity defined for the spiral model is accomplished by invoking the following actions: prototyping and/or analysis modeling and specification and design.

The concurrent process a series of events that will trigger transitions from state to state for each of the software engineering activities, actions, or tasks. For example, during early stages of design (a software engineering actions that occur during the modeling activity), an inconsistency in the analysis model is uncovered. This generates the event analysis model correction which will trigger the analysis action from the done state into the awaiting changes state.

The concurrent process defines a series of events that will trigger from state to state for each of the software engineering activities, actions or tasks. For example, during early stages of design (a software engineering actions that occur during the modeling activity), an inconsistency in the analysis model is uncovered. This generates the event analysis model correction which will trigger the analysis action from the done state into the awaiting changes state.


Commercial off- the shelf (COTS) software components, developed by vendors to offer them as products, can be used, when software is to be built. These components provide targeted functionality with well- defined interfaces that enable the components to be integrated into the software.

The component- based development model incorporates many of the characteristics of the spiral model. It is evolutionary in nature demanding an iterative approach to the creation of software. However, the model composes applications from pre-packaged software components.

Modeling and construction activities begin with the identification of candidate components. These components can be designed as either conventional software modules or object-oriented classes or packages of classes. Regardless of the technology that is used to create thee components, the component based development model incorporates the following steps (implemented using an evolutionary approach);

• Available component-based products are researched and evaluated for thee application domain in question.
• Component integration issues are considered.
• A software architecture is designed to accommodate thee components.
• Components are integrated into the architecture.
• Comprehensive testing is conducted to ensure proper functionality.

The component- based development model leads to software reuse, and reusability provides software engineers with a number of measurable benefits.


The formal methods model encompasses a set of activities that lads to formal mathematical specification of computer software. Formal methods enable a software engineer to specify develop, and verify a computer- based system by applying a rigorous, mathematical notation. A variation on this approach, called clan-room software engineering, is currently applied by some software development organizations.

Alan Perlis: “It is easier to write an incorrect program than understand a correct one.”

When formal methods are used during development, they provide a mechanism for eliminating many of the problems that are difficult to overcome using other software engineering paradigms. Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily- not through ad hoc review, but through the application of mathematical analysis. When formal methods are used during design, they serve as a basis for program verification and therefore, enable the software engineer to discover and correct errors that might otherwise go undetected.

Although not a mainstream approach, thee formal methods offer the promise of detect-free software. Yet, concern about its applicability in a business environment has been voiced.

• The development of formal models is currently quite time- consuming and expensive.
• Because few software developers have the necessary background to apply formal methods, extensive training is required.
• It is difficult to use the models as a communication mechanism for technically unsophisticated customers.

These concerns notwithstanding, the formal methods approach has gained adherence among software developers who must build safety- critical software (e.g., developers of aircraft avionics and medical devices) and among developers who would suffer severe economic hardship should software errors occur.

Aspect-Oriented Software Development

Regardless of the software process that is chosen, the builders of complex software invariably implement a set of localized features, functions, and information content. These localized software characteristics are modeled as components (e.g., object- oriented classes) and then constructed within the context of a system architecture. As modern computer- based systems become more sophisticated (and complex), certain “concerns”----- customer required properties or areas of technical interest ---- span the entire architecture. Some concerns are high- level properties of a system (e.g., security, fault tolerance), other concerns affect functions (e.g., the application of business rules), while others are systemic (e.g., task synchronization or memory management).

When concerns cut across multiple system functions, features, and information, they are often referred to as crosscutting concerns. Aspectual requirements define those crosscutting concerns that have impact across the software architecture. Aspect- oriented software development ( AOSD), often referred to as aspect- oriented programming (AOP), is a relatively new software engineering paradigm that provides a process and methodological approach for defining, specifying, designing, and constructing aspects--- “Mechanism beyond subroutines and inheritance for localizing the expression of a crosscutting concern.”

Grundy provides further discussion of aspects in the context of what he calls aspect- oriented component engineering (AOCE):

AOCE uses a concept of horizontal slices through vertically – decomposed software components, called “aspects, “to characterize cross- cutting functional and non-functional properties of components. Common, systemic aspects include user interfaces, collaborative, work, distribution, persistency, memory management, transaction processing, security, integrity and so on. Components may provide or require one or more “ aspect details” relating to a particular aspect, such as a viewing mechanisms, extensible affordance and interface kind ( user interface aspects): event generation, transport and receiving (distribution aspects); data store/ retrieve and indexing (persistency aspects); authentication ,encoding and access rights (security aspects); transaction atomicity, concurrency control and logging strategy ( transaction aspects); and so on, Each aspect detail has a number of properties, relating to functional and/or non-functional characteristics of the aspect detail.

A distinct aspect- oriented process has not yet matured. However, it is likely that such a process will adopt characteristics of both the spiral and concurrent process models. The evolutionary nature of the spiral is appropriate as aspects are identified and then constructed. The parallel nature of concurrent development is essential because aspects are engineered independently of localized software components and yet, aspect have a direct impact on these components. Hence, it is essential to instantiate asynchronous communication between the software process activities applied to the engineering and construction of aspects and components.

The United Process

The united process recognizes the importance of customer communications and streamlined methods for describing the customer‘s view of a system.

In their seminal book on the United Process, Ivar Jacobson, Grady Booth, and James Rumbaugh discuss the need for a “use- case driven architecture- centric, iterative and incremental” software process when they state:

Today, the trend in software is toward bigger and more complex systems. That is due in part to the fact that computers, become more powerful every year, leading users to expect more from them. This trend has also been influenced by the expending use of the internet for exchanging all kinds of information …. Our appetite for ever – more sophisticated software grows as we learn from one product release to the next how the product could be improved. We want software that is better adapted to our needs, but that, in turn, merely makes the software more complex. In short, we want more.

In some ways the United Process (UP) is an attempt to draw on the best features and characteristics of conventional software process models, but characterize them in a way that implements many of the best principles of agile software development. The United Process recognizes the importance of customer communication and streamlined methods for describing the customer’s view of a system (i.e., the use case). It emphasizes the important role of software architecture and helps the architect focus on the right goals, such as understandability, reliance to future changes, and reuse.” It suggests a process flow that is iterative and incremental. Providing the evolutionary feel that is essential in modern software department.

In this section we present an overview of the key elements of the United Process. In Part 2 of this book, we discuss the methods that populate the process and the complementary UML modeling techniques and notations that are required as the United Process is applied in actual software engineering work.

A Brief History:

During the 1980s and into the early 1990s, object- oriented (OO) methods and programming languages gained a widespread audience throughout the software engineering community. A wide variety of object- oriented analysis (OOA) and design (OOD) methods were proposed during the same time period, and a general purpose object- oriented process model (similar to the evolutionary models presented in this chapter) was introduced. Like most “new” paradigms for software engineering, adherents of each of the OOA and OOD methods argued about which was best, but no individual method or language dominated the software engineering landscape.

During the early 1990s James Rumbagh, Grady Booch, and Ivar Jacobson began working on a “United method” that would combine the best features of each of their individual methods and adopt additional features proposed by other expert (e.g., in the OO field). The result was UML--- a unified modeling language that contains a robust notation for the modeling and development of OO systems. By 1997, UML become an industry standard for object- oriented software development. At the same time, the Rational Corporation and Other vendors developed automated tools to support UML methods.

UML provides the necessary technology to support object-oriented software engineering practice, but it does not provide thee process framework to guide project teams in their application of the technology. Over the next few years, Jacobson, Rumbaugh, and Booch developed the United Process, a framework for object- oriented software engineering using UML. Today, the United Process and UML are widely used on OO projects of all kinds. The iterative, incremental model proposed by the UP can and should be adapted to meet specific project needs.

An array of work products (e.g., models and documents) can be produced as a consequence of applying UML. However, these are often pared down by software engineers to make development more agile and more responsive to change.

The Various Phases of the United Process are

1. Inception phase of the UP encompasses both customer communication and planning activities. By collaborating with thee customer and end-user, business requirements for the software are identified, a rough architecture for the system is proposed, and a plan for the iterative, incremental nature of the ensuring project is developed.

2. Elaboration phase encompasses the customer communication and modeling activities of the generic process model. Elaboration refines and expands the preliminary use- cases that were developed as part of the inception phase and expands the architectural representation to include five different views of the software-the use-case model, the analysis model, the design model, the implementation model, and the deployment, model.

Construction phase of the UP is identical with the construction activity defined for the generic software process. Using the architectural model as input, the construction phase develops or acquires the software components that will make each use- case operational for end-users.

1. Transition phase of the UP encompasses the latter stages of the generic construction activities and the first part of the generic deployment activity. Software is given to end-users for beta testing, and user feedback reports both for defects and necessary changes.

2. Production phase of the UP coincides with the deployment activity of the generic process. During this phase, the on-going use of the software is monitored, support for the operating environment (infrastructure) is provided, and defect reports and requests for changes are submitted and evaluated.


• The waterfall model is a linear progression of framework activities that is often inconsistent with modern realities (e.g., continuous change, evolving systems, tight timelines) in the software world.

• Incremental software process models produce software as a series of increment releases. The RAD model is designed for larger projects that must be delivered in tight time frames.

• Evolutionary process models recognize the iterative nature of most software engineering projects and are designed to accommodate change.

• The component-based model emphasizes component reuse and assembly.

• The Unified process is a “use-case driven, architecture- centric, iterative and incremental” software process designed as a framework for UML methods and tools.
Copyright © 2015         Home | Contact | Projects | Jobs

Review Questions
  • 1. What are process models? Describe the various models as approaches to software development.
  • 2. Define the term Evolutionary process models. Explain various such models available for a software engineer.
  • 3. What is component based development under software engineering? Discuss the various characteristics of the spiral model. Explain the various benefits of component based development models.
  • 4. What is the unified process? What are the various phases of this process?
  • 5. Describe the process? What are the various phases of this process?
  • 6. Describe the process framework and the various elements involved in the generic process.
  • 7. Write short note on:
    a) End product and the process.
    b) Process patterns.
    c) CMMI
    d) Process Technology.
Copyright © 2015         Home | Contact | Projects | Jobs

Related Topics
Software Engineering Process Models Keywords
  • Software Engineering Process Models Notes

  • Software Engineering Process Models Programs

  • Software Engineering Process Models Syllabus

  • Software Engineering Process Models Sample Questions

  • Software Engineering Process Models Subjects

  • EMBA Software Engineering Process Models Subjects

  • Software Engineering Process Models Study Material

  • BBA Software Engineering Process Models Study Material