SEPM UT-2

Module 4-Software Risk, Configuration Management

1.Explain Risk & its types? Explain the steps involved in

setting up or generating RMMM plan. 10M
Risk: -
• Risk-possibility of suffering loss.
• Risk refers to the possibility of an uncertain event or situation occurring
that can have a negative impact on the outcome of a particular activity
or project.
• Might cause degraded quality of product, increased costs, delayed
completion or failure.
Types: -
1. Schedule Risk: -
Schedule related risks refers to time related risks or project delivery
related planning risks. The wrong schedule affects the project
development and delivery. These risks are mainly indicates to running
behind time as a result project development doesn’t progress timely and
it directly impacts to delivery of project.
Some reasons for Schedule risks –
• Time is not estimated perfectly
• Improper resource allocation
• Tracking of resources like system, skill, staff etc
• Frequent project scope expansion
• Failure in function identification and its’ completion
2. Budget Risk: -
Budget related risks refers to the monetary risks mainly it occurs due to
budget overruns. Always the financial aspect for the project should be
 managed as per decided but if financial aspect of project mismanaged
then there budget concerns will arise by giving rise to budget risks.
Some reasons for Budget risks –
• Wrong/Improper budget estimation
• Unexpected Project Scope expansion
• Mismanagement in budget handling
• Cost overruns
• Improper tracking of Budget
3. Operational Risks: -
Operational risk refers to the procedural risks means these are the risks
which happen in day-to-day operational activities during project
development due to improper process implementation or some external
operational risks.
Some reasons for Operational risks –
• Insufficient resources
• Conflict between tasks and employees
• Improper management of tasks
• No proper planning about project
• Less number of skilled people
• Lack of communication and cooperation
• Lack of clarity in roles and responsibilities
• Insufficient training
4. Technical Risks: -
Technical risks refers to the functional risk or performance risk which
means this technical risk mainly associated with functionality of product
or performance part of the software product.
Some reasons for Technical risks –
• Frequent changes in requirement
• Less use of future technologies
 • Less number of skilled employee
• High complexity in implementation
• Improper integration of modules
5. Programmatic Risks: -
Programmatic risks refers to the external risk or other unavoidable risks.
These are the external risks which are unavoidable in nature. These risks
come from outside and it is out of control of programs.
Some reasons for Programmatic risks –
• Rapid development of market
• Running out of fund / Limited fund for project development
• Changes in Government rules/policy
• Loss of contracts due to any reason

RMMM: -
An effective strategy to assist the project team in developing a strategy for
dealing with risk must consider three issues:
1. Risk avoidance (Mitigation)
2. Risk Monitoring
3. Risk Management and contingency planning

1. Risk Mitigation: Based on the risk analysis, the next step is to develop
strategies to mitigate or reduce the identified risks. This can include risk
avoidance, risk transfer, risk reduction, or risk acceptance.
To mitigate this risk, project management must develop a strategy for
reducing turnover. The possible steps to be taken are:
• Meet the current staff to determine causes for turnover (e.g., poor
working conditions, low pay, competitive job market).
• Mitigate those causes that are under our control before the project
starts.
• Once the project commences, assume turnover will occur and develop
techniques to ensure continuity when people leave.
 • Organize project teams so that information about each development
activity is widely dispersed.
• Define documentation standards and establish mechanisms to ensure
that documents are developed in a timely manner.
• Assign a backup staff member for every critical technologist.

2. Risk Monitoring: Once the risk mitigation strategies have been

implemented, it is important to monitor and review the effectiveness of the
strategies. This can be done through regular risk assessments or key
performance indicators.
the following factors can be monitored:
• General attitude of team members based on project pressures.
• Interpersonal relationships among team members.
• Potential problems with compensation and benefits.
• The availability of jobs within the company and outside it.

3. Risk Management: The final step in setting up an RMMM plan is to manage

the risks on an ongoing basis. This includes updating the risk assessment,
revising the risk mitigation strategies, and communicating the risks and
strategies to stakeholders.

2.What is Software Configuration Management (SCM)?

Explain the various steps involved in change control. 10M

