UNIT – I

SOFTWARE PROCESS AND PROJECT MANAGEMENT

The evolving role of software – the changing nature of software-
Life cycle models - Water fall - Incremental - Spiral -
Evolutionary - Prototyping – Concurrent development –
Specialised process models - Verification - Validation - Life cycle
process - Development process - System engineering hierarchy -
Introduction to CMM - Levels of CMM

The Evolving role of software

INTRODUCTION:
Software Engineering is a framework for building software and is an
engineering approach to software development. Software programs
can be developed without S/E principles and methodologies but they
are indispensable if we want to achieve good quality software in a
cost effective manner.
Software is defined as:
Instructions + Data Structures + Documents
Engineering is the branch of science and technology concerned with
the design, building, and use of engines, machines, and structures. It
is the application of science, tools and methods to find cost effective
solution to simple and complex problems.
SOFTWARE ENGINEERING is defined as a systematic,
disciplined and quantifiable approach for the development, operation
and maintenance of software.
The Evolving role of software The dual role of Software is as follows:
1. A Product- Information transformer producing, managing and
displaying information.
 2. A Vehicle for delivering a product- Control of computer(operating
system),the communication of information(networks) and the creation
of other programs.
Characteristics of software
• Software is developed or engineered, but it is not manufactured in
the classical sense.
• Software does not wear out, but it deteriorates due to change.
• Software is custom built rather than assembling existing
components.

What is Software Engineering?

The term software engineering is the product of two

words, software, and engineering.

The software is a collection of integrated programs.

Software subsists of carefully-organized instructions and code written

by developers on any of various particular computer languages.

Computer programs and related documentation such as requirements,

design models and user manuals.

Engineering is the application of scientific and practical knowledge

to invent, design, build, maintain, and improve frameworks,
processes, etc.
Software Engineering is an engineering branch related to the
evolution of software product using well-defined scientific principles,
techniques, and procedures. The result of software engineering is an
effective and reliable software product.

Why is Software Engineering required?

Software Engineering is required due to the following reasons:

o To manage Large software

o For more Scalability
o Cost Management
o To manage the dynamic nature of software
o For better quality Management

Need of Software Engineering

The necessity of software engineering appears because of a higher
rate of progress in user requirements and the environment on which
the program is working.

o Huge Programming: It is simpler to manufacture a wall than to

a house or building, similarly, as the measure of programming
become extensive engineering has to step to give it a scientific
process.
o Adaptability: If the software procedure were not based on
scientific and engineering ideas, it would be simpler to re-create
new software than to scale an existing one.
o Cost: As the hardware industry has demonstrated its skills and
huge manufacturing has let down the cost of computer and
electronic hardware. But the cost of programming remains high
if the proper process is not adapted.
o Dynamic Nature: The continually growing and adapting nature
of programming hugely depends upon the environment in which
the client works. If the quality of the software is continually
changing, new upgrades need to be done in the existing one.
o Quality Management: Better procedure of software
development provides a better and quality software product.

Characteristics of a good software engineer

The features that good software engineers should possess are as

follows:

Exposure to systematic methods, i.e., familiarity with software

engineering principles.

Good technical knowledge of the project range (Domain knowledge).

Good programming abilities.

Good communication skills. These skills comprise of oral, written,

and interpersonal skills.
High motivation.

Sound knowledge of fundamentals of computer science.

Intelligence.

Ability to work in a team

Discipline, etc.

Importance of Software Engineering

The importance of Software engineering is as follows:

1. Reduces complexity: Big software is always complicated and

challenging to progress. Software engineering has a great
solution to reduce the complication of any project. Software
engineering divides big problems into various small issues. And
then start solving each small issue one by one. All these small
problems are solved independently to each other.
2. To minimize software cost: Software needs a lot of hardwork
and software engineers are highly paid experts. A lot of
manpower is required to develop software with a large number
of codes. But in software engineering, programmers project
 everything and decrease all those things that are not needed. In
