Documente Academic
Documente Profesional
Documente Cultură
Level 3 – Defined
Organization Process Focus
Organization Process Definition
Training Program
Integrated Software Management
Maturity Levels
Software Product Engineering
Intergroup Coordination
& KPAs
Peer Reviews
Level 2 – Repeatable
Requirements Management
Software Project Planning
Software Project Tracking & Oversight
Software Subcontract Management
Software Quality Assurance
Software Configuration Management Level 1 - Initial
Assessment Method
CMM-based appraisal for internal process improvement (CBA-IPI)
Software Capability Evaluation
CBA-IPI evaluates :
Strengths & weaknesses of the software process
Satisfaction of the different goals of the different KPAs
Sources of Information:
Maturity Questionnaires
Documentation
Interviews
Consolidation Process
PROPOSALS
&
CONTRACTS
Overview
Customer: A person/organization who needs a software to
ease its own needs
Vendor: A company who offers to develop a software or
provide services based on customer requirements. Eg.
Infosys…
When a vendor is to develop some software for a customer, a clear
understanding is needed between the two parties
A vendor proceeds with the project only when the proposal has been
accepted by the customer and the contract is signed.
Many issues have to be handled in a contract and a proposal, like
Legal concerns,
Commercial arrangements
intellectual property rights.( employee exchange etc.)
These two documents form the starting point of a business
transaction or relationship.
Customer – Vendor interaction
Customer –Vendor interaction is initiated either by the customer
organization itself or by the sales staff of the vendor.
The customer agrees to the rates for payment and then pays based
on the actual effort expended.
This model is usually adopted when the customer is not very clear on
the requirements or expects a continuous stream of project, many of
them small. Hence mainly used in maintenance projects.
In first part ,i.e. T&M model customer agrees to pay vendor on basis
of actual effort spent by the analyst, without any hard estimate of
how much effort it will take to do the analysis.
The second part, includes the detailed cost estimates is given after
the first part is over. The vendors for the first and second part might
be different
Based on the above models effort estimates are done and sent
to the customer.
Gather
Prepare Analyze
Requirements
6 Standard Requirements
6.1 User Interface
6.4 Document
7 Special User Requirements
7.1 Security
7.2 Audit Trail
7.3 Reliability
7.4 Transaction Volume and Data Volumes
7.5 Backup and Recovery
7.6 Legal
7.7 Data Migration
7.8 Data Retention
7.9 Installation
7.10 User Training
7.11 User Manual and Help
7.12 Automated and Manual Functions
7.13 Features Not Required
8 Constraints
9 Prototype
• Hence it is critical to carefully verify requirements to make sure
that what is specified is indeed what is desired.
• For requirements validation, requirement reviews are done and
usually involve the customer.
• As with any review, the effectiveness is increased if there is a
checklist specifying what the reviewers should be looking for.
The checklist is derived from the template and the nature of errors
that have been found in the past.
• Special attention is given to errors falling in the categories of
omission, incorrect fact, inconsistency, and ambiguity- the most
common requirement errors.
Requirements Change
Management
• The requirement change management process defines the set of
activities that needs to be performed when there are some new
requirement or changes to existing requirements (we will call both
changes in the requirements.)
• Requirement changes can occur at any point during the project
execution stage.
• A change in the requirements might alter the schedule of the
project it might even affect the work products that that have already
been produced.
• The further down in the life cycle the requirements change, the
more severe the impact on the project.
• Uncontrolled changes to requirements also have a high potential for
seriously jeopardizing the chances of a project's success by having a very
adverse effect on the cost, schedule, and quality of the project.
• Requirement changes can account for as much as 40% of the total cost.
• The basic goal of the requirements change management process is to
control requirement changes and minimize their effect on the project.
• This goal necessitates understanding the full implications of a
requirements change request, as well as the cumulative impact of
changes.
• It also requires making the customer fully aware of the effects of the
changes on the project so that changes in the negotiated terms can be
done amicably.
• The requirements change management process, in the sense, tries to
ensure that a project succeeds despite requirement changes.
Requirements change
management Process
• Requirements change management has two aspects : agreement
with the customer about how to deal with the changes and the
process of actually making the changes.
• The overall approach for handling changes has to be agreed to by
the customer and is frequently a part of the proposal as well as the
project management plan.
• Generally, it specifies how the change requests will be made, when
formal approvals are needed, building a buffer in the estimates for
handling changes, and so on.
• In the context of the overall approach, wjem a request for a
requirements change comes in, the requirements change
management process must be executed.
• The project leader is primarily responsible for executing the
process to incorporate the change in the project.
• The customer, the business manager to whom the project leader
reports, and the development team also participate in this process.
• The entry criterion for this process is that a change request has
been received, and the inputs are the change request and the work
products that have already been produced in the project.
• The main outputs are the impact analysis report for the change
request, the revised project plan, and the changed work products.
• The exit criterion is that the change has been incorporated lowing
are the major steps in the process.
Log the changes.
Perform impact analysis on the work products.
Estimate effort needed for the change request.
Re estimate delivery schedule.
Perform cumulative cost impact analysis.
Review the impact with senior management, if thresholds are exceeded.
Obtain customer sign-off.
Rework work products.
• A change request log is maintained to keep tract of the change request.
• Each entry in the log contains a change request number, a brief
description of the change, the effect of the change, the status of the
change request, and key dates.
• The effect of a change request is assessed by performing impact
analysis.
• Impact analysis involves identifying work products that need to be
changed and evaluating the quantum of change to each; reassessing the
project's risks by revisiting the risk management plan; and evaluating the
overall implications of the changes for the effort and schedule estimates.
• The outcome of the analysis is reviewed and approved by the project
leader and the customer.
• The change request itself is incorporated in the requirements
specification document might also be modified to reflect the changes.
• Monitoring of approved change request and ensuring their proper
implementation are handled by the configuration management process.
• A change might be classified as minor if the total errors involved in
implementing it does not exceed a predetermined value, say two person-
days.
• Changes that are minor typically become part of the project effort,
and the planned estimates must contain a buffer for such changes (
typically a small percentage of the total project effort), with proper
provisions made in the proposal and contract.
• If the actual cumulative effort on minor changes exceeds this
thresholds, the effort estimates might have to be renegotiated,
perhaps by adding another buffer to absorb further changes.
• The delivery schedule might also be revisited and renegotiated, if
necessary.
• Major changes usually have a larger financial cost and are formally
approved by the client.
Example
• To specify the changes and the output of the change management
process, a simple template has been defined, containing summaries of
various attributes.
• Each change is assigned a unique number for reference that is specified
by the request number field. The change specification gives a brief
description of the requested change.
• The category of change( for example, design change, contract change,
functionality change, performance change) might also be specified, and
the nature of the change specified as change category.
• The summary of the impact analysis is recorded, with brief information
being given regarding work products that will be affected, the effort
involved, and the implications for the schedule.
• The state of the change request- what is being done with this request is
recorded in the status field.
• The date of the change request might also be recorded, along with the
date the change was approved, if approval is needed.
TRACEABILITY MANAGEMENT
The basic goal of the project.
This objective implies that some way exists for checking that
software meets all requirements.
To aid this validation Traceability of requirement is important.
This means that it is possible to trace each and every requirements
to design and code the implementation of any particular
requirement and test cases that test that implementation.
Through this tracing it is possible to validate that software has met
all requirements and the software has been tested for all the
requirements.
There are two types of Traceability exists.
Forward.
Backward.
Forward Traceability implies that it is possible to trace a requirement
to element in the output of later phases (design, coding) in life cycle.
Example : Paper work for any C, C++ program.
Backward Traceability is the reverse. It implies that it is possible to
trace elements in the output of various stages back to requirement or
we can have ability to trace the requirements back to their origin.
Example : Debugging for same programs.
TRACEABILITY MATRIX
The simplex way to support traceability is to have a mapping
From Requirement element to Design element,
From Design element to Code element,
Code element to Test cases.
In Infosys this mapping is maintain in Traceability Matrix.
Traceability Matrix… Format
Reqmt # is a references to the requirement specification.
Matrix requires proper numbering scheme to be used in the requirement
specification document, such that individual requirement have unique
numbers or labels.
The description should be obtain from the requirement specification.
It could be keyword, bullets or couple of sentences. This description
makes the matrix more readable and standalone.
The HLD Ref. # is a reference to the functional specification that satisfies
the corresponding requirement.
The design is the section number from the corresponding design
document that contain the part of the design that satisfy the specific
requirement.
Implementation refers to the corresponding program that implement the
requirement.
Here note that first two entry that specify the requirement, the matrix
could enter multiple entries for the same requirement.
The unit test cast represents the test case number in the unit test plan for
the program that implement the requirement.
Those requirements do not have program level implementation might have
no entry in this column.
System/Integration test case : All requirement should have a test cast at
integration or system level.
The integration test plan typically has the business and technical test cases
clearly identified.
The last field is Acceptance Test Case.
The described column of the matrix aim to map the requirements to
different units as the software evolves.
This effort helps to ensure that the requirements have been incorporated
in the software being built.
The traceability matrix shown here tells the traceability of one
requirement.
Requirement number is 1.1.2
This requirement is about real time integration or highlighter with
data collection is implemented by section 5.3.2 of the HLD Doc
(High level Design Document) and at a detail level is implemented
by the interface between two modules.
Two programs implement this particular requirement, and both are
listed here on different rows.
For each of two programs table gives the unit test case number in the
respective unit test plan, Integration test case number in their
integration test plan and Acceptance test case number in their
acceptance test plan.
Matrix Maintenance & Usages :
The traceability matrix helps to track/trace all requirement through the
various life-cycle phases to ensure that all requirements have been
incorporated.
This helps in reducing rework due to missing requirement.
The matrix aids reviews by providing a mechanism for reviewers to easily
check that all requirements have been handled.
It helps in demonstrating to the customer about the project and test cases.
A Traceability matrix, unless maintained properly, it is of limited use.
AT the start, the matrix contains data in the first two columns only and as
development proceeds, data for the other columns are added.
For maintenance of a matrix for a project, the numbering scheme must be
used in all documents.
After the matrix is built and is being maintained properly, some completeness
checks can be performed.
Some of these checks are as follows.
Go through the requirement number in the matrix and the requirement in the
requirement document.
This goal can be achieved easily by sorting the matrix by requirement number and then
checking the number against the numbers in the requirement document.
To ensure that all programs listed in the matrix are needed in the final software and no
unnecessary code appears, every program, class and other elements must be
mentioned in the matrix.
One can check implementation of requirements by ensuring that functional
requirements have no blank columns.
For any requirement, if the design and program fields are blank, check that this
requirement have no direct effect on programs.
For each performance requirement, there should be some test cases.
The integration and system test plan can be cross – checked with the matrix to ensure
that all conditions in the requirements are included in the system test plan.
Maintaining the integrity of the matrix under requirement changes
is not easy.
Requirement changes are incorporated in the requirement
document in 2 ways.
By changing some existing requirement in the document,
By appending the change request.
The approach followed in updating the requirement specification
document can also be followed in updating the traceability matrix.
If the requirement change request is appended to the document, it
is treated as an additional requirement and entry is done in matrix.
If some existing requirement changes, you need to see if the entry
in the matrix needs to change or not.