CS8494-SOFTWARE ENGINEERING

UNIT-I

1.1. INTRODUCTION TO SOFTWARE ENGINEERING

Software definition:
Definition 1: Software is instructions (computer programs) that are intended to provide desired
Features, function, and performance;
Definition 2: Software is a data structure that enables the programs to adequately manipulate information.
Characteristics of software are
1. Software is developed or engineered; it is not manufactured in the classical sense.
In both activities, high quality is achieved through good design, but the manufacturing phase
for hardware can introduce quality problems that are nonexistent for software
2. Software doesn’t “wear out.”
The failure rate curve for software should take the form of the “idealized curve” shown in
Figure. Undiscovered defects will cause high failure rates early in the life of a program. However, these
are corrected and the curve flattens as shown. The idealized curve is a gross oversimplification of actual
failure models for software. However, the implication is clear—software doesn’t wear out. But it does
deteriorate!

3. Although the industry is moving toward component-based construction, most software continues
to be custom built.
Software Application Domains
Seven broad categories of computer software
1) System software—a collection of programs written to service other programs. Some system
software are compilers, editors, and assembler. The purpose of the sysem software is to establish a
communication with the hardware.
2) Application software—stand-alone programs that solve a specific business need.
3) Engineering/scientific software—has been characterized by “number crunching” algorithms.
4) Embedded software—resides within a product or system and is used to implement and control
features and functions for the end user and for the system itself.
5) Product-line software—designed to provide a specific capability for use by many different
customers.
6) Web applications—called “WebApps,” this network-centric software category spans a wide
array of applications.
7) Artificial intelligence software—makes use of non numerical algorithms to solve complex
problems that are not amenable to computation or straightforward analysis.
Legacy software systems:
Legacy software systems . . . were developed decades ago and have been continually modified to meet
changes in business requirements and computing platforms.
A few simple realities to build software that is ready to meet the challenges of the twenty-first century
are:
1. A concerted effort should be made to understand the problem before a software solution is developed.
2. Design becomes a pivotal activity
3. Software should exhibit high quality
4. Software should be maintainable
Software in all of its forms and across all of its application domains should be engineered.
Software engineering:
A definition proposed by Fritz Bauer is
[Software engineering is] the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and works efficiently on real machines.
The IEEE definition is:
Software Engineering is the application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of engineering to software. .
Software engineering is a layered technology.

1) Quality focus
A disciplined quality management is a backbone of software engineering technology.
2) Process layer:
The foundation for software engineering is the process layer. Process defines a framework that
must be established for effective delivery of software engineering technology.
3) Methods:
Software engineering methods provide the technical how-to’s for building software. Methods encompass a
broad array of tasks that include communication, requirements analysis, design modeling, program
construction, testing, and support.
4) Tools:
Software engineering tools provide automated or semiautomated support for the process and the methods.
When tools are integrated so that information created by one tool can be used by another, a system for the
support of software development, called computer-aided software engineering, is established.
1.2. SOFTWARE PROCESS:

 A process is a collection of activities, actions, and tasks that are performed when some work
product is to be created.
 An activity strives to achieve a broad objective (e.g., communication with stakeholders) and is
applied regardless of the application domain, size of the project, complexity of the effort, or degree
of rigor with which software engineering is to be applied.
 An action (e.g., architectural design) encompasses a set of tasks that produce a major work product
(e.g., an architectural design model).
  A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a
tangible outcome.
 In the context of software engineering, a process is not a rigid prescription for how to build
computer software. Rather, it is an adaptable approach that enables the people doing the work (the
software team) to pick and choose the appropriate set of work actions and tasks. The intent is always
to deliver software in a timely manner and with sufficient quality to satisfy those who have
sponsored its creation and those who will use it.
A process framework establishes the foundation for a complete software engineering process by
identifying a small number of framework activities that are applicable to all software projects, regardless
of their size or complexity.
A generic process framework for software engineering encompasses five activities:
1) Communication:
Before any technical work can commence, it is critically important to communicate and collaborate with
the customer. The intent is to understand stakeholders’ objectives for the project and to gather requirements
that help define software features and functions.
2) Planning:
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) Modeling:
Software engineers will create models to better understand software requirements and the design that will
achieve those requirements.
4) Construction:
This activity combines code generation and the testing that is required uncovering errors in the code.
5) Deployment:
The software is delivered to the customer who evaluates the delivered product and provides feedback based
on the evaluation.
These five generic framework activities can be used during the development of small, simple programs, the
creation of large Web applications, and for the engineering of large, complex computer-based systems.
Umbrella activities:
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) A technical review—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.
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.

