MODULE – IV

Software Project Management

Software project management is an art and science of planning
and leading software projects. It is a sub-discipline of project
management in which software projects are planned,
implemented, monitored and controlled.

Software Project
A Software Project is the complete procedure of software
development from requirement gathering to testing and
maintenance, carried out according to the execution
methodologies, in a specified period of time to achieve intended
software product.
Need of software project management
Software is said to be an intangible product. Software development is a kind of all new stream
in world business and there’s very little experience in building software products. Most
software products are tailor made to fit client’s requirements. The most important is that the
underlying technology changes and advances so frequently and rapidly that experience of one
product may not be applied to the other one. All such business and environmental constraints
bring risk in software development hence it is essential to manage software projects
efficiently.

The image above shows triple constraints for software projects. It is an essential part of
software organization to deliver quality product, keeping the cost within client’s budget
constrain and deliver the project as per scheduled.
There are several factors, both internal and external, which may impact this
triple constrain triangle. Any of three factor can severely impact the other
two.
Therefore, software project management is essential to incorporate user
requirements along with budget and time constraints.

Software Project Manager

A software project manager is a person who undertakes the responsibility of
executing the software project. Software project manager is thoroughly aware
of all the phases of SDLC that the software would go through. Project
manager may never directly involve in producing the end product but he
controls and manages the activities involved in production.
A project manager closely monitors the development process, prepares and executes
various plans, arranges necessary and adequate resources, maintains communication
among all team members in order to address issues of cost, budget, resources, time, quality
and customer satisfaction. Let us see few responsibilities that a project manager
shoulders -

Managing People
Act as project leader
Liaison with stakeholders
Managing human resources
Setting up reporting hierarchy etc.
Managing Project
Defining and setting up project scope
Managing project management activities
Monitoring progress and performance
Risk analysis at every phase
Take necessary step to avoid or come out of problems
Act as project spokesperson
Project Scheduling
Project Scheduling in a project refers to roadmap of all activities to be done with
specified order and within time slot allotted to each activity. Project managers tend to
define various tasks, and project milestones and arrange them keeping various factors in
mind. They look for tasks lie in critical path in the schedule, which are necessary to
complete in specific manner (because of task interdependency) and strictly within the
time allocated. Arrangement of tasks which lies out of critical path are less likely to
impact over all schedule of the project.
For scheduling a project, it is necessary to -

Break down the project tasks into smaller, manageable form

Find out various tasks and correlate them
Estimate time frame required for each task
Divide time into work-units
Assign adequate number of work-units for each task
Calculate total time required for the project from start to finish
Software Project Management Activities
Software project management comprises of a number of activities, which
contains planning of project, deciding scope of software product, estimation of
cost in various terms, scheduling of tasks and events, and resource management.
Project management activities may include:
1. Project Planning
2. Scope Management
3. Project Estimation
I. Project Planning
Software project planning is task, which is performed before the production of
software actually starts. It is there for the software production but involves no
concrete activity that has any direction connection with software production;
rather it is a set of multiple processes, which facilitates software production.
II. Scope Management
It defines the scope of project; this includes all the activities, process need to
be done in order to make a deliverable software product. Scope management
is essential because it creates boundaries of the project by clearly defining
what would be done in the project and what would not be done. This makes
project to contain limited and quantifiable tasks, which can easily be
documented and in turn avoids cost and time overrun.
During Project Scope management, it is necessary to -
Define the scope
Decide its verification and control
Divide the project into various smaller parts for ease of management.
Verify the scope
Control the scope by incorporating changes to the scope
III. Project Estimation
For an effective management accurate estimation of various measures is a must. With
correct estimation managers can manage and control the project more efficiently and
effectively. Project estimation may involve the following:

1. Software size estimation

Software size may be estimated either in terms of KLOC (Kilo Line of Code) or by
calculating number of function points in the software. Lines of code depend upon coding
practices and Function points vary according to the user or software requirement.

