SRI RAMAKRISHNA ENGINEERING COLLEGE, COIMBATORE

(Autonomous Institution, Reaccredited by NAAC with 8A+9 GRADE Approved by AICTE and Permanently affiliated to Anna University, Chennai)

AUTONOMOUS EXAMINATIONS – MAY 2023

B.E / B.TECH – UG REGULATION - 2020

SUBJECT CODE & SUBJECT NAME : 20CS213 Software Development Process

Answer Key
Answer ALL questions
Duration: 3 Hours Maximum: 100 Marks
PART – A (7 x 1 = 7
Objective Type - Multiple Choice Question Marks)
Q.No Question Marks CO BL PI
1. What is the major drawback of the Spiral Model?
a) Higher b) Doesn9t c) d) Strong
amount of work well Additional approval
risk for smaller functionaliti and
analysis projects es are added documentati
later on on control
2. Which of the following is/are the advantages of using
agile methodology?
a) b) c) Last- d) All of the
Customer Application above
moment
is satisfied ’s
developmen changes are
t is rapid
also
accepted
3. Which one of the following is not a step of requirement
engineering?
a) b) Design c) Analysis d)
Elicitation documentati
on
4. Which one of the following is a functional requirement?
a) b) c) d) None of
Maintainab Portability Robustness the
ility mentioned

-1-
 5. White-box testing can be started:
a) After b) After c) After d) After
installation SRS programmi designing
creation ng
6. Software measurement is useful to
a) Indicate b) Track c) Assess d) All of the
quality of progress productivity above
the product

7. A design is said to be a good design if the components

are
a) Strongly b) Weakly c) Strongly d) Strongly
coupled cohesive coupled and cohesive
weakly and weakly
cohesive coupled

Objective Type – Fill in the Blanks (3 x 1 = 3 Marks)

8. A product is built in a series of repetitions called ____ Sprints
9. In size-oriented metrics, metrics are developed based on the _______ number of lines of
code
10. __________ combines procedures and tools to manage different versions of configuration
objects that are created during the software process. Version control
PART – B (5 x 3 = 15
Short Answers Marks)
Q.No Question Marks CO BL PI
11. State various Agile methods
Key:
The different types of agile methodology that
software development teams can use:
 Kanban
 Scrum
 Extreme Programming
 Crystal
 Dynamic Systems Development
 Feature-driven Development

-2-
 Lean Software Development Methodology

12. State Characteristics of SRS document

Key:
Software requirement specification (SRS) is a document
that completely describes what the proposed software
should do without describing how software will do it. The
basic goal of the requirement phase is to produce the SRS,
Which describes the complete behavior of the proposed
software. SRS is also helping the clients to understand
their own needs.
Characteristics of an SRS:
1. Correct
2. Complete
3. Unambiguous
4. Verifiable
5. Consistent
6. Ranked for importance and/or stability
7. Modifiable
8. Traceable
13. List out software quality attributes
Key:
a. Functionality: is assessed by evaluating the
features set, the generality of the functions that are
delivered, and the security of the overall system.
b. Usability: is assessed by considering human
factors, overall aesthetics, consistency, and
documentation.
c. Reliability: is evaluated by measuring the
frequency and severity of failure, the accuracy of
output results, the mean-time-to-failure, the ability to
recover from failure, and the predictability of the
program.
d. Performance: is measured by processing speed,
response time, resource consumption, throughput,
and efficiency.
e. Supportability: combines the ability to extend the
program extensibility, adaptability, serviceability ➔
maintainability. In addition, testability, compatibility,
configurability, etc.
14. Define Software Testing. List out the advantages of
Software Testing.
Key:
Software Testing: Testing is the process of
exercising a program with the specific intent of

-3-
 finding errors prior to delivery to the end user.
Advantages of software testing:
Software testing shows
1. errors
2. requirements conformance
3. performance
4. an indication of quality
15. Differentiate between verification and validation
Key:

