What is Legacy Software?
Legacy software may be defined informally as "software we don't know what to do with, but it's
still performing a useful job." Legacy software systems are programs that are critical to the
operation of companies, but that were developed years ago using early programming languages
such as Cobol and Fortran. These programs have been maintained for many years by hundreds of
programmers, and while many changes have been made to the software, the supporting
documentation may not be current. These factors contribute to the staggering cost of maintaining
legacy systems. Consequently, there is an urgent need to find ways to make these programs more
maintainable without disrupting the operation of the company.
The Need to Re-engineer
The implication is that the preferred solution is to discard the software completely, and start
again with a new system. This may not be appropriate in all cases, for example:
1. The software represents years of accumulated experience, which is not represented elsewhere,
so discarding the software will also discard this knowledge, however inconveniently it is
represented.
2. The manual system that was replaced by the software no longer exists, so system analysis
must be undertaken on the software itself.
3. The software may actually work well, and its behavior may be well understood. A new
replacement system may perform much more badly, at least in the early days. Hence it may be
worth recovering some of the good features of the legacy system.
4. A typical large legacy software system has many users, who typically have exploited
undocumented "features" and side effects in the software. It may not be acceptable to demand
that users undertake a substantial rewrite for no discernable benefit. Therefore, it may be
important to retain the interfaces and exact functionality of the legacy code, both explicit and
implicit.
5. Users may prefer an evolutionary rather than a revolutionary approach.
Capability Maturity Model Integration
Capability Maturity Model Integration (CMMI) is a process improvement approach that
provides organizations with the essential elements of effective processes that ultimately improve
their performance. CMMI can be used to guide process improvement across a project, a division,
or an entire organization
CMMI in software engineering and organizational development is a trademarked process
improvement approach that provides organizations with the essential elements for effective
process improvement.
CMMI according to the Software Engineering Institute (SEI, 2008), helps "integrate traditionally
separate organizational functions, set process improvement goals and priorities, provide guidance
for quality processes, and provide a point of reference for appraising current processes."[2]
Overview
CMMI currently addresses three areas of interest:
(1) Product and service development — CMMI for Development (CMMI-DEV),
(2) Service establishment, management, and delivery — CMMI for Services (CMMI-
SVC), and
(3) Product and service acquisition — CMMI for Acquisition (CMMI-ACQ).
CMMI was developed by a group of experts from industry, government, and the Software
Engineering Institute (SEI) at Carnegie Mellon University. CMMI models provide guidance for
developing or improving processes that meet the business goals of an organization. A CMMI
model may also be used as a framework for appraising the process maturity of the organization.[1]
CMMI originated in software engineering but has been highly generalised over the years to
embrace other areas of interest, such as the development of hardware products, the delivery of all
kinds of services, and the acquisition of products and services. The word "software" does not
appear in definitions of CMMI. This generalization of improvement concepts makes CMMI
extremely abstract. It is not as specific to software engineering as its predecessor, the Software
CMM (CMM, see below)...
History
CMMI was developed by the CMMI project, which aimed to improve the usability of maturity
models by integrating many different models into one framework. The project consisted of
members of industry, government and the Carnegie Mellon Software Engineering Institute (SEI).
The main sponsors included the Office of the Secretary of Defense (OSD) and the National
Defense Industrial Association.
CMMI is the successor of the capability maturity model (CMM) or software CMM. The CMM
was developed from 1987 until 1997. In 2002, CMMI Version 1.1 was released. Version 1.2
followed in August 2006.
[edit] CMMI topics
[edit] CMMI representation
CMMI exists in two representations: continuous and staged.[1] The continuous representation is
designed to allow the user to focus on the specific processes that are considered important for the
organization's immediate business objectives, or those to which the organization assigns a high
degree of risk. The staged representation is designed to provide a standard sequence of
improvements, and can serve as a basis for comparing the maturity of different projects and
organizations. The staged representation also provides for an easy migration from the SW-CMM
to CMMI.[1]
[edit] CMMI model framework
For more details on this topic, see Process area (CMMI).
Depending on the CMMI constellation (acquisition, services, development) used, the process
areas it contains will vary. Key process areas are the areas that will be covered by the
organization's processes. The table below lists the process areas that are present in all CMMI
constellations. This collection of sixteen process areas is called the CMMI Model Framework, or
CMF.
Capability Maturity Model Integration (CMMI) Model Framework (CMF)
Abbreviat Maturity
Name Area
ion Level
REQM Requirements Management Engineering 2
Project
PMC Project Monitoring and Control 2
Management
Project
PP Project Planning 2
Management
CM Configuration Management Support 2
MA Measurement and Analysis Support 2
Process and Product Quality
PPQA Support 2
Assurance
Organizational Process Process
OPD 3
Definition Management
CAR Causal Analysis Support 5
[edit] CMMI models
CMMI best practices are published in documents called models, each of which addresses a
different area of interest. The current release of CMMI, version 1.2, provides models for three
areas of interest: development, acquisition, and services.
• CMMI for Development (CMMI-DEV
), v1.2 was released in August 2006. It addresses product and service
development processes.
• CMMI for Acquisition (CMMI-ACQ
), v1.2 was released in November 2007. It addresses supply chain
management, acquisition, and outsourcing processes in government and
industry.
• CMMI for Services (CMMI-SVC
), v1.2 was released in February 2009. It addresses guidance for delivering
services within an organization and to external customers.
• CMMI Product Suite (includes Development, Acquisition, and Services), v1.3 is
expected to be released in 2010. CMMI Version 1.3—Plans for the Next
Version
Regardless of which model an organization chooses, CMMI best practices should be adapted by
an organization according to its business objectives.
[edit] Appraisal
An organization cannot be certified in CMMI; instead, an organization is appraised. Depending
on the type of appraisal, the organization can be awarded a maturity level rating (1-5) or a
capability level achievement profile.
Many organizations find value in measuring their progress by conducting an appraisal.
Appraisals are typically conducted for one or more of the following reasons:
1. To determine how well the organization’s processes compare to CMMI best
practices, and to identify areas where improvement can be made
2. To inform external customers and suppliers of how well the organization’s
processes compare to CMMI best practices
3. To meet the contractual requirements of one or more customers
Appraisals of organizations using a CMMI model[3] must conform to the requirements defined in
the Appraisal Requirements for CMMI (ARC) document. There are three classes of appraisals,
A, B and C, which focus on identifying improvement opportunities and comparing the
organization’s processes to CMMI best practices. Appraisal teams use a CMMI model and ARC-
conformant appraisal method to guide their evaluation of the organization and their reporting of
conclusions. The appraisal results can then be used (e.g., by a process group) to plan
improvements for the organization.
The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is an appraisal
method that meets all of the ARC requirements.[4]
A class A appraisal is more formal and is the only one that can result in a level rating. Results of
an appraisal may be published (if the appraised organization approves) on the CMMI Web site of
the SEI: Published SCAMPI Appraisal Results
. SCAMPI also supports the conduct of ISO/IEC 15504, also known as SPICE
(Software Process Improvement and Capability Determination), assessments etc.
[edit] Achieving CMMI compliance
The traditional approach that organizations often adopt to achieve compliance with the CMMI
involves the establishment of an Engineering Process Group (EPG) and Process Action Teams
(PATs) [5] This approach requires that members of the EPG and PATs be trained in the CMMI,
that an informal (SCAMPI C) appraisal be performed, and that process areas be prioritized for
improvement. More modern approaches that involve the deployment of commercially available,
CMMI-compliant processes, can significantly reduce the time to achieve compliance. SEI has
maintained statistics on the "time to move up" for organizations adopting the earlier Software
CMM and primarily using the traditional approach.[6] These statistics indicate that, since 1987,
the median times to move from Level 1 to Level 2 is 23 months, and from Level 2 to Level 3 is
an additional 20 months. These statistics have not been updated for the CMMI.
The Software Engineering Institute’s (SEI) Team Software Process methodology and the
Capability Maturity Modeling framework have been successfully employed to accelerate
progress from Maturity Level 1 to Maturity Level 4. They’ve demonstrated progressing from
Level 1 to Level 4 in 30 months, which is less than half of the average time it has taken
traditionally.[7]
[edit] Applications
The SEI published that 60 organizations measured increases of performance in the categories of
cost, schedule, productivity, quality and customer satisfaction.[8] The median increase in
performance varied between 14% (customer satisfaction) and 62% (productivity). However, the
CMMI model mostly deals with what processes should be implemented, and not so much with
how they can be implemented. These results do not guarantee that applying CMMI will increase
performance in every organization. A small company with few resources may be less likely to
benefit from CMMI; this view is supported by the process maturity profile
(page 10). Of the small organizations (<25 employees), 70.5% are assessed at level
2: Managed, while 52.8% of the organizations with 1001–2000 employees are rated
at the highest level (5: Optimizing).
Interestingly, Turner & Jain (2002) argue that although it is obvious there are large differences
between CMMI and agile methods, both approaches have much in common. They believe
neither way is the 'right' way to develop software, but that there are phases in a project where one
of the two is better suited. They suggest one should combine the different fragments of the
methods into a new hybrid method. Sutherland et al. (2007) assert that a combination of Scrum
and CMMI brings more adaptability and predictability than either one alone. David J. Anderson
(2005) gives hints on how to interpret CMMI in an agile manner. Other viewpoints about using
CMMI and Agile development are available on the SEI Web site
The combination of the project management technique earned value management (EVM) with
CMMI has been described (Solomon, 2002
). To conclude with a similar use of CMMI, Extreme Programming (XP), a software
engineering method, has been evaluated with CMM/CMMI (Nawrocki et al., 2002).
For example, the XP requirements management approach, (which relies on oral
communication), was evaluated as not compliant with CMMI.
CMMI can be appraised using two different approaches: staged and continuous. The staged
approach yields appraisal results as one of five maturity levels. The continuous approach yields
one of six capability levels. The differences in these approaches are felt only in the appraisal; the
best practices are equivalent and result in equivalent process improvement results.
A brief overview of Software Product & the characteristics a Software Product should
possess.
Software is subtle, it has no mass, no volume, no color, no odor-no material or physical
properties. The source code is simply a fixed image of a computer program and while effects
produced by a program are visible, the program itself is not.
As software has no physical properties it does not degrade with time as hardware does. Failures
in software are mainly caused by design and implementation errors and not by degradation.
Because software is intangible, extraordinary measures must be taken to determine the status of
software product which is in the development phase.
In short, the software engineer creates models of actual or physical situation in software. The
mapping between the model and the reality or real situation being modeled has been called the
“intellectual distance” between the problem and the computerized solution to the problem.
The basic principle of software engineering is to design software products that minimize the
intellectual distance between problem and solution. However, only creativity and clarity of
programmer limits the variety of approaches to software development.
Software product characteristics:
Successful software is one which provides functionality as per the requirement i.e. it fulfils all
the consumer’s needs and requirements. Software should be readily available for use and
presentable by real users. Software should function in a manner that needs to be predictable,
reliable and dependable. Software should utilize resources efficiently and should not have any
loop holes.
It is ideal that software should be usable for a lifetime, which is not the case in many types of
software as demands, need for information, and processing information techniques keep varying.
Software should provide a user-friendly or easy-to-use, understandable & clear and appropriate
user interface. The software should be accompanied by proper documentation i.e. user manuals,
copyrights summary, debugging, etc. The software should be portable and at the same time free
of maintenance or should be easily maintained by end-users.