2. Effort estimation
The managers estimate efforts in terms of personnel requirement and man-hour required
to produce the software. For effort estimation software size should be known. This can
either be derived by managers’ experience, organization’s historical data or software size
can be converted into efforts by using some standard formulae.
3. Time estimation
Once size and efforts are estimated, the time required to produce the software can be
estimated. Efforts required is segregated into sub categories as per the requirement
specifications and interdependency of various components of software. Software tasks are
divided into smaller tasks, activities or events by Work Breakthrough Structure (WBS). The
tasks are scheduled on day-to-day basis or in calendar months.
The sum of time required to complete all tasks in hours or days is the total time invested to
complete the project.
4. Cost estimation
This might be considered as the most difficult of all because it depends on
more elements than any of the previous ones. For estimating project cost,
it is required to consider -

Size of software
Software quality
Hardware
Additional software or tools, licenses etc.
Skilled personnel with task-specific skills
Travel involved
Communication
Training and support
Project Estimation Techniques
We discussed various parameters involving project estimation such as size, effort, time and
cost. Project manager can estimate the listed factors using two broadly recognized techniques
Decomposition Technique
This technique assumes the software as a product of various compositions.

There are two main models -

1. Line of Code Estimation
2. Function Points Estimation
.
 Line of Code Estimation is done on behalf of number of line of codes in the software
product. It is the simplest and most widely used metric. Comments and blank lines should
not be counted.
The advantages are as follows:
- It is widely used and universally accepted.
- It permits comparison of size and productivity metrics between diverse development
groups.
- It directly relates to the end product.
- LOC are easily measured upon project completion.
- It measures software from the developers point of view- what he actually does (write
line of codes).
- Continuous improvement activities exist for estimation techniques.
Disadvantages of Using LOC
 Size can vary with coding style.
 Focuses on coding activity alone.
 Correlates poorly with quality and efficiency of code.
 Penalizes higher level programming languages, code reuse, etc.
• Function Points Estimation is done on behalf of number of function points in the software
product. Function points allow the measurement of software size in standard units, independent of
the underlying language in which the software is developed. Instead of counting the lines of code
that make up a system, count the number of externals (inputs, outputs, inquiries, and interfaces) that
make up the system.
There are five types of externals to count:
1. External inputs - data or control inputs (input files, tables, forms, screens, messages, etc.) to the
system
2. External outputs - data or control outputs from the system
3. External inquiries - I/O queries which require a response (prompts, interrupts, calls, etc.)
4. External interfaces - libraries or programs which are passed into and out of the system (I/O
routines, sorting procedures, math libraries, run-time libraries, etc.)
5. Internal data files - groupings of data stored internally in the system (entities, internal control
files, directories)
Apply these steps to calculate the size of a project:
1. Count or estimate all the occurrences of each type of external.
2. Assign each occurrence a complexity weight.
3. Multiply each occurrence by its complexity weight, and total the results to obtain a function
count.
1. Empirical Estimation Technique
This technique uses empirically derived formulae to make estimation. These formulae are based on LOC or FPs.
2. Putnam Model
This model is made by Lawrence H. Putnam, which is based on Norden’s frequency distribution (Rayleigh curve).
Putnam model maps time and efforts required with software size. when making an estimate for a software task the
software equation is solved for effort:

where:
• Size is the product size (whatever size estimate is used by your organization is appropriate).
• B is a scaling factor and is a function of the project size
• Productivity is the Process Productivity, the ability of a particular software organization to produce software
of a given size at a particular defect rate.
• Effort is the total effort applied to the project in person/years.
• Time is the total schedule of the project in years.
An estimated software size at project completion and organizational process productivity is used. Plotting effort as a
function of time yields the Time-Effort Curve. The points along the curve represent the estimated total effort to
complete the project at some time. One of the distinguishing features of the Putnam model is that total effort decreases
as the time to complete the project is extended.
 COCOMO
COCOMO stands for COnstructive COst MOdel, developed by Barry W. Boehm. It is a model
for estimating effort, cost, and schedule for software projects. It divides the software product
into three categories of software: organic, semi-detached and embedded.

1. Basic COCOMO
Basic COCOMO computes software development effort (and cost) as a function of program size.
Program size is expressed in estimated thousands of source lines of code (SLOC) COCOMO
applies to three classes of software projects:
1. Organic projects - "small" teams with "good" experience working with "less than rigid"
requirements
2. Semi-detached projects - "medium" teams with mixed experience working with a mix of
rigid and less than rigid requirements
3. Embedded projects - developed within a set of "tight" constraints. It is also combination
of organic and semi-detached projects.(hardware, software, operational, ...)
The basic COCOMO equations take the form
where, KLOC is the estimated number of delivered lines (expressed in thousands ) of code for project. The coefficients a
b, bb, c b and d b are given in the following table:

Basic COCOMO is good for quick estimate of software costs. However it does not account for differences in hardware
constraints, personnel quality and experience, use of modern tools and techniques, and so on.
2. Intermediate COCOMOs
Intermediate COCOMO computes software development effort as function of program size and a set of "cost drivers"
that include subjective assessment of product, hardware, personnel and project attributes. This extension considers a set
of four "cost drivers",each with a number of subsidiary attributes:-
• Product attributes
• Required software reliability
• Size of application database
• Complexity of the product
• •Hardware attributes
• Run-time performance constraints
• Memory constraints
• Volatility of the virtual machine environment
• Required turnabout time
• Personnel attributes
• Analyst capability
• Software engineering capability
• Applications experience
• Virtual machine experience
• Programming language experience
• Project attributes
• Use of software tools
• Application of software engineering methods
• Required development schedule
The Intermediate COCOMO formula now takes the form:

where E is the effort applied in person-months, SLoC is the estimated number of thousands of delivered lines of code
for the project, and EAF is the factor calculated above. The coefficient ai and the exponent bi are given in the next
table.

The Development time D calculation uses E in the same way as in the Basic COCOMO.
3. Detailed COCOMO
Detailed COCOMO incorporates all characteristics of the intermediate
version with an assessment of the cost driver's impact on each step
(analysis, design, etc.) of the software engineering process. In detailed
COCOMO, the effort is calculated as function of program size and a set of
cost drivers given according to each phase of software life cycle.

The five phases of detailed COCOMO are:-

• Plan and requirement.
• System design.
• Detailed design.
• Module code and test.
• Integration and test.
5. Resource management
All elements used to develop a software product may be assumed as resource for that
project. This may include human resource, productive tools, equipment, and software
libraries.
The resources are available in limited quantity and stay in the organization as a pool
of assets. The shortage of resources hampers the development of project and it can
lag behind the schedule. Allocating extra resources increases development cost in the
end. It is therefore necessary to estimate and allocate adequate resources for the
project.
Resource management includes -
- Defining proper organization project by creating a project team and allocating
responsibilities to each team member
- Determining resources required at a particular stage and their availability
- Manage Resources by generating resource request when they are required and de-
allocating them when they are no more needed.
Risk identification
Risk is inevitable in business organisation when undertaking
projects. however the project manager needs to ensure that risks
are kept a minimal. risks can be mainly divided between two
types. negative impact risks and positive impact risk.
not all the time would project managers be facing negative
impact risk as there are positive impact risks too. once the
risk has been identified, project managers need to come up
with a mitigation plan or any other solution to counter
attack the risk.

managers face many difficulties when it comes to

identifying and naming the risks that occur when
undertaking projects. these trees could be resolved through
structured or unstructured brainstorming or strategies.
it is important to understand that risks pertaining to the project
can only be handled by the project manager and other
stakeholders of the projects. Risks, such as operational or
business risks will be e handled by the relevant teams. The
risks that often impact a project are supplier risk, resource risk
and budget risk supplier risks would refer to risks that can
occur in case the supplier is not meeting the timeline to supply
the resources required. resources risk occurs when the human
resource used in the project is not enough or not skilled
enough. budget risk would refer to risks that can occur if the
costs are more than what was budgeted
risks analysis

Risk analysis is a process that helps you identify and manage

potential problems that could undermine key business initiatives
for projects
to carry out a risk analysis you must first identify the possible
threats that you face and then estimate the likelihood that these
products will materialize. risk analysis can be complex as you will
need to draw on detailed information such as project plans financial
data security protocols marketing forcast and other relevant
information however it is an essential planning tool and one that
could save time money and reputation
Risk analysis has the following steps
identify threats the first step in risk analysis is to identify the existing
and possible threats that you might face. this can come from many
different sources for instance that could be
- human illness, death, injury or other loss of a key individual
- Operational- disruption to supplies and operations, loss of access to
essential assets or failure in distribution
- Reputational- loss of customer or employee confidence or damage to
market reputation
- Procedural - failures of accountability, internal systems or controls or
from fraud
- project - going over budget, taking too long on key tasks, or
experiencing issues with product or service quality
- financial - business failure, stock market fluctuations, interest rate changes
or non availability of fund.
- Technical - advances in technology or from technical failure,
- Natural – weather, natural disasters or disease
- political - changes in tax, public opinion, government policy, for foreign
influence
- structural - dangerous chemicals, poor lighting, falling boxes or any
situation were staff, products or technology can be harmed.
Risk mitigation

