SOFTWARE ENGINEERING (017013493), 1ST SEM

Chapter 1: Introduction to Software Engineering & Software process models

❖ What is software?
➢ Software is: (1) set of instructions (computer programs) that when executed provide desired features,
function, and performance; (2) data structures that enable the programs to adequately manipulate
information, and (3) descriptive information (documentation) in both hard copy and virtual forms that
describes the operation and use of the programs.

❖ What is software engineering?

➢ Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of engineering to software.
(2) The study of approaches as in (1).
➢ Software Engineering is an engineering discipline that is concerned with all aspects of software
production from the early stages of system specification through to maintaining the system has gone into
use.

❖ Framework activities:
➢ A generic process framework for software engineering encompasses five activities:
• Communication
➢ Before any technical work can commence, it is critically important to communicate and collaborate with
the customer (and other stakeholders). The intent is to understand stakeholders’ objectives for the project
and to gather requirements that help define software features and functions.
• Planning
➢ Any complicated journey can be simplified if a map exists. A software project is a complicated journey,
and the planning activity creates a “map” that helps guide the team as it makes the journey. The map
called a software project plan defines the software engineering work by describing the technical tasks to
be conducted, the risks that are likely, the resources that will be required, the work products to be
produced, and a work schedule.
• Modelling
➢ Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a carpenter, or an architect, you
work with models every day. You create a “sketch” of the thing so that you’ll understand the big picture
what it will look like architecturally, how the constituent parts fit together, and many other
characteristics. If required, you refine the sketch into greater and greater detail in an effort to better
understand the problem and how you’re going to solve it. A software engineer does the same thing by
creating models to better understand software requirements and the design that will achieve those
requirements.
• Construction
➢ This activity combines code generation (either manual or automated) and the testing that is required to
uncover errors in the code.
• Deployment
➢ The software (as a complete entity or as a partially completed increment) is delivered to the customer
who evaluates the delivered product and provides feedback based on the evaluation.

❖ Software Development Life cycle (SDLC):

1. Analysis
2. Design
3. Code
4. Test

❖ Generic Process framework:

➢ Software engineering process framework activities are complemented by a number of umbrella

Prepared By: Mr. Mohammedadil Shaikh Page

 SOFTWARE ENGINEERING (017013493), 1ST SEM
Chapter 1: Introduction to Software Engineering & Software process models
activities. In general, umbrella activities are applied throughout a software project and help a software
team manage and control progress, quality, change, and risk.
➢ Typical umbrella activities include:
1. Software project tracking and control: allows the software team to assess progress against the project
plan and take any necessary action to maintain the schedule.
2. Risk management: assesses risks that may affect the outcome of the project or the quality of the
product.
3. Software quality assurance (SQA): defines and conducts the activities required to ensure software
quality.
4. Technical reviews: assesses software engineering work products in an effort to uncover and remove
errors before they are propagated to the next activity.
5. Measurement: defines and collects process, project, and product measures that assist the team in
delivering software that meets stakeholders’ needs; can be used in conjunction with all other framework
and umbrella activities.
6. Software configuration management (SCM): manages the effects of change throughout the software
process.
7. Reusability management: defines criteria for work product reuse (including software components) and
establishes mechanisms to achieve reusable components.
8. Work product (WP) preparation and production: encompasses the activities required to create work
products such as models, documents, logs, forms, and lists.

Figure 1: A Generic Process Model

Prepared By: Mr. Mohammedadil Shaikh Page
 SOFTWARE ENGINEERING (017013493), 1ST SEM
Chapter 1: Introduction to Software Engineering & Software process models
❖ Prescriptive Process model:
➢ “Prescriptive” because they prescribe a set of process elements, framework activities, SE actions, tasks,
work products, quality assurance, and change control mechanisms for each project. Each process model
also prescribes a process flow.

Figure 2: Classification of Prescriptive Process Model

❖ Waterfall model:
➢ The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential approach
to software development that begins with customer specification of requirements and progresses through
planning, modelling, construction, and deployment, culminating in ongoing support of the completed
software.

Figure 3: The Waterfall Model

➢ The waterfall model is the oldest paradigm for software engineering. However, over the past three
decades, criticism of this process model has caused even ardent supporters to question its efficiency.
Among the problems (Disadvantages) that are sometimes encountered when the waterfall model is
applied are:
1. Real projects rarely follow the sequential flow that the 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.
2. It is often difficult for the customer to state all requirements explicitly. The waterfall model requires this
and has difficulty accommodating the natural uncertainty that exists at the beginning of many projects.
3. The customer must have patience. A working version of the program(s) will not be available until late in
the project time span. A major blunder, if undetected until the working program is reviewed, can be
disastrous.
4. Linear nature leads to the “blocking” states in which some team members must wait for others to
complete dependent tasks.
❖ Incremental model:
➢ 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

Prepared By: Mr. Mohammedadil Shaikh Page

 SOFTWARE ENGINEERING (017013493), 1ST SEM
Chapter 1: Introduction to Software Engineering & Software process models
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. The incremental model combines elements of
linear and parallel process flows.

Figure 4: The Incremental Process Model

➢ For example, word-processing software developed using the incremental paradigm might deliver basic
file management, editing, and document production functions in the first increment; more sophisticated
editing and document production capabilities in the second increment; spelling and grammar checking
in the third increment; and advanced page layout capability in the fourth increment. It should be noted
that the process flow for any increment can incorporate the prototyping paradigm.
➢ 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). As a result of
use and/or evaluation, a plan is developed for the next increment. The plan addresses the modification of
the core product to better meet the needs of the customer and the delivery of additional features and
functionality. This process is repeated following the delivery of each increment, until the complete
product is produced.
• Advantages:
1. The increment model is useful when the size of the development team is small or some team members
are not available.
2. Increments can be properly planned to handle technical risks.
3. The customer can give feedback on increments.
4. Initial Product delivery is fast.
• Disadvantages:
1. It needs a very clear and complete planning and design before the whole system is broken into
increments.
2. Additional demands of customer after each increment can cause problems.
❖ RAD model:
➢ Rapid application development (RAD) is an incremental software development process model that
emphasizes an extremely short development cycle. If requirements are well understood and project
scope is constrained, the RAD process enables a development team to create a “fully functional system”
within very short time periods (e.g.: 60 to 90 days)
➢ The RAD Model encompasses the following phases:
1. Business modeling. The information flow among business functions is modeled in a way that answers
the following questions: What information drives the business process? What information is generated?

Prepared By: Mr. Mohammedadil Shaikh Page

 SOFTWARE ENGINEERING (017013493), 1ST SEM
Chapter 1: Introduction to Software Engineering & Software process models
Who generates it? Where does the information go? Who processes it?
2. Data modeling. The information flow defined as part of the business modeling phase is refined into a set
of data objects that are needed to support the business. The characteristics (called attributes) of each
object are identified and the relationships between these objects defined.
3. Process modeling. The data objects defined in the data modeling phase are transformed to achieve the
information flow necessary to implement a business function. Processing descriptions are created for
adding, modifying, deleting, or retrieving a data object.
4. Application generation. RAD assumes the use of fourth generation techniques. Rather than creating
software using conventional third generation programming languages the RAD process works to reuse
existing program components (when possible) or create reusable components (when necessary). In all
cases, automated tools are used to facilitate construction of the software.
5. Testing and turnover. Since the RAD process emphasizes reuse, many of the program components
have already been tested. This reduces overall testing time. However, new components must be tested
and all interfaces must be fully exercised.
• Disadvantages:
1. For large but scalable projects, RAD requires sufficient human resources to create the right number of
RAD teams.
2. RAD requires developers and customers who are committed to the rapid-fire activities necessary to get a
system complete in a much-abbreviated time frame. If commitment is lacking from either constituency,
RAD projects will fail.
3. Not all types of applications are appropriate for RAD. If a system cannot be properly modularized,
building the components necessary for RAD will be problematic. If high performance is an issue and
performance is to be achieved through tuning the interfaces to system components, the RAD approach
may not work.
4. RAD is not appropriate when technical risks are high. This occurs when a new application makes heavy
use of new technology or when the new software requires a high degree of interoperability with existing
computer programs.

Figure 5: The RAD Model

❖ Prototype model:
➢ 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

Prepared By: Mr. Mohammedadil Shaikh Page

 SOFTWARE ENGINEERING (017013493), 1ST SEM
Chapter 1: Introduction to Software Engineering & Software process models
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 communication. You meet with other stakeholders to 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 (in the form of
a “quick design”) occurs. A quick design focuses on a representation of those aspects of the software that
will be visible to end users (e.g., human interface layout or output display). Both stakeholders and
software engineers like the prototyping paradigm. Users get a feel for the actual system, and developers
get to build something immediately.
• Disadvantages:
1. Stakeholders see what appears to be a working version of the software, unaware that the Prototype is held
together haphazardly, unaware that in the rush to get it working you 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, stakeholders cry foul and demand that “a few fixes” be applied to make the
prototype a working product.
2. As a software engineer, you often make implementation compromises in order 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, you 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.

Figure 6: Prototype Model

❖ Spiral model:
➢ It is an evolutionary software process model that couples the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model. It provides the potential for rapid
development of increasingly more complete versions of the software. Two main distinguishing
features of Spiral Model are (1) Cyclic Approach and (2) Anchor point Milestones
➢ Using the spiral model, software is developed in a series of evolutionary releases. During early
iterations, the release might be a model or prototype. During later iterations, increasingly more
complete versions of the engineered system are produced.

Prepared By: Mr. Mohammedadil Shaikh Page

 SOFTWARE ENGINEERING (017013493), 1ST SEM
Chapter 1: Introduction to Software Engineering & Software process models

Figure 7: The Spiral Model

➢ A spiral model is divided into a set of framework activities defined by the software engineering team.
Each of the framework activities represent one segment of the spiral path illustrated in Figure 7. As this
evolutionary process begins, the software team performs activities that are implied by a circuit around
the spiral in a clockwise direction, beginning at the center. Risk is considered as each revolution is made.
Anchor point milestones—a combination of work products and conditions that are attained along the
path of the spiral— are noted for each evolutionary pass.
➢ 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 is a realistic approach to the development of large-scale systems and software. Because
software evolves as the process progresses, the developer and customer better understand and react to
risks at each evolutionary level. The spiral model uses prototyping as a risk reduction mechanism but,
more important, enables you to apply the prototyping approach at any stage in the evolution of the
product. It maintains the systematic stepwise approach suggested by the classic life cycle but
incorporates it into an iterative framework that more realistically reflects the real world. 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.
• Disadvantages:
1. May be difficult to convince customers that the evolutionary approach is controllable
2. It demands considerable risk assessment expertise and relies on this expertise for success. If a major risk is
not uncovered and managed, problems will undoubtedly occur.

Prepared By: Mr. Mohammedadil Shaikh Page