turn, the cost for software productions becomes less as
compared to any software that does not use software
engineering method.
3. To decrease time: Anything that is not made according to the
project always wastes time. And if you are making great
software, then you may need to run many codes to get the
definitive running code. This is a very time-consuming
procedure, and if it is not well handled, then this can take a lot
of time. So if you are making your software according to the
software engineering method, then it will decrease a lot of time.
4. Handling big projects: Big projects are not done in a couple of
days, and they need lots of patience, planning, and management.
And to invest six and seven months of any company, it requires
heaps of planning, direction, testing, and maintenance. No one
can say that he has given four months of a company to the task,
and the project is still in its first stage. Because the company has
provided many resources to the plan and it should be completed.
So to handle a big project without any problem, the company
has to go for a software engineering method.
5. Reliable software: Software should be secure, means if you
have delivered the software, then it should work for at least its
given time or subscription. And if any bugs come in the
software, the company is responsible for solving all these bugs.
Because in software engineering, testing and maintenance are
given, so there is no worry of its reliability.
6. Effectiveness: Effectiveness comes if anything has made
according to the standards. Software standards are the big target
of companies to make it more effective. So Software becomes
more effective in the act with the help of software engineering.

Changing Nature of Software:

Nowadays, seven broad categories of computer software present

continuing challenges for software engineers. Which is given below:
1. System Software: System software is a collection of
programs that are written to service other programs. Some
system software processes complex but determinate,
information structures. Other system application processes
largely indeterminate data. Sometimes when, the system
software area is characterized by the heavy interaction with
computer hardware that requires scheduling, resource
sharing, and sophisticated process management.
2. Application Software: Application software is defined as
programs that solve a specific business need. Application in
this area processes business or technical data in a way that
facilitates business operation or management technical
decision-making. In addition to conventional data processing
applications, application software is used to control business
functions in real-time.
3. Engineering and Scientific Software: This software is used
to facilitate the engineering function and task. however
modern applications within the engineering and scientific
area are moving away from conventional numerical
algorithms. Computer-aided design, system simulation, and
other interactive applications have begun to take a real-time
and even system software characteristic.
4. Embedded Software: Embedded software resides within
the system or product and is used to implement and control
features and functions for the end-user and for the system
itself. Embedded software can perform limited and esoteric
functions or provide significant function and control
capability.
5. Product-line Software: Designed to provide a specific
capability for use by many customers, product-line software
can focus on the limited and esoteric marketplace or address
the mass consumer market.
6. Web Application: It is a client-server computer program
that the client runs on the web browser. In their simplest
form, Web apps can be little more than a set of linked
hypertext files that present information using text and
limited graphics. However, as e-commerce and B2B
 applications grow in importance. Web apps are evolving into
a sophisticated computing environment that not only
provides a standalone feature, computing function, and
content to the end user.
7. Artificial Intelligence Software: Artificial intelligence
software makes use of a nonnumerical algorithm to solve a
complex problem that is not amenable to computation or
straightforward analysis. Applications within this area
include robotics, expert systems, pattern recognition,
artificial neural networks, theorem proving, and game
playing.

Software Development Life Cycle (SDLC)

A software life cycle model (also termed process model) is a pictorial

and diagrammatic representation of the software life cycle. A life
cycle model represents all the methods required to make a software
product transit through its life cycle stages. It also captures the
structure in which these methods are to be undertaken.

In other words, a life cycle model maps the various activities

performed on a software product from its inception to retirement.
Different life cycle models may plan the necessary development
activities to phases in different ways. Thus, no element which life
cycle model is followed, the essential activities are contained in all
life cycle models though the action may be carried out in distinct
orders in different life cycle models. During any life cycle stage, more
than one activity may also be carried out.

Need of SDLC

The development team must determine a suitable life cycle model for
a particular plan and then observe to it.
Without using an exact life cycle model, the development of a
software product would not be in a systematic and disciplined
manner. When a team is developing a software product, there must be
a clear understanding among team representative about when and
what to do. Otherwise, it would point to chaos and project failure.
This problem can be defined by using an example. Suppose a
software development issue is divided into various parts and the parts
are assigned to the team members. From then on, suppose the team
representative is allowed the freedom to develop the roles assigned to
them in whatever way they like. It is possible that one representative
might start writing the code for his part, another might choose to
prepare the test documents first, and some other engineer might begin
with the design phase of the roles assigned to him. This would be one
of the perfect methods for project failure.

A software life cycle model describes entry and exit criteria for each
phase. A phase can begin only if its stage-entry criteria have been
fulfilled. So without a software life cycle model, the entry and exit
criteria for a stage cannot be recognized. Without software life cycle
models, it becomes tough for software project managers to monitor
the progress of the project.

SDLC Cycle

SDLC Cycle represents the process of developing software. SDLC

framework includes the following steps:
The stages of SDLC are as follows:

Stage1: Planning and requirement analysis