1.3. PRESCRIPTIVE PROCESS MODELS (OR) LIFE CYCLE MODELS:

The process model can be defined as the abstract representation of process. The appropriate
process model can be chosen based on abstract representation of process. These process models will
follow some rules for correct usage.
It is called “prescriptive” model because they prescribe a set of process elements—framework
activities, software engineering actions, tasks, work products, quality assurance, and change control
mechanisms for each project. Each process model also prescribes a process flow (also called a work flow)—
that is, the manner in which the process elements are interrelated to one another.
1.3.1. The Waterfall Model (or)classic life cycle (or) sequential life cycle model

(or) Software Development Life Cycle ( SDLC)

(or) Systems development life cycle (SDLC)

 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, modeling, construction, and deployment, culminating in ongoing
support of the completed software.
 The waterfall model is the oldest paradigm for software engineering.
 In requirement gathering and analysis phase the basic requirements of the system must be
understood by software engineer, who is called analyst.
 The design is an intermediate step between requirements analysis and coding.
Design focuses on:
1) Data Structure
2) Software architecture
3) Interface representation
4) Algorithm details
 Coding is a step in which design is translated into machine readable form.
 Testing begins when coding is done. The purpose of testing is to uncover errors, fix the bugs and
meet the customer requirements.
 Maintenance is the longest life cycle phase. The purpose of maintenance is when the system is
installed and put in practical use then error may get introduced, correcting such errors and putting it
in use.
Advantages:
1) The waterfall model is simple to implement
2) For implementation of small systems it is usefull.

Problems in waterfall model:

1. Real projects rarely follow the sequential flow that the model proposes. Changes can cause
confusion as the project team proceeds.
2. It is 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.
 V-Model: In each phase, testing will be done.

A variation in the representation of the waterfall model is called the V-model.

 The V-model depicts the relationship of quality assurance actions to the actions associated with
communication, modeling, and early construction activities. As a software team moves down the
left side of the V, basic problem requirements are refined into progressively more detailed and
technical representations of the problem and its solution.
 Once code has been generated, the team moves up the right side of the V, essentially performing a
series of tests (quality assurance actions) that validate each of the models created as the team moved
down the left side.
 In reality, there is no fundamental difference between the classic life cycle and the V-model. The
V-model provides a way of visualizing how verification and validation actions are applied to earlier
engineering work.
1.3.2. Incremental Process Models
 The incremental model combines elements of linear and parallel process flows.
 The incremental model delivers series of releases to the customer. These releases are called
increments. More and more functionality is associated with each increment.
 The incremental model combines elements of linear and parallel process flows. The incremental
model applies linear sequences in a staggered fashion as calendar time progresses.
 Each linear sequence produces deliverable “increments” of the software in a manner that is
similar to the increments produced by an evolutionary process flow.
When we can choose incremental:
1) When initial software requirements are reasonably well defined
2) When the overall scope of the development effort precludes a purely linear process.
3) When limited set of software functionality needed quickly
  The incremental model applies linear sequences in a staggered fashion as calendar time
progresses.
 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.
 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, 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.
 Incremental development is particularly useful when staffing is unavailable for a complete
implementation by the business deadline that has been established for the project. Early increments
can be implemented with fewer people.
 If the core product is well received, then additional staff (if required) can be added to implement
the next increment. In addition, increments can be planned to manage technical risks.
Advantages:
1) Generates working software quickly and early during the software life cycle.
2) This model is more flexible – less costly to change scope and requirements.
3) It is easier to test and debug during a smaller iteration.
4) In this model customer can respond to each built.
5) Lowers initial delivery cost.
6) Easier to manage risk because risky pieces are identified and handled during it’d iteration.
Disadvantages:
1) Needs good planning and design.
2) Needs a clear and complete definition of the whole system before it can be broken down and built
incrementally.
3) Total cost is higher than waterfall.
 1.3.3. Evolutionary Process Models
 Business and product requirements often change as development proceeds, making a straight line
