Planning a Software (Unit-2) CS340

Once a project is found to be possible, computer code project managers undertake project
design. Project designing is undertaken and completed even before any development activity
starts. Project designing consists of subsequent essential activities: Estimating the subsequent
attributes of the project:
Project size: What’s going to be the downside quality in terms of the trouble and time needed
to develop the product?
Cost: What proportion is it reaching to value to develop the project?
Duration: How long is it to reach design plate amended development?
Effort: What proportion of effort would be required?
Precedence ordering among project planning activities:
The different project-connected estimates done by a project manager have already been
mentioned. The below diagram shows the order in which vital project coming up with
activities is also undertaken. It may be simply discovered that size estimation is the 1st
activity. It’s conjointly the foremost basic parameter supported that all alternative coming up
with activities square measure dispensed, alternative estimations like the estimation of effort,
cost, resource, and project length also are vital elements of the project coming up with.

What Is Software Estimation

Software estimation is the process of estimating the time, effort, and resources required to
complete a software project or specific tasks within it. It is a crucial step in project planning,
as accurate estimation helps avoid schedule and budget misalignments that can lead to project
failure.

Software estimation is challenging, given the ever-changing nature of software development.

However, developers use several techniques to achieve reliable and consistent estimations.
Here are some of the main techniques:
  Expert Judgement: This technique involves consulting with experienced individuals
to provide estimates based on their experience and knowledge.
 Bottom-up Estimation: This technique involves breaking the project into smaller,
manageable components and estimating the effort required to complete each
component.
 Three-point Estimation: This technique calculates the expected effort using a
weighted average of three estimates: the most optimistic, the most pessimistic, and the
most likely.
 Planning Poker: This technique is a variation of the three-point estimation technique
that involves team members playing a card game to assign relative sizes to user stories
or features.
 Agile Story Points: This technique assigns a relative size to user stories or features
based on their complexity and the effort required rather than absolute hours or days.
Each technique has advantages and disadvantages, and the choice of technique often depends
on the specific project requirements and the team’s expertise.

Why Is Estimating Software Important

Here are some advantages to getting the estimations right

3.1 Impact on Budget and Schedule

Accurate software estimation helps budget planning, enabling businesses to allocate resources,
make informed decisions, and avoid financial losses.In Agile and Waterfall project
management methodologies, effort estimates are crucial to project planning and management.
Here’s how they are utilized:
 Agile Methodology:
 In Agile project management, effort estimates are used to plan sprints or iterations.
During sprint planning, the team estimates the effort required to complete each user
story, typically using Agile story points.
 These estimates are used to prioritize user stories, plan the sprint backlog, and allocate
team members’ tasks.
 Waterfall Methodology:
  In the Waterfall project management methodology, effort estimates are used to plan
and schedule activities in the project lifecycle.
 Typically, project managers and developers estimate the effort required for each
activity, from requirements gathering and design to coding, testing, and deployment.
3.2 Risk Management
Accurate estimation helps identify potential risks and challenges during software development.
Project managers can then plan and allocate resources to mitigate such risks and ensure the
project’s success.

Technical Risk Management and Decision Analysis — Introduction and Fundamental

Principles

3.3 Communication
Estimation also plays a vital role in communication between developers and project managers.
Accurate estimations help developers communicate the expected timeline and workload to
project managers, leading to improved collaboration and better decision-making.
3.4 Resource Allocation
Estimation helps allocate resources, including human resources, equipment, and software tools.
Knowing the effort required for each task helps distribute workloads equitably and ensures
developers have the necessary resources to complete tasks within the scheduled timeline.
It is common for customers, particularly large ones, to have several concurrent projects, making
it crucial to deliver on time to avoid jeopardizing other projects.

The Critical Importance of Software Project Management

3.5 Improving Team Morale

Maintaining high morale is critical for achieving optimal performance and preserving the long-
term mental well-being of any human group, including software development teams.
Setting unrealistic deadlines can increase stress levels, negatively impacting morale and
confidence. This effect can be especially detrimental when such deadlines become common
occurrences instead of isolated incidents.

3.6 Managing Stakeholder Expectations

Accurate estimation is pivotal in effectively managing stakeholder expectations and ensuring
a successful implementation. However, IT projects are inherently complex, making meeting
the project’s schedule and budget constraints challenging.
Even though stakeholders understand the intricacies of completing IT projects, they still expect
the supplier to deliver the project within the stipulated time and budget. The supplier is
expected to put in their best efforts to achieve project objectives, as stakeholders are not likely
to provide an unlimited budget or time.

Stakeholder Analysis and Management

3.7 Product Quality and Technical Debt

There are ample opportunities to enhance processes in any software development life cycle
(SDLC) phase, including the Analysis stage, particularly the effort estimation component.
 Code Quality: The code, feature, or product quality usually suffers, and this
degrades technical debt, which has long-term implications.
 User Experience: This results in software failing to meet customer expectations,
which can become unusable sometimes.
  Product Quality: Cutting software testing activities is another example of such
compromises, directly resulting in more testing cycles and customer dissatisfaction.
 Launch Delays: This translates into delayed time to market, potential loss of profits,
and loss to competitors.

Uncertainties In Effort Estimation

Estimates are difficult to calculate because of the uncertainty usually involved in complex
systems like IT solutions, IT environments, and human groups. These uncertainties typically
fall into two groups: known unknowns and unknown unknowns.

(The challenge with software estimation is compounded by its immediate effect on the
budget, schedule, and resource allocation.)
Examples of known unknowns are:
 Periodically updated industry regulations
 Legacy code
 Poor processes or outdated delivery methodologies
 Changes in organisational strategy and priorities
 Natural disasters
 Loss of talent.
Unknown unknowns are more difficult (if not impossible) to anticipate; examples can be:
 Changing business requirements as a result of users interacting with the software
 Changing user preferences
 Novel technologies where users have yet to understand what the technology can do
for them.
Estimation Challenges
Several reasons make estimation hard, including:
 Lack of clarity: Unclear project requirements or goals can lead to inaccurate
estimates.
 Project complexity: Highly complex projects with multiple dependencies and
technical challenges are harder to estimate accurately.
 Limited historical data: Lack of past project data can make it difficult to estimate
future projects accurately.
 Changing requirements: Changes in project requirements can significantly impact
the effort required and affect the estimate.
 Human error: Estimation is subjective and relies on human judgment, which can be
prone to error.
 Uncertainty: Software development always has an inherent degree of uncertainty,
making estimation challenging.
 Time constraints: Estimation requires time and effort, which can be limited in fast-
paced development environments.
Addressing these challenges requires careful planning, robust estimation techniques, and
continuous refinement of the estimation process.
Cost Estimation Models in Software Engineering
Cost estimation simply means a technique that is used to find out the cost estimates. The cost
estimate is the financial spend that is done on the efforts to develop and test software in
Software Engineering. Cost estimation models are some mathematical algorithms or
parametric equations that are used to estimate the cost of a product or a project. Various
techniques or models are available for cost estimation, also known as Cost Estimation Models.
Cost Estimation Models as shown below :

Cost Estimation Models

Empirical Estimation Technique – Empirical estimation is a technique or model in which
empirically derived formulas are used for predicting the data that are a required and essential
part of the software project planning step. These techniques are usually based on the data that
is collected previously from a project and also based on some guesses, prior experience with
the development of similar types of projects, and assumptions. It uses the size of the software
to estimate the effort. In this technique, an educated guess of project parameters is made.
Hence, these models are based on common sense. However, as there are many activities
involved in empirical estimation techniques, this technique is formalized. For example Delphi
technique and Expert Judgement technique.
Heuristic Technique – Heuristic word is derived from a Greek word that means “to discover”.
The heuristic technique is a technique or model that is used for solving problems, learning, or
discovery in the practical methods which are used for achieving immediate goals. These
techniques are flexible and simple for taking quick decisions through shortcuts and good
enough calculations, most probably when working with complex data. But the decisions that
are made using this technique are necessary to be optimal. In this technique, the relationship
among different project parameters is expressed using mathematical equations. The popular
heuristic technique is given by Constructive Cost Model (COCOMO). This technique is also
used to increase or speed up the analysis and investment decisions.
Analytical Estimation Technique – Analytical estimation is a type of technique that is used
to measure work. In this technique, firstly the task is divided or broken down into its basic
component operations or elements for analyzing. Second, if the standard time is available from
some other source, then these sources are applied to each element or component of work. Third,
if there is no such time available, then the work is estimated based on the experience of the
work. In this technique, results are derived by making certain basic assumptions about the
project. Hence, the analytical estimation technique has some scientific basis. Halstead’s
software science is based on an analytical estimation model.

A Bottom-Up Estimation Approach

The term "bottom-up" refers to an approach that starts at the lowest detail level and works up
to more general conclusions. In the case of project cost estimates, it means assessing the cost
of an activity by breaking it down into smaller work packages, and then adding them together
until you arrive at the total summary cost. Bottom-up estimating deals with the most detailed
level of the Work Breakdown Structure (WBS).
It is a unique technique in project management because it helps project managers see every
minute element of the entire project before starting. It provides a highly accurate estimate to
use for the budget baseline, as it is uniquely tailored to the project at hand.
For example, let’s say you have a project that requires three different tasks:
 Task A – Write code for feature X
 Task B – Write code for feature Y
 Task C – Fix bugs in existing application
Using the bottom-up approach, you would estimate how long each task would take and then
add up those estimates to arrive at an overall project cost.
The beauty of using bottom-up estimating is that you can also use other estimation techniques
so that you can have more accurate final estimates.

When project managers use bottom-up estimating

A project manager can use bottom-up budgeting when creating a new product or service,
when there are no similar projects to base the estimate on. Because the bottom-up technique
involves examining all the tasks in the activity at a granular level, it is a time-consuming
activity. However, having a definitive estimate will help you avoid making losses in the long-
run.
Unlike the parametric estimating technique, which involves complex statistics, bottom-up
analysis is fairly straightforward to do. However, it is still very detailed. Project managers
plan milestones, and may involve other team members to make a to-do list around each
milestone and decide steps they'll use to accomplish each task.
Bottom-up estimating example
Let's take a look at bottom-up estimating in practice.
If you are looking to start a marketing project you have not done before, you have a few
options to get a project estimate. The quickest would be to consult colleagues who have
already completed similar projects for an idea of overall cost -- but they might have done
things differently to you, and so their cost estimation might not be completely accurate.
One of the more accurate ways to come up with your estimate is to look at each activity you
will need to complete in the project. What are your resource requirements? How many hours
will the copywriter need to produce your marketing copy? How long will the design team
take to create the materials? Do task dependencies influence when each task can be
performed - and will that mean added costs as you pay a team member overtime or call in a
more expensive contractor?
This detailed estimating approach will reduce estimation error, both in terms of the cost
estimate and the duration estimate.

Advantages & disadvantages of bottom-up estimation technique

Before you choose an estimation technique, it is best to look at the pros and cons of each.
Here are some advantages and disadvantages of bottom-up estimating:
Advantages
More accurate estimates
Bottom-up estimating helps a project manager in the resource planning for their project. They
can visualize every component of the project and see who will be involved in its execution.
Team members can also be invited to give an estimation for their assigned tasks, because they
know what their work package entails.
Provides a realistic time frame
Because the bottom-up estimation is composed of an aggregation of all the smaller tasks, it
gives you a clear idea of what is involved in each task and how long the job will take to
complete. This helps you negotiate with your client for a realistic time frame.
Can be combined with other estimation techniques
You can use the bottom-up approach together with other techniques such as analogous
estimating technique or the parametric estimating technique to come up with the most
accurate schedule and budget estimate.
Keeps the project on track
When you use the bottom-up approach, you know from the beginning which are your critical
tasks, and what delays or change requests are likely to impact the budget and project
duration. This means you are able to handle changes in resource needs more effectively
throughout the project life cycle.
Disadvantages
Requires more resources
Bottom-up estimating can be costly because of the time it takes you and your team members
to break down the costs for each activity. This can significantly increase planning and project
costs.
If your project is time constricted, then long periods of planning associated with the bottom-
up estimation approach will not be ideal for your project. However, if stakeholders are more
concerned about accuracy than speed, this will work well.
Takes longer to complete
The project must be broken down into parts to apply the bottom-up technique. It involves
building a list of individual tasks or work packages used to create a total cost for the effort. If
the project is large or has intricate details, it will take much longer to complete.
COCOMO Model – Software Engineering
The Constructive Cost Model (COCOMO) is a software cost estimation model that helps
predict the effort, cost, and schedule required for a software development project. Developed
by Barry Boehm in 1981, COCOMO uses a mathematical formula based on the size of the
software project, typically measured in lines of code (LOC)
What is the COCOMO Model?
The COCOMO Model is a procedural cost estimate model for software projects and is often
used as a process of reliably predicting the various parameters associated with making a
project such as size, effort, cost, time, and quality. It was proposed by Barry Boehm in 1981
and is based on the study of 63 projects, which makes it one of the best-documented models.

The key parameters that define the quality of any software product, which are also an
outcome of COCOMO, are primarily effort and schedule:

Effort: Amount of labor that will be required to complete a task. It is measured in person-
months units.
Schedule: This simply means the amount of time required for the completion of the job,
which is, of course, proportional to the effort put in. It is measured in the units of time such as
weeks, and months.
Types of Projects in the COCOMO Model
In the COCOMO model, software projects are categorized into three types based on their
complexity, size, and the development environment. These types are:

Organic: A software project is said to be an organic type if the team size required is
adequately small, the problem is well understood and has been solved in the past and also the
team members have a nominal experience regarding the problem.
Semi-detached: A software project is said to be a Semi-detached type if the vital
characteristics such as team size, experience, and knowledge of the various programming
environments lie in between organic and embedded. The projects classified as Semi-Detached
are comparatively less familiar and difficult to develop compared to the organic ones and
require more experience better guidance and creativity. Eg: Compilers or different Embedded
Systems can be considered Semi-Detached types.
Embedded: A software project requiring the highest level of complexity, creativity, and
experience requirement falls under this category. Such software requires a larger team size
than the other two models and also the developers need to be sufficiently experienced and
creative to develop such complex models:

Detailed Structure of COCOMO Model

Detailed COCOMO incorporates all characteristics of the intermediate version with an
assessment of the cost driver’s impact on each step of the software engineering process. The
detailed model uses different effort multipliers for each cost driver attribute. In detailed
COCOMO, the whole software is divided into different modules and then we apply
COCOMO in different modules to estimate effort and then sum the effort.
The Six phases of detailed COCOMO are:

Planning and requirements: This initial phase involves defining the scope, objectives, and
constraints of the project. It includes developing a project plan that outlines the schedule,
resources, and milestones
System design: : In this phase, the high-level architecture of the software system is created.
This includes defining the system’s overall structure, including major components, their
interactions, and the data flow between them.
Detailed design: This phase involves creating detailed specifications for each component of
the system. It breaks down the system design into detailed descriptions of each module,
including data structures, algorithms, and interfaces.
Module code and test: This involves writing the actual source code for each module or
component as defined in the detailed design. It includes coding the functionalities,
implementing algorithms, and developing interfaces.
Integration and test: This phase involves combining individual modules into a complete
system and ensuring that they work together as intended.
Cost Constructive model: The Constructive Cost Model (COCOMO) is a widely used
method for estimating the cost and effort required for software development

Importance of the COCOMO Model

Cost Estimation: To help with resource planning and project budgeting, COCOMO offers a
methodical approach to software development cost estimation.
Resource Management: By taking team experience, project size, and complexity into
account, the model helps with efficient resource allocation.
Project Planning: COCOMO assists in developing practical project plans that include
attainable objectives, due dates, and benchmarks.
Risk management: Early in the development process, COCOMO assists in identifying and
mitigating potential hazards by including risk elements.
Support for Decisions: During project planning, the model provides a quantitative
foundation for choices about scope, priorities, and resource allocation.
Benchmarking: To compare and assess various software development projects to industry
standards, COCOMO offers a benchmark.
Resource Optimization: The model helps to maximize the use of resources, which raises
productivity and lowers costs.

Type of COCOMO model.

1-Basic COCOMO Model
The Basic COCOMO model is a straightforward way to estimate the effort needed for a
software development project. It uses a simple mathematical formula to predict how many
person-months of work are required based on the size of the project, measured in thousands
of lines of code (KLOC).
Example of Basic COCOMO Model
Suppose that a Basic project was estimated to be 400 KLOC (kilo lines of code). Calculate
effort and time for each of the three modes of development.

2. Intermediate COCOMO Model

The basic COCOMO model assumes that the effort is only a function of the number of lines
of code and some constants evaluated according to the different software systems. However,
in reality, no system’s effort and schedule can be solely calculated based on Lines of Code.
For that, various other factors such as reliability, experience, and Capability. These factors
are known as Cost Drivers (multipliers) and the Intermediate Model utilizes 15 such drivers
for cost estimation.

3. Detailed COCOMO Model

Detailed COCOMO goes beyond Basic and Intermediate COCOMO by diving deeper into
project-specific factors. It considers a wider range of parameters, like team experience,
development practices, and software complexity. By analyzing these factors in more detail,
Detailed COCOMO provides a highly accurate estimation of effort, time, and cost for
software projects. It’s like zooming in on a project’s unique characteristics to get a clearer
picture of what it will take to complete it successfully.

CASE Studies and Examples

NASA Space Shuttle Software Development: NASA estimated the time and money needed
to build the software for the Space Shuttle program using the COCOMO model. NASA was
able to make well-informed decisions on resource allocation and project scheduling by taking
into account variables including project size, complexity, and team experience.
Big Business Software Development: The COCOMO model has been widely used by big
businesses to project the time and money needed to construct intricate business software
systems. These organizations were able to better plan and allocate resources for their software
projects by using COCOMO’s estimation methodology.
Commercial Software goods: The COCOMO methodology has proven advantageous for
software firms that create commercial goods as well. These businesses were able to decide on
pricing, time-to-market, and resource allocation by precisely calculating the time and expense
of building new software products or features.
Academic Research Initiatives: To estimate the time and expense required to create
software prototypes or carry out experimental studies, academic research initiatives have
employed COCOMO. Researchers were able to better plan their projects and allocate
resources by using COCOMO’s estimate approaches.

Advantages of the COCOMO Model

Systematic cost estimation: Provides a systematic way to estimate the cost and effort of a
software project.
Helps to estimate cost and effort: This can be used to estimate the cost and effort of a
software project at different stages of the development process.
Helps in high-impact factors: Helps in identifying the factors that have the greatest impact
on the cost and effort of a software project.
Helps to evaluate the feasibility of a project: This can be used to evaluate the feasibility of
a software project by estimating the cost and effort required to complete it.
Disadvantages of the COCOMO Model
Assumes project size as the main factor: Assumes that the size of the software is the main
factor that determines the cost and effort of a software project, which may not always be the
case.
Does not count development team-specific characteristics: Does not take into account the
specific characteristics of the development team, which can have a significant impact on the
cost and effort of a software project.
Not enough precise cost and effort estimate: This does not provide a precise estimate of the
cost and effort of a software project, as it is based on assumptions and averages.

Project schedule simply means a mechanism that is used to communicate and know about
that tasks are needed and has to be done or performed and which organizational resources
will be given or allocated to these tasks and in what time duration or time frame work is
needed to be performed. Effective project scheduling leads to success of project, reduced
cost, and increased customer satisfaction. Scheduling in project management means to list
out activities, deliverables, and milestones within a project that are delivered. It contains
more notes than your average weekly planner notes. The most common and important form
of project schedule is Gantt chart.

The manager needs to estimate time and resources of project while scheduling project. All
activities in project must be arranged in a coherent sequence that means activities should be
arranged in a logical and well-organized manner for easy to understand. Initial estimates of
project can be made optimistically which means estimates can be made when all favorable
things will happen and no threats or problems take place.
The total work is separated or divided into various small activities or tasks during project
schedule. Then, Project manager will decide time required for each activity or task to get
completed. Even some activities are conducted and performed in parallel for efficient
performance. The project manager should be aware of fact that each stage of project is not
problem-free.
Problems arise during Project Development Stage :
 People may leave or remain absent during particular stage of development.
 Hardware may get failed while performing.
 Software resource that is required may not be available at present, etc.
The project schedule is represented as set of chart in which work-breakdown structure and
dependencies within various activities are represented. To accomplish and complete project
within a given schedule, required resources must be available when they are needed.
Therefore, resource estimation should be done before starting development.
Resources required for Development of Project :
 Human effort
 Sufficient disk space on server
 Specialized hardware
 Software technology
 Travel allowance required by project staff, etc.
Advantages of Project Scheduling :
There are several advantages provided by project schedule in our project management:
 It simply ensures that everyone remains on same page as far as tasks get
completed, dependencies, and deadlines.
 It helps in identifying issues early and concerns such as lack or unavailability of
resources.
 It also helps to identify relationships and to monitor process.
 It provides effective budget management and risk mitigation.

Techniques of project scheduling in software engineering

1- Gantt charts

Gantt charts are a popular technique for project scheduling in software engineering.

They provide a visual representation of the project schedule, depicting the start and end dates
of the various tasks and their interdependencies.

This visualisation aids in understanding the project’s flow and identifying potential
bottlenecks.

Additionally, Gantt charts facilitate progress tracking and enable team members to stay on
the same page when shared.

By comparing the planned schedule with the actual progress, project managers can identify
deviations and take corrective actions promptly.

This proactive approach helps to keep the project on track and ensures its timely completion.
Critical Path Method (CPM)
The Critical Path Method (CPM) is another widely used project scheduling technique
in software engineering. It involves identifying the longest sequence of tasks in a
project, known as the critical path. This path determines the shortest possible duration
for the project.

CPM aids in prioritizing tasks. Tasks on the critical path have zero slack time,
meaning any delay in these tasks will delay the entire project.Therefore, these tasks
are given the utmost priority to ensure the project’s timely completion.

Challenges in project scheduling in software engineering

Despite its importance, project scheduling in software engineering is fraught with
challenges.

One of the primary challenges is the estimation of task durations.

Due to the complex and dynamic nature of software development, accurately

estimating the time required for each task can be difficult.

This inaccuracy can lead to schedule overruns and project delays.

Another challenge is the management of task dependencies.

In software engineering, tasks are often interdependent, meaning the start or

completion of one task depends on another.

Managing these dependencies while maintaining the project schedule can be a

daunting task.

Furthermore, resource constraints can pose a challenge to project scheduling.

Limited resources, such as personnel, equipment, and budget, can restrict the project’s
progress and lead to schedule overruns.

Detailed scheduling is used to:

Determine the resources and dates/times for carrying out operations, taking resource
and product availability into consideration

Support the scheduler in scheduling resources, that is, when creating an optimal
processing sequence for operations

The basic detailed scheduling activities are:

Scheduling, that is, dispatching operations to resources at a specific date/time

Rescheduling, that is, dispatching already scheduled operations to a different

date/time or to different resources

Deallocating, that is, removing scheduled operations from the resource schedule.
Features
Controlling Detailed Scheduling
Alongside the desired scheduling date, the basis of detailed scheduling for an order,
for example, are the capacity requirements of the activities. You control which
constraints, rules, and parameters the system must take into account during scheduling
using settings and data in the following objects:
Resource
Source of supply for in-house production (production process model (PPM), iPPE
access object, or production data structure generated from ERP master data)
Dates/Times and Planning Directions
The starting point for scheduling or rescheduling is the desired start or end date/time
of the orders or operations. When you create an order, for example, the availability
date/time of the primary order product defines the desired end date/time. If you
reschedule an operation on the detailed scheduling planning board using Drag&Drop,
for example, the desired date/time is the date/time at which you “let go” the operation.

Effective software project team organization is crucial for project success. Common
structures include hierarchical, chief-programmer, matrix, egoless, and democratic
teams, each with unique benefits and challenges. The right structure depends on
project needs and team dynamics. Choosing the appropriate organization enhances
communication, productivity, and software quality.

Team Structure
Software Project Team Organization
There are many ways to organize the project team. Some important ways are as
follows :

Hierarchical team organization

Chief-programmer team organization
Matrix team, organization
Egoless team organization
Democratic team organization
Hierarchical team organization
In this, the people of the organization at different levels follow a tree structure. People
at the bottom level generally possess the most detailed knowledge about the system.
People at higher levels have a broader appreciation of the whole project.
 Below are some benefits of Hierarchical Team Organization:

It limits the number of communication paths and still allows for the needed
communication.
It can be expanded over multiple levels.
It is well suited for the development of hierarchical software products.
Large software projects may have several levels.
The chief programmer team organization is composed of a small team consisting of
the following team members :

The Chief programmer is the person who is actively involved in the planning,
specification and design process and ideally in the implementation process.
The project assistant is the closest technical co-worker of the chief programmer.
The project secretary relieves the chief programmer and all other programmers of
administration tools.
Specialists: These people select the implementation language, implement individual
system components employ software tools, and carry out tasks.
Advantages of Chief-programmer team organization

Centralized decision-making
Reduced communication paths
Small teams are more productive than large teams
The chief programmer is directly involved in system development and can exercise
better control functions.
Disadvantages of Chief-programmer team organization:

Project survival depends on one person only.

This can cause psychological problems as the “chief programmer” is like the “king”
who takes all the credit and other members are resentful.
Team organization is limited to only a small team and a small team cannot handle
every project.
The effectiveness of the team is very sensitive to the Chief programmer’s technical
and managerial activities.

System Configuration Management (SCM) is a software engineering practice that

focuses on managing the configuration of software systems and ensuring that software
components are properly controlled, tracked, and stored. It is a critical aspect of
software development, as it helps to ensure that changes made to a software system
are properly coordinated and that the system is always in a known and stable state.
SCM involves a set of processes and tools that help to manage the different
components of a software system, including source code, documentation, and other
assets. It enables teams to track changes made to the software system, identify when
and why changes were made, and manage the integration of these changes into the
final product. SCM involves a set of processes and tools that help to manage the
different components of a software system, including source code, documentation,
and other assets. It enables teams to track changes made to the software system,
identify when and why changes were made, and manage the integration of these
changes into the final product.
Processes involved in SCM – Configuration management provides a disciplined
environment for smooth control of work products. It involves the following activities:

1-Identification and Establishment – Identifying the configuration items from

products that compose baselines at given points in time (a baseline is a set of mutually
consistent Configuration Items, which has been formally reviewed and agreed upon,
and serves as the basis of further development). Establishing relationships among
items, creating a mechanism to manage multiple levels of control and procedure for
the change management system.
2-Version control – Creating versions/specifications of the existing product to build
new products with the help of the SCM system. A description of the version is given
below:
Suppose after some changes, the version of the configuration object changes from 1.0
to 1.1. Minor corrections and changes result in versions 1.1.1 and 1.1.2, which is
followed by a major update that is object 1.2. The development of object 1.0 continues
through 1.3 and 1.4, but finally, a noteworthy change to the object results in a new
evolutionary path, version 2.0. Both versions are currently supported.
3-Change control – Controlling changes to Configuration items (CI). The change
control process is explained in Figure below:

change request (CR) is submitted and evaluated to assess technical merit, potential
side effects, the overall impact on other configuration objects and system functions,
and the projected cost of the change. The results of the evaluation are presented as a
change report, which is used by a change control board (CCB) —a person or group
who makes a final decision on the status and priority of the change. An engineering
change Request (ECR) is generated for each approved change. Also, CCB notifies the
developer in case the change is rejected with proper reason. The ECR describes the
change to be made, the constraints that must be respected, and the criteria for review
and audit. The object to be changed is “checked out” of the project database, the
change is made, and then the object is tested again. The object is then “checked in”
to the database and appropriate version control mechanisms are used to create the next
version of the software.
4-Configuration auditing – A software configuration audit complements the formal
technical review of the process and product. It focuses on the technical correctness of
the configuration object that has been modified. The audit confirms the completeness,
correctness, and consistency of items in the SCM system and tracks action items from
the audit to closure.
Why need for System configuration management?
1-Replicability: Software version control (SCM) makes ensures that a software
system can be replicated at any stage of its development. This is necessary for testing,
2-debugging, and upholding consistent environments in production, testing, and
development.
3-Identification of Configuration: Source code, documentation, and executable files
are examples of configuration elements that SCM helps in locating and labeling. The
management of a system’s constituent parts and their interactions depend on this
identification.
4-Effective Process of Development: By automating monotonous processes like
managing dependencies, merging changes, and resolving disputes, SCM simplifies
the development process. Error risk is decreased and efficiency is increased because
of this automation.
The main advantages of SCM
1-Improved productivity and efficiency by reducing the time and effort required to
manage software changes.
2-Reduced risk of errors and defects by ensuring that all changes were properly tested
and validated.
3-Increased collaboration and communication among team members by providing a
central repository for software artifacts.
4-Improved quality and stability of software systems by ensuring that all changes are
properly controlled and managed.
The main disadvantages of SCM
1-Increased complexity and overhead, particularly in large software systems.
Difficulty in managing dependencies and ensuring that all changes are properly
integrated.
2Potential for conflicts and delays, particularly in large development teams with
multiple contributors.

Risk Management is a systematic process of recognizing, evaluating, and handling

threats or risks that have an effect on the finances, capital, and overall operations of
an organization. These risks can come from different areas, such as financial
instability, legal issues, errors in strategic planning, accidents, and natural disasters.
A risk is a probable problem; it might happen, or it might not. There are main two
characteristics of risk.

Uncertainty: the risk may or may not happen which means there are no 100% risks.
Loss: If the risk occurs in reality, undesirable results or losses will occur.
The risk management process
Risk management is a sequence of steps that help a software team to understand,
analyze, and manage uncertainty. Risk management process consists of

Risks Identification.
Risk Assessment.
Risks Planning.
Risk Monitoring

Risk Identification: Risk identification refers to the systematic process of

recognizing and evaluating potential threats or hazards that could negatively impact
an organization, its operations, or its workforce. This involves identifying various
types of risks, ranging from IT security threats like viruses and phishing attacks to
unforeseen events such as equipment failures and extreme weather conditions.
Risk analysis: Risk analysis is the process of evaluating and understanding the
potential impact and likelihood of identified risks on an organization. It helps
determine how serious a risk is and how to best manage or mitigate it. Risk Analysis
involves evaluating each risk’s probability and potential consequences to prioritize
and manage them effectively.
Risk Planning: Risk planning involves developing strategies and actions to manage
and mitigate identified risks effectively. It outlines how to respond to potential risks,
including prevention, mitigation, and contingency measures, to protect the
organization’s objectives and assets.
Risk Monitoring: Risk monitoring involves continuously tracking and overseeing
identified risks to assess their status, changes, and effectiveness of mitigation
strategies. It ensures that risks are regularly reviewed and managed to maintain
alignment with organizational objectives and adapt to new developments or
challenges.
Reactive and Proactive RCA :
The main question that arises is whether RCA is reactive or proactive? Some people
think that RCA is only required to solve problems or failures that have already
occurred. But, it’s not true. One should know that RCA can be both i.e. reactive and
proactive as given below –

Reactive RCA :
The main question that arises in reactive RCA is “What went wrong?”. Before
investigating or identifying the root cause of failure or defect, failure needs to be in
place or should be occurred already. One can only identify the root cause and perform
the analysis only when problem or failure had occurred that causes malfunctioning in
the system. Reactive RCA is a root cause analysis that is performed after the
occurrence of failure or defect.
Advantages :Helps one to prioritize tasks according to its severity and then resolve
it. Increases teamwork and their knowledge.
Disadvantages : Sometimes, resolving equipment after failure can be more costly
than preventing failure from an occurrence.
Failed equipment can cause greater damage to system and interrupts production
activities.
Proactive RCA

The main question that arises in proactive RCA is “What could go wrong?”. RCA can
also be used proactively to mitigate failure or risk. The main importance of RCA can
be seen when it is applied to events that have not occurred yet. Proactive RCA is a
root cause analysis that is performed before any occurrence of failure or defect. It is
simply done to control, implemented to prevent defect from its occurrence. As both
reactive and proactive RCAs are is important, one should move from reactive to
proactive RCA.

It is better to prevent issues from its occurrence rather than correcting it after its
occurrence. In simple words, Prevention is better than correction. Here, prevention
action is considered as proactive and corrective action is considered as reactive. It is
also known as proactive risk management. It identifies the root cause of problem to
eliminate it from reoccurring. With help of proactive RCA, we can identify the main
root cause that leads to the occurrence of problem or failure, or defect. After knowing
this, we can take various measures and implement actions to prevent these causes
from the occurrence.

Advantages :
Future chances of failure occurrence can be minimized.
Reduce overall cost required to resolve failure by simply preventing failure from an
occurrence.
Increases overall productivity by minimizing chances of interruption due to failure.
Disadvantages
Sometimes, preventing equipment from failure can be more costly than resolving
failure after occurrence.
Many resources and tools required to prevent failure from an occurrence that can
affect the overall cost.
Requires highly skilled technicians to perform maintenance tasks.

Risk Mitigation, Monitoring, and Management (RMMM) plan

A risk management technique is usually seen in the software Project plan. This can
be divided into Risk Mitigation, Monitoring, and Management Plan (RMMM). In this
plan, all works are done as part of risk analysis. As part of the overall project plan
project manager generally uses this RMMM plan.
1-Risk Mitigation :
It is an activity used to avoid problems (Risk Avoidance). Steps for mitigating the
risks as follows.
Finding out the risk.
i-Removing causes that are the reason for risk creation.
ii-Controlling the corresponding documents from time to time.
iii-Conducting timely reviews to speed up the work.
2-Risk Monitoring :
It is an activity used for project tracking. It has the following primary objectives as
follows.
i-To check if predicted risks occur or not.
ii-To ensure proper application of risk aversion steps defined for risk.
iii-To collect data for future risk analysis.
iv-To allocate what problems are caused by which risks throughout the project.
3-Risk Management and planning :
It assumes that the mitigation activity failed and the risk is a reality. This task is done
by Project manager when risk becomes reality and causes severe problems. If the
project manager effectively uses project mitigation to remove risks successfully then
it is easier to manage the risks. This shows that the response that will be taken for
each risk by a manager. The main objective of the risk management plan is the risk
register. This risk register describes and focuses on the predicted threats to a software
project.
Example: Let us understand RMMM with the help of an example of high staff
turnover.
Risk Mitigation:
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.
Drawbacks of RMMM:
It incurs additional project costs.
It takes additional time.
For larger projects, implementing an RMMM may itself turn out to be another tedious
project.
RMMM does not guarantee a risk-free project, infact, risks may also come up after
the project is delivered.