PART – C (5 x 15 = 75
Long Answers Marks)
[Answer any FIVE Questions]
Q.No Question
16. i) Explain the function of spiral model.
Key:
Spiral ModelSpiral model is a combination of both, iterative model and one of
the
SDLC model. It can be seen as if you choose one SDLC model and combine it
with This model considers risk, which often goes un-noticed by most other
models. The model starts with determining objectives and constraints of the
software at the start of one iteration. Next phase is of prototyping the software.
This includes risk analysis. Then one standard SDLC model is used to build the
software. In the fourth phase of the plan of next iteration is prepared.

-4-
 Explanation of all the phases

ii) Compare Agile and Waterfall models.

Key:
Agile Waterfall
It separates the project development Software development process is divided into
lifecycle into sprints. distinct phases.
Waterfall methodology is a sequential design
It follows an incremental approach
process.
Waterfall is a structured software
Agile methodology is known for its
development methodology so most times it
flexibility.
can be quite rigid.
Agile can be considered as a collection of Software development will be completed as
many different projects. one single project.
Agile is quite a flexible method which
There is no scope of changing the
allows changes to be made in the project
requirements once the project development
development requirements even if the
starts.
initial planning has been completed.
Agile methodology, follow an iterative
development approach because of this All the project development phases like
planning, development, prototyping and designing, development, testing, etc. are
other software development phases may completed once in the Waterfall model.
appear more than once.
The test plan is rarely discussed during the
Test plan is reviewed after each sprint
test phase.
Agile development is a process in which The method is ideal for projects which have
the requirements are expected to change definite requirements and changes not at all
and evolve. expected.
In Agile methodology, testing is performed In this methodology, the <Testing= phase
concurrently with software development. comes after the <Build= phase

-5-
 Agile introduces a product mindset where
This model shows a project mindset and
the software product satisfies needs of its
places its focus completely on accomplishing
end customers and changes itself as per the
the project.
customer’s demands.
Agile methdology works exceptionally
Reduces risk in the firm fixed price contracts
well with Time & Materials or non-fixed
by getting risk agreement at the beginning of
funding. It may increase stress in fixed-
the process.
price scenarios.
Prefers small but dedicated teams with a
Team coordination/synchronization is very
high degree of coordination and
limited.
synchronization.
Products owner with team prepares
Business analysis prepares requirements
requirements just about every day during a
before the beginning of the project.
project.
Test team can take part in the requirements It is difficult for the test to initiate any change
change without problems. in requirements.
Description of project details can be altered Detail description needs to implement
anytime during the SDLC process. waterfall software development approach.
The Agile Team members are
interchangeable, as a result, they work In the waterfall method, the process is always
faster. There is also no need for project straightforward so, project manager plays an
managers because the projects are managed essential role during every stage of SDLC.
by the entire team

17. i) Explain the various phases of software development life cycle (SDLC) and
identify deliverables at each phase.
Key:
A typical Software Development life cycle consists of the following stages:

Stage 3: Designing the product architecture

d Maintenance
Requirement Gathering and analysis: All possible requirements of the system
to be developed are captured in this phase and documented in a requirement
specification doc.
System Design: The requirement specifications from first phase are studied in
this phase and system design is prepared. System Design helps in specifying
hardware and system requirements and also helps in defining overall system
architecture.
Implementation: With inputs from system design, the system is first
developed in small programs called units, which are integrated in the next phase.
Each unit is developed and tested for its functionality which is referred to as Unit
Testing.
Integration and Testing: All the units developed in the implementation phase
are

-6-
 integrated into a system after testing of each unit. Post integration the entire