path to an end product unrealistic; In such case, the iterative approach needs to be adopted. Evolutionary
process model is also called as iterative process model
 Evolutionary models are iterative. They are characterized in a manner that enables you to develop
increasingly more complete versions of the software.
1.3.3.1. Prototyping
 Software prototyping, refers to the activity of creating prototypes of software applications, i.e.,
incomplete versions of the software program being developed. It is an activity that can occur in software
development and is comparable to prototyping as known from other fields, such as mechanical engineering
or manufacturing.
 When we can choose Prototype:
o A customer defines a set of general objectives for software, but does not identify detailed
requirements for functions and features.
o The developer may be unsure of the efficiency of an algorithm, the adaptability of an
operating system
o When requirements are fuzzy
 Although prototyping can be used as a stand-alone process model, it is more commonly used as a
technique that can be implemented within the context of any one of the process models.
 Although prototyping can be used as a stand-alone process model, it is more commonly used as a
technique that can be implemented within the context of any one of the process models.
 The prototyping assists you and other stakeholders to better understand what is to be built when
requirements are fuzzy.
 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 formats).

 The quick design leads to the construction of a prototype. The prototype is deployed and
evaluated by stakeholders, who provide feedback that is used to further refine requirements.
  Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while at the
same time enabling you to better understand what needs to be done
 Ideally, the prototype serves as a mechanism for identifying software requirements. If a working
prototype is to be built, you can make use of existing program fragments or apply tools (e.g., report
generators and window managers) that enable working programs to be generated quickly.
 In most projects, the first system built is barely usable. It may be too slow, too big, 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.
 The prototype can serve as “the first system.” The one that Brooks recommends you throw away.
But this may be an idealized view. Although some prototypes are built as “throwaways,” others are
evolutionary in the sense that the prototype slowly evolves into the actual system.
 Both stakeholders and software engineers like the prototyping paradigm. Users get a feel for the
actual system, and developers get to build something immediately.
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 Requirements validation, Quick implementation
of, incomplete, but functional, application.
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.
2) Software engineer make implementation compromises in order to get a prototype working quickly.
3) 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.
Usage of prototyping:
 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, all stakeholders should
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 toward quality.

1.3.3.2. The Spiral Model.

 The spiral model 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.
 The spiral development model is a risk-driven process model generator that is used to guide multi-
stakeholder concurrent engineering of software intensive systems.
It has two main distinguishing features.
(1) One is a cyclic approach for incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk.
 (2) The other is a set of anchor point milestones for ensuring stakeholder commitment to feasible and
mutually satisfactory system solutions.
 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.
 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 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.

The functions of these four quadrants are discussed below-

 Objectives determination and identify alternative solutions (Concept development

projects): Requirements are gathered from the customers and the objectives are identified,
elaborated and analyzed at the start of every phase. Then alternative solutions possible for the
phase are proposed in this quadrant.
 Identify and resolve Risks (New product development projects): During the second quadrant
all the possible solutions are evaluated to select the best possible solution. Then the risks
associated with that solution is identified and the risks are resolved using the best possible
strategy. At the end of this quadrant, Prototype is built for the best possible solution.
 Develop next version of the Product (Product Enhancement projects): During the third
quadrant, the identified features are developed and verified through testing. At the end of the third
quadrant, the next version of the software is available.
 Review and plan for the next Phase (product Maintenance projects): In the fourth quadrant,
the Customers evaluate the so far developed version of the software. In the end, planning for the
next phase is started.
Advantages:
 High amount of risk analysis hence, avoidance of Risk is enhanced.
 Good for large and mission-critical projects.
  Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.
Disadvantages:
 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.
1.3.4. Concurrent development Models
 The concurrent development model, sometimes called concurrent engineering, allows a software
team to represent iterative and concurrent elements of any of the process models.
 For example, the modeling activity defined for the spiral model is accomplished by invoking one
or more of the following software engineering actions: prototyping, analysis, and design.
 Figure provides a schematic representation of one software engineering activity within the
modeling activity using a concurrent modeling approach. The activity—modeling—may be in any one of
the states noted at any given time.
 Similarly, other activities, actions, or tasks (e.g., communication or construction) can be