System Configuration Management (SCM) is an arrangement of exercises

which controls change by recognizing the items for change, setting up
connections between those things, making/characterizing instruments for
overseeing diverse variants, controlling the changes being executed in the
current framework, inspecting and revealing/reporting on the changes made.
Consists of 5 tasks: -
• Identification
• Version Control
• Change Control
• Configuration Audit
• Status Reporting
A. Identification: The identification task involves identifying and defining the
software products that will be managed and controlled by the SCM process.
This includes identifying the software components, documentation, and other
related artifacts.
B. Version Control: The version control task involves managing and tracking
changes to software products over time. This includes creating and maintaining
different versions of software products, tracking changes to individual
components, and managing changes to related artifacts.
C. Change Control: The change control task involves managing and controlling
changes to software products. This includes submitting change requests,
evaluating change requests, approving or rejecting changes, implementing
changes, and testing changes.
D. Configuration Audit: The configuration audit task involves verifying that the
software products are consistent with the defined configuration management
plan. This includes checking that the software products are properly versioned,
that the appropriate changes have been made, and that the software products
are properly documented.
E. Status Reporting: The status reporting task involves providing regular
updates on the status of the software products and the SCM process. This
includes providing updates on changes made, the status of ongoing projects,
and any issues or risks that may impact the SCM process.

steps involved in change control: -

1. Documenting the change request. The client's change request or
proposal is categorized and recorded along with informal assessments of
the importance of that change and the difficulty of implementing it.
2. Formal assessment. This step evaluates the justification for the change
and the risks and benefits of making or not making the change. If the
change request is accepted, a development team will be assigned. If the
change request is rejected, that is documented and communicated to
the client.
3. Planning. The team responsible for the change creates a detailed plan
for its design and implementation, as well as for rolling back the change
should it be deemed unsuccessful.
4. Designing and testing. The team designs the program for the software
change and tests it. If the change is deemed successful, the team
requests approval and an implementation date.
 5. Implementation and review. The team implements the program
and stakeholders review the change.
6. Final assessment. If the client is satisfied with the implementation of the
change, the change request is closed. If the client is not satisfied, the
project is reassessed and steps may be repeated.

3.Prepare a Risk Identification checklist & RMMM plan for

creating an UID with Biometrics (Unique Identification
Number) for highly populated country.

Risk Identification Checklist:

1. Technical Risks:
• Failure to capture accurate biometric data due to technical issues.
• Security risks associated with storing and transmitting biometric data.
• Failure to integrate the UID system with existing government systems.
• Lack of scalability of the system to handle a large number of users.
2. Operational Risks:
• Inadequate training of staff and officials responsible for capturing
biometric data.
• Insufficient infrastructure to support the UID system, such as power
supply and internet connectivity.
• Delays in the enrollment process due to technical or operational issues.
3. Legal and Regulatory Risks:
• Non-compliance with data protection laws and regulations.
• Unauthorized access or misuse of biometric data.
• Legal challenges to the UID system by individuals or organizations.
4. Social Risks:
• Resistance from citizens to provide biometric data.
• Discrimination against certain population groups due to the use of
biometric data.
RMMM Plan:
Risk Mitigation:
• Conduct thorough testing of the biometric capture and storage systems
to ensure accuracy and security.
• Develop and implement strict data protection and security policies and
protocols.
• Provide extensive training to staff and officials responsible for capturing
biometric data.
• Establish redundant infrastructure to minimize downtime and ensure the
smooth functioning of the UID system.
• Ensure compliance with all relevant laws and regulations related to data
protection and privacy.
• Develop and implement a communication strategy to educate citizens
about the benefits and importance of the UID system.
Risk Monitoring:
• Regularly monitor the accuracy and security of biometric data capture
and storage systems.
• Monitor the enrollment process to identify and address any technical or
operational issues that may arise.
• Monitor legal and regulatory developments related to data protection
and privacy.
• Regularly survey citizens to identify any social concerns or resistance to
the UID system.
Risk Management:
• Establish a dedicated risk management team to oversee and manage all
risks associated with the UID system.
• Develop and implement a risk management plan to address identified
risks.
• Regularly review and update the risk management plan to reflect new
risks and changes in the risk landscape.
 • Develop contingency plans to minimize the impact of any risks that may