Requirement Analysis is the most important and necessary stage in

SDLC.

The senior members of the team perform it with inputs from all the
stakeholders and domain experts or SMEs in the industry.

Planning for the quality assurance requirements and identifications of

the risks associated with the projects is also done at this stage.

Business analyst and Project organizer set up a meeting with the client
to gather all the data like what the customer wants to build, who will
be the end user, what is the objective of the product. Before creating a
product, a core understanding or knowledge of the product is very
necessary.

For Example, A client wants to have an application which concerns

money transactions. In this method, the requirement has to be precise
like what kind of operations will be done, how it will be done, in
which currency it will be done, etc.

Once the required function is done, an analysis is complete with

auditing the feasibility of the growth of a product. In case of any
ambiguity, a signal is set up for further discussion.

Once the requirement is understood, the SRS (Software Requirement

Specification) document is created. The developers should thoroughly
follow this document and also should be reviewed by the customer for
future reference.

Stage2: Defining Requirements

Once the requirement analysis is done, the next stage is to certainly

represent and document the software requirements and get them
accepted from the project stakeholders.

This is accomplished through "SRS"- Software Requirement

Specification document which contains all the product requirements
to be constructed and developed during the project life cycle.

Stage3: Designing the Software

The next phase is about to bring down all the knowledge of

requirements, analysis, and design of the software project. This phase
is the product of the last two, like inputs from the customer and
requirement gathering.

Stage4: Developing the project

In this phase of SDLC, the actual development begins, and the

programming is built. The implementation of design begins
concerning writing code. Developers have to follow the coding
guidelines described by their management and programming tools
like compilers, interpreters, debuggers, etc. are used to develop and
implement the code.

Stage5: Testing

After the code is generated, it is tested against the requirements to

make sure that the products are solving the needs addressed and
gathered during the requirements stage.

During this stage, unit testing, integration testing, system testing,

acceptance testing are done.

Stage6: Deployment

Once the software is certified, and no bugs or errors are stated, then it
is deployed.

Then based on the assessment, the software may be released as it is or

with suggested enhancement in the object segment.

After the software is deployed, then its maintenance begins.

Stage7: Maintenance

Once when the client starts using the developed systems, then the real
issues come up and requirements to be solved from time to time.

This procedure where the care is taken for the developed product is
known as maintenance.

SDLC Models

Software Development life cycle (SDLC) is a spiritual model used in

project management that defines the stages include in an information
system development project, from an initial feasibility study to the
maintenance of the completed application.

There are different software development life cycle models specify

and design, which are followed during the software development
phase. These models are also called "Software Development Process
Models." Each process model follows a series of phase unique to its
type to ensure success in the step of software development.

Here, are some important phases of SDLC life cycle:

Water fall models

Waterfall model

Winston Royce introduced the Waterfall Model in 1970.This model

has five phases: Requirements analysis and specification, design,
implementation, and unit testing, integration and system testing, and
operation and maintenance. The steps always follow in this order and
do not overlap. The developer must complete every phase before the
next phase begins. This model is named "Waterfall Model", because
its diagrammatic representation resembles a cascade of waterfalls.

1. Requirements analysis and specification phase: The aim of this

phase is to understand the exact requirements of the customer and to
document them properly. Both the customer and the software
developer work together so as to document all the functions,
performance, and interfacing requirement of the software. It describes
the "what" of the system to be produced and not "how."In this phase,
a large document called Software Requirement Specification
(SRS) document is created which contained a detailed description of
what the system will do in the common language.

2. Design Phase: This phase aims to transform the requirements

gathered in the SRS into a suitable form which permits further coding
in a programming language. It defines the overall software
architecture together with high level and detailed design. All this
work is documented as a Software Design Document (SDD).

3. Implementation and unit testing: During this phase, design is

implemented. If the SDD is complete, the implementation or coding
phase proceeds smoothly, because all the information needed by
software developers is contained in the SDD.
During testing, the code is thoroughly examined and modified. Small
modules are tested in isolation initially. After that these modules are
tested by writing some overhead code to check the interaction
between these modules and the flow of intermediate output.

4. Integration and System Testing: This phase is highly crucial as

the quality of the end product is determined by the effectiveness of
the testing carried out. The better output will lead to satisfied
customers, lower maintenance costs, and accurate results. Unit testing
determines the efficiency of individual modules. However, in this
phase, the modules are tested for their interactions with each other and
with the system.

5. Operation and maintenance phase: Maintenance is the task