system is tested for any faults and failures.
Deployment of system: Once the functional and non-functional testing is
done, the product is deployed in the customer environment or released into the
market.
Maintenance: There are some issues which come up in the client
environment. To fix those issues patches are released. Also to enhance the
product some better versions are released. Maintenance is done to deliver these
changes in the customer environment.
ii) Explain Agile Method in detail.
Key:
Scrum is the type of Agile framework. It is a framework within which people
can address complex adaptive problem while productivity and creativity of
delivering product is at highest possible values. Scrum uses Iterative process.
Silent features of Scrum are:
 Scrum is light-weighted framework
 Scrum emphasizes self-organization
 Scrum is simple to understand
 Scrum framework help the team to work together
Lifecycle of Scrum:

Sprint:
A Sprint is a time-box of one month or less. A new Sprint starts immediately
after the completion of the previous Sprint.
Release:
When the product is completed then it goes to the Release stage.
Sprint Review:

-7-
 If the product still have some non-achievable features then it will be checked in
this stage and then the product is passed to the Sprint Retrospective stage.
Sprint Retrospective:
In this stage quality or status of the product is checked.
Product Backlog:
According to the prioritize features the product is organized.
Sprint Backlog:
Sprint Backlog is divided into two parts Product assigned features to sprint and
Sprint planning meeting.
Advantage of using Scrum framework:
 Scrum framework is fast moving and money efficient.
 Scrum framework works by dividing the large product into small sub-
products. It’s like a divide and conquer strategy
 In Scrum customer satisfaction is very important.
 Scrum is adaptive in nature because it have short sprint.
 As Scrum framework rely on constant feedback therefore the quality of
product increases in less amount of time
Disadvantage of using Scrum framework:
 Scrum framework do not allow changes into their sprint.
 Scrum framework is not fully described model. If you wanna adopt it
you need to fill in the framework with your own details like Extreme
Programming(XP), Kanban, DSDM.
 It can be difficult for the Scrum to plan, structure and organize a project
that lacks a clear definition.
 The daily Scrum meetings and frequent reviews require substantial
resources.

18. i) Illustrate about CASE Tools.

Key:
CASE tools are set of software application programs, which are used to automate
SDLC activities. CASE tools are used by software project managers, analysts and
engineers to develop software system.

Components of CASE Tools

CASE tools can be broadly divided into the following parts based on their use at

-8-
a particular SDLC stage:
Central Repository - CASE tools require a central repository, which can
serve as a source of common, integrated and consistent information. Central
repository is a central place of storage where product specifications,
requirement documents, related reports and diagrams, other useful information
regarding management is stored. Central repository also serves
as data dictionary.

Upper Case Tools - Upper CASE tools are used in planning, analysis and
design stages of SDLC.
Lower Case Tools - Lower CASE tools are used in implementation, testing
and maintenance.
Integrated Case Tools - Integrated CASE tools are helpful in all the stages
of SDLC, from Requirement gathering to Testing and documentation.
CASE tools can be grouped together if they have similar functionality, process
activities and capability of getting integrated with other tools.
Scope of Case Tools
The scope of CASE tools goes throughout the SDLC.
Case Tools Types
Now we briefly go through various CASE tools
Diagram tools
These tools are used to represent system components, data and control flow
among various software components and system structure in a graphical form.
For example, Flow Chart Maker tool for creating state-of-the-art flowcharts.
Process Modeling Tools
Process modeling is method to create software process model, which is used to
develop the software. Process modeling tools help the managers to choose a
process model or modify it as per the requirement of software product. For
example, EPF Composer
Project Management Tools
These tools are used for project planning, cost and effort estimation, project

-9-
 scheduling and resource planning. Managers have to strictly comply project