represented in an analogous manner. All software engineering activities exist concurrently but reside in
different states.
 For example, early in a project the communication activity (not shown in the figure) has completed
its first iteration and exists in the awaiting changes state. The modeling activity (which existed in the
inactive state while initial communication was completed, now makes a transition into the under
development state.
 If the customer indicates that changes in requirements must be made, the modeling activity moves
from the under development state into the awaiting changes state.
 Concurrent modeling defines 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 major software engineering action that occurs during
the modeling activity), an inconsistency in the requirements model is uncovered. This generates the
event analysis model correction, which will trigger the requirements analysis action from the done
state into the awaiting changes state.
 Concurrent modeling is applicable to all types of software development and provides an accurate
picture of the current state of a project. Rather than confining software engineering activities,
actions, and tasks to a sequence of events, it defines a process network.
 Each activity, action, or task on the network exists simultaneously with other activities, actions, or
tasks. Events generated at one point in the process network trigger transitions among the states.
Advantages:
1) The concurrent development model, sometimes called concurrent engineering. It’s can be
represented schematically as a series of frame work activities, software engineering actions,
software engineering task and their associated states.
2) The concurrent process model defines a series of events that will trigger transition from state to
state for each of the software engineering activities and action or task.
3) The concurrent process model is applicable to all types of software development and provides an
accurate picture of the current state of a project.
Disadvantages:
1) The SRS must be continually updated to reflect changes.
2) It requires discipline to avoid adding too many new features too late in the project.

1.4. SPECIALIZED PROCESS MODELS

 Specialized process models take on many of the characteristics of one or more of the traditional
models. However, these models tend to be applied when a specialized or narrowly defined software
engineering approach is chosen.

1.4.1. Component-Based Development

 Commercial off-the-shelf (COTS) software components, developed by vendors who offer them as
products, provide targeted functionality with well-defined interfaces that enable the component to be
integrated into the software that is to be built.
 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 component-based development model constructs applications from prepackaged
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
packages16 of classes.
 Regardless of the technology that is used to create the components, the component-based
development model incorporates the following steps (implemented using an evolutionary approach):
1) Available component-based products are researched and evaluated for the application domain in
question.
2) Component integration issues are considered.
3) Software architecture is designed to accommodate the components.
 4) Components are integrated into the architecture.
5) 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. Your software engineering team can achieve a
reduction in development cycle time as well as a reduction in project cost if component reuse becomes part
of your culture.
Advantages:
 The component based development model leads to software re-used and re-usability provides a
number of tangible benefits.
 It leads to reduction in development cycle time.
 It leads to significant reduction in project cost.
 It leads to significant increase in productivity.
Disadvantages:
1) Customization
2) Problem to adapt a component
3) The integration of a reusable component into new component is also a major problem
4) Security is another major concern for the developers
5) Efficiency of the Software applications developed using CBD is also debatable.
1.4.2. The Formal Methods Model
 The formal methods model encompasses a set of activities that leads to formal mathematical
specification of computer software. Formal methods enable you to specify, develop, and verify a computer-
based system by applying a rigorous, mathematical notation. A variation on this approach, called clean
room software engineering is currently applied by some software development organizations.
 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 you to discover and
correct errors that might otherwise go undetected.
Advantage:
 Although not a mainstream approach, the formal methods model offers the promise of defect-free
software.
Disadvantages:
1) The development of formal models is currently quite time consuming and expensive.
2) Because few software developers have the necessary background to apply formal methods,
extensive training is required.
3) It is difficult to use the models as a communication mechanism for technically unsophisticated
customers.

1.4.3. 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., objectoriented 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
an 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— “mechanisms
beyond subroutines and inheritance for localizing the expression of a crosscutting concern”
 A distinct aspect-oriented process has not yet matured. However, it is likely that such a process will
adopt characteristics of both evolutionary and concurrent process models. The evolutionary model 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, aspects 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.
COMPARISON OF DIFFERENT SDLC MODELS
Waterfall Model Spiral Model Prototyping Model Incremental Model

Requirements must be The requirements analysis Requirements analysis Requirements analysis