performed by every user once the software has been delivered to the
customer, installed, and operational.

When to use SDLC Waterfall Model?

Some Circumstances where the use of the Waterfall model is most

suited are:

o When the requirements are constant and not changed regularly.

o A project is short
o The situation is calm
o Where the tools and technology used is consistent and is not
changing
o When resources are well prepared and are available to use.

Advantages of Waterfall model

o This model is simple to implement also the number of resources

that are required for it is minimal.
o The requirements are simple and explicitly declared; they
remain unchanged during the entire project development.
o The start and end points for each phase is fixed, which makes it
easy to cover progress.
 o The release date for the complete product, as well as its final
cost, can be determined before development.
o It gives easy to control and clarity for the customer due to a
strict reporting system.

Disadvantages of Waterfall model

o In this model, the risk factor is higher, so this model is not

suitable for more significant and complex projects.
o This model cannot accept the changes in requirements during
development.
o It becomes tough to go back to the phase. For example, if the
application has now shifted to the coding phase, and there is a
change in requirement, It becomes tough to go back and change
it.
o Since the testing done at a later stage, it does not allow
identifying the challenges and risks in the earlier phase, so the
risk reduction strategy is difficult to prepare.

Incremental Model

Incremental Model is a process of software development where

requirements divided into multiple standalone modules of the
software development cycle. In this model, each module goes through
the requirements, design, implementation and testing phases. Every
subsequent release of the module adds function to the previous
release. The process continues until the complete system achieved.
The various phases of incremental model are as follows:

1. Requirement analysis: In the first phase of the incremental model,

the product analysis expertise identifies the requirements. And the
system functional requirements are understood by the requirement
analysis team. To develop the software under the incremental model,
this phase performs a crucial role.

2. Design & Development: In this phase of the Incremental model of

SDLC, the design of the system functionality and the development
method are finished with success. When software develops new
practicality, the incremental model uses style and development phase.

3. Testing: In the incremental model, the testing phase checks the

performance of each existing function as well as additional
functionality. In the testing phase, the various methods are used to test
the behavior of each task.

4. Implementation: Implementation phase enables the coding phase

of the development system. It involves the final coding that design in
the designing and development phase and tests the functionality in the
testing phase. After completion of this phase, the number of the
product working is enhanced and upgraded up to the final system
product

When we use the Incremental Model?

o When the requirements are superior.

o A project has a lengthy development schedule.
o When Software team are not very well skilled or trained.
o When the customer demands a quick release of the product.
o You can develop prioritized requirements first.

Advantage of Incremental Model

o Errors are easy to be recognized.

o Easier to test and debug
o More flexible.
o Simple to manage risk because it handled during its iteration.
o The Client gets important functionality early.

Disadvantage of Incremental Model

o Need for good planning

o Total Cost is high.
o Well defined module interfaces are needed.

Spiral Model

The spiral model, initially proposed by Boehm, is an evolutionary

software process model that couples the iterative feature of
prototyping with the controlled and systematic aspects of the linear
sequential model. It implements the potential for rapid development
of new versions of the software. Using the spiral model, the software
is developed in a series of incremental releases. During the early
iterations, the additional release may be a paper model or prototype.
During later iterations, more and more complete versions of the
engineered system are produced.
The Spiral Model is shown in fig:

Each cycle in the spiral is divided into four parts:

Objective setting: Each cycle in the spiral starts with the

identification of purpose for that cycle, the various alternatives that
are possible for achieving the targets, and the constraints that exists.

Risk Assessment and reduction: The next phase in the cycle is to

calculate these various alternatives based on the goals and constraints.
The focus of evaluation in this stage is located on the risk perception
for the project.

Development and validation: The next phase is to develop strategies

that resolve uncertainties and risks. This process may include
activities such as benchmarking, simulation, and prototyping.

Planning: Finally, the next step is planned. The project is reviewed,

and a choice made whether to continue with a further period of the
spiral. If it is determined to keep, plans are drawn up for the next step
of the project.

The development phase depends on the remaining risks. For example,

if performance or user-interface risks are treated more essential than
the program development risks, the next phase may be an
evolutionary development that includes developing a more detailed
prototype for solving the risks.

The risk-driven feature of the spiral model allows it to accommodate

any mixture of a specification-oriented, prototype-oriented,
simulation-oriented, or another type of approach. An essential
element of the model is that each period of the spiral is completed by
a review that includes all the products developed during that cycle,
including plans for the next cycle. The spiral model works for
development as well as enhancement projects.