execution with every mentioned step in software project management. Project
management tools help in storing and sharing project information in real-time
throughout the organization. For example, Creative Pro Office, Trac Project,
Basecamp.
Documentation Tools
Documentation in a software project starts prior to the software process, goes
throughout all phases of SDLC and after the completion of the project.
Documentation tools generate documents for technical users and end users.
Technical users are mostly in-house professionals of the development team who
refer to system manual, reference manual, training manual, installation manuals
etc. The end user documents describe the functioning and how-to of the system
such as user manual. For example, Doxygen, DrExplain, Adobe RoboHelp for
documentation.
Analysis Tools
These tools help to gather requirements, automatically check for any
inconsistency, inaccuracy in the diagrams, data redundancies or erroneous
omissions. For example, Accept 360, Accompa, CaseComplete for requirement
analysis, Visible Analyst for total analysis.
Design Tools
These tools help software designers to design the block structure of the software,
which may further be broken down in smaller modules using refinement
techniques. These tools provides detailing of each module and interconnections
among modules. For example, Animated Software Design.
Configuration Management Tools
An instance of software is released under one version. Configuration
Management tools deal with –

ii) Explain Software Requirement Elicitation in detail

Key:
The aims of the requirements elicitation process are to understand the work that
stakeholders do and how they might use a new system to help support that work.
During requirements elicitation, software engineers work with stakeholders to
find out about the application domain, work activities, the services and system
features that stakeholders want, the required performance of the system,
hardware constraints, and so on.
Eliciting and understanding requirements from system stakeholders is a difficult
process for several reasons:
1. Stakeholders often don’t know what they want from a computer system except
in the most general terms; they may find it difficult to articulate what they want
the system to do; they may make unrealistic demands because they don’t know
what is and isn’t feasible.
2. Stakeholders in a system naturally express requirements in their own terms and
with implicit knowledge of their own work. Requirements engineers, without
experience in the customer’s domain, may not understand these requirements.

- 10 -
 3. Different stakeholders, with diverse requirements, may express their
requirements in different ways. Requirements engineers have to discover all
potential sources of requirements and discover commonalities and conflict.
4. Political factors may influence the requirements of a system. Managers may
demand specific system requirements because these will allow them to increase
their influence in the organization.
5. The economic and business environment in which the analysis takes place is
dynamic. It inevitably changes during the analysis process. The importance of
particular requirements may change. New requirements may emerge from new
stakeholders who were not originally consulted.
A process model of the elicitation and analysis process is shown in Figure.

The process activities are:

1. Requirements discovery and understanding This is the process of interacting
with stakeholders of the system to discover their requirements. Domain
requirements from stakeholders and documentation are also discovered during
this activity.
2. Requirements classification and organization This activity takes the
unstructured collection of requirements, groups related requirements and
organizes them into coherent clusters.
3. Requirements prioritization and negotiation Inevitably, when multiple
stakeholders are involved, requirements will conflict. This activity is concerned
with prioritizing requirements and finding and resolving requirements conflicts
through negotiation. Usually, stakeholders have to meet to resolve differences
and agree on compromise requirements.
4. Requirements documentation The requirements are documented and input into
the next round of the spiral. An early draft of the software requirements
documents may be produced at this stage, or the requirements may simply be
maintained informally on whiteboards, wikis, or other shared spaces.
Requirements elicitation techniques
There are two fundamental approaches to requirements elicitation:
1. Interviewing, where you talk to people about what they do.
2. Observation or ethnography, where you watch people doing their job to see

- 11 -
 what artifacts they use, how they use them, and so on.
Stories and scenarios
Explanation with example
19. i) Draw following four UML diagrams for Online Banking System:
1. Use Case Diagram
2. Class Diagram
3. Activity Diagram
4. State chart Diagram

Key:
Use Case Diagram (3 Marks)

Class Diagram (3 Marks)

Activity Diagram (6 Marks)

- 12 -
 State Chart Diagram (3 Marks)

20. i) Describe the steps involved in Risk management.

Key:
The key steps to risk management are summarized below.

- 13 -
Risk Assessment
The goal of risk assessment is to identify the risk factors that are a part of the
activity being undertaken. Basically, it's about working out what could go wrong.
For example, the task could be attending a client meeting. The possible risk
factors would include
 Distance from office to client's premises
 Number of people having to attend meeting
 What materials are required for meeting (eg. Laptop, projector…etc)
 Availability of cabs
 Availability of public transport
 Time of meeting, eg. Midday, peak hour