materialize.
In summary, the UID system using biometrics presents several risks, both
technical and operational, legal and regulatory, and social. To mitigate these
risks, a comprehensive RMMM plan should be developed and implemented,
which includes risk identification, risk mitigation, risk monitoring, and risk
management. By following this plan, the UID system can be developed and
implemented successfully, ensuring that it meets its intended objectives while
minimizing any associated risks.

4 Explain the features of repository required to support

SCM. 5M
A repository is a central storage location where all the artifacts related to a
software project are stored. It is a critical component of software configuration
management (SCM) as it allows for version control, change tracking, and
collaboration among team members. Here are some of the features of a
repository required to support SCM:
1. Version Control: The repository should support version control to enable
the tracking of changes made to the artifacts over time. It should allow
for branching and merging of code, enabling developers to work on
different versions of the same codebase simultaneously.
2. File Storage: The repository should provide a secure and centralized
location for storing all project-related files, including code,
documentation, test cases, and configuration files. It should ensure that
all files are easily accessible to team members with appropriate access
permissions.
3. Access Control: The repository should support access control to ensure
that only authorized users have access to project files. It should allow
administrators to grant and revoke access permissions at a granular level,
based on user roles and responsibilities.
4. Collaboration: The repository should provide tools for collaboration,
enabling team members to communicate, share feedback, and work
 together on project files. It should support features such as commenting,
notifications, and task management.
5. Change Management: The repository should support change
management, enabling team members to track changes made to project
files over time. It should provide a detailed history of changes, including
who made the changes, when they were made, and what changes were
made.
6. Integration: The repository should support integration with other tools
used in the software development lifecycle, such as continuous
integration and deployment (CI/CD) tools, issue trackers, and project
management tools. It should enable seamless integration to streamline
the development process and ensure consistency across all tools.

5. Explain in detail the Software Configuration Management

process with suitable diagram. 10M
Software Configuration Management (SCM) is the process of managing and
controlling changes to software artifacts throughout the software development
lifecycle. SCM provides a systematic approach to version control, change
management, and configuration management, ensuring that software artifacts
are properly tracked and controlled. Here is a detailed explanation of the SCM
process along with a suitable diagram.
The SCM process consists of several key steps, including:
1. Configuration Identification: This is the first step in the SCM process,
which involves identifying and defining the software configuration items
(SCIs) that are subject to change control. SCIs can include source code,
executable files, documentation, test cases, and configuration files. The
configuration identification process typically involves creating a baseline
of the software artifacts, which serves as the starting point for version
control and change management.
2. Version Control: Once the SCIs are identified, the next step is to establish
version control, which involves tracking changes made to the SCIs over
time. Version control tools, such as Git or SVN, are used to manage
 different versions of software artifacts, enabling developers to work on
