310904 Software Engineering and Project Management

Introduction to Software Engineering

Software is a program or set of programs containing instructions that provide desired
functionality. Engineering is the process of designing and building something that serves a
particular purpose and finds a cost-effective solution to problems.

Software Engineering is mainly used for large projects based on software systems rather
than single programs or applications. The main goal of software Engineering is to develop
software applications for improving the quality, budget and time efficiency. Software
Engineering ensures that the software that has to built should be consistent, correct, also on
budget, on time and within the required requirements. There are Four main Attributes of
Software Engineering:-

● Efficiency
● Reliability
● Robustness
● Maintainability

Software Engineering is a systematic, disciplined, quantifiable study and approach to the

design, development, operation, and maintenance of a software system.

Dual Role of Software:

1. As a product –

● It delivers the computing potential across networks of Hardware.

● It enables the Hardware to deliver the expected functionality.
● It acts as an information transformer because it produces, manages, acquires,
modifies, displays, or transmits information.

2. As a vehicle for delivering a product –

● It provides system functionality (e.g., payroll system)

● It controls other software (e.g., an operating system)
 ● It helps build other software (e.g., software tools)

Objectives of Software Engineering:

1. Maintainability –
It should be feasible for the software to evolve to meet changing requirements.
2. Efficiency –
The software should not make wasteful use of computing devices such as
memory, processor cycles, etc.
3. Correctness –
A software product is correct if the different requirements as specified in the SRS
document have been correctly implemented.
4. Reusability –
A software product has good reusability if the different modules of the product
can easily be reused to develop new products.
5. Testability –
Here software facilitates both the establishment of test criteria and the evaluation
of the software with respect to those criteria.
6. Reliability –
It is an attribute of software quality. The extent to which a program can be
expected to perform its desired function, over an arbitrary time period.
7. Portability –
In this case, the software can be transferred from one computer system or
environment to another.
8. Adaptability –
In this case, the software allows differing system constraints and the user needs
to be satisfied by making changes to the software.
9. Interoperability – Capability of 2 or more functional units to process data
cooperatively.

Program vs Software Product:

1. A program is a set of instructions that are given to a computer in order to achieve

a specific task whereas software is when a program is made available for
 commercial business and is properly documented along with its licensing.
Software=Program+documentation+licensing.
2. A program is one of the stages involved in the development of the software,
whereas a software development usually follows a life cycle, which involves the
feasibility study of the project, requirement gathering, development of a prototype,
system design, coding, and testing.

Software Engineering Practices

These best practices are empirically proven approaches that software developers can use to
improve their software development skills and outreach to users and users. They include:

Enhance Code Readability

The one rule about coding is to make your code readable, understandable, clean, and
modular. This also makes it logically structured to make it more efficient, organized, and
reusable. Making a code simple and trimming all the fat out of it may appear like extra effort,
but it pays better dividends in the long run.

It will also make the code update, future-proofing, and debugging easier. In general, concise
coding is useful to implement in projects.

Keep Code Efficiency

Optimize your code to work efficiently and execute its function quickly. Writing a code quickly
and correctly may be pointless if it ends up as a slow and unstable product. When writing a
code, ensure it works efficiently, minimizes its memory footprint, and works with many
functions.

This will also ensure that other engineers can work with your code and even improve on it.

Test Often
Writing codes and automating tests when engineering new software is a practice every
user-facing platform should carry out. Testing ensures smooth functionality and generates a
pleasant user experience (UX). This is important to many users who expect easy navigation,
personalization, and adequate engagement. You can even outsource testing on platforms
such as GitHub.

Be Descriptive
Every software engineer needs a distinct professional coding style. This often comes by
reading more and understanding it better than crafting a concise, functional, and easily
understood code. Expert engineers/coders create unstructured code blocks to make them
universally understandable by other software engineers.

They achieve this by using descriptive names for variables and functions, avoiding excessive
indentation, and implementing modularity in their codes. Good, brief descriptive codes can
save hours of a software project.

Use Version Control

Version control is a software engineering model that tracks changes in a code and
synchronizes them with a master code/file stored on a remote database or server. Using
version control ensures a code’s adaptability and makes it easily editable across your team.

It also ensures that your code is backed up and available in case of a system crash. There’s
also a chance that many developers can work with the code independently to edit features or
make changes without impacting other team members’ work.

Refactor Your Code

Refactoring a code is basically improving its structure without modifying its actual
functionality. If the code has multiple blocks that perform similar functions, refactoring them
into a single function can improve its structure. Refactoring your code makes it simple.

If you want to change the code’s function, you’ll only update one function and then locate
and change several. In the long run, code refactoring will help speed up your software
development time and make it smoother.

Apply the KISS Principle

KISS is an acronym for “keep it simple, stupid,” created by the U.S. Navy in 1960. It means
cutting out the excess or unnecessary and making sure your code is less crowded. It’s highly
relevant to software engineering as it is to the military.

The keyword is “simple,” which implies keeping your code simple, meaningful, and to the
point. Using the KISS principle, your code remains easily maintainable and easy to debug.

Branch Feature Design

Feature design often causes design and functionality problems. Teams working on the same
code’s different features may be forced to figure out changes and bugs that others create.
Feature design combines modular functionality and version control for better modern coding.

Designing code features on separate branches and merging them can make the code more
compatible with the software engineering larger project. This often helps the software
project’s longevity and improves the code’s overall quality.

Endnote
Thanks to technology development, strong industry demand, and technical expertise,
software engineering continues to develop. Every industry needs a skilled software engineer.
But along with working within the different industries, every software engineer needs to
follow these best practices to support the functionality of their codes.
Software Myths