The more risk factors there are with a given task, the more that can go wrong.
Risk Evaluation
Once you have identified the risk factors, then you have to work out what impact
they can have on the task. Following the previous example, what would be the
impact of arriving at the meeting late?

mpact on your next review?

If the impact is low, the risk doesn't require much attention.

Risk Reduction
Risk reduction can also be considering risk containment or minimisation. What
term you use doesn't matter as long as you are consistent. The are two parts to
risk reduction

In getting to our client meeting on time we could take the following actions
Leave earlier (allow more travel time)

The idea is to avoid the risk altogether but if that's not possible, have plans in
place that can minimize the impact.
Risk Monitoring
Risk monitoring has two dimensions to it. Firstly it's about keeping an eye on the
risks that you've already identified to see if anything has changed, if the impact
has increased or decrease, which could require action. And secondly, to see if
there are any new risks that have arisen during the project.
For example, while we're on our way to the client meeting, we could be keeping
an eye on the time while listening to traffic reports for any potential traffic

- 14 -
 delays. The most important thing to remember is that just because we have
identified risks upfront, that doesn't mean new ones won't emerge.
Risk Reporting
Risk reporting is about on-going awareness and the effectiveness of any actions
or strategies taken to contain or reduce risk. For example calling your colleagues
about traffic delays or train cancellations. The goal of risk reporting is to keep an
eye on the existing risks to help any new ones arising.
ii) Summarize Software Measurements and Metrics
Key:
Software Measurement: A measurement is a manifestation of the size,
quantity, amount, or dimension of a particular attribute of a product or process.
Software measurement is a titrate impute of a characteristic of a software
product or the software process. It is an authority within software engineering.
The software measurement process is defined and governed by ISO Standard.

Software Measurement Principles:

The software measurement process can be characterized by five activities-

1. Formulation: The derivation of software measures and metrics
appropriate for the representation of the software that is being considered.
2. Collection: The mechanism used to accumulate data required to derive
the formulated metrics.
3. Analysis: The computation of metrics and the application of
mathematical tools.
4. Interpretation: The evaluation of metrics resulting in insight into the
quality of the representation.
5. Feedback: Recommendation derived from the interpretation of product
metrics transmitted to the software team.

Need for Software Measurement:

Software is measured to:

 Create the quality of the current product or process.
 Anticipate future qualities of the product or process.
 Enhance the quality of a product or process.
 Regulate the state of the project in relation to budget and schedule.

Classification of Software Measurement:

There are 2 types of software measurement:

1. Direct Measurement: In direct measurement, the product, process, or
thing is measured directly using a standard scale.
2. Indirect Measurement: In indirect measurement, the quantity or

- 15 -
 quality to be measured is measured using related parameters i.e. by use of
reference.

Metrics:

A metric is a measurement of the level at which any impute belongs to a system

product or process.
Software metrics will be useful only if they are characterized effectively and
validated so that their worth is proven. There are 4 functions related to software
metrics:
1. Planning
2. Organizing
3. Controlling
4. Improving

Characteristics of software Metrics:

1. Quantitative: Metrics must possess quantitative nature. It means

metrics can be expressed in values.
2. Understandable: Metric computation should be easily understood, and
the method of computing metrics should be clearly defined.
3. Applicability: Metrics should be applicable in the initial phases of the
development of the software.
4. Repeatable: The metric values should be the same when measured
repeatedly and consistent in nature.
5. Economical: The computation of metrics should be economical.
6. Language Independent: Metrics should not depend on any
programming language.

Classification of Software Metrics:

There are 3 types of software metrics:

1. Product Metrics: Product metrics are used to evaluate the state of the
product, tracing risks and undercover prospective problem areas. The ability
of the team to control quality is evaluated.
2. Process Metrics: Process metrics pay particular attention to enhancing
the long-term process of the team or organization.
3. Project Metrics: The project matrix describes the project characteristic
and execution process.
 Number of software developer
 Staffing patterns over the life cycle of software
 Cost and schedule
 Productivity