When to use Spiral Model?

o When deliverance is required to be frequent.

o When the project is large
o When requirements are unclear and complex
o When changes may require at any time
o Large and high budget projects

Advantages

o High amount of risk analysis

o Useful for large and mission-critical projects.

Disadvantages

o Can be a costly model to use.

o Risk analysis needed highly particular expertise
o Doesn't work well for smaller projects.

Prototype Model
The prototype model requires that before carrying out the
development of actual software, a working prototype of the system
should be built. A prototype is a toy implementation of the system. A
prototype usually turns out to be a very crude version of the actual
system, possible exhibiting limited functional capabilities, low
reliability, and inefficient performance as compared to actual
software. In many instances, the client only has a general view of
what is expected from the software product. In such a scenario where
there is an absence of detailed information regarding the input to the
system, the processing needs, and the output requirement, the
prototyping model may be employed.
Steps of Prototype Model

1. Requirement Gathering and Analyst

2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product

Advantage of Prototype Model

1. Reduce the risk of incorrect user requirement

2. Good where requirement are changing/uncommitted
3. Regular visible process aids management
4. Support early product marketing
5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the system is made side
by side.

Disadvantage of Prototype Model

1. An unstable/badly implemented prototype often becomes the

final product.
2. Require extensive customer collaboration
o Costs customer money

o Needs committed customer

o Difficult to finish if customer withdraw

o May be too customer specific, no broad market

3. Difficult to know how long the project will last.

4. Easy to fall back into the code and fix without proper
requirement analysis, design, customer evaluation, and
feedback.
 5. Prototyping tools are expensive.
6. Special tools & techniques are required to build a prototype.
7. It is a time-consuming process.

Evolutionary Process Model

Evolutionary process model resembles the iterative enhancement

model. The same phases are defined for the waterfall model occurs
here in a cyclical fashion. This model differs from the iterative
enhancement model in the sense that this does not require a useful
product at the end of each cycle. In evolutionary development,
requirements are implemented by category rather than by priority.

For example, in a simple database application, one cycle might

implement the graphical user Interface (GUI), another file
manipulation, another queries and another updates. All four cycles
must complete before there is a working product available. GUI
allows the users to interact with the system, file manipulation allow
the data to be saved and retrieved, queries allow user to get out of the
system, and updates allows users to put data into the system.

Benefits of Evolutionary Process Model

Use of EVO brings a significant reduction in risk for software

projects.

EVO can reduce costs by providing a structured, disciplined avenue

for experimentation.

EVO allows the marketing department access to early deliveries,

facilitating the development of documentation and demonstration.

Better fit the product to user needs and market requirements.

Manage project risk with the definition of early cycle content.

Uncover key issues early and focus attention appropriately.

Increase the opportunity to hit market windows.

Accelerate sales cycles with early customer exposure.

Increase management visibility of project progress.

Increase product team productivity and motivations.

V-Model

Verification and Validation is the process of investigating whether

a software system satisfies specifications and standards and fulfills
the required purpose. Barry Boehm described verification and
validation as the following:

Verification: Are we building the product right?

Validation: Are we building the right product?

Verification
Verification is the process of checking that software achieves its goal
without any bugs. It is the process to ensure whether the product that
is developed is right or not. It verifies whether the developed product
fulfills the requirements that we have. Verification is simply known
as Static Testing.

Static Testing
Verification Testing is known as Static Testing and it can be simply
termed as checking whether we are developing the right product or
not and also whether our software is fulfilling the customer’s
requirement or not. Here are some of the activities that are involved
in verification.
 Inspections
 Reviews
 Walkthroughs
 Desk-checking
Validation
Validation is the process of checking whether the software product is
up to the mark or in other words product has high-level
requirements. It is the process of checking the validation of the
product i.e. it checks what we are developing is the right product. it
is a validation of actual and expected products. Validation is simply
known as Dynamic Testing.

Dynamic Testing
Validation Testing is known as Dynamic Testing in which we
examine whether we have developed the product right or not and
also about the business needs of the client. Here are some of the
activities that are involved in Validation.
1. Black Box Testing
2. White Box Testing
3. Unit Testing
4. Integration Testing

Note: Verification is followed by Validation.

V-Model also referred to as the Verification and Validation Model. In