risk mitigation planning is the process of developing options

and actions to enhance opportunities and reduce threats to
produce project objectives risk mitigation implementation is
the process of executing race mitigation actions risk mitigation
progress monitoring includes tracking identified raised
identifying new risk and evaluating which process
effectiveness throughout the project
Risk Monitoring
risk management means risk containment and mitigation first you
have got to identify the plan. then be ready to act when a risk
arises. drawing upon the experience and knowledge of and their
team to minimise the impact to the project
Risk management includes the following task
- identify risks and their triggers
- classify and prioritise all risks
- Craft a plan that links each risk to a mitigation
- monitor for risk triggers during the project
- implement the mitigating action if any risk materializes.
- communicate risk status throughout project
Project Risk Management
Risk management involves all activities pertaining to identification, analyzing and making provision
for predictable and non-predictable risks in the project. Risk may include the following:
Experienced staff leaving the project and new staff coming in.
Change in organizational management.
Requirement change or misinterpreting requirement.
Under-estimation of required time and resources.
Technological changes, environmental changes, business competition.
Risk Management Process
There are following activities involved in risk management process:

1. Identification - Make note of all possible risks, which may occur in the project.
2. Categorize - Categorize known risks into high, medium and low risk intensity as per their possible
impact on the project.
3. Manage - Analyze the probability of occurrence of risks at various phases. Make plan to avoid or
face risks. Attempt to minimize their side-effects.
4. Monitor - Closely monitor the potential risks and their early symptoms. Also monitor the effects of
steps taken to mitigate or avoid them.
 Quality management

this include procedures tools and techniques that are used to ensure
that the output and benefits meet customer requirements. quality
management has four components quality planning, quality
assurance, quality control and internal improvements
the first component quality planning involves the preparation of a
quality management plan that describes the processes and metrics
that will be used but quality management plan needs to be agreed
with elements stakeholders to ensure that their expectations to
quality are correctly identified. the processes described in the
quality management plan should confirm to the processes culture
and values of the host organization.
quality assurance provides confidence to the first
organization that it's projects programs and portfolios are
being well managed. where it's the consistent use of
procedures and standards and ensures that stuff have the
correct knowledge skills and attitudes to fulfill their project
roles and responsibilities in commission manner. quality
assurance must be independent of the project program for
portfolio to which it applies.
quality control consists of inspection, testing and measurements to verify
that the deliverables conform to specification are fit for purpose and meet
stakeholder expectations. determine whether acceptance criteria have or have
not been made for this to be effective specifications must be under strict
configuration control it is possible that once agreed the specification may
need to be modified commonly this is to accommodate change request or
issues while maintaining acceptable time and cost constraints any
consequence changes to acceptance criteria should be approved and
communicated the last component continual improvement is the generic
term used by organisations to describe how information provided by quality
assurance and quality control processes is used to drive improvements in in
efficiency and effectiveness 3 maturity model provides a framework against
which continual improvement can be initiated and embedded in the
organisation.
Configuration Management
Configuration management is a process of tracking and controlling the changes
in software in terms of the requirements, design, functions and development of
the product.

IEEE defines it as “the process of identifying and defining the items in the
system, controlling the change of these items throughout their life cycle,
recording and reporting the status of items and change requests, and
verifying the completeness and correctness of items”.

Generally, once the SRS is finalized there is less chance of requirement of