clearly understood and and gathering can be done in can be made in the later can be made in the later
defines at the beginning iteration because stages of the stages of the
only. requirements get changed development cycle. development cycle.
quite often. Because requirements
get changed quite often.
The development team The development team The development team The development team
having the adequate having the adequate having the adequate having the adequate
experience of working on experience of working on experience of working experience of working
the similar project is chose the similar project is on the similar project is on the similar project is
to work on this allowed in this process allowed in this process chose to work on this
type of process model model. model. type of process model
There is no user There is no user There is user There is user
involvement in all the involvement in all the involvement in all the involvement in all the
phases of development phases of development phases of development phases of development
process. process. process. process.
When the requirements Due to iterative nature of When developer is When the requirements
are reasonably well this model, the risk unsure about the are reasonably well
defined and the identification and efficiency of an defined and the
development effort rectification is done before algorithm or the development effort
suggests a purely linear they get problematic. adaptability of an suggests a purely linear
effort then the waterfall Hence for handling real time operating system then effort and when limited
model is chosen. problems the spiral model the prototyping model set of software
is chosen. is chosen. functionality is needed
quickly then the
incremental model is
chosen.
The comparison of the different models is represented in the following table on the basis of certain
features.

1.5 Introduction to Agility:

Agile is a time-bound, iterative approach to software delivery that builds software incrementally
from the start of the project, instead of trying to deliver all at once.

The agile manifesto for agile software development is a formal declaration of four values and 12
principles to guide an iterative and people centric approach to software development

Individuals and interactions over Process and Tools

Working software over Comprehensive documentation

Customer collaboration over Contact negotiation

Responding to changes over Following a Plan

Fig. Agile Manifesto

Why Agile?
Technology in this current era is progressing faster than ever, enforcing the global software
companies to work in a fast-paced changing environment. Because these businesses are operating in an
ever-changing environment, it is impossible to gather a complete and exhaustive set of software
requirements. Without these requirements, it becomes practically hard for any conventional software
model to work.
Agile was specially designed to meets the needs of the rapidly changing environment by
embracing the idea of incremental development and develop the actual final product.
1.6. Agile Process:
 In 1980’s the heavy weight, plan based software development approach was used to develop any
software product.
  In this approach too many things are done which were not directly related to software product
being produced.
 If requirements get changed, then rework was essential. Hence new methods were proposed in
1990’s which are known as agile process.
 The agile process is light-weight methods which are people-based rather than plan-based
methods.
 The agile process forces the development team to focus on software itself rather than design and
documentation.
 The agile process believes in iterative method.
 The aim of agile process is to deliver the working model of software quickly to the customer.
Conventional software Development Methodology:
 The conventional wisdom in software development is that the cost of change increases nonlinearly
as a project progresses.
 It is relatively easy to accommodate a change when a software team is gathering requirements. A
usage scenario might have to be modified, a list of functions may be extended, or a written
specification can be edited.
 As the progresses and if the customer suggest the changes during the testing phase of the SDLC then
to accommodate these changes the architectural design needs to be modified and ultimately these
changes will affect other phases of SDLC. These changes are actually costly to execute.
Agile Methodology:
When incremental delivery is coupled with other agile practices such as continuous unit testing and
pair programming then the cost of changes can be controlled.
The following graph represents the how the software development approach has a strong influence on
the development cost due to changes suggested.

1.6.1 Principles:
There are famous 12 principles used as agile principles:
1. Highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. It welcomes changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shortest timescale.
4. Business people and developers must work together throughout the project.
5. Build projects around motivated individuals. Give them the environment and the support they
need, and trust them to get the job done.
 6. The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote constant development. The sponsors, developers, and users should be
able to maintain a constant.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity the art of maximizing the amount of work not done is essential.
11. The team must be self– organizing teams for getting best architectures, requirements, and designs
emerge from
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly
1.7 Extreme programming:
Extreme programming (XP) is one of the best known agile processes.
1.7.1 XP values:
The set of five values that serve as a basis for all work performed as part of XP—communication,
simplicity, feedback, courage, and respect. Each of these values is used as a driver for specific XP activities,
actions, and tasks.
1. Communication:
To achieve effective communication between software engineers in order to covey
important concepts and to get continuous feedback.