this, each phase of SDLC must complete before the next phase starts.
It follows a sequential design process same as the waterfall model.
Testing of the device is planned in parallel with a corresponding stage
of development.
Verification: It involves a static analysis method (review) done
without executing code. It is the process of evaluation of the product
development process to find whether specified requirements meet.

Validation: It involves dynamic analysis method (functional, non-

functional), testing is done by executing code. Validation is the
process to classify the software after the completion of the
development process to determine whether the software meets the
customer expectations and requirements.

So V-Model contains Verification phases on one side of the

Validation phases on the other side. Verification and Validation
process is joined by coding phase in V-shape. Thus it is known as V-
Model.

There are the various phases of Verification Phase of V-model:

1. Business requirement analysis: This is the first step where

product requirements understood from the customer's side. This
phase contains detailed communication to understand customer's
expectations and exact requirements.
 2. System Design: In this stage system engineers analyze and
interpret the business of the proposed system by studying the
user requirements document.
3. Architecture Design: The baseline in selecting the architecture
is that it should understand all which typically consists of the list
of modules, brief functionality of each module, their interface
relationships, dependencies, database tables, architecture
diagrams, technology detail, etc. The integration testing model
is carried out in a particular phase.
4. Module Design: In the module design phase, the system breaks
down into small modules. The detailed design of the modules is
specified, which is known as Low-Level Design
5. Coding Phase: After designing, the coding phase is started.
Based on the requirements, a suitable programming language is
decided. There are some guidelines and standards for coding.
Before checking in the repository, the final build is optimized
for better performance, and the code goes through many code
reviews to check the performance.

There are the various phases of Validation Phase of V-model:

1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are

developed during the module design phase. These UTPs are
executed to eliminate errors at code level or unit level. A unit is
the smallest entity which can independently exist, e.g., a
program module. Unit testing verifies that the smallest entity
can function correctly when isolated from the rest of the codes/
units.
2. Integration Testing: Integration Test Plans are developed
during the Architectural Design Phase. These tests verify that
groups created and tested independently can coexist and
communicate among themselves.
3. System Testing: System Tests Plans are developed during
System Design Phase. Unlike Unit and Integration Test Plans,
System Tests Plans are composed by the client?s business team.
 System Test ensures that expectations from an application
developer are met.
4. Acceptance Testing: Acceptance testing is related to the
business requirement analysis part. It includes testing the
software product in user atmosphere. Acceptance tests reveal the
compatibility problems with the different systems, which is
available within the user atmosphere. It conjointly discovers the
non-functional problems like load and performance defects
within the real user atmosphere.

When to use V-Model?

o When the requirement is well defined and not ambiguous.

o The V-shaped model should be used for small to medium-sized
projects where requirements are clearly defined and fixed.
o The V-shaped model should be chosen when sample technical
resources are available with essential technical expertise.

Advantage (Pros) of V-Model:

1. Easy to Understand.
2. Testing Methods like planning, test designing happens well
before coding.
3. This saves a lot of time. Hence a higher chance of success over
the waterfall model.
4. Avoids the downward flow of the defects.
5. Works well for small plans where requirements are easily
understood.

Disadvantage (Cons) of V-Model:

1. Very rigid and least flexible.

2. Not a good for a complex project.
3. Software is developed during the implementation stage, so no
early prototypes of the software are produced.
4. If any changes happen in the midway, then the test documents
along with the required documents, has to be updated.
Concurrent development:
Concurrent 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.
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.
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, 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 odeling is applicable to all types of
software development and provides an accurate picture of the current
state of a project.

SPECIALIZED PROCESS MODELS

These models tend to be applied when a specialized or narrowly

defined software engineering approach is chosen.
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 packages of classes. Regardless
of the technology that is used to create the components, the
component-based development model incorporates the following
steps 1. Available component-based products are researched and
evaluated for the application domain in question.
2. Component integration issues are considered.
3. A 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.
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 cleanroom software engineering, is currently
applied by some software development organizations. 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.
Although not a mainstream approach, the formal methods model
offers the promise of defect-free software. Yet, concern about its
applicability in a business environment has been voiced: • The
development of formal models is currently quite time consuming and
expensive. • Because few software developers have the necessary
background to apply formal methods, extensive training is required. •
It is difficult to use the models as a communication mechanism for
technically unsophisticated customers.
Aspect-Oriented Software Development:
Regardless of the software process that is chosen, the builders of
complex software invariably implement a set of localized features,
functions, and information content. These localized software
characteristics are modeled as components (e.g., object oriented
classes) and then constructed within the context of a system
architecture. As modern computer-based systems become more
sophisticated (and complex), 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. Aspectoriented 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. AOCE uses a concept of horizontal slices
through vertically-decomposed software components, called
“aspects,” to characterize cross-cutting functional and nonfunctional
properties of components. Common, systemic aspects include user
interfaces, collaborative work, distribution, persistency, memory
management, transaction processing, security, integrity and so on.