different versions of the same codebase simultaneously.
3. Change Control: Change control involves managing and controlling
changes to the software artifacts. When a change request is received,
the change control process assesses the impact of the change, evaluates
its feasibility, and approves or rejects the change request based on its
impact. If the change is approved, it is implemented, and the updated
version of the software artifact is stored in the version control system.
4. Configuration Status Accounting: Configuration status accounting
involves tracking and reporting the status of the SCIs throughout the
software development lifecycle. It provides a comprehensive view of the
configuration items, including their current versions, status, and history
of changes.
5. Configuration Audit: Configuration audit involves reviewing the software
artifacts to ensure that they comply with the defined configuration
standards and requirements. It involves comparing the software artifacts
against the baseline and verifying that all changes are properly
documented and approved.
6. Release Management: Release management involves preparing the
software artifacts for release and deploying them to the target
environment. It involves ensuring that all the necessary components,
such as documentation, test cases, and configuration files, are included
in the release package and that the package is properly tested and
validated before deployment.
6.What is FTR in SQA? What are its objectives? Explain the
steps in FTR. 10M
FTR stands for Formal Technical Review, which is a software quality assurance
(SQA) technique used to review and evaluate software artifacts formally. FTR is
typically conducted before the software is released, ensuring that the software
meets the specified requirements, standards, and quality metrics. FTR is an
effective way to identify defects and issues in software artifacts early in the
software development lifecycle.
Here are the objectives of FTR:
1. To identify defects and issues in software artifacts early in the software
development lifecycle, reducing the cost and effort of fixing them later.
2. To ensure that the software artifacts meet the specified requirements,
standards, and quality metrics, ensuring the quality of the software.
3. To improve the communication and collaboration among team members,
ensuring that everyone has a shared understanding of the software
artifacts.
4. To enhance the learning and knowledge sharing among team members,
ensuring that everyone learns from the review process and improves
their skills.
Steps in FTR: -
1.The review meeting
Every review meeting should be conducted by considering the following
constraints- Involvement of people Between 3 and 5 people should be involve
in the review.
Advance preparation should occur but it should be very short that is at the
most 2 hours of work for each person can be spent in this preparation.
The short duration of the review meeting should be less than two hour.
2.Review reporting and record keeping
During the FTR, the reviewer actively record all the issues that have been
raised. At the end of meeting these all raised issues are consolidated and
review issue list is prepared. Finally, formal technical review summary report is
produced.
3.Review guidelines
Guidelines for the conducting of formal technical review must be established in
advance. These guidelines must be distributed to all reviewers, agreed upon,
and then followed.

7. What is FTR? Explain the review guidelines considered

during FTR.
(same as quation 6)

8.Explain how version control & change control are carried

out during SCM?
Version control and change control are two critical processes in Software
Configuration Management (SCM) that help manage the changes made to
software artifacts during the software development lifecycle. Here's how
version control and change control are carried out during SCM:
1. Version control:
• During version control, the SCM system keeps track of the different
versions of software artifacts, such as code files, documents, and test
cases, as they evolve over time.
• Each version of the artifact is identified by a unique version number, and
the SCM system maintains a history of all the changes made to the
artifact.
• Developers can access and modify the artifacts only after checking them
out from the SCM system, ensuring that only one developer works on a
particular version at a time.
• Developers check in their changes to the SCM system, which creates a
new version of the artifact. The system maintains a record of who made
the changes, when they made them, and the purpose of the changes.
 • The version control process helps developers to track changes, revert to
earlier versions, and collaborate effectively on software development
projects.
2. Change control:
• Change control is the process of managing changes made to software
artifacts throughout the software development lifecycle.
• When a developer wants to make a change to a software artifact, they
must follow a defined change control process. The process typically
involves requesting the change, assessing the impact of the change,
implementing the change, and verifying that the change has been
correctly implemented.
• The change control process helps ensure that changes are made
correctly and that the quality of the software is maintained throughout
the software development lifecycle.
• The SCM system maintains a record of all the changes made to each
software artifact and tracks the status of each change request.
• Change control is critical in ensuring that changes made to software
artifacts do not adversely affect the overall quality of the software.

9.Write short note on – Risk Management

Risk management is the process of identifying, assessing, and mitigating risks in
a project, organization, or system. It involves a structured approach to
understanding potential risks and developing strategies to reduce or eliminate
them. The main objective of risk management is to minimize the negative
impact of uncertain events on project objectives or business goals.
The risk management process involves the following steps:
1. Risk identification: Identifying potential risks that may arise during the
project or system development lifecycle.
2. Risk assessment: Evaluating the likelihood and impact of each identified
risk, and prioritizing them based on their potential impact.
 3. Risk mitigation: Developing strategies to reduce or eliminate the
identified risks, including risk avoidance, risk transfer, risk reduction, or
risk acceptance.
4. Risk monitoring: Continuously monitoring the risks throughout the
project or system development lifecycle and making adjustments to the
risk management strategies as needed.
Effective risk management can help organizations avoid unexpected events that
can derail projects, delay timelines, or cause significant financial losses. By
proactively identifying and mitigating risks, organizations can improve their
chances of success and achieve their project objectives.