2. Simplicity:
XP focuses on the current needs instead of future needs to incorporate in the design. Hence
the XP believes that the Software design should be simple.
3. Feedback:
The feedback for the software product can be obtained from the developers of the software,
customers and other software team members.
4. Courage:
the strict adherence to certain XP practices require courage. The agile XP team must be
disciplined to design the system today, recognize the future requirements and make the
changes dramatically as per demand.
5. Respect:
By following the above states XP values the agile team can win the respect of the
stakeholders.
1.7.2 Process:
The extreme programming process is explained as follows -
 Customer specifies and priorities the system requirements. Customer becomes or of the important
members of development team. The developer and customer together prepare a story-card in which
customer needs are mentioned. 
 The developer team then aims to implement the scenarios in the story-card.
 After developing the story-card the development team breaks down the total work in small tasks. The
efforts and the estimated resources required for these tasks are estimated.
 The customer priorities the stories for implementation. If the requirement changes then sometimes
unimplemented stories have to be discarded. Then release the complete software in small and frequent
releases.
 For accommodating new changes, new story-card must be developed.
 Evaluate the system along with the customer.
Various rules and practices used in extreme programming are as given below-
XP Principle Description

User story-cards Instead of creating a large requirement document user stories are
written by the customer in which what they need is mentioned.
Release planning A release plan for overall project is
prepared from which the iteration plan can be prepared for individual
iteration
Small releases The developer breaks down the user
Planning Stories into small releases and a plan for releasing the small
functionalities is prepared.
Iterative process Divide the development work into small iterations. Keep the iteration
of nearly constant length. Iterative development helps in quick or agile
development.
Stand up The stand up meetings must be, conducted for the current outcomes of
meetings the project.
Simple design Simple design always takes less time than the complex design. It is always
good to keep the things simple to meet the current requirements
Spike solution For answering the tough technical
problems create the spike solutions. The goal of these solutions
Designing
should be to reduce the technical risks.
Refactoring Refactoring means reductions in the redundancy, elimination of
unused functionalities, redesign the obsolete designs. This will
improve the quality of the project.
Customer The most essential requirement of the XP is availability of the
Coding availability customer. In Extreme programming the customer not only helps
the developer team but it should be the part of the project.
 Paired All the code to be included in the project must be coded by groups
programming of two people working at the same computer. This will increase the
quality of coding

Collective By having collective code ownership approach the everyone

code contributes new ideas and not any single person becomes the
ownership bottleneck of the project. Anyone can change any line of code to
fix a bug or to refactor.

Unit testing The test framework that contains automated test case suite is used to
the code. All the code must be using unit testing before its release.

Continuous As soon as one task is finished integrate it into the whole system.
integration Again after such integration unit testing must be conducted
Testing

No overtime Working overtime loses the spirit and motivation of the team. Conduct
the release of the team. Conduct the release planning meeting to
change the project scope or to reschedule the project

Applications of Extreme Programming (XP): Some of the projects that are suitable to develop
using XP model are given below:
 Small projects: XP model is very useful in small projects consisting of small teams as face to
face meeting is easier to achieve.
 Projects involving new technology or Research projects: This type of projects face changing
of requirements rapidly and technical problems. So XP model is used to complete this type of
projects.
1.7.3. Industrial XP:
The industrial XP (IXP) is an organic evolution of XP. It is customer-centric. It has expanded role for
customers, and its advanced technical practices.
Various new practices that are appended to XP to create IXP are as follows:
1. Readiness Assessment:
Prior to the initiation of an IXP project, the organization should conduct a readiness
assessment.
(1) an appropriate development environment exists to support IXP
(2) The team should contain appropriate and skilled stakeholders
(3) The organization has a distinct quality program and supports continuous improvement
(4) The organizational culture will support the new values of an agile team.
(5) The broader project community will be populated appropriately.
2. Project Community:
Skilled and efficient people must be chosen as the agile team members for the success of the
project. The team is reffered as the community when extreme programming approach is
considered. The project community consists of technologies, customers, and other stakeholders
 who play rthe vital role for the success of the project. The role of the community members must