The UNIFIED PROCESS

Introduction: The Unified Process is an attempt to draw on the best
features and characteristics of traditional software process models, but
haracterize them in a way that implements many of the best principles
of agile software development. The Unified Process recognizes the
importance of customer communication and streamlined methods for
describing the customer’s view of a system.

Phases of the Unified Process: The Unified Process is with five basic
framework activities depicted in figure . It depicts the “phases” of the
UP and relates them to the generic activities.
The inception phase of the UP encompasses both customer
communication and planning activities. The elaboration phase
encompasses the communication and modeling activities of the
generic process model. The construction phase of the UP is identical
to the construction activity defined for the generic software process.
The transition phase of the UP encompasses the latter stages of the
generic construction activity and the first part of the generic
deployment (delivery and feedback) activity. Software is given to end
users for beta testing and user feedback reports both defects and
necessary changes. In addition, the software team creates the
necessary support information (e.g., user manuals, troubleshooting
guides, installation procedures) that is required for the release. The
production phase of the UP coincides with the deployment activity of
the generic process. During this phase, the ongoing use of the
software is monitored, support for the operating environment
(infrastructure) is provided, and defect reports and requests for
changes are submitted and evaluated. A software engineering
workflow is distributed across all UP phases.
System Engineering Hierarchy:

Business Process Engineering • Uses an integrated set of procedures,

methods, and tools to identify how information systems can best meet
the strategic goals of an enterprise • Focuses first on the enterprise
and then on the business area • Creates enterprise models, data models
and process models • Creates a framework for better information
management distribution, and control
Information Strategy Planning Management issues :

• Define strategic business goals/objectives

• isolate critical success factors
• conduct analysis of technology impact
• perform analysis of strategic systems Technical issues
• create a top-level data model
• cluster by business/organizational area
• refine model and clustering

Defining Objectives and Goals

Objective-general statement of direction Goal-defines measurable

course of action
Examples:
• objective-reduce manufactured cost of our product
• goals ! decrease reject rate by 20% in first 6 months ! gain 10%
price concessions from suppliers ! re-enqineer 30% of components for
ease of manufacture during first year Objectives tend to be strategic
while goals tend to be tactical

Introduction to CMM:
Capability maturity model (CMM) – Software Engineering

Capability Maturity Model (CMM) was developed by the

Software Engineering Institute (SEI) at Carnegie Mellon University
in 1987. It is not a software process model. It is a framework that is
used to analyze the approach and techniques followed by any
organization to develop software products. It also provides
guidelines to further enhance the maturity of the process used to
develop those software products.
It is based on profound feedback and development practices adopted
by the most successful organizations worldwide. This model
describes a strategy for software process improvement that should be
followed by moving through 5 different levels. Each level of
maturity shows a process capability level. All the levels except level
1 are further described by Key Process Areas (KPA).

Principles of Capability Maturity Model (CMM)

 People’s capability is a competitive issue. Competition
arises when different organizations are performing the same
task (such as software development). In such a case, the
people of an organization are sources of strategy and skills,
which in turn results in better performance of the
organization.
 The people’s capability should be defined in relation to the
business objectives of the organization.
  An organization should invest in improving the capabilities
and skills of the people as they are important for its success.
 The management should be responsible for enhancing the
capability of the people in the organization.
 The improvement in the capability of people should be done
as a process. This process should incorporate appropriate
practices and procedures.
 The organization should be responsible for providing
improvement opportunities so that people in the organization
can take advantage of them.
 Since new technologies and organizational practices emerge
rapidly, organizations should continually improve their
practices and develop the abilities of people.

Key Process Areas (KPA)

Each of these KPA (Key Process Areas) defines the basic
requirements that should be met by a software process in order to
satisfy the KPA and achieve that level of maturity.
Conceptually, key process areas form the basis for management
control of the software project and establish a context in which
technical methods are applied, work products like models,
documents, data, reports, etc. are produced, milestones are
established, quality is ensured and change is properly managed.

Levels of Capability Maturity Model (CMM)