changes from user. If they occur, the changes are addressed only with prior
approval of higher management, as there is a possibility of cost and time
overrun. at its simplest configuration management is version control
configuration management is an invaluable tool for providing control of the
deliverables and avoiding mistakes and misunderstandings. it is an integral part of
quality management
the process ensures that the deliverable meets the specified performance criteria it also
ensures that take it process is in place to provide conditioning maintenance for the
duration of the product life cycle
Five activities within a configuration management process
Configuration management planning a configuration management plan should
describe any specific procedures and the extent of the application during the life cycle
the plan should also identify the roles and responsibilities for carrying out configuration
management configuration management must be planned in order to effective
predictable and repeatable
configuration identification this involves breaking down the work into component
deliverables configuration items creating a unique numbering for referencing system
and establishing configuration baseline
configuration control this ensures that all changes to configuration
items are documented and important aspect is the ability to identify
the interrelationships between configuration items. this is essential
information for the review and assessment steps in the change control
process
configuration status accounting this tracks the current status of the
configuration providing readability traceability of configuration
items throughout their development and operation configuration
verification and audit this is used to determine whether undeliverable
confirms to its requirements and configuration information typically
an adult is undertaken at the end of a phase stage or transfer
Project Execution & Monitoring
In this phase, the tasks described in project plans are executed according to their schedules.
Execution needs monitoring in order to check whether everything is going according to the
plan. Monitoring is observing to check the probability of risk and taking measures to address
the risk or report the status of various tasks.
These measures include -
Activity Monitoring - All activities scheduled within some task can be monitored on day-to-
day basis. When all activities in a task are completed, it is considered as complete.
Status Reports - The reports contain status of activities and tasks completed within a given
time frame, generally a week. Status can be marked as finished, pending or work-in-progress
etc.
Milestones Checklist - Every project is divided into multiple phases where major tasks are
performed (milestones) based on the phases of SDLC. This milestone checklist is prepared
once every few weeks and reports the status of milestones.
Project Communication Management
Effective communication plays vital role in the success of a project. It bridges gaps between client
and the organization, among the team members as well as other stake holders in the project such as
hardware suppliers.
Communication can be oral or written. Communication management process may have the following
steps:
1. Planning - This step includes the identifications of all the stakeholders in the project and the mode
of communication among them. It also considers if any additional communication facilities are
required.
2. Sharing - After determining various aspects of planning, manager focuses on sharing correct
information with the correct person on correct time. This keeps every one involved the project up to
date with project progress and its status.
3. Feedback - Project managers use various measures and feedback mechanism and create status and
performance reports. This mechanism ensures that input from various stakeholders is coming to the
project manager as their feedback.
4. Closure - At the end of each major event, end of a phase of SDLC or end of the project itself,
administrative closure is formally announced to update every stakeholder by sending email, by
distributing a hardcopy of document or by other mean of effective communication.
After closure, the team moves to next phase or project.
Project Management Tools
The risk and uncertainty rises multifold with respect to the size of the project, even when the project is
developed according to set methodologies. There are tools available, which aid for effective project management.
A few are described -
Gantt Chart
Gantt charts was devised by Henry Gantt (1917). It represents project schedule with respect to time periods. It is
a horizontal bar chart with bars representing activities and time scheduled for the project activities.
PERT Chart
PERT (Program Evaluation & Review Technique) chart is a tool that depicts project as
network diagram. It is capable of graphically representing main events of project in both
parallel and consecutive way. Events, which occur one after another, show dependency of the
later event over the previous one.

Events are shown as numbered nodes. They are connected by labeled arrows depicting
sequence of tasks in the project.
Resource Histogram
This is a graphical tool that contains bar or chart representing number of resources (usually
skilled staff) required over time for a project event (or phase). Resource Histogram is an
effective tool for staff planning and coordination.
Critical Path Analysis(CPA)
This tools is useful in recognizing interdependent tasks in the
project. It also helps to find out the shortest path or critical path to
complete the project successfully. Like PERT diagram, each event is
allotted a specific time frame. This tool shows dependency of event
assuming an event can proceed to next only if the previous one is
completed.

The events are arranged according to their earliest possible start