- 16 -
 Advantages of Software Metrics:

1. Reduction in cost or budget.

2. It helps to identify the particular area for improvising.
3. It helps to increase the product quality.
4. Managing the workloads and teams.
5. Reduction in overall time to produce the product,.
6. It helps to determine the complexity of the code and to test the code
with resources.
7. It helps in providing effective planning, controlling and managing of the
entire product.

Disadvantages of Software Metrics:

1. It is expensive and difficult to implement the metrics in some cases.

2. Performance of the entire team or an individual from the team can’t be
determined. Only the performance of the product is determined.
3. Sometimes the quality of the product is not met with the expectation.
4. It leads to measure the unwanted data which is wastage of time.
5. Measuring the incorrect data leads to make wrong decision making.

21. i) Explain the different types of coupling.

Key:
Coupling measures the strength of all relationships between functional units
Advantages
-effect of changes in
other modules.

decreased inter-module dependency.

modules do not need to be included.

Disadvantages

modules.
more effort and/or time due to the
increased inter-module dependency.

modules must be included.

The different types of coupling are
Contentcoupling(high)
Content coupling is when one module modifies or relies on the internal workings
of another module (e.g., accessing local data of another module). Therefore
changing the way the second module produces data (location, type, timing) will
lead to
changing the dependent module.

- 17 -
 Commoncoupling
Common coupling is when two modules share the same global data (e.g., a global
variable). Changing the shared resource implies changing all the modules using
it.
Externalcoupling
External coupling occurs when two modules share an externally imposed data
format, communication protocol, or device interface.
Controlcoupling
Control coupling is one module controlling the flow of another, by passing it
information on what to do (e.g., passing a what-to-do flag). Stamp coupling (Data
structured coupling). Stamp coupling is when modules share a composite data
structure and use only a part of it, possibly a different part (e.g., passing a whole
record to a function that only needs one field of it). This may lead to changing the
way a module reads a record because a field, which the module doesn't need, has
been modified.
Datacoupling
Data coupling is when modules share data through, for example, parameters.
Each datum is an elementary piece, and these are the only data shared (e.g.,
passing an integer to a function that computes a square root).
ii) Discuss in detail about test strategies for conventional software.
Key:
Strategy for Testing Conventional Software

 Unit testing
– Exercises specific paths in a component's control structure to ensure
complete coverage and maximum error detection
– Components are then assembled and integrated
• Integration testing
– Focuses on inputs and outputs, and how well the components fit
together and work together
• Validation testing
– Provides final assurance that the software meets all functional,

- 18 -
 behavioral, and performance requirements
• System testing
– Verifies that all system elements (software, hardware, people,
databases) mesh properly and that overall system function and
performance is achieved

22. i) Identify the various tasks in software configuration management process.

Key:
Software configuration management is the task of tracking and controlling
changes in the software, part of the larger cross-disciplinary field of configuration
management.
Tasks in SCM process
Configuration Identification
Baselines
Change Control
Configuration Status Accounting
Configuration Audits and Reviews
Softw are
Vm.n

reporti ng

configuration auditing

vers ion control

change c ontrol

i denti fi cati on

SCIs

Explanation of all the tasks

ii) Illustrate CMM and its levels in detail.
Key:
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

- 19 -
 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 (KPA9s):
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 –

- 20 -
 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

- 21 -
 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.

*****

BL – Bloom9s Taxonomy Levels (1- Remembering, 2- Understanding, 3 –

Applying, 4 – Analysing, 5 – Evaluating, 6 - Creating)
CO – Course Outcomes PO – Program Outcomes; PI Code – Performance
Indicator Code

Bloom's Level
wise
Marks Distribution
Level
L2
25 25
Level
L3
Level
L1
50

Signature

- 22 -