be explicitly defined
3. Project charting:
Project charting means assessing the justification for the project as a business application. That
means, the IXP team assess whether the project satisfies the goals and objectives of the
organization.
4. Test driven management:
For assessing the state of the project and its progress the industrial XP needs some measurable
criteria. In test driven management the project is tested with the help of these measurable criteria.
5. Retrospectives:
After delivering the software increment, the specialized review is conducted which is called as
retrospective. The intention of retrospective is to improve the industrial XP process.
1.8 CMMI:
The Capability Maturity Model Integration (CMMI) is a capability maturity model developed by the
Software Engineering Institute, part of Carnegie Mellon University in Pittsburgh, USA. The CMMI
principal is that “the quality of a system or product is highly influenced by the process used to develop
and maintain it”. CMMI can be used to guide process improvement across a project, a division, or an
entire organization.
CMMI provides:
 Guidelines for processes improvement
 An integrated approach to process improvement
 Embedding process improvements into a state of business as usual
 A phased approach to introducing improvements
CMMI Models
CMMI consists of three overlapping disciplines (constellations) providing specific focus into the
Development, Acquisition and Service Management domains respectively:
 CMMI for Development (CMMI-DEV) – Product and service development
 CMMI for Services (CMMI-SVC) – Service establishment, management, and delivery
 CMMI for Acquisition (CMMI-ACQ) – Product and service acquisition
Originating in software engineering, CMMI has been highly generalised over the years to embrace other
business processes such as the development of hardware products, service delivery and purchasing which
has had the effect of abstracting CMMI.
 ANNA UNIVERSITY QUESTIONS
PART A
1. What is Software Engineering? NOV/DEC 2013, NOV / DEC 2014, APRIL/MAY 2017,
APRIL/MAY 2017
Software engineering is the application of a systematic, disciplined, quantifiable approach to the
development, operation and maintenance of software as well as the study of approaches of the same.
2. 'Software doesn't wear out'. Justify. NOV/DEC 2013, MAY/JUNE 2016
The failure rate curve for software should take the form of the “idealized curve” shown in Figure.
Undiscovered defects will cause high failure rates early in the life of a program. However, these are
corrected and the curve flattens as shown. The idealized curve is a gross oversimplification of actual failure
models for software. However, the implication is clear—software doesn’t wear out. But it does deteriorate!
Figure : Failure curves for software

3. Differentiate : Verification Vs Validation. NOV / DEC 2014

Verification Validation
The set of activities that ensure that software The set of activities that ensure that the
correctly implements a specific function. software has been built is traceable to customer
requirements
Verification represents the set of activities that Validation represents the set of activities that
are carried out to confirm that the software ensure that the software that has been
correctly implements the specific functionality built is satisfying the customer requirements.
4. Write the Process framework and Umbrella activities. APRIL/MAY 2015
 Software project tracking and control.
 Risk management.
 Software Quality Assurance.
 Formal Technical Reviews.
 Software Configuration Management.
 Work product preparation and production.
 Reusability management.
 Measurement.
5. What are the pros and cons of Iterative software development models? NOV/DEC 2015
The advantage of this model is that there is a working model of the system at a very early stage of
development which makes it easier to find functional or design flaws. Finding issues at an early
stage of development enables to take corrective measures in a limited budget.
 The disadvantage with this SDLC model is that it is applicable only to large and bulky software
development projects. This is because it is hard to break a small software system into further
small serviceable increments/modules.
6. If you have to develop a word processing software product, what process model will you
choose? Justify your answer. NOV/DEC 2016
Incremental model: 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
7. Depict the relationship between Work product, task, activity and System. NOV/DEC 2016,
APRIL/MAY 2017
 Each framework activity under umbrella activities of software process framework consists of
various task set.
 Each task set consists of work task, work products, quality assurance points and project
milestones. The task also accommodates the needs of the system getting developed.
8. List two deficiencies in waterfall model. Which process model do you suggest to overcome each
deficiency? APRIL/MAY 2017
i. It is difficult to define all the requirements at the beginning of project, this model is not suitable
for accommodating any changes.
To overcome this efficiency: prototyping
ii. It does not scale up to large project
To overcome this efficiency: spiral model.
9. What is software? List the characteristics. APRIL/MAY 2018
Software is instructions (computer programs) that are intended to provide desired Features,
function, and performance
Characteristics:
 Software is developed or engineered;
 Software doesn’t “wear out”
 most software continues to be custom built.