time. Path between start and end node is critical path which cannot
be further reduced and all events require to be executed in same
order.
Change Control
Change control is function of configuration management, which ensures that all changes made to
software system are consistent and made as per organizational rules and regulations.
A change in the configuration of product goes through following steps -
1. Identification - A change request arrives from either internal or external source. When change
request is identified formally, it is properly documented.
2. Validation - Validity of the change request is checked and its handling procedure is confirmed.
3. Analysis - The impact of change request is analyzed in terms of schedule, cost and required
efforts. Overall impact of the prospective change on system is analyzed.
4. Control - If the prospective change either impacts too many entities in the system or it is
unavoidable, it is mandatory to take approval of high authorities before change is incorporated
into the system. It is decided if the change is worth incorporation or not. If it is not, change
request is refused formally.
5. Execution - If the previous phase determines to execute the change request, this phase take
appropriate actions to execute the change, does a thorough revision if necessary.
6. Close request - The change is verified for correct implementation and merging with the rest of
the system. This newly incorporated change in the software is documented properly and the
request is formally is closed.
software change management

Change management in software development involves

tracking and managing changes to artifacts, such as code
and requirements.

is the process of selecting which changes to encourage

and which to prevent according to project criteria such as
schedule and cost.
CHANGE MANAGEMENT
Change management is the handling of change requests. A change request leads
to the creation of a new release
General change process
1. The change is requested (this can be done by anyone including users and
developers)
2. The change request is assessed against project goals
3. Following the assessment, the change is accepted or rejected
4. If it is accepted, the change is assigned to a developer and implemented
5. The implemented change is audited.
6. The complexity of the change management process varies with the
project.
7. Small projects can perform change requests informally and fast while
complex projects require detailed change request forms and the official approval
by one more managers.
Controlling Changes
Two types of controlling change:
1. Promotion: The internal development state of a software is
changed.
2. Release: A changed software system is made visible
outside the development organization.
Approaches for controlling change (Change Policy)
1. Informal (good for research type environments and
promotions)
2. Formal approach (good for externally developed CIs and
for releases)
Software project management framework
Have you ever worked on a project that was completed smoothly on time with
great results, then you probably had a good project manager who use a project
management framework for success
what is project management framework basically it is a combination of
processes, task and tools used to transition a project from start to finish. The
overview of a generic process used by this framework is
- Initiation when the project starts
- Planning when all of the key decisions are made
- Execution when project work actually takes place
- Control when adjustments are made to the plan
- Monitoring when project progress is checked
- Termination when the project comes to an end
each stage of this process involves the completion of many task by project team members using various tools
the generic process just described is a project life cycle from initiation to termination which is one part of the
framework now let's dive deeper into the three parts of a project management framework life cycle control
cycle and tools and templates

Life cycle the life cycle of the framework explain the stages involved in the project and what needs to happen
at each stage it allows the management team to make adjustments and customize the stages based on the size
and scope of the project
for example a company that is completing a project designing children's learning materials may have a life
cycle as follows
first the company initiatives the projects the company may go through numerous upfront procedures to decide
whether or not to pursue the business opportunity make it available for BITS and finalize contracts
second the company plans for projects the company defines in detail the project deliverables schedule detailed
budget extra
third the company executes the project by proceeding with Excel project as such as creating the learning
materials it manages the project according to plan by using the control cycle to monitor progress and adjust
the plan if required
finally when the materials are completed the company terminates the project and follows a closure procedure
Capability Maturity Model (CMM)

The Software Engineering Institute (SEI) Capability

Maturity Model (CMM) specifies an increasing series
of levels of a software development organization. The
higher the level, the better the software development
process, hence reaching each level is an expensive and
time-consuming process.
CMMI
The Capability Maturity Model Integration (CMMI) is a capability
maturity model developed by the Software Engineering Institute, part of
Carnegie Mellon University in Pittsburgh, USA. The CMMI principal is
that “the quality of a system or product is highly influenced by the
process used to develop and maintain it”. CMMI can be used to guide
process improvement across a project, a division, or an entire organization.

CMMI provides:
• Guidelines for processes improvement
• An integrated approach to process improvement
• Embedding process improvements into a state of business as usual
• A phased approach to introducing improvements
CMMI Maturity Levels
A maturity level is a well-defined evolutionary plateau toward
achieving a mature software process. Each maturity level
provides a layer in the foundation for continuous process
improvement.
In CMMI models with a staged representation, there are five
maturity levels designated by the numbers 1 through 5
1. Initial
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizing
 CMMI Staged Representation- Maturity Levels