Software Myths:

Most experienced experts have seen myths or superstitions (false beliefs or interpretations)
or misleading attitudes (naked users) which creates major problems for management and
technical people. The types of software-related myths are listed below.

`Types of Software Myths

(i) Management Myths:

Myth 1:

We have all the standards and procedures available for software development.

Fact:

● Software experts do not know all the requirements for software development.
● And all existing processes are incomplete as new software development is based
on new and different problems.

Myth 2:

The addition of the latest hardware programs will improve the software development.

Fact:

● The role of the latest hardware is not very high on standard software
development; instead (CASE) Engineering tools help the computer, they are more
important than hardware to produce quality and productivity.
● Hence, the hardware resources are misused.

Myth 3:
 ● With the addition of more people and program planners to Software development
can help meet project deadlines (If lagging behind).

Fact:

● If software is late, adding more people will merely make the problem worse. This
is because the people already working on the project now need to spend time
educating the newcomers, and are thus taken away from their work. The
newcomers are also far less productive than the existing software engineers, and
so the work put into training them to work on the software does not immediately
meet with an appropriate reduction in work.

(ii)Customer Myths:

The customer can be the direct users of the software, the technical team, marketing / sales
department, or other company. Customers has myths leading to false expectations
(customer) & that’s why you create dissatisfaction with the developer.

Myth 1:

A general statement of intent is enough to start writing plans (software development) and
details of objectives can be done over time.

Fact:

● Official and detailed description of the database function, ethical performance,

communication, structural issues and the verification process are important.
● Unambiguous requirements (usually derived iteratively) are developed only
through effective and continuous
communication between customer and developer.

Myth 2:

Software requirements continually change, but change can be easily accommodated

because software is flexible

Fact:

● It is true that software requirements change, but the impact of change varies with
the time at which it is introduced. When requirements changes are requested
early (before design or code has been started), the cost impact is relatively small.
 However, as time passes, the cost impact grows rapidly—resources have been
committed, a design framework has been established, and change can cause
upheaval that requires additional resources and major design modification.

Different Stages of Myths

(iii)Practitioner’s Myths:

Myths 1:

They believe that their work has been completed with the writing of the plan.

Fact:

● It is true that every 60-80% effort goes into the maintenance phase (as of the
latter software release). Efforts are required, where the product is available first
delivered to customers.

Myths 2:

There is no other way to achieve system quality, until it is “running”.

Fact:

● Systematic review of project technology is the quality of effective software

verification method. These updates are quality filters and more accessible than
test.
Myth 3:

An operating system is the only product that can be successfully exported project.

Fact:

● A working system is not enough, the right document brochures and booklets are
also required to provide guidance & software support.

Myth 4:

Engineering software will enable us to build powerful and unnecessary document & always
delay us.

Fact:

● Software engineering is not about creating documents. It is about creating a

quality product. Better quality leads to reduced rework. And reduced rework
results in faster delivery times

Process Model

What is a software process?

A software process is the development team's activities that lead to the final development of
their software program. Each of these activities relates to the other in some way, forming a
linear path the team follows from initial planning to final deliverables.

Teams create software processes to outline their methods to improve them and reduce
errors and to overcome challenges. With a better understanding of how the team works
toward its goals, you can find ways to improve the process and make it more efficient for the
next project.

Developers across the industry typically organize software processes into a similar pattern,
following this four-step formula:
 1. Specification: The team defines the main functionality of the software program
they're building. They also consider the constraints of the project and the specific
features that should exist in the final software program.
2. Design and implementation: The team designs the software around the
specification phase's parameters and programs the software. This includes all of the
coding, planning, 3D design and initial planning aside from defining the project's
specifications.
3. Verification and validation: The team verifies that the completed software program
conforms to the customer's needs and meets quality expectations. The team
presents the prototype to the customer for review.
4. Evolution: The team listens to customer feedback and adjusts the software to meet
new parameters or improve original parameters for better functionality. This can be
an ongoing process for the team if they offer post-development support for their
software.

What is a software process model?

A software process model is a digital or hand-written model that details the software
development process. Process models help provide a visual representation of the
development process for both the team and the customer to review.

This helps them determine the right process to follow for specific software, identify early
challenges or cost constraints and acts as a record of the team's development process for
the future.

Analysis and comparison of Process Models:

Software processes, methodologies and frameworks range from specific prescriptive steps
that can be used directly by an organization in day-to-day work, to flexible frameworks that
an organization uses to generate a custom set of steps tailored to the needs of a specific
project or group. In some cases a “sponsor” or “maintenance” organization distributes an
official set of documents that describe the process.

One of the basic notions of the software development process is SDLC models which stands
for Software Development Life Cycle models. There are many development life cycle models
that have been developed in order to achieve different required objectives. The models
specify the various stages of the process and the order in which they are carried out. The
most used, popular and important SDLC models are given below:

Waterfall Model
The waterfall model is a breakdown of project activities into linear sequential phases, where
each phase depends on the deliverables of the previous one and corresponds to a
specialisation of tasks. The approach is typical for certain areas of engineering design.

The waterfall software process model is one of the simplest and most effective software
process models. The waterfall model displays each step of the development process as a
separate, sequential step so that it's easy to follow. You can view the development process
from beginning to end with a glance and adjust steps as the development process continues.

The waterfall process model works well for simple software development projects that likely
won't change significantly during the development process. The team understands each
parameter thoroughly and can work through the development phases quickly.

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 requirements 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 contains 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:

● When the requirements are constant and not changed regularly.

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

Advantages of Waterfall model

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

Disadvantages of Waterfall model

● In this model, the risk factor is higher, so this model is not suitable for more
significant and complex projects.
● This model cannot accept the changes in requirements during development.
● 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.
● Since the testing is 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 Models

The incremental build model is a method of software development where the model is
designed, implemented and tested incrementally (a little more is added each time) until the
product is finished. It involves both development and maintenance. The product is defined as
finished when it satisfies all of its requirements. Each iteration passes through the
requirements, design, coding and testing phases. And each subsequent release of the
system adds function to the previous release until all designs functionally has been
implemented. This model combines the elements of the waterfall model with the iterative
philosophy of prototyping.

Incremental development is the process of dividing the development phases into various
sections based on user feedback. The team develops in increments, developing one part of
the software and submitting it to user testing and feedback before moving on to the next
phase in the process. This allows the team to identify issues or challenges early on and keep
the customer's parameters aligned with the actual development.

This also allows the team to work closely with their customers to learn more about what they
want from their software. This method benefits development teams who are creating more
complex software programs that need frequent usability testing.
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?

● When the requirements are superior.

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

Advantage of Incremental Model

● Errors are easy to be recognized.

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

Disadvantage of Incremental Model

● Need for good planning

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

Iterative Models

In this Model, you can start with some of the software specifications and develop the first
version of the software. After the first version if there is a need to change the software, then
a new version of the software is created with a new iteration. Every release of the Iterative
Model finishes in an exact and fixed period that is called iteration.

The Iterative Model allows the accessing earlier phases, in which the variations made
respectively. The final output of the project renewed at the end of the Software Development
Life Cycle (SDLC) process.
The various phases of Iterative model are as follows:

1. Requirement gathering & analysis: In this phase, requirements are gathered from
customers and check by an analyst whether requirements will fulfil or not. Analyst checks
that need will achieve within budget or not. After all of this, the software team skips to the
next phase.

2. Design: In the design phase, team design the software by the different diagrams like Data
Flow diagram, activity diagram, class diagram, state transition diagram, etc.

3. Implementation: In the implementation, requirements are written in the coding language

and transformed into computer programmes which are called Software.

4. Testing: After completing the coding phase, software testing starts using different test
methods. There are many test methods, but the most common are white box, black box, and
grey box test methods.

5. Deployment: After completing all the phases, software is deployed to its work
environment.

6. Review: In this phase, after the product deployment, review phase is performed to check
the behaviour and validity of the developed product. And if there are any error found then the
process starts again from the requirement gathering.

7. Maintenance: In the maintenance phase, after deployment of the software in the working
environment there may be some bugs, some errors or new updates are required.
Maintenance involves debugging and new addition options.
When to use the Iterative Model?

1. When requirements are defined clearly and easy to understand.

2. When the software application is large.
3. When there is a requirement of changes in future.

Advantage(Pros) of Iterative Model:

1. Testing and debugging during smaller iteration is easy.

2. A Parallel development can plan.
3. It is easily acceptable to ever-changing needs of the project.
4. Risks are identified and resolved during iteration.
5. Limited time spent on documentation and extra time on designing.

Disadvantage(Cons) of Iterative Model:

1. It is not suitable for smaller projects.

2. More Resources may be required.
3. Design can be changed again and again because of imperfect requirements.
4. Requirement changes can cause over budget.
5. Project completion date not confirmed because of changing requirements.

Evolutionary Models

Evolutionary model is a combination of Iterative and Incremental model of software

development life cycle. Delivering your system in a big bang release, delivering it in
incremental process over time is the action done in this model. Some initial requirements
and architecture envisioning need to be done. It is better for software products that have
their feature sets redefined during development because of user feedback and other factors.
The Evolutionary development model divides the development cycle into smaller,
incremental waterfall models in which users are able to get access to the product at the end
of each cycle. Feedback is provided by the users on the product for the planning stage of the
next cycle and the development team responds, often by changing the product, plan or
process. Therefore, the software product evolves with time. All the models have the
disadvantage that the duration of time from start of the project to the delivery time of a
solution is very high. Evolutionary model solves this problem in a different approach.
Evolutionary model suggests breaking down of work into smaller chunks, prioritizing them
and then delivering those chunks to the customer one by one. The number of chunks is huge
and is the number of deliveries made to the customer. The main advantage is that the
customer’s confidence increases as he constantly gets quantifiable goods or services from
the beginning of the project to verify and validate his requirements. The model allows for
changing requirements as well as all work in broken down into maintainable work chunks.

Application of Evolutionary Model:

1. It is used in large projects where you can easily find modules for incremental
implementation. Evolutionary model is commonly used when the customer wants
to start using the core features instead of waiting for the full software.
2. Evolutionary model is also used in object oriented software development because
the system can be easily portioned into units in terms of objects.

Necessary conditions for implementing this model:-

● Customer needs are clear and been explained in deep to the developer team.
● There might be small changes required in separate parts but not a major change.
● As it requires time, so there must be some time left for the market constraints.
● Risk is high and continuous targets to achieve and report to customer repeatedly.
● It is used when working on a technology is new and requires time to learn.

Advantages:
 ● In evolutionary model, a user gets a chance to experiment partially developed
system.
● It reduces the error because the core modules get tested thoroughly.

Disadvantages:

● Sometimes it is hard to divide the problem into several versions that would be
acceptable to the customer which can be incrementally implemented and
delivered.

Concurrent

The concurrent development model

Concurrent engineering is an approach to product development in which multiple phases of

the product development process are carried out simultaneously instead of sequentially. The
main objective of concurrent engineering is to improve product quality and shorten
development time by overlapping the different product life cycle stages. Concurrent
engineering uses tools like development models to maximize the product development
process. Concurrent engineering is a holistic approach to product development in which all
stakeholders work together from the beginning to the end of the project.

Concurrent engineering is like a team sport because it requires close collaboration and
communication among all members of the development team and the customer. Each team
member must know what the other members are working on and how their work fits into the
project.

● The communication activity has completed in the first iteration and exits in the
awaiting changes state.
● The modeling activity completed its initial communication and then go to the
underdevelopment state.
● If the customer specifies the change in the requirement, then the modeling activity
moves from the under development state into the awaiting change state.
● The concurrent process model activities moving from one state to another state
Advantages of the concurrent development model

● This model is applicable to all types of software development processes.

● It is easy to understand and use.
● It gives immediate feedback from testing.
● It provides an accurate picture of the current state of a project.
● Reduced overall development time: By working on various aspects of the project
simultaneously, the development team can complete the project in a shorter amount
of time.
● Reduced development costs: Working on multiple aspects of the project concurrently
can help to reduce the overall development costs.
● Increased customer satisfaction: The development team can deliver the final product
to the customer sooner by completing the project in a shorter time. This can lead to
increased customer satisfaction.
● Improved quality of the final product: By simultaneously working on various aspects
of the project, the development team can quickly identify and resolve potential
problems. This can reduce the risk of making changes later and lead to a significantly
improved final product quality.

Disadvantages of the concurrent development model

● It needs better communication between the team members. This may not be
achieved all the time.
● It requires us to remember the status of the different activities.
● Increased complexity: Working on multiple aspects of the project simultaneously can
increase the project's complexity.
● Increased risk of errors: If communication and collaboration among team members
are not well-organized, there is a greater risk of errors.
 ● Requires more planning time: To properly implement concurrent engineering, the
development team must spend more time planning and organizing the project.

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.

There are 3 types of specialized process models:

1. Component Based Development
2. Formal Methods Model
3. Aspect Oriented Software development

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 component. Modeling and construction
activities begin with the identification of candidate components. These components can be
designed as either conventional software modules or objectoriented 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. 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.

2. Formal Methods Model : The formal methods model encompasses a set of activities that
leads to formal mathematical specification of computer software. Formal methods enable 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 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, 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. The formal methods model offers the promise of
defect-free software.

There are some of the disadvantages too:

• 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

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 modelled as
components and then constructed within the context of a system architecture. As modern
computer-based systems become more sophisticated certain concerns span the entire
architecture. Some concerns are high-level properties of a system, Other concerns affect
functions, while others are systemic. 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. 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. It is essential to instantiate asynchronous communication
between the software process activities applied to the engineering and construction of
aspects and components.

Personal and Team Process Models

Personal Software Process (PSP)

The Personal Software Process (PSP) emphasizes personal measurement of both the work
product that is produced and the resultant quality of the work product.
In addition PSP makes the practitioner responsible for project planning and empowers the
practitioner to control the quality of all software work products that are developed. The PSP
model defines five framework activities:

● Planning. This activity isolates requirements and develops both size and resource
estimates. In addition, defects estimate (the number of defects projected for the
work) is made. All metrics are recorded on worksheets or templates. Finally,
development tasks are identified and a project schedule is created.
● High level design. External specifications for each component to be constructed are
developed and a component design is created. Prototypes are built when uncertainty
exists. All issues are recorded and tracked.
● High level design review. Formal verification methods are applied to uncover errors
in the design. Metrics are maintained for all important tasks and work results.
● Development. The component level design is refined and reviewed. Code is
generated, reviewed, compiled, and tested. Metrics are maintained for all important
tasks and work results.
● Postmortem. Using the measures and metrics collected, the effectiveness of the
process is determined. Measures and metrics should provide guidance for modifying
the process to improve its effectiveness.

PSP stresses the need to identify errors early and, just as important, to understand the types
of errors that you are likely to make. PSP represents a disciplined, metrics based approach
to software engineering that may lead to culture shock for many practitioners.

Advantages of PSP
1. PSP represents a disciplined, metrics-based approach to software engineering.
2. PSP resulting improvement in software engineering productivity and software quality
are significant.
3. It helps the software engineers in developing high quality software products.
4. It guides the engineer for personal improvement.
5. It gives the confidence to do the job the way you know you should.
6. The PSP gives the command over your work.
Disadvantages of PSP
1. PSP is intellectually challenging and demands a level of commitment which is always
not possible
to obtain.
2. Training for PSP is lengthy and costs for the training are high.
3. Required level of measurement is culturally difficult.

Team Software Process (TSP)

Watts Humphrey extended the lessons learned from the introduction of PSP and proposed a
Team Software Process (TSP). The goal of TSP is to build a “self directed” project team that
organizes itself to produce high quality software.
Humphrey defines the following objectives for TSP:

■ Build self directed teams that plan and track their work, establish goals, and own their
processes and plans. These can be pure software teams or integrated product teams
(IPTs) of 3 to about 20 engineers.
■ Show managers how to coach and motivate their teams and how to help them
sustain peak performance
■ Accelerate software process improvement by making CMM23 Level 5 behavior
normal and expected.
■ Provide improvement guidance to high-maturity organizations.
■ Facilitate university teaching of industrial-grade team skills.

A self directed team has a consistent understanding of its overall goals and objectives;
defines roles and responsibilities for each team member; tracks quantitative project data
(about productivity and quality); identifies a team process that is appropriate for the project
and a strategy for implementing the process; defines local standards that are applicable to
the team’s software engineering work; continually assesses risk and reacts to it; and tracks,
manages, and reports project status.

TSP defines the following framework activities: project launch, high level design,
implementation, personal and team process model, integration and test, and postmortem.

TSP makes use of a wide variety of scripts, forms, and standards that serve to guide team
members in their work. “Scripts” define specific process activities (project launch, design,
implementation, integration and system testing, postmortem) and other more detailed work
functions (development planning, requirements development, software configuration
management, unit test) that are part of the team process.

What is TSP ?

TSP (Team Software Process) is a guideline for software product development teams.

TSP focuses on helping development teams to improve their quality and productivity to
better meet goals of cost and progress.

TSP is designed for groups ranging from 2 persons to 20 persons. TSP can be applied to
large multiple-group processes for up to 150 persons.

There are 8 steps for implementing PSP and TSP. Each step is focused on solving particular
process problems.
Objectives(Purpose) of TSP

1.To build a self-directed teams that plan and track their work, establish goals and own their
process and plans. These can be pure software teams or integrated teams

2.Shows managers how to coach and motivate the team members so that they can give
peak (high) performance.

3.It accelerate (increases) the software process development

Goal of TSP

The goal of the TSP is to build a ―Self-Directed project teams that organizes itself to
produce high quality software.

Activities of TSP

1) Project Launch: It reviews project objective and describes the TSP structure and content.
It assigns need and roles to the team members and describes the customers need
statement.

2) High Level Design: it creates the high level design, specify the design, inspect the design
and develop the integration plan.

3) Implementation: This uses the PSP to implement the modules and the functions.

4) Integration and Testing: Testing builds and integrates the system.

5) Postmortem: Writes the cycle report and produces peer and team review.
TSP Advantages

1. Defines roles and responsibilities for each team member.

2. Track quantitative project data.
3. Identifies a team process that is appropriate for the project and a strategy for
implementing the process.
4. Defines local standards that are applicable to the team‘s software engineering work;
5. Continually assesses risk and reacts to it;
6. Tracks, manages, and reports project status.
TSP & PSP Comparison
PSP
1. PSP(Personal Software
Process)provide a standard personal
process structure for software developers
2. PSP consists of a set of methods,
tables, scripts etc. that serve as a
guideline for software developers to plan,
measure and manage their Work,
including how to define their processes
and measure quality and productivity.
TSP
1. TSP (Team Software Process) is a
guideline for software product
Development teams.
2. TSP focuses on helping development
teams to improve their quality and
productivity to better meet goals of cost
and progress.
3. PSP skills are used in a TSP team
Environment.
4. The PSP is a personal process that can
be adapted to suit the needs of the
individual developer.
5. The Personal Software Process (PSP)
is an SEI technology that brings discipline
to the practices of individual software
engineers for improving product quality
and increasing cost.
3. TSP teams consist of PSP-trained
developers who volunteer for areas of
project responsibility, so the project is
managed by the team Itself.
4. TSP uses team based planning
sessions
5. The Team Software Process (TSP) is
complementary SEI technology that
enables teams to develop
software-intensive products more
effectively.
Introduction to Clean Room Software Engineering.

Introduction to cleanroom software engineering

● It is an engineering approach which is used to build correctness in developed

software.
● The main concept behind the cleanroom software engineering is to remove the
dependency on the costly processes.
● The cleanroom software engineering includes the quality approach of writing the
code from the beginning of the system and finally gathers into a complete system.

Following tasks occur in cleanroom engineering:

1. Incremental planning
● In this task, the incremental plan is developed.
● The functionality of each increment, projected size of the increment and the
cleanroom development schedule is created.
● The care is to be taken that each increment is certified and integrated in proper time
according to the plan.

2. Requirements gathering
● Requirement gathering is done using the traditional techniques like analysis, design,
code, test and debug.
● A more detailed description of the customer level requirement is developed.

3. Box structure specification

● The specification method uses box structure.
● Box structure is used to describe the functional specification.
● The box structure separate and isolate the behaviour, data and procedure in each
increment.

4. Formal design
 ● The cleanroom design is a natural specification by using the black box structure
approach.
● The specification is called as state boxes and the component level diagram called
as the clear boxes.

5. Correctness verification
● The cleanroom conducts the exact correctness verification activities on the design
and then the code.
● Verification starts with the highest level testing box structure and then moves toward
the design detail and code.
● The first level of correctness takes place by applying a set of 'correcting questions'.
● More mathematical or formal methods are used for verification if correctness does
not signify that the specification is correct.

6. Code generation, inspection and verification

● The box structure specification is represented in a specialized language and these
are translated into the appropriate programming language.
● Use the technical reviews for the syntactic correctness of the code.

7. Statical test planning

● Analyzed, planned and designed the projected usages of the software.
● The cleanroom activity is organized in parallel with specification, verification and
code generation.

8. Statistical use testing

● The exhaustive testing of computer software is impossible. It is compulsory to
design a limited number of test cases.
● Statistical use technique execute a set of tests derived from a statistical sample in
all possible program executions.
● These samples are collected from the users from a targeted population.

9. Certification
 ● After the verification, inspection and correctness of all errors, the increments are
certified and ready for integration.

Cleanroom process model

● The modeling approach in cleanroom software engineering uses a method called

box structure specification.
● A 'box' contains the system or the aspect of the system in detail.
● The information in each box specification is sufficient to define its refinement without
depending on the implementation of other boxes.

The cleanroom process model uses three types of boxes as follows:

1. Black box
● The black box identifies the behaviour of a system.
● The system responds to specific events by applying the set of transition rules.

2. State box
● The box consists of state data or operations that are similar to the objects.
● The state box represents the history of the black box i.e the data contained in the
state box must be maintained in all transitions.

3. Clear box
● The transition function used by the state box is defined in the clear box.
● It simply states that a clear box includes the procedural design for the state box.

Software Quality Assurance (SQA): Verification and

Validation

What is Quality?
Quality defines any measurable characteristics such as correctness, maintainability,
portability, testability, usability, reliability, efficiency, integrity, reusability, and interoperability.

There are two kinds of Quality:

Quality of Design: Quality of Design refers to the characteristics that designers specify for
an item. The grade of materials, tolerances, and performance specifications that all
contribute to the quality of design.

Quality of conformance: Quality of conformance is the degree to which the design

specifications are followed during manufacturing. Greater the degree of conformance, the
higher is the level of quality of conformance.

Software Quality: Software Quality is defined as the conformance to explicitly state

functional and performance requirements, explicitly documented development standards,
and inherent characteristics that are expected of all professionally developed software.

Quality Control: Quality Control involves a series of inspections, reviews, and tests used
throughout the software process to ensure each work product meets the requirements place
upon it. Quality control includes a feedback loop to the process that created the work
product.

Quality Assurance: Quality Assurance is the preventive set of activities that provide greater
confidence that the project will be completed successfully.

Quality Assurance focuses on how the engineering and management activity will be done?

As anyone is interested in the quality of the final product, it should be assured that we are
building the right product.

It can be assured only when we do inspection & review of intermediate products, if there are
any bugs, then it is debugged. This quality can be enhanced.
Importance of Quality
We would expect the quality to be a concern of all producers of goods and services.
However, the distinctive characteristics of software and in particular its intangibility and
complexity, make special demands.

Increasing criticality of software: The final customer or user is naturally concerned about
the general quality of software, especially its reliability. This is increasing in the case as
organizations become more dependent on their computer systems and software is used
more and more in safety-critical areas. For example, to control aircraft.

The intangibility of software: This makes it challenging to know that a particular task in a
project has been completed satisfactorily. The results of these tasks can be made tangible
by demanding that the developers produce 'deliverables' that can be examined for quality.

Accumulating errors during software development: As computer system development is

made up of several steps where the output from one level is input to the next, the errors in
the earlier deliverables will be added to those in the later stages leading to accumulated
determinable effects. In general the later in a project that an error is found, the more
expensive it will be to fix. In addition, because the number of errors in the system is
unknown, the debugging phases of a project are particularly challenging to control.

Software Quality Assurance

Software quality assurance is a planned and systematic plan of all actions necessary to
provide adequate confidence that an item or product conforms to establish technical
requirements.

A set of activities designed to calculate the process by which the products are developed or
manufactured.

SQA Encompasses

● A quality management approach

● Effective Software engineering technology (methods and tools)

● Formal technical reviews that are tested throughout the software process

● A multi tiered testing strategy

● Control of software documentation and the changes made to it.

● A procedure to ensure compliances with software development standards

● Measuring and reporting mechanisms.

SQA Activities
Software quality assurance is composed of a variety of functions associated with two
different constituencies ? the software engineers who do technical work and an SQA group
that has responsibility for quality assurance planning, record keeping, analysis, and
reporting.

Following activities are performed by an independent SQA group:

1. Prepares an SQA plan for a project: The program is developed during project
planning and is reviewed by all stakeholders. The plan governs quality assurance
activities performed by the software engineering team and the SQA group. The plan
identifies calculations to be performed, audits and reviews to be performed,
standards that apply to the project, techniques for error reporting and tracking,
documents to be produced by the SQA team, and amount of feedback provided to
the software project team.

2. Participates in the development of the project's software process description:

The software team selects a process for the work to be performed. The SQA group
reviews the process description for compliance with organizational policy, internal
software standards, externally imposed standards (e.g. ISO-9001), and other parts of
the software project plan.

3. Reviews software engineering activities to verify compliance with the defined

software process: The SQA group identifies, reports, and tracks deviations from the
process and verifies that corrections have been made.

4. Audits designated software work products to verify compliance with those

defined as a part of the software process: The SQA group reviews selected work
products, identifies, documents and tracks deviations, verify that corrections have
been made, and periodically reports the results of its work to the project manager.

5. Ensures that deviations in software work and work products are documented
and handled according to a documented procedure: Deviations may be
encountered in the project method, process description, applicable standards, or
technical work products.

6. Records any noncompliance and reports to senior management: Non-

compliance items are tracked until they are resolved.

Quality Assurance v/s Quality control

Quality Assurance Quality Control

 Quality Assurance (QA) is the set of actions Quality Control (QC) is described as the
including facilitation, training, measurement, processes and methods used to
and analysis needed to provide adequate compare product quality to
confidence that processes are established and requirements and applicable standards,
continuously improved to produce products or and the actions are taken when a
services that conform to specifications and are nonconformance is detected.
fit for use.

QA is an activity that establishes and calculates QC is an activity that demonstrates

the processes that produce the product. If there whether or not the product produced
is no process, there is no role for QA. met standards.

QA helps establish process QC relates to a particular product or

service

QA sets up a measurement program to QC verified whether particular attributes

evaluate processes exist, or do not exist, in a explicit
product or service.

QA identifies weakness in processes and QC identifies defects for the primary

improves them goals of correcting errors.

Quality Assurance is a managerial tool. Quality Control is a corrective tool.

Verification is an example of QA. Validation is an example of QC.

Differences between Verification and Validation

Verification is the process of checking that a 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 static
testing.

Verification means Are we building the product right?

Validation is the process of checking whether the software product is up to the mark or in
other words the product has high level requirements. It is the process of checking the
validation of a product i.e. it checks what we are developing is the right product. It is
validation of actual and expected product. Validation is dynamic testing.

Validation means Are we building the right product?

The difference between Verification and Validation is as follow:

Verification Validation

It includes checking documents, design, It includes testing and validating the actual
codes and programs. product.

Verification is the static testing. Validation is the dynamic testing.

It does not include the execution of the

It includes the execution of the code.
code.

Methods used in verification are reviews, Methods used in validation are Black Box
walkthroughs, inspections and Testing, White Box Testing and
desk-checking. non-functional testing.

It checks whether the software meets the

It checks whether the software conforms to
requirements and expectations of a
specifications or not.
customer or not.

It can find the bugs in the early stage of It can only find the bugs that could not be
the development. found by the verification process.

The goal of verification is application and

The goal of validation is an actual product.
software architecture and specification.

Validation is executed on software code

Quality assurance team does verification.
with the help of testing team.

It comes before validation. It comes after verification.

 It consists of checking of documents/files It consists of execution of program and is
and is performed by human. performed by computer.

SQA Plans

Software Quality Assurance Plan

Abbreviated as SQAP, the software quality assurance plan comprises the procedures,
techniques, and tools that are employed to make sure that a product or service aligns with
the requirements defined in the SRS(software requirement specification).
The plan identifies the SQA responsibilities of a team, and lists the areas that need to be
reviewed and audited. It also identifies the SQA work products.

The SQA plan document consists of the below sections:

1. Purpose section
2. Reference section
3. Software configuration management section
4. Problem reporting and corrective action section
5. Tools, technologies, and methodologies section
6. Code control section
7. Records: Collection, maintenance, and retention section
8. Testing methodology

SQA Activities

Given below is the list of SQA activities:

#1) Creating an SQA Management Plan:

The foremost activity includes laying down a proper plan regarding how the SQA will be
carried out in your project.

Along with what SQA approach you are going to follow, what engineering activities will be
carried out, and it also includes ensuring that you have the right talent mix in your team.

#2) Setting the Checkpoints:

The SQA team sets up different checkpoints according to which it evaluates the quality of
the project activities at each checkpoint/project stage. This ensures regular quality inspection
and working as per the schedule.

#3) Apply software Engineering Techniques:

Applying some software engineering techniques aids a software designer in achieving

high-quality specifications. For gathering information, a designer may use techniques such
as interviews and FAST (Functional Analysis System Technique).

Later, based on the information gathered, the software designer can prepare the project
estimation using techniques like WBS (work breakdown structure), SLOC (source line of
codes), and FP(functional point) estimation.

#4) Executing Formal Technical Reviews:

An FTR is done to evaluate the quality and design of the prototype.

In this process, a meeting is conducted with the technical staff to discuss the actual quality
requirements of the software and the design quality of the prototype. This activity helps in
detecting errors in the early phase of SDLC and reduces rework effort in the later phases.

#5) Having a Multi-Testing Strategy:

By multi-testing strategy, we mean that one should not rely on any single testing approach,
instead, multiple types of testing should be performed so that the software product can be
tested well from all angles to ensure better quality.

#6) Enforcing Process Adherence:

This activity insists on the need for process adherence during the software development
process. The development process should also stick to the defined procedures.

This activity is a blend of two sub-activities which are explained below in detail:

(i) Product Evaluation:

This activity confirms that the software product is meeting the requirements that were
discovered in the project management plan. It ensures that the set standards for the project
are followed correctly.

(ii) Process Monitoring:

This activity verifies if the correct steps were taken during software development. This is
done by matching the actually taken steps against the documented steps.

#7) Controlling Change:

In this activity, we use a mix of manual procedures and automated tools to have a
mechanism for change control.

By validating the change requests, evaluating the nature of change, and controlling the
change effect, it is ensured that the software quality is maintained during the development
and maintenance phases.

#8) Measure Change Impact:

If any defect is reported by the QA team, then the concerned team fixes the defect.

After this, the QA team should determine the impact of the change which is brought by this
defect fix. They need to test not only if the change has fixed the defect, but also if the
change is compatible with the whole project.
For this purpose, we use software quality metrics that allow managers and developers to
observe the activities and proposed changes from the beginning till the end of SDLC and
initiate corrective action wherever required.

#9) Performing SQA Audits:

The SQA audit inspects the entire actual SDLC process followed by comparing it against the
established process.

It also checks whether whatever was reported by the team in the status reports was actually
performed or not. This activity also exposes any non-compliance issues.

#10) Maintaining Records and Reports:

It is crucial to keep the necessary documentation related to SQA and share the required
SQA information with the stakeholders. The test results, audit results, review reports, change
requests documentation, etc. should be kept for future reference.

#11) Manage Good Relations:

In fact, it is very important to maintain harmony between the QA and the development team.

We often hear that testers and developers often feel superior to each other. This should be
avoided as it can affect the overall project quality.

Software Quality Frameworks

Software Quality Framework is a model for software quality by connecting and integrating
the different views of software quality. This framework connects the customer view with the
developer view of software quality and it treats software as a product. The software product
view describes the characteristics of a product that bear on its ability to satisfy stated and
implied needs.
This is a framework that describes all the different concepts relating to quality in a common
way measured by qualitative scale that can be understood and interpreted in a common way.
Therefore the most influential factor for the developers is the customer perception. This
framework connects the developer with the customer to derive a common interpretation for
quality.

1. Developers View:
Validation and verification are two independent methods used together for checking
that a software product meets the requirements and that it fulfills its intended
purpose.Validation checks that the product design satisfies the purposeful usage and
 verification checks for errors in the software. The primary concern for developers is in
the design and engineering processes involved in producing software. Quality can be
measured by the degree of conformance to predetermined requirement and
standards, and deviations from these standards can lead to poor quality and low
reliability. While validation and verification are used by the developers to improve the
software, the two methods don’t represent a quantifiable quality measurement.
The developer view of software quality and customer view of software quality are
both different things.

For example the customer understands or describes the quality of operation as

meeting the requirement while the developers use different factors to describe the
software quality.
The developer view of quality in the software is influenced by many factors.

This model stresses on 3 primary ones:

1. The code:
It is measured by its correctness and reliability.
2. The data:
It is measured by the application integrity.
3. Maintainability:
It has different measures the simplest is the mean time to change.

2. Users View:
When the user acquires software, he/she always expect a high-quality software.
When end users develop their software then quality is different. End-user
programming, a phrase popularized by which is programming to achieve the result of
a program primarily for personal, rather than public use. The important distinction
here is that software itself is not primarily intended for use by a large number of users
with varying needs.

For example, a teacher may write a spreadsheet to track students’test scores. In

these end-user programming situations, the program is a means to an end that could
be used to accomplish a goal. In contradiction to end-user programming, professional
programming has the goal of producing software for others to use.

For example, the moment a novice Web developer moves from designing a web
page for himself to designing a Web page for others, the nature of this activity has
changed.
Users find software quality as a fit between their goals and software’s functionality.
The better the quality, the more likely the user will be satisfied with the soft-ware.
When the quality is bad, developers must meet user needs or face a diminishing
demand for their software. Therefore, the user understands quality as fitness for
purpose. Avoiding complexity and keeping software simple, considerably lessens the
implementation risk of software.In some instances, users abandoned the
 implementation of a complex software because the software developers were
expecting the users to change their business and to go with the way the software
works.

3. Product View:
The product view describes quality as correlated to inherent characteristics of the
product. Product quality is defined as the set of characteristics and features of a
product that gives contribution to its ability to fulfill given requirements. Product
quality can be measured by the value-based view which sees the quality as
dependent on the amount a customer is willing to pay for it. According the users, a
high-quality product is one that satisfies their expectations and preferences while
meeting their requirement. Satisfaction of end users of the product represents craft to
learn, use, upgrade the product and when asked to participate in rating the product, a
positive rating is given.

ISO 9000 Models

ISO 9000 Certification

ISO (International Standards Organization) is a group or consortium of 63 countries

established to plan and fosters standardization. ISO declared its 9000 series of standards in
1987. It serves as a reference for the contract between independent parties. The ISO 9000
standard determines the guidelines for maintaining a quality system. The ISO standard
mainly addresses operational methods and organizational methods such as responsibilities,
reporting, etc. ISO 9000 defines a set of guidelines for the production process and is not
directly concerned about the product itself.

Types of ISO 9000 Quality Standards

The ISO 9000 series of standards is based on the assumption that if a proper stage is
followed for production, then good quality products are bound to follow automatically. The
types of industries to which the various ISO standards apply are as follows.

1. ISO 9001: This standard applies to the organizations engaged in design,

development, production, and servicing of goods. This is the standard that applies to
most software development organizations.

2. ISO 9002: This standard applies to those organizations which do not design products
but are only involved in the production. Examples of these category industries
contain steel and car manufacturing industries that buy the product and plants
designs from external sources and are engaged in only manufacturing those
products. Therefore, ISO 9002 does not apply to software development
organizations.

3. ISO 9003: This standard applies to organizations that are involved only in the
installation and testing of the products. For example, Gas companies.

How to get ISO 9000 Certification?

An organization determines to obtain ISO 9000 certification applies to ISO registrar office for
registration. The process consists of the following stages:
 1. Application: Once an organization decided to go for ISO certification, it applies to
the registrar for registration.

2. Pre-Assessment: During this stage, the registrar makes a rough assessment of the
organization.

3. Document review and Adequacy of Audit: During this stage, the registrar reviews
the document submitted by the organization and suggest an improvement.

4. Compliance Audit: During this stage, the registrar checks whether the organization
has compiled the suggestion made by it during the review or not.

5. Registration: The Registrar awards the ISO certification after the successful
completion of all the phases.

6. Continued Inspection: The registrar continued to monitor the organization time by

time.

CMM Models.

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’s).

Shortcomings of SEI/CMM:
 ● It encourages the achievement of a higher maturity level in some cases by
displacing the true mission, which is improving the process and overall software
quality.
● It only helps if it is put into place early in the software development process.
● It has no formal theoretical basis and in fact is based on the experience of very
knowledgeable people.
● It does not have good empirical support and this same empirical support could
also be constructed to support other models.

Key Process Areas (KPA’s):

Each of these KPA’s 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.
The 5 levels of CMM are as follows:

Level-1: Initial –

● No KPA’s 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.

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 which are
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 the 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.
● Use of new tools, techniques, and evaluation of software processes is done to
prevent 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.

*********************All the best **********************