10. How does “project Risk” factor affect the spiral model of software development?
The spiral model demands considerable risk assessment because if a major risk is not uncovers
and managed, problems will occur in the project and then it will not be acceptable by end user.
11. What led to the transition from product oriented development to process oriented development
to process oriented development? APRIL/MAY 2016
The software process model led to the transition from product oriented development to process
oriented development.
12. What is the significance of the spiral model when compared with other models.
NOV/DEC 2017
1. High amount of risk analysis.
2. Good for large and mission-critical projects.
3. Software is produced early in the software life cycle.
13. Write a note on the unique characters of software. NOV/DEC 2017
 Functionality
 Reliability
 Usability
 Efficiency
  Maintainability
 Portability
14. What is software process?
The process model can be defined as the abstract representation of process. The appropriate process
model can be chosen based on abstract representation of process. These process models will follow some
rules for correct usage.
15. Define an evolutionary prototype.
 Evolutionary models are iterative. They are characterized in a manner that enables you to develop
increasingly more complete versions of the software.
 Software prototyping, refers to the activity of creating prototypes of software applications, i.e.,
incomplete versions of the software program being developed. 
16. List any two agile process model.
The following are the agile process model.
 Extreme Processing (XP)
 Agile Modeling
 Scrum

PART B
1. Compare the following life cycle models based on their distinguishing factors, strengths and
weaknesses — Waterfall Model, RAD Model, Spiral Model and Formal Methods Model. (Present in
the form of table only — use diagrams wherever necessary) NOV/DEC 2013, NOV/DEC 2018
2. Assume that you are the technical manager of a software development organization. A client
approached you for a software solution. The problems stated by the client have uncertainties which lead
to loss if it not planned and solved. Which software development model you will suggest for this project
– Justify. Explain that model with its pros and cons and neat sketch. NOV/DEC 2015
3. Explain the various levels of capability maturity model integration. NOV/DEC 2015
4. Discuss the prototyping model. What is the effect of designing a prototype on the overall cost of the
software project? MAY/JUNE 2016
5. Describe the type of situations where iterative enhancement model might lead to difficulties
MAY/JUNE 2016
6. Elucidate the key features of the software process models with suitable examples. MAY/JUNE 2016
7. What is the role of user participation in the selection of a life cycle model? MAY/JUNE 2016
8. Which process model is best suited for risk management? Discuss in detail with an example. Give the
advantages and disadvantages of the model. NOV/DEC 2016
9. List the principles of agile software development. NOV/DEC 2016, NOV/DEC 2019
10. What is a process model? Describe the process model that you would choose to manufacture a car.
Explain giving suitable reasons. MAY/JUNE 2017, NOV/DEC 2019 (Spiral Model)
QUESTION BANK
PART A
1. What is the impact of reusability in software development process?
2. Explain the component based software development model with a neat sketch.
3. What are the characteristics of software?
4. Software doesn’t wears out. Justify
5. What are the layers of software engineering?
6. Write down the generic process framework that is applicable to any software project.
7. List the goals of Software Engineering
8. Give two reasons why system engineers must understand the environment of a
system.
9. What are the two types of software products?
10. What is Software Engineering? What are their applications?
11. List out evolutionary software process model.
11. What are the difference between product and process?
12. What are the advantages and disadvantages of Waterfall Model?
13. What are the advantages and disadvantage of Incremental Model?
14. What are the advantages and disadvantages of Spiral Model?
15. Define Computer based system and specify its components.
16. What are the advantages and disadvantages of Prototyping Model?
17. Depict the relationship between work product, task, activity and system.
18. List two deficiencies in waterfall model. Which
process model do you suggest to overcome each
deficiency?
19. What are the pros and cons of Iterative software development models?
20. What is legacy software? What are characteristics of legacy software?
21. What is an agile process?
22. List out the principles of Agile.
PART B
1. Explain the following: (i) waterfall model (ii) Spiral model (iii) Prototyping
model
2. Discuss the various life cycle models in software development.
3. Compare and contrast the different lifecycle models.
4. Discuss in detail about any two evolutionary process models.
5. Explain in detail about the software process.
6. Which process model is best suit for risk management? Discuss in
detail with an example. Give advantages and disadvantages of the
model.
7. List the principles of agile development.
8. Explain in details about extreme programming XP process.
9. Explain about agile process.