There are basically 5 levels of Capability Maturity Models . We will
discuss each one of them in detail.
CMM

Level-1: Initial
 No KPIs defined.
 Processes followed are Adhoc and immature and are not
well defined.
 Unstable environment for software development .
 No basis for predicting product quality, time for completion,
etc.
 Limited project management capabilities, such as no
systematic tracking of schedules, budgets, or progress.
 We have limited communication and coordination among
team members and stakeholders.
 No formal training or orientation for new team members.
 Little or no use of software development tools or
automation.
  Highly dependent on individual skills and knowledge rather
than standardized processes.
 High risk of project failure or delays due to a lack of process
control and stability.

Level-2: Repeatable
 Focuses on establishing basic project management policies.
 Experience with earlier projects is used for managing new
similar-natured projects.
 Project Planning- It includes defining resources required,
goals, constraints, etc. for the project. It presents a detailed
plan to be followed systematically for the successful
completion of good-quality software.
 Configuration Management- The focus is on maintaining
the performance of the software product, including all its
components, for the entire lifecycle.
 Requirements Management- It includes the management
of customer reviews and feedback which result in some
changes in the requirement set. It also consists of
accommodation of those modified requirements.
 Subcontract Management- It focuses on the effective
management of qualified software contractors i.e. it manages
the parts of the software developed by third parties.
 Software Quality Assurance- It guarantees a good quality
software product by following certain rules and quality
standard guidelines while developing.

Level-3: Defined
 At this level, documentation of the standard guidelines and
procedures takes place.
 It is a well-defined integrated set of project-specific software
engineering and management processes.
 Peer Reviews: In this method, defects are removed by using
a number of review methods like walkthroughs, inspections,
buddy checks, etc.
  Intergroup Coordination: It consists of planned
interactions between different development teams to ensure
efficient and proper fulfillment of customer needs.
 Organization Process Definition: Its key focus is on the
development and maintenance of standard development
processes.
 Organization Process Focus: It includes activities and
practices that should be followed to improve the process
capabilities of an organization.
 Training Programs: It focuses on the enhancement of
knowledge and skills of the team members including the
developers and ensuring an increase in work efficiency.

Level-4: Managed
 At this stage, quantitative quality goals are set for the
organization for software products as well as software
processes.
 The measurements made help the organization to predict the
product and process quality within some limits defined
quantitatively.
 Software Quality Management: It includes the
establishment of plans and strategies to develop quantitative
analysis and understanding of the product’s quality.
 Quantitative Management: It focuses on controlling the
project performance in a quantitative manner.

Level-5: Optimizing
 This is the highest level of process maturity in CMM and
focuses on continuous process improvement in the
organization using quantitative feedback.
 The use of new tools, techniques, and evaluation of software
processes is done to prevent the recurrence of known
defects.
 Process Change Management: Its focus is on the
continuous improvement of the organization’s software
processes to improve productivity, quality, and cycle time
for the software product.
  Technology Change Management: It consists of the
identification and use of new technologies to improve
product quality and decrease product development time.
 Defect Prevention It focuses on the identification of causes
of defects and prevents them from recurring in future
projects by improving project-defined processes.

CMM (Capability Maturity Model) vs CMMI (Capability

Maturity Model Integration)
Capability
Capability Maturity Model
Maturity Model Integration
Aspects (CMM) (CMMI)

Expands to various
Primarily focused
disciplines like
on software
Scope systems engineering,
engineering
hardware
processes.
development, etc.

Initially had a staged

Had a five-level representation;
Maturity Levels maturity model introduced
(Level 1 to Level 5). continuous
representation later.

Offers flexibility to
More rigid structure
tailor process areas
Flexibility with predefined
to organizational
practices.
needs.

Gained popularity in Gained wider

Adoption and software adoption across
Popularity development industries due to
industry. broader applicability.
Levels of CMMI
There are basically 5 performance levels of the CMMI Model.
Level 1: Initial: Processes are often ad hoc and unpredictable. There
is little or no formal process in place.
Level 2: Managed: Basic project management processes are
established. Projects are planned, monitored, and controlled.
Level 3: Defined: Organizational processes are well-defined and
documented. Standardized processes are used across the
organization.
Level 4: Quantitatively Managed: Processes are measured and
controlled using statistical and quantitative techniques. Process
performance is quantitatively understood and managed.
Level 5: Optimizing: Continuous process improvement is a key
focus. Processes are continuously improved based on quantitative
feedback.