Maturity levels consist of a predefined set of process areas. The maturity
levels are measured by the achievement of the specific and generic goals that
apply to each predefined set of process areas. The following sections
describe the characteristics of each maturity level in detail.
Matruity Level 1 – Initial
At maturity level 1, processes are usually ad hoc and chaotic. The organization usually
does not provide a stable environment. Success in these organizations depends on the
competence and heroics of the people in the organization and not on the use of proven
processes.
Maturity level 1 organizations often produce products and services that work; however,
they frequently exceed the budget and schedule of their projects.
Maturity Level 2 - Managed
At maturity level 2, an organization has achieved all the specific and generic goals of the
maturity level 2 process areas. In other words, the projects of the organization have
ensured that requirements are managed and that processes are planned, performed,
measured, and controlled.
At maturity level 2, requirements, processes, work products, and services are managed.
The status of the work products and the delivery of services are visible to management
at defined points.
Maturity Level 3 - Defined
At maturity level 3, an organization has achieved all the specific and
generic goals of the process areas assigned to maturity levels 2 and 3.
At maturity level 3, processes are well characterized and understood,
and are described in standards, procedures, tools, and methods.
A critical distinction between maturity level 2 and maturity level 3 is
the scope of standards, process descriptions, and procedures. At
maturity level 2, the standards, process descriptions, and procedures
may be quite different in each specific instance of the process (for
example, on a particular project). At maturity level 3, the standards,
process descriptions, and procedures for a project are tailored from the
organization's set of standard processes to suit a particular project or
organizational unit.
Maturity Level 4 - Quantitatively Managed
At maturity level 4, an organization has achieved all the specific goals of the
process areas assigned to maturity levels 2, 3, and 4 and the generic goals
assigned to maturity levels 2 and 3.
At maturity level 4 Subprocesses are selected that significantly contribute to
overall process performance. These selected subprocesses are controlled using
statistical and other quantitative techniques.
Maturity Level 5 - Optimizing
At maturity level 5, an organization has achieved all the specific goals of the
process areas assigned to maturity levels 2, 3, 4, and 5 and the generic goals
assigned to maturity levels 2 and 3.
Processes are continually improved based on a quantitative understanding of
the common causes of variation inherent in processes.
Maturity level 5 focuses on continually improving process performance
through both incremental and innovative technological improvements.
CMMI Models
CMMI consists of three overlapping disciplines (constellations)
providing specific focus into the Development, Acquisition and
Service Management domains respectively:
• CMMI for Development (CMMI-DEV) – Product and service
development
• CMMI for Services (CMMI-SVC) – Service establishment,
management, and delivery
• CMMI for Acquisition (CMMI-ACQ) – Product and service
acquisition
CMMI Benefits
CMMI-based process improvement benefits include
• improved schedule and budget predictability
• improved cycle time
• increased productivity
• improved quality (as measured by defects)
• increased customer satisfaction
• improved employee morale
• increased return on investment
• decreased cost of quality
 Computer Aided Software Engineering (CASE)
Computer-Aided Software Engineering (CASE) technologies are tools that
provide automated assistance for software development . The goal of
introducing CASE tools is the reduction of the time and cost of software
development and the enhancement of the quality of the systems developed.

CASE is used to ensure a high-quality and defect-free software. CASE ensures a

check-pointed and disciplined approach and helps designers, developers, testers,
managers and others to see the project milestones during development.

CASE can also help as a warehouse for documents related to projects, like business
plans, requirements and design specifications. One of the major advantages of using
CASE is the delivery of the final product, which is more likely to meet real-world
requirements as it ensures that customers remain part of the process.
 CASE illustrates a wide set of labor-saving tools that
are used in software development. It generates a
framework for organizing projects and to be helpful in
enhancing productivity. There was more interest in the
concept of CASE tools years ago, but less so today, as the
tools have morphed into different functions, often in
reaction to software developer needs. The concept of CASE
also received a heavy dose of criticism after its release.
CASE Tools:
The essential idea of CASE tools is that in-built programs can
help to analyze developing systems in order to enhance quality
and provide better outcomes. Throughout the 1990, CASE tool
became part of the software lexicon, and big companies like IBM
were using these kinds of tools to help create software.

Various tools are incorporated in CASE and are called CASE

tools, which are used to support different stages and milestones in
a software development life cycle.
 Components of CASE Tools
CASE tools can be broadly divided into the following parts based on their use at 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.
Types of CASE Tools:

1. Diagramming Tools:
It helps in diagrammatic and graphical representations of the data and
system processes. It represents system elements, control flow and data flow
among different software components and system structure in a pictorial
form.
For example, Flow Chart Maker tool for making state-of-the-art flowcharts.

2. Computer Display and Report Generators:

It helps in understanding the data requirements and the relationships
involved.
3. Analysis Tools:
It focuses on inconsistent, incorrect specifications involved in the diagram and data
flow. It helps in collecting requirements, automatically check for any irregularity,
imprecision in the diagrams, data redundancies or erroneous omissions.
For example,
(i) Accept 360, Accompa, CaseComplete for requirement analysis.
(ii) Visible Analyst for total analysis.

4. Central Repository:
It provides the single point of storage for data diagrams, reports and documents related
to project management.

5. Documentation Generators:
It helps in generating user and technical documentation as per standards. It creates
documents for technical users and end users.
For example, Doxygen, DrExplain, Adobe RoboHelp for documentation.
6. Code Generators:
It aids in the auto generation of code, including definitions, with the help of
the designs, documents and diagrams.
Advantages of the CASE approach:

As special emphasis is placed on the design as well as testing,

the servicing cost of a product over its expected lifetime is
considerably reduced.
The overall quality of the product is improved as an organized
approach is undertaken during the process of development.
Chances to meet real-world requirements are more likely and
easier with a computer-aided software engineering approach.
CASE indirectly provides an organization with a competitive
advantage by helping ensure the development of high-quality
products.
 CASE tool and its scope
A CASE (Computer power-assisted software package Engineering) tool could be a
generic term accustomed denote any type of machine-driven support for software
package engineering. in a very additional restrictive sense, a CASE tool suggests that
any tool accustomed automatize some activity related to software package
development.

Several CASE tools square measure obtainable. A number of these CASE tools assist in
part connected tasks like specification, structured analysis, design, coding, testing, etc.;
and other to non-phase activities like project management and configuration
management.

Reasons for using CASE tools:

The primary reasons for employing a CASE tool are:

to extend productivity
CASE environment:
Although individual CASE tools square measure helpful, the true power of a
toolset is often completed only this set of tools square measure integrated into a
typical framework or setting. CASE tools square measure characterized by the
stage or stages of package development life cycle that they focus on. Since totally
different tools covering different stages share common data, it’s needed that they
integrate through some central repository to possess an even read of data related to
the package development artifacts. This central repository is sometimes
information lexicon containing the definition of all composite and elementary data
things.

Through the central repository, all the CASE tools in a very CASE setting share
common data among themselves. therefore a CASE setting facilities the
automation of the step-wise methodologies for package development. A schematic
illustration of a CASE setting is shown in the below diagram:
A CASE environment facilitates the automation of the in small stages methodologies for package
development. In distinction to a CASE environment, a programming environment is an Associate
in a Nursing integrated assortment of tools to support solely the cryptography part of package
development.
 Benefits of CASE
Several benefits accrue from the employment of a CASE setting or perhaps isolated
CASE tools. a number of those benefits are:

- A key profit arising out of the employment of a CASE setting is value saving
through all development phases. totally different studies performed to live the impact
of CASE place the trouble reduction between 30% to 40%.
- The use of CASE tools results in goodish enhancements to quality. this can be
primarily thanks to the fact that one can effortlessly retell through the various phases
of code development and therefore the possibilities of human error ar significantly
reduced.
- CASE tools facilitate the manufacture of prime quality and consistent documents.
Since the necessary information with reference to a wares ar maintained in an
exceedingly central repository, redundancy within the keep information is reduced
and thus possibilities of inconsistent documentation are reduced to a good extent.
- CASE tools confiscate most of the labor in an exceedingly code
engineer’s work. for instance, they have not to check meticulously the
leveling of the DFDs, however, they will effortlessly through the press
of a button.
- CASE tools have crystal rectifier to revolutionary value saving in
code maintenance efforts. This arises not solely thanks to the
tremendous worth of a CASE setting in traceability and consistency
checks, however additionally thanks to the systematic info capture
throughout the assorted phases of code development as a result of
adhering to a CASE setting.
The introduction of a CASE setting has an impression on the
design of operating of an organization and makes it oriented towards
the structured and orderly approach.