UNIT 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.
❖ Difference between Program and Software:
Program
Software
Small in size.
Large in size.
Authors himself is user-soul.
Large number.
Single developer.
Team developer.
Adopt development.
Systematic development.
Lack proper interface.
Well define interface.
Large proper documentation.
Well documented
❖ 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 in
to use.
❖ Generic Process framework:
➢ A software process is defined as a collection of work activities, actions, and tasks that are performed
when some work product is to be created.
➢ Each of these activities, actions, and tasks reside within a framework or model that defines their
relationship with the process and with one another.
➢ Each framework activity is populated by a set of software engineering actions.
➢ Each software engineering action is defined by a task set that identifies the work tasks that are to be
completed, the work products that will be produced, the quality assurance points that will be required,
and the milestones that will be used to indicate progress.
➢ A generic process framework for software engineering encompasses five activities— communication,
planning, modeling, construction, and deployment.
➢ In addition, it defines a set of umbrella activities.
Page | 1
UNIT 1: INTRODUCTION TO SOFTWARE ENGINEERING
& SOFTWARE PROCESS MODELS
Figure.1: A Generic Process Model
❖ Framework activities:
1) 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.
2) 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.
3) 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
Page | 2
UNIT 1: INTRODUCTION TO SOFTWARE ENGINEERING
& SOFTWARE PROCESS MODELS
characteristics. If required, you refine the sketch in to 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.
4) Construction
➢ This activity combines code generation (either manual or automated) and the testing that is required to
uncover errors in the code.
5) 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.
2.
3.
4.
Analysis
Design
Code
Test
❖ Umbrella Activities:
➢ Software engineering process framework activities are complemented by a number of umbrella
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—defines and conducts the activities required to ensure software quality.
4) Technical reviews—assess 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—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 preparation and production—encompasses the activities required to create work
products such as models, documents, logs, forms, and lists.
Page | 3
UNIT 1: INTRODUCTION TO SOFTWARE ENGINEERING
& SOFTWARE PROCESS MODELS
❖ Prescriptive Process model:
➢ “Prescriptive” because they prescribe a set of process elements, frame work 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
➢ When to use waterfall model?
•
•
•
•
•
•
Requirements are very well known, clear and fixed
Product definition is stable
Technology is understood
There are no ambiguous requirements
Ample resources with required expertise are available freely
The project is short
➢ 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 efficacy.
Among the problems (Disadvantages) that are sometimes encountered when the waterfall model is
applied are:
Page | 4
UNIT 1: INTRODUCTION TO SOFTWARE ENGINEERING
& SOFTWARE PROCESS MODELS
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
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.
Page | 5
UNIT 1: INTRODUCTION TO SOFTWARE ENGINEERING
& SOFTWARE PROCESS MODELS
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).
Figure.5: The RAD Model
➢ 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?
Who generates it? Where does the information go? Who processes it?
2. Data modeling. The information flow defined as a 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.
Page | 6
UNIT 1: INTRODUCTION TO SOFTWARE ENGINEERING
& SOFTWARE PROCESS MODELS
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 th program components have
already been tested. This reduces overall testing time. However, new components must be tested and all
interfaces must be fully exercised.
• When to use RAD model?
1. RAD should be used when there is a need to create a system that can be modularized in 2-3 months of
time.
2. It should be used if there’s high availability of designers for modeling and the budget is high enough to
afford their cost along with the cost of automated code generating tools.
3. RAD SDLC model should be chosen only if resources with high business knowledge are available and
there is a need to produce the system in a short span of time (2-3 months).
•
1.
2.
3.
4.
5.
Advantages:
Reduced development time.
Increases reusability of components
Quick initial reviews occur
Encourages customer feedback
Integration from very beginning solves a lot of integration issues.
• 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.
❖ Evolutionary Models:
➢ Software, like all complex systems, evolves over a period of time. 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 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. In these and similar
situations, you need a process model that has been explicitly designed to accommodate a product that
evolves over time.
❖ 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
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.
Page | 7
UNIT 1: INTRODUCTION TO SOFTWARE ENGINEERING
& SOFTWARE PROCESS MODELS
Figure.6: Prototype Model
➢ 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 displays Both stakeholders and
software engineers like the prototyping paradigm. Users get a feel for the actual system, and developers
get to build something immediately.
• When to use Prototype Model?
1. Prototype model should be used when the desired system needs to have a lot of interaction with the
endusers.
2. Typically, online systems, web interfaces have a very high amount of interaction with end users, are
best suited for Prototype model. It might take a while for a system to be built that allows ease of use
and needs minimal training for the end user.
3. Prototyping ensures that the end users constantly work with the system and provide a feedback
which is incorporated in the prototype to result in a useable system. They are excellent for
designing good human computer interface systems.
•
Advantages
1. Users are actively involved in the development
2. Since in this methodology a working model of the system is provided, the users get a better
understanding of the system being developed.
3. Errors can be detected much earlier.
4. Quicker user feedback is available leading to better solutions.
5. Missing functionality can be identified easily
6. Confusing or difficult functions can be identified
•
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.
Page | 8
UNIT 1: INTRODUCTION TO SOFTWARE ENGINEERING
& SOFTWARE PROCESS MODELS
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.
❖ Spiral model:
➢ It was originally proposed by Barry Boehm, 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.
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 represents one segment of the spiral path illustrated in Figure. 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
Page | 9
UNIT 1: INTRODUCTION TO SOFTWARE ENGINEERING
& SOFTWARE PROCESS MODELS
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.
•
When to use spiral process model?
1. When costs and risk evaluation is important for medium to high-risk projects.
2. Long-term project commitment unwise because of potential changes to economic priorities
3. Users are unsure of their needs.
4. Requirements are complex
5. New product line Significant changes are expected (research and exploration)
•
Advantages:
1. High amount of risk analysis hence, avoidance of Risk is enhanced.
2. Good for large and mission-critical projects.
3. Strong approval and documentation control.
4. Additional Functionality can be added at a later date.
5. Software is produced early in the software life cycle.
•
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.
Page | 10