Se Unit Iii

UNIT- III
Software Project Management (SPM)- Project Management Process, Project size

estimation techniques, System Configuration Management (SCM), COCOMO
Model, Capability Maturity Model (CMM), Risk Management in SDLC, Role and
Responsibility of a Software Project Manager, Software Maintenance.
Software Design- Abstraction, Architecture, Patterns, Modularity, Information
Hiding, Functional Independence- Cohesion & Coupling, Object Oriented Design-
Data Design, Architectural Design, UserInterface Design, Component Level Design.
Software Project Management (SPM)

Software Project Management (SPM) is a proper way of planning and leading software projects. It is
a part of project management in which software projects are planned, implemented, monitored, and
controlled. Need for Software Project Management: Software is a non-physical product. Software
development is a new stream in business and there is very little experience in building software
products. Most of the software products are made to fit clients’ requirements. The most important is
that the basic technology changes and advances so frequently and rapidly that experience of one
product may not be applied to the other one. Such type of business and environmental constraints
increase risk in software development hence it is essential to manage software projects efficiently. It is
necessary for an organization to deliver quality products, keep the cost within the client’s budget
constrain and deliver the project as per schedule. Hence in order, software project management is
necessary to incorporate user requirements along with budget and time constraints.
Software Project Management consists of Several Different Types of Management:
1. Conflict Management: Conflict management is the process to restrict the negative features of
conflict while increasing the positive features of conflict. The goal of conflict management is to
improve learning and group results including efficacy or performance in an organizational setting.
Properly managed conflict can enhance group results.
2. Risk Management: Risk management is the analysis and identification of risks that is followed
by synchronized and economical implementation of resources to minimize, operate and control the
possibility or effect of unfortunate events or to maximize the realization of opportunities.
3. Requirement Management: It is the process of analyzing, prioritizing, tracking, and
documenting requirements and then supervising change and communicating to pertinent
stakeholders. It is a continuous process during a project.
4. Change Management: Change management is a systematic approach for dealing with the
transition or transformation of an organization’s goals, processes, or technologies. The purpose of
1
Software Engineering (R15)
change management is to execute strategies for effecting change, controlling change, and helping
people to adapt to change.
5. Software Configuration Management: Software configuration management is the process of
controlling and tracking changes in the software, part of the larger cross-disciplinary field of
configuration management. Software configuration management includes revision control and the
inauguration of baselines.
6. Release Management: Release Management is the task of planning, controlling, and
scheduling the build-in deploying releases. Release management ensures that the organization
delivers new and enhanced services required by the customer while protecting the integrity of
existing services.
Aspects of Software Project Management:
The list of focus areas it can tackle and the broad upsides of the Software Project. Management are:
1. Planning: The software project manager lays out the complete project’s blueprint. The
project plan will outline the scope, resources, timelines, techniques, strategy,
communication, testing, and maintenance steps. SPM can aid greatly here.
2. Leading: A software project manager brings together and leads a team of engineers, strategists,
programmers, designers, and data scientists. Leading a team necessitates exceptional
communication, interpersonal, and leadership abilities. One can only hope to do this effectively if
one sticks with the core SPM principles.
3. Execution: SPM comes to the rescue here also as the person in charge of software projects (if
well versed with SPM/Agile methodologies) will ensure that each stage of the project is completed
successfully. measuring progress, monitoring to check how teams function, and generating status
reports are all part of this process.
4. Time management: Abiding by a timeline is crucial to completing deliverables successfully.
This is especially difficult when managing software projects because changes to the original project
charter are unavoidable over time. To assure progress in the face of blockages or changes, software
project managers ought to be specialists in managing risk and emergency preparedness. This Risk
Mitigation and
management is one of the core tents of the philosophy of SPM.
5. Budget: Software project managers, like conventional project managers, are responsible
for generating a project budget and adhering to it as closely as feasible, regulating spending
and reassigning funds as needed. SPM teaches us how to effectively manage the monetary
aspect of projects to avoid running into a financial crunch later on in the project.
6. Maintenance: Software project management emphasizes continuous product testing to find and
repair defects early, tailor the end product to the needs of the client, and keep the project on track.
The software project manager makes ensuring that the product is thoroughly tested, analyzed, and
adjusted as needed. Another point in favour of SPM.
2
Downsides of Software Project Management:
Numerous issues can develop if a Software project manager lacks the necessary expertise or knowledge.
Software Project management has several drawbacks, including resource loss, scheduling difficulty,
data protection concerns, and interpersonal conflicts between Developers/Engineers/Stakeholders.
Furthermore, outsourcing work or recruiting additional personnel to complete the project may result in
hefty costs for one’s company.
1. Costs are high: Consider spending money on various kinds of project management tools,
software, & services if ones engage in Software Project Management strategies. These initiatives
can be expensive and time-consuming to put in place. Because your team will be using them as well,
they may require training. One may need to recruit subject matter experts or specialists to assist
with a project, depending on the circumstances. Stakeholders will frequently press for the inclusion
of features that were not originally envisioned. All of these factors can quickly drive up a project’s
cost.
2. Complexity will be increased: Software Project management is a multi-stage, complex
process. Unfortunately, some specialists might have a propensity to over complicate everything,
which can lead to confusion among teams and lead to delays in project completion. They may also
become dogmatic and specific in their ideas, resulting in a difficult work atmosphere. Projects
having a larger scope are typically more arduous to complete, especially if there isn’t a dedicated
team committed completely to the project. Members of cross-functional teams may lag far
behind their daily tasks, adding to the overall complexity of the project being worked on.
3. Overhead in Communication: Recruits enter your organisation when we hire software project
management personnel. This provides a steady flow of communication that may or may not match a
company’s culture. As a result, it is advised that you maintain your crew as
small as feasible. The communication overhead tends to skyrocket when a team becomes large
3
enough. When a large team is needed for a project, it’s critical to identify software project
managers who can conduct effective communication with a variety of people.
4. Lack of originality: Software Project managers can sometimes provide little or no space
for creativity. Team leaders either place an excessive amount of emphasis on
management processes or impose hard deadlines on their employees, requiring them to develop and
operate code within stringent guidelines. This can stifle innovative thought and innovation that
could be beneficial to the project. When it comes to Software project management, knowing when
to encourage creativity and when to stick to the project plan is crucial. Without Software project
management personnel, an organization can perhaps build and ship code more quickly. However,
employing a trained specialist to handle these areas, on the other hand, can open up new doors and
help the organisation achieve its objectives more
quickly and more thoroughly.
Project Management Process

Project Management is a discipline about planning, monitoring, and controlling software projects,
identifying the scope, estimating the work involved, and creating a project schedule. Along with it is
also responsible to keep the team up to date on the project’s progress and handle problems and discuss
solutions.
The Project Management Process consists of the following 4 stages:
 Feasibility study
 Project Planning
 Project Execution
 Project Termination
Feasibility Study: A feasibility study explores system requirements to determine project feasibility.
There are several fields of feasibility study including economic feasibility, operational feasibility, and
technical feasibility. The goal is to determine whether the system can be implemented or not. The
process of feasibility study takes as input the required details as specified by the user and other
domain-specific details. The output of this process simply tells whether the project should be
4
undertaken or not and if yes, what would the constraints be. Additionally, all the risks and their
potential effects on the projects are also evaluated before a decision to start the project is taken.
Project Planning: A detailed plan stating a stepwise strategy to achieve the listed objectives is an
integral part of any project. Planning consists of the following activities:
 Set objectives or goals
 Develop strategies
 Develop project policies
 Determine courses of action
 Making planning decisions
 Set procedures and rules for the project
 Develop a software project plan
 Prepare budget
 Conduct risk management
 Document software project plans
This step also involves the construction of a work breakdown structure(WBS). It also includes size,
effort, schedule, and cost estimation using various techniques.
Principles of effective project planning:
Project should be effective so that the project begins with well-defined tasks. Effective project planning
helps to minimize the additional costs incurred on the project while it is in progress.
1. Planning is necessary: Planning should be done before a project begins.
2. Risk analysis: Before starting the project, senior management and the project management team
should consider the risks that may affect the project.
3. Tracking of project plan: Once the project plan is prepared, it should be tracked and modified
accordingly.
4. Most quality standards and produce quality deliverable: The project plan should identify
processes by which the project management team can ensure quality in software.
5. Description of flexibility to accommodate changes: The result of project planning is recorded in
the form of a project plan, which should allow new changes to be accommodated when the project
is in progress
Project Execution: A project is executed by choosing an appropriate software development lifecycle
model(SDLC). It includes a number of steps including requirements analysis, design, coding, testing
and implementation, testing, delivery, and maintenance. There are a number of factors that need to be
considered while doing so including the size of the system, the nature of the project, time and budget
constraints, domain requirements, etc. An inappropriate SDLC can lead to the failure of the project.
Project Termination: There can be several reasons for the termination of a project. Though expecting
a project to terminate after successful completion is conventional, at times, a project may also
terminate without completion. Projects have to be closed down when the requirements are not fulfilled
according to given time and cost constraints.
Some of the reasons for failure include:
 Fast-changing technology
 Project running out of time
5
 Organizational politics
 Too much change in customer requirements
 Project exceeding budget or funds
Once the project is terminated, a post-performance analysis is done. Also, a final report is published
describing the experiences, lessons learned, and recommendations for handling future projects.
Project management is a systematic approach to planning, organizing, and controlling the resources
required to achieve specific project goals and objectives. The project management process involves a
set of activities that are performed to plan, execute, and close a project. The project management
process can be divided into several phases, each of which has a specific purpose and set of tasks.
The main phases of the project management process are:
1. Initiation: This phase involves defining the project, identifying the stakeholders, and
establishing the project’s goals and objectives.
2. Planning: In this phase, the project manager defines the scope of the project, develops a detailed
project plan, and identifies the resources required to complete the project.
3. Execution: This phase involves the actual implementation of the project, including the
allocation of resources, the execution of tasks, and the monitoring and control of project progress.
4. Monitoring and Control: This phase involves tracking the project’s progress, comparing actual
results to the project plan, and making changes to the project as necessary.
5. Closing: This phase involves completing the project, documenting the results, and closing out
any open issues.
6. Effective project management requires a clear understanding of the project management process
and the skills necessary to apply it effectively. The project manager must have the ability to plan
and execute projects, manage resources, communicate effectively, and handle risks and issues.
Advantages of the project management process:
1. Provides a structured approach to managing projects.

2. Helps to define project objectives and requirements.
3. Facilitates effective communication and collaboration among team members.
4. Helps to manage project risks and issues.
5. Ensures that the project is delivered on time and within budget.
Disadvantages of the project management process:
1. Can be time-consuming and bureaucratic

2. May be inflexible and less adaptable to changes
3. Requires a skilled project manager to implement effectively
4. May not be suitable for small or simple projects.
Responsibilities of software project manager:
-Proper project management is essential for the successful completion of a software project and the
person who is responsible for it is called project manager.
6
-To do his job effectively, the project manager must have certain set of skills. This section discusses
both the job responsibilities of project manager and the skills required by him.
Job Responsibilities :
-Involves with the senior managers in the process of appointing team members.
-Builds the project team and assigns tasks to various team members.
-Responsible for effective project planning and scheduling, project monitoring and control activities in
order to achieve the project objectives.
-Acts as a communicator between the senior management and the other persons involved in the project
like the development team and internal and external stakeholders.
-Effectively resolves issues that arise between the team members by changing their roles and
responsibilities.
-Modifies the project plan(if required)to deal with the situation.
Project size estimation

Project size estimation is a crucial aspect of software engineering, as it helps in planning and allocating
resources for the project. Here are some of the popular project size estimation techniques used in
software engineering:
Expert Judgment: In this technique, a group of experts in the relevant field estimates the project size
based on their experience and expertise. This technique is often used when there is limited information
available about the project.
Analogous Estimation: This technique involves estimating the project size based on the similarities
between the current project and previously completed projects. This technique is useful when historical
data is available for similar projects.
Bottom-up Estimation: In this technique, the project is divided into smaller modules or tasks, and
each task is estimated separately. The estimates are then aggregated to arrive at the overall project
estimate.
Three-point Estimation: This technique involves estimating the project size using three values:
optimistic, pessimistic, and most likely. These values are then used to calculate the expected project
size using a formula such as the PERT formula.
Function Points: This technique involves estimating the project size based on the functionality
provided by the software. Function points consider factors such as inputs, outputs, inquiries, and files
to arrive at the project size estimate.
7
Use Case Points: This technique involves estimating the project size based on the number of use cases
that the software must support. Use case points consider factors such as the complexity of each use
case, the number of actors involved, and the number of use cases.
Each of these techniques has its strengths and weaknesses, and the choice of technique depends on
various factors such as the project’s complexity, available data, and the expertise of the team.
Estimation of the size of the software is an essential part of Software Project Management. It helps the
project manager to further predict the effort and time which will be needed to build the project. Various
measures are used in project size estimation. Some of these are:
 Lines of Code
 Number of entities in ER diagram
 Total number of processes in detailed data flow diagram
 Function points
1. Lines of Code (LOC): As the name suggests, LOC counts the total number of lines of source code
in a project. The units of LOC are:
 KLOC- Thousand lines of code
 NLOC- Non-comment lines of code
 KDSI- Thousands of delivered source instruction
The size is estimated by comparing it with the existing systems of the same kind. The experts use it to
predict the required size of various components of software and then add them to get the total size.
It’s tough to estimate LOC by analyzing the problem definition. Only after the whole code has been
developed can accurate LOC be estimated. This statistic is of little utility to project managers because
project planning must be completed before development activity can begin.
Two separate source files having a similar number of lines may not require the same effort. A file with
complicated logic would take longer to create than one with simple logic. Proper estimation may not be
attainable based on LOC.
The length of time it takes to solve an issue is measured in LOC. This statistic will differ greatly from
one programmer to the next. A seasoned programmer can write the same logic in fewer lines than a
newbie coder.
Advantages:
 Universally accepted and is used in many models like COCOMO.
 Estimation is closer to the developer’s perspective.
 Both people throughout the world utilize and accept it.
 At project completion, LOC is easily quantified.
 It has a specific connection to the result.
 Simple to use.
Disadvantages:
 Different programming languages contain a different number of lines.
 No proper industry standard exists for this technique.
 It is difficult to estimate the size using this technique in the early stages of the project.
 When platforms and languages are different, LOC cannot be used to normalize.
8
2. Number of entities in ER diagram: ER model provides a static view of the project. It describes the
entities and their relationships. The number of entities in ER model can be used to measure the
estimation of the size of the project. The number of entities depends on the size of the project. This is
because more entities needed more classes/structures thus leading to more coding.
Advantages:
 Size estimation can be done during the initial stages of planning.
 The number of entities is independent of the programming technologies used.
Disadvantages:
 No fixed standards exist. Some entities contribute more to project size than others.
 Just like FPA, it is less used in the cost estimation model. Hence, it must be converted to LOC.
3. Total number of processes in detailed data flow diagram: Data Flow Diagram(DFD) represents
the functional view of software. The model depicts the main processes/functions involved in software
and the flow of data between them. Utilization of the number of functions in DFD to predict software
size. Already existing processes of similar type are studied and used to estimate the size of the process.
Sum of the estimated size of each process gives the final estimated size.
Advantages:
 It is independent of the programming language.
 Each major process can be decomposed into smaller processes. This will increase the accuracy
of the estimation
Disadvantages:
 Studying similar kinds of processes to estimate size takes additional time and effort.
 All software projects are not required for the construction of DFD.
4. Function Point Analysis: In this method, the number and type of functions supported by the
software are utilized to find FPC(function point count). The steps in function point analysis are:
 Count the number of functions of each proposed type.
 Compute the Unadjusted Function Points(UFP).
 Find the Total Degree of Influence(TDI).
 Compute Value Adjustment Factor(VAF).
 Find the Function Point Count(FPC).
The explanation of the above points is given below:
 Count the number of functions of each proposed type: Find the number of functions
belonging to the following types:
 External Inputs: Functions related to data entering the system.
 External outputs: Functions related to data exiting the system.
 External Inquiries: They lead to data retrieval from the system but don’t change the
system.
 Internal Files: Logical files maintained within the system. Log files are not included here.
 External interface Files: These are logical files for other applications which are used by
our system.
 Compute the Unadjusted Function Points(UFP): Categorise each of the five function types
like simple, average, or complex based on their complexity. Multiply the count of each function
9
type with its weighting factor and find the weighted sum. The weighting factors for each type based
on their complexity are as follows:
Function type Simple Average Complex
External Inputs 3 4 6
External Output 4 5 7
External Inquiries 3 4 6
Internal Logical Files 7 10 15
External Interface Files 5 7 10
 Find Total Degree of Influence: Use the ’14 general characteristics’ of a system to find the
degree of influence of each of them. The sum of all 14 degrees of influence will give the TDI. The
range of TDI is 0 to 70. The 14 general characteristics are: Data Communications, Distributed Data
Processing, Performance, Heavily Used Configuration, Transaction Rate, On-Line Data Entry, End-
user Efficiency, Online Update, Complex Processing Reusability, Installation Ease, Operational
Ease, Multiple Sites and Facilitate Change.
Each of the above characteristics is evaluated on a scale of 0-5.
 Compute Value Adjustment Factor(VAF): Use the following formula to calculate VAF
VAF = (TDI * 0.01) + 0.65
 Find the Function Point Count: Use the following formula to calculate FPC
FPC = UFP * VAF
Advantages:
 It can be easily used in the early stages of project planning.
 It is independent of the programming language.
 It can be used to compare different projects even if they use different technologies(database,
language, etc).
Disadvantages:
 It is not good for real-time systems and embedded systems.
 Many cost estimation models like COCOMO use LOC and hence FPC must be converted to
LOC.
System configuration management

Whenever a software is build, there is always scope for improvement and those improvements brings
changes in picture. Changes may be required to modify or update any existing solution or to create a
new solution for a problem. Requirements keeps on changing on daily basis and so we need to keep on
upgrading our systems based on the current requirements and needs to meet desired outputs. Changes
10
should be analyzed before they are made to the existing system, recorded before they are implemented,
reported to have details of before and after, and controlled in a manner that will improve quality and
reduce error. This is where the need of System Configuration Management comes. 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. It is essential to control the
changes in light of the fact that if the changes are not checked legitimately then they may wind up
undermining a well-run programming. In this way, SCM is a fundamental piece of all project
management activities. 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 relationship among items, creating a mechanism to manage multiple
level of control and procedure for change management system.
2. Version control – Creating versions/specifications of the existing product to build new products
from the help of SCM system. A description of version is given
below: Suppose after some

changes, the version of 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
11
below: A
change request (CR) is submitted and evaluated to assess technical merit, potential side effects,
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 track action items from the audit to closure.
5. Reporting – Providing accurate status and current configuration data to developers, tester, end
users, customers and stakeholders through admin guides, user guides, FAQs, Release notes, Memos,
Installation Guide, Configuration guide etc .
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.
12
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.
The key objectives of SCM are to:
1. Control the evolution of software systems: SCM helps to ensure that changes to a software
system are properly planned, tested, and integrated into the final product.
2. Enable collaboration and coordination: SCM helps teams to collaborate and coordinate their
work, ensuring that changes are properly integrated and that everyone is working from the same
version of the software system.
3. Provide version control: SCM provides version control for software systems, enabling teams to
manage and track different versions of the system and to revert to earlier versions if necessary.
4. Facilitate replication and distribution: SCM helps to ensure that software systems can be easily
replicated and distributed to other environments, such as test, production, and customer sites.
5. SCM is a critical component of software development, and effective SCM practices can help to
improve the quality and reliability of software systems, as well as increase efficiency and reduce
the risk of errors.
The main advantages of SCM are:
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 are 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 are:
1. Increased complexity and overhead, particularly in large software systems.

2. Difficulty in managing dependencies and ensuring that all changes are properly integrated.
3. Potential for conflicts and delays, particularly in large development teams with multiple
contributors.
COCOMO Model
Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e number of Lines of Code.
It 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.
13
The key parameters which define the quality of any software products, which are also an outcome of
the Cocomo are primarily Effort & Schedule:
 Effort: Amount of labor that will be required to complete a task. It is measured in person-
months units.
 Schedule: 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.
Different models of Cocomo have been proposed to predict the cost estimation at different levels,
based on the amount of accuracy and correctness required. All of these models can be applied to a
variety of projects, whose characteristics determine the value of the constant to be used in subsequent
calculations.
These characteristics pertaining to different system types are mentioned below. Boehm’s definition of
organic, semidetached, and embedded systems:
1. 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.
2. 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 environment lie in between
that of 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 and better
guidance and creativity. Eg: Compilers or different Embedded Systems can be considered Semi-
Detached types.
3. Embedded – A software project requiring the highest level of complexity, creativity, and experience
requirement fall 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.
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model
1. Basic Model –
The above formula is used for the cost estimation of for the basic COCOMO model, and also is used in
the subsequent models. The constant values a,b,c, and d for the Basic Model for the different categories
of the system:
Software Projects a b c d
14
Software Projects a b c d
Organic 2.4 1.05 2.5 0.38
Semi-Detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
The effort is measured in Person-Months and as evident from the formula is dependent on Kilo-Lines
of code. The development time is measured in months. These formulas are used as such in the Basic
Model calculations, as not much consideration of different factors such as reliability, and expertise is
taken into account, henceforth the estimate is rough.
Capability maturity model (CMM)

CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in
1987.
 It is not a software process model. It is a framework that is used to analyze the approach and
techniques followed by any organization to develop software products.
 It also provides guidelines to further enhance the maturity of the process used to develop those
software products.
 It is based on profound feedback and development practices adopted by the most successful
organizations worldwide.
 This model describes a strategy for software process improvement that should be followed by
moving through 5 different levels.
 Each level of maturity shows a process capability level. All the levels except level-1 are further
described by Key Process Areas (KPA’s).
People-CMM is based on several principles, which are listed below:
 People capability is a competitive issue. Competition arises when different organizations are
performing the same task(such as software development). In such a case, the people of an
organization are sources of strategy and skills, which in turn results in better performance of the
organization.
 The people capability should be defined in relation to the business objectives of the organization.
 An organization should invest in improving the capabilities and skills of the people as they are
important for its success.
 The management should be responsible for enhancing the capability of the people in the
organization.
 The improvement in the capability of people should be done as a process. This process should
incorporate appropriate practices and procedures.
 The organization should be responsible for providing improvement opportunities so that people
in the organization can take advantage of them.
15
 Since, new technologies and organizational practices emerge rapidly, the organizations should
continually improve their practices and develop the abilities of people.
Shortcomings of SEI/CMM:
 It encourages the achievement of a higher maturity level in some cases by displacing the true
mission, which is improving the process and overall software quality.
 It only helps if it is put into place early in the software development process.
 It has no formal theoretical basis and in fact is based on the experience of very knowledgeable
people.
 It does not have good empirical support and this same empirical support could also be
constructed to support other models.
 Difficulty in measuring process improvement: The SEI/CMM model may not provide an
accurate measure of process improvement, as it relies on self-assessment by the organization and
may not capture all aspects of the development process.
 Focus on documentation rather than outcomes: The SEI/CMM model may focus too much on
documentation and adherence to procedures, rather than on actual outcomes such as software
quality and customer satisfaction.
 May not be suitable for all types of organizations: The SEI/CMM model may not be suitable for
all types of organizations, particularly those with smaller development teams or those with less
structured development processes.
 May not keep up with rapidly evolving technologies: The SEI/CMM model may not be able to
keep up with rapidly evolving technologies and development methodologies, which could limit its
usefulness in certain contexts.
 Lack of agility: The SEI/CMM model may not be agile enough to respond quickly to changing
business needs or customer requirements, which could limit its usefulness in dynamic and rapidly
changing environments.
Key Process Areas (KPA’s): Each of these KPA’s defines the basic requirements that should be met
by a software process in order to satisfy the KPA and achieve that level of maturity.
Conceptually, key process areas form the basis for management control of the software project and
establish a context in which technical methods are applied, work products like models, documents, data,
reports, etc. are produced, milestones are established, quality is ensured and change is properly
managed.
16
The 5 levels of CMM are as follows:
Level-1: Initial –
 No KPA’s defined.
 Processes followed are Adhoc and immature and are not well defined.
 Unstable environment for software development.
 No basis for predicting product quality, time for completion, etc.
 Limited project management capabilities, such as no systematic tracking of schedules, budgets,
or progress.
 Limited communication and coordination among team members and stakeholders.
 No formal training or orientation for new team members.
 Little or no use of software development tools or automation.
 Highly dependent on individual skills and knowledge rather than standardized processes.
 High risk of project failure or delays due to lack of process control and stability.
Level-2: Repeatable –
 Focuses on establishing basic project management policies.
 Experience with earlier projects is used for managing new similar natured projects.
17
 Project Planning- It includes defining resources required, goals, constraints, etc. for the project.
It presents a detailed plan to be followed systematically for the successful completion of good
quality software.
 Configuration Management- The focus is on maintaining the performance of the software
product, including all its components, for the entire lifecycle.
 Requirements Management- It includes the management of customer reviews and feedback
which result in some changes in the requirement set. It also consists of accommodation of those
modified requirements.
 Subcontract Management- It focuses on the effective management of qualified software
contractors i.e. it manages the parts of the software which are developed by third parties.
 Software Quality Assurance- It guarantees a good quality software product by following
certain rules and quality standard guidelines while developing.
Level-3: Defined –
 At this level, documentation of the standard guidelines and procedures takes place.
 It is a well-defined integrated set of project-specific software engineering and management
processes.
 Peer Reviews- In this method, defects are removed by using a number of review methods like
walkthroughs, inspections, buddy checks, etc.
 Intergroup Coordination- It consists of planned interactions between different development
teams to ensure efficient and proper fulfillment of customer needs.
 Organization Process Definition- Its key focus is on the development and maintenance of the
standard development processes.
 Organization Process Focus- It includes activities and practices that should be followed to
improve the process capabilities of an organization.
 Training Programs- It focuses on the enhancement of knowledge and skills of the team
members including the developers and ensuring an increase in work efficiency.
Level-4: Managed –
 At this stage, quantitative quality goals are set for the organization for software products as well
as software processes.
 The measurements made help the organization to predict the product and process quality within
some limits defined quantitatively.
 Software Quality Management- It includes the establishment of plans and strategies to
develop quantitative analysis and understanding of the product’s quality.
 Quantitative Management- It focuses on controlling the project performance in a quantitative
manner.
Level-5: Optimizing –
 This is the highest level of process maturity in CMM and focuses on continuous process
improvement in the organization using quantitative feedback.
 Use of new tools, techniques, and evaluation of software processes is done to prevent recurrence
of known defects.
 Process Change Management- Its focus is on the continuous improvement of the
organization’s software processes to improve productivity, quality, and cycle time for the software
product.
18
 Technology Change Management- It consists of the identification and use of new technologies
to improve product quality and decrease product development time.
 Defect Prevention- It focuses on the identification of causes of defects and prevents them from
recurring in future projects by improving project-defined processes.
Integrating Risk Management in SDLC

The Software Development Life Cycle (SDLC) is a conceptual model for defining the tasks
performed at each step of the software development process. This model gives you a brief about the life
cycle of Software in the development phase. In this particular article, we are going to discuss risk
management in each and every step of the SDLC Model.
Steps in SDLC Model

Though there are various models for SDLC, in general, SDLC (Software Development Life Cycle)
comprises of following steps:
 Preliminary Analysis
 System Analysis and Requirement Definition
 System Design
 Development
 Integration and System Testing
 Installation, Operation, and Acceptance Testing
 Maintenance
 Disposal
We will be discussing these steps in brief and how risk assessment and management are incorporated
into these steps to ensure less risk in the software being developed.
1. Preliminary Analysis
In this step, you need to find out the organization’s objective

 Nature and scope of problem under study
 Propose alternative solutions and proposals after having a deep understanding of the problem
and what competitors are doing
 Describe costs and benefits.
Support from Risk Management Activities: Below mentioned is the support from the activities of
Risk Management.
 Establish a process and responsibilities for risk management
 Document Initial known risks
 The Project Manager should prioritize the risks
2. System Analysis and Requirement Definition
This step is very important for a clear understanding of customer expectations and requirements. Thus
it is very important to conduct this phase with utmost care and given due time as any possible error will
19
cause the failure of the entire process. Following are the series of steps that are conducted during this
stage.
 End-user requirements are obtained through documentation, client interviews, observation, and
questionnaires
 Pros and cons of the current system are identified so as to avoid the cons and carry forward the
pros in the new system.
 Any Specific user proposals are used to prepare the specifications and solutions for the
shortcomings discovered in step two are found.
 Identify assets that need to be protected and assign their criticality in terms of confidentiality,
integrity, and availability.
 Identify threats and resulting risks to those assets.
 Determine existing security controls to reduce that risks.
Feasibility Study: This is the first and most important phase. Often this phase is conducted as a
standalone phase in big projects not as a sub-phase under the requirement definition phase. This phase
allows the team to get an estimate of major risk factors cost and time for a given project. You might be
wondering why this is so important. A feasibility study helps us to get an idea of whether it is worth
constructing the system or not. It helps to identify the main risk factors.
Risk Factors: Following is the list of risk factors for the feasibility study phase.
 Project managers often make a mistake in estimating the cost, time, resources, and scope of the
project. Unrealistic budget, time, inadequate resources, and unclear scope often lead to project
failure.
 Unrealistic Budget: As discussed above inaccurate estimation of the budget may lead to the
project running out of funds early in the SDLC. An accurate estimation budget is directly related to
correct knowledge of time, effort, and resources.
 Unrealistic Schedule: Incorrect time estimation lead to a burden on developers by project
managers to deliver the project on time. Thus compromising the overall quality of the project and
thus making the system less secure and more vulnerable.
 Insufficient resources: In some cases, the technology, and tools available are not up-to-date to
meet project requirements, or resources(people, tools, technology) available are not enough to
complete the project. In any case, it is the project will get delayed, or in the worst case it may lead
to project failure.
 Unclear project scope: Clear understanding of what the project is supposed to do, which
functionalities are important, which functionalities are mandatory, and which functionalities can be
considered as extra is very important for project managers. Insufficient knowledge of the system
may lead to project failure.
Requirement Elicitation: It starts with an analysis of the application domain. This phase requires the
participation of different stakeholders to ensure efficient, correct, and complete gathering of system
services, their performance, and constraints. This data set is then reviewed and articulated to make it
ready for the next phase.
Risk Factors: Following is the list of risk factors for the Requirement Elicitation phase.
 Incomplete requirements: In 60% of the cases users are unable to state all requirements in the
beginning. Therefore requirements have the most dynamic nature in the complete SDLC (Software
20
Development Life Cycle) Process. If any of the user needs, constraints, or other functional/non-
functional requirements are not covered then the requirement set is said to be incomplete.
 Inaccurate requirements: If the requirement set does not reflect real user needs then in that
case requirements are said to be inaccurate.
 Unclear requirements: Often in the process of SDLC there exists a communication gap
between users and developers. This ultimately affects the requirement set. If the requirements stated
by users are not understandable by analysts and developers then these requirements are said to be
unclear.
 Ignoring nonfunctional requirements: Sometimes developers and analysts ignore the fact that
nonfunctional requirements hold equal importance as functional requirements. In this confusion,
they focus on delivering what the system should do rather than how the system should be like
scalability, maintainability, testability, etc.
 Conflicting user requirements: Multiple users in a system may have different requirements. If
not listed and analyzed carefully, this may lead to inconsistency in the requirements.
 Gold plating: It is very important to list out all requirements in the beginning. Adding
requirements later during development may lead to threats in the system. Gold plating is nothing
but adding extra functionality to the system that was not considered earlier. Thus inviting threats
and making the system vulnerable.
 Unclear description of real operating environment: Insufficient knowledge of real operating
environment leads to certain missed vulnerabilities thus threats remain undetected until a later stage
of the software development life cycle.
Requirement Analysis Activity: In this step requirements that are gathered by interviewing users or
brainstorming or by another means will be: first analyzed and then classified and organized such as
functional and nonfunctional requirements groups and then these are prioritized to get a better
knowledge of which requirements are of high priority and need to be definitely present in the system.
After all these steps requirements are negotiated.
Risk Factors: Risk management in this Requirement Analysis Activity step has the following task to
do.
 Nonverifiable requirements: If a finite cost-effective process like testing, inspection, etc is not
available to check whether the software meets the requirement or not then that requirement is said
to be nonverifiable.
 Infeasible requirement: if sufficient resources are not available to successfully implement the
requirement then it is said to be an infeasible requirement.
 Inconsistent requirement: If a requirement contradicts any other requirement then the
requirement is said to be inconsistent.
 Nontraceable requirement: It is very important for every requirement to have an origin source.
During documentation, it is necessary to write the origin source of each requirement so that it can
be traced back in the future when required.
 Unrealistic requirement: If a requirement meets all the above criteria like it is complete,
accurate, consistent, traceable, verifiable, etc then that requirement is realistic enough to be
documented and implemented.
Requirement Validation Activity: This involves validating the requirements that are gathered and
analyzed till now to check whether they actually define what users want from the system.
Risk Factors: Following is the list of risk factors for the Requirement Validation Activity phase.
21
 Misunderstood domain-specific terminology: Developers and Application specialists often
use domain-specific terminology or we can say technical terms which are not understandable for
the majority of end users. Thus creating a misunderstanding between end users and developers.
 Using natural language to express requirements: Natural language is not always the best way
to express requirements as different users may have different signs and conventions. Thus it is
advisable to use formal language for expressing and documenting.
Requirement Documentation Activity: This step involves creating a Requirement Document (RD) by
writing down all the agreed-upon requirements using formal language. RD serves as a means of
communication between different stakeholders.
Risk Factors: Following is the list of risk factors for the Requirement Documentation Activity phase.
 Inconsistent requirements data and RD: Sometimes it might happen, due to glitches in the
gathering and documentation process, actual requirements may differ from the documented ones.
 Nonmodifiable RD: If during RD preparation, structuring of RD with maintainability is not
considered then it will become difficult to edit the document in the course of change without
rewriting it.
Role and Responsibilities of a software Project

Manager
A software project manager is the most important person inside a team who takes the overall
responsibilities to manage the software projects and plays an important role in the successful
completion of the projects. A project manager has to face many difficult situations to accomplish these
works. In fact, the job responsibilities of a project manager range from invisible activities like building
up team morale to highly visible customer presentations. Most of the managers take responsibility for
writing the project proposal, project cost estimation, scheduling, project staffing, software process
tailoring, project monitoring and control, software configuration management, risk management,
managerial report writing and presentation and interfacing with clients. The task of a project manager
are classified into two major types:
1. Project planning
2. Project monitoring and control
Project planning
Project planning is undertaken immediately after the feasibility study phase and before the starting of
the requirement analysis and specification phase. Once a project has been found to be feasible,
Software project managers started project planning. Project planning is completed before any
development phase starts. Project planning involves estimating several characteristics of a project and
then plan the project activities based on these estimations. Project planning is done with most care and
attention. A wrong estimation can result in schedule slippage. Schedule delay can cause customer
dissatisfaction, which may lead to a project failure. Before starting a software project, it is essential to
determine the tasks to be performed and properly manage allocation of tasks among individuals
involved is the software development .Hence , planning is important as it results in effective software
development . project planning is an organized and integrated management process, which focuses on
activities required for successful completion of the project. It prevents obstacles that arise in the project
such as changes in projects or organizations objectives, non- availability of resources, and so on.
Project planning also helps in better utilization of resources and optimal usage of the allotted time for a
22
project. The other objectives of project planning are listed below. It defines the roles and
responsibilities of the project management team members .It ensures that the project management
team works according to the business objectives. It checks feasibility of the schedule and user
requirements. It determines project constraints- several individuals help in planning the project. These
include senior management and project management team. For effective project planning, in addition
to a very good knowledge of various estimation techniques, past experience is also very important.
During the project planning the project manager performs the following activities:
1. Project Estimation: Project Size Estimation is the most important parameter based on which all
other estimations like cost, duration and effort are made.
 Cost Estimation: Total expenses to develop the software product is estimated.
 Time Estimation: The total time required to complete the project.
 Effort Estimation: The effort needed to complete the project is estimated.
2. Scheduling: After the completion of the estimation of all the project parameters, scheduling for
manpower and other resources is done.
3. Staffing: Team structure and staffing plans are made.
4. Risk Management: The project manager should identify the unanticipated risks that may occur
during project development risk, analyze the damage that might cause these risks, and take a risk
reduction plan to cope with these risks.
5. Miscellaneous plans: This includes making several other plans such as quality assurance plans,
configuration management plans, etc.
 Lead the team: The project manager must be a good leader who makes a team of
different members of various skills and can complete their individual tasks.
 Motivate the team-member: One of the key roles of a software project manager is to
encourage team members to work properly for the successful completion of the project.
 Tracking the progress: The project manager should keep an eye on the progress of the
project. A project manager must track whether the project is going as per plan or not. If any
problem arises, then take the necessary action to solve the problem. Moreover, check whether the
product is developed by maintaining correct coding standards or not.
 Liaison: The project manager is the link between the development team and the
customer. Project manager analysis the customer requirements and convey it to the development
team and keep telling the progress of the project to the customer. Moreover, the project manager
checks whether the project is fulfilling the customer’s requirements or not.
 Monitoring and reviewing: Project monitoring is a continuous process that lasts the
whole time a product is being developed, during which the project manager compares actual
progress and cost reports with anticipated reports as soon as possible. While most firms have a
formal system in place to track progress, qualified project managers may still gain a good
understanding of the project’s development by simply talking with participants.
 Documenting project report: The project manager prepares the documentation of the
project for future purposes. The reports contain detailed features of the product and various
techniques. These reports help to maintain and enhance the quality of the project in the future.
 Reporting: Reporting project status to the customer and his or her organization is the
responsibility of the project manager. Additionally, they could be required to prepare brief, well-
organized pieces that summarise key details from in-depth studies.
 Knowledge of project estimation techniques
 Good decision-making abilities at the right time
23
 Previous experience managing a similar types of projects
 Good communication skills to meet the customer satisfaction
 A project manager must encourage all the team members to successfully develop the product
 He must know the various type of risks that may occur and the solution to these problems
Software Maintenance
Software Maintenance refers to the process of modifying and updating a software system after it has
been delivered to the customer. This can include fixing bugs, adding new features, improving
performance, or updating the software to work with new hardware or software systems. The goal of
software maintenance is to keep the software system working correctly, efficiently, and securely, and
to ensure that it continues to meet the needs of the users.
Software maintenance is a continuous process that occurs throughout the entire life cycle of the
software system. It is important to have a well-defined maintenance process in place, which
includes testing and validation, version control, and communication with stakeholders.
Several Key Aspects of Software Maintenance

 Bug Fixing: The process of finding and fixing errors and problems in the software.
 Enhancements: The process of adding new features or improving existing features to meet the
evolving needs of the users.
 Performance Optimization: The process of improving the speed, efficiency, and reliability of
the software.
 Porting and Migration: The process of adapting the software to run on new hardware or
software platforms.
 Re-Engineering: The process of improving the design and architecture of the software to make
it more maintainable and scalable.
 Documentation: The process of creating, updating, and maintaining the documentation for the
software, including user manuals, technical specifications, and design documents.
Software maintenance is a critical part of the software development life cycle (SDLC) and is necessary
to ensure that the software continues to meet the needs of the users over time. It is also important to
consider the cost and effort required for software maintenance when planning and developing a
software system.
Software maintenance is the process of modifying a software system after it has been delivered to the
customer. The goal of maintenance is to improve the system’s functionality, performance, and
reliability and to adapt it to changing requirements and environments.
Several Types of Software Maintenance

 Corrective Maintenance: This involves fixing errors and bugs in the software system.
 Patching: It is an emergency fix implemented mainly due to pressure from management.
Patching is done for corrective maintenance but it gives rise to unforeseen future errors due to lack
of proper impact analysis.
 Adaptive Maintenance: This involves modifying the software system to adapt it to changes in
the environment, such as changes in hardware or software, government policies, and business rules.
 Perfective Maintenance: This involves improving functionality, performance, and reliability,
and restructuring the software system to improve changeability.
24
 Preventive Maintenance: This involves taking measures to prevent future problems, such as
optimization, updating documentation, reviewing and testing the system, and implementing
preventive measures such as backups.
It’s important to note that software maintenance can be costly and complex, especially for large and
complex systems. Therefore, the cost and effort of maintenance should be taken into account during the
planning and development phases of a software project. It’s also important to have a clear and well-
defined maintenance plan that includes regular maintenance activities, such as testing, backup, and bug
fixing.
Software Maintenance is the process of modifying a software product after it has been delivered to the
customer. The main purpose of software maintenance is to modify and update software applications
after delivery to correct faults and improve performance. Maintenance can be categorized into
proactive and reactive types. Proactive maintenance involves taking preventive measures to avoid
problems from occurring, while reactive maintenance involves addressing problems that have already
occurred.
Maintenance can be performed by different stakeholders, including the original development team, an
in-house maintenance team, or a third-party maintenance provider. Maintenance activities can be
planned or unplanned. Planned activities include regular maintenance tasks that are scheduled in
advance, such as updates and backups. Unplanned activities are reactive and are triggered by
unexpected events, such as system crashes or security breaches. Software maintenance can involve
modifying the software code, as well as its documentation, user manuals, and training materials. This
ensures that the software is up-to-date and continues to meet the needs of its users.
Software maintenance can also involve upgrading the software to a new version or platform. This can
be necessary to keep up with changes in technology and to ensure that the software remains compatible
with other systems. The success of software maintenance depends on effective communication with
stakeholders, including users, developers, and management. Regular updates and reports can help to
keep stakeholders informed and involved in the maintenance process.
Software maintenance is also an important part of the Software Development Life Cycle(SDLC). To
update the software application and do all modifications in software application so as to improve
performance is the main focus of software maintenance. Software is a model that runs on the basis of
the real world. so, whenever any change requires in the software that means the need for real-world
changes wherever possible.
Need for Maintenance

Software Maintenance must be performed in order to:
 Correct faults.
 Improve the design.
 Implement enhancements.
 Interface with other systems.
 Accommodate programs so that different hardware, software, system features, and
telecommunications facilities can be used.
 Migrate legacy software.
 Retire software.
 Requirement of user changes.
25
 Run the code fast
Challenges in Software Maintenance
The various challenges in software maintenance are given below:
 The popular age of any software program is taken into consideration up to ten to fifteen years.
As software program renovation is open-ended and might maintain for decades making it very
expensive.
 Older software programs, which had been intended to paint on sluggish machines with much
less reminiscence and garage ability can not maintain themselves tough in opposition to newly
coming more advantageous software programs on contemporary-day hardware.
 Changes are frequently left undocumented which can also additionally reason greater conflicts
in the future.
 As the era advances, it turns into high prices to preserve vintage software programs.
 Often adjustments made can without problems harm the authentic shape of the software
program, making it difficult for any next adjustments.
 There is a lack of Code Comments.
 Lack of documentation: Poorly documented systems can make it difficult to understand how
the system works, making it difficult to identify and fix problems.
 Legacy code: Maintaining older systems with outdated technologies can be difficult, as it may
require specialized knowledge and skills.
 Complexity: Large and complex systems can be difficult to understand and modify, making it
difficult to identify and fix problems.
 Changing requirements: As user requirements change over time, the software system may
need to be modified to meet these new requirements, which can be difficult and time-consuming.
 Interoperability issues: Systems that need to work with other systems or software can be
difficult to maintain, as changes to one system can affect the other systems.
 Lack of test coverage: Systems that have not been thoroughly tested can be difficult to
maintain as it can be hard to identify and fix problems without knowing how the system behaves in
different scenarios.
 Lack of personnel: A lack of personnel with the necessary skills and knowledge to maintain the
system can make it difficult to keep the system up-to-date and running smoothly.
 High-Cost: The cost of maintenance can be high, especially for large and complex systems,
which can be difficult to budget for and manage.
To overcome these challenges, it is important to have a well-defined maintenance process in place,
which includes testing and validation, version control, and communication with stakeholders. It is also
important to have a clear and well-defined maintenance plan that includes regular maintenance
activities, such as testing, backup, and bug fixing. Additionally, it is important to have personnel with
the necessary skills and knowledge to maintain the system.
Categories of Software Maintenance

Maintenance can be divided into the following categories.
 Corrective maintenance: Corrective maintenance of a software product may be essential either
to rectify some bugs observed while the system is in use, or to enhance the performance of the
system.
26
 Adaptive maintenance: This includes modifications and updations when the customers need
the product to run on new platforms, on new operating systems, or when they need the product to
interface with new hardware and software.
 Perfective maintenance: A software product needs maintenance to support the new features
that the users want or to change different types of functionalities of the system according to the
customer’s demands.
 Preventive maintenance: This type of maintenance includes modifications and updations to
prevent future problems with the software. It goals to attend to problems, which are not significant
at this moment but may cause serious issues in the future.
Advantages of Software Maintenance
 Improved Software Quality: Regular software maintenance helps to ensure that the software is
functioning correctly and efficiently and that it continues to meet the needs of the users.
 Enhanced Security: Maintenance can include security updates and patches, helping to ensure
that the software is protected against potential threats and attacks.
 Increased User Satisfaction: Regular software maintenance helps to keep the software up-to-
date and relevant, leading to increased user satisfaction and adoption.
 Extended Software Life: Proper software maintenance can extend the life of the software,
allowing it to be used for longer periods of time and reducing the need for costly replacements.
 Cost Savings: Regular software maintenance can help to prevent larger, more expensive
problems from occurring, reducing the overall cost of software ownership.
 Better Alignment with business goals: Regular software maintenance can help to ensure that
the software remains aligned with the changing needs of the business. This can help to improve
overall business efficiency and productivity.
 Competitive Advantage: Regular software maintenance can help to keep the software ahead of
the competition by improving functionality, performance, and user experience.
 Compliance with Regulations: Software maintenance can help to ensure that the software
complies with relevant regulations and standards. This is particularly important in industries such as
healthcare, finance, and government, where compliance is critical.
 Improved Collaboration: Regular software maintenance can help to improve collaboration
between different teams, such as developers, testers, and users. This can lead to better
communication and more effective problem-solving.
 Reduced Downtime: Software maintenance can help to reduce downtime caused by system
failures or errors. This can have a positive impact on business operations and reduce the risk of lost
revenue or customers.
 Improved Scalability: Regular software maintenance can help to ensure that the software is
scalable and can handle increased user demand. This can be particularly important for growing
businesses or for software that is used by a large number of users.
Disadvantages of Software Maintenance
 Cost: Software maintenance can be time-consuming and expensive, and may require significant
resources and expertise.
 Schedule disruptions: Maintenance can cause disruptions to the normal schedule and
operations of the software, leading to potential downtime and inconvenience.
 Complexity: Maintaining and updating complex software systems can be challenging, requiring
specialized knowledge and expertise.
27
 Risk of introducing new bugs: The process of fixing bugs or adding new features can introduce
new bugs or problems, making it important to thoroughly test the software after maintenance.
 User resistance: Users may resist changes or updates to the software, leading to decreased
satisfaction and adoption.
 Compatibility issues: Maintenance can sometimes cause compatibility issues with other
software or hardware, leading to potential integration problems.
 Lack of documentation: Poor documentation or lack of documentation can make software
maintenance more difficult and time-consuming, leading to potential errors or delays.
 Technical debt: Over time, software maintenance can lead to technical debt, where the cost of
maintaining and updating the software becomes increasingly higher than the cost of developing a
new system.
 Skill gaps: Maintaining software systems may require specialized skills or expertise that may
not be available within the organization, leading to potential outsourcing or increased costs.
 Inadequate testing: Inadequate testing or incomplete testing after maintenance can lead to
errors, bugs, and potential security vulnerabilities.
 End-of-life: Eventually, software systems may reach their end-of-life, making maintenance and
updates no longer feasible or cost-effective. This can lead to the need for a complete system
replacement, which can be costly and time-consuming.
Software Design Concepts

Introduction: Software design encompasses the set of principles, concepts, and practices that
lead to the development of a high-quality system or product. Design principles establish an
overriding philosophy that guides you in the design work you must perform. Design is pivotal to
successful software engineering
The goal of design is to produce a model or representation that exhibits firmness,
commodity, and delight Software design changes continually as new methods, better analysis,
and broader understanding evolve
DESIGN CONCEPTS
A set of fundamental software design concepts has evolved over the history of software
engineering. Each provides the software designer with a foundation from which more
sophisticated design methods can be applied. Each helps you answer the following questions:
• What criteria can be used to partition software into individual components?
• How is function or data structure detail separated from a conceptual representation of
the software?
• What uniform criteria define the technical quality of a software design?
28
The following brief overview of important software design concepts that span both traditional
and object-oriented software development.
Abstraction
Abstraction is the act of representing essential features without including the background
details or explanations. the abstraction is used to reduce complexity and allow efficient design
and implementation of complex software systems. Many levels of abstraction can be posed. At
the highest level of abstraction, a solution is stated in broad terms using the language of the
problem environment. At lower levels of abstraction, a more detailed description of the solution
is provided.
As different levels of abstraction are developed, you work to create both procedural and
data abstractions.
A procedural abstraction refers to a sequence of instructions that have a specific and
limited function. The name of a procedural abstraction implies these functions, but specific
details are suppressed.
A data abstraction is a named collection of data that describes a data object.
Architecture
Software architecture alludes to “the overall structure of the software and the ways in
which that structure provides conceptual integrity for a system” Architecture is the structure or
organization of program components (modules), the manner in which these components interact,
and the structure of data that are used by the components.
Shaw and Garlan describe a set of properties that should be specified as part of an architectural
design:
 Structural properties. This aspect of the architectural design representation defines the
components of a system (e.g., modules, objects, filters) and the manner in which those
components are packaged and interact with one another.
 Extra-functional properties. The architectural design description should address how
the design architecture achieves requirements for performance, capacity, reliability,
security, adaptability, and other system characteristics.
 Families of related systems. The architectural design should draw upon repeatable
patterns that are commonly encountered in the design of families of similar systems. In
essence, the design should have the ability to reuse architectural building blocks.
The architectural design can be represented using one or more of a number of different models.
29
Structural models: Represent architecture as an organized collection of program components.
Framework models: Increase the level of design abstraction by attempting to identify repeatable
architectural design frameworks that are encountered in similar types of applications.
Dynamic models : Address the behavioral aspects of the program architecture, indicating how
the structure or system configuration may change as a function of external events.
Process models :Focus on the design of the business or technical process that the system must
accommodate.
Functional models can be used to represent the functional hierarchy of a system.
A number of different architectural description languages (ADLs) have been developed
to represent these models.
Patterns
Brad Appleton defines a design pattern in the following manner: “A pattern is a named
nugget of insight which conveys the essence of a proven solution to a recurring problem within a
certain context amidst competing concerns”
A design pattern describes a design structure that solves a particular design problem
within a specific context and amid “forces” that may have an impact on the manner in which the
pattern is applied and used.
The intent of each design pattern is to provide a description that enables a designer to
determine (1) whether the pattern is applicable to the current work, (2) whether the pattern can
be reused (hence, saving design time), and (3) whether the pattern can serve as a guide for
developing a similar, but functionally or structurally different pattern.
Separation of Concerns
Separation of concerns is a design concept that suggests that any complex problem can
be more easily handled if it is subdivided into pieces that can each be solved and/or optimized
independently. A concern is a feature or behavior that is specified as part of the requirements
model for the software.
Separation of concerns is manifested in other related design concepts: modularity,
aspects, functional independence, and refinement. Each will be discussed in the subsections that
follow.
Modularity
Modularity is the most common manifestation of separation of concerns. Software is
divided into separately named and addressable components, sometimes called module.
30
Modularity is the single attribute of software that allows a program to be intellectually
manageable
Fig : Modularity and software cost

Information Hiding
The principle of information hiding suggests that modules be “characterized by design decisions
that hides from all others.” In other words, modules should be specified and designed so that
information contained within a module is inaccessible to other modules that have no need for
such information.
The use of information hiding as a design criterion for modular systems provides the
greatest benefits when modifications are required during testing and later during software
maintenance. Because most data and procedural detail are hidden from other parts of the
software, inadvertent errors introduced during modification are less likely to propagate to other
locations within the software.
Functional Independence
The concept of functional independence is a direct outgrowth of separation of concerns,
modularity, and the concepts of abstraction and information hiding. Functional independence is
achieved by developing modules with “single minded” function and an “aversion” to excessive
interaction with other modules.
Independence is assessed using two qualitative criteria: cohesion and coupling.
Cohesion is an indication of the relative functional strength of a module. Coupling is an
31
indication of the relative interdependence among modules.
Cohesion is a natural extension of the information-hiding concept. A cohesive module
performs a single task, requiring little interaction with other components in other parts of a
program. Stated simply, a cohesive module should do just one thing. Although you should
always strive for high cohesion (i.e., single-mindedness).
Coupling is an indication of interconnection among modules in a software structure.
Coupling depends on the interface complexity between modules, the point at which entry or
reference is made to a module, and what data pass across the interface. In software design, you
should strive for the lowest possible coupling.
Refinement
Stepwise refinement is a top-down design strategy originally proposed by Niklaus Wirth.
Refinement is actually a process of elaboration. You begin with a statement of function that is
defined at a high level of abstraction.
Abstraction and refinement are complementary concepts. Abstraction enables you to
specify procedure and data internally but suppress the need for “outsiders” to have knowledge of
low-level details. Refinement helps you to reveal low-level details as design progresses.
Aspects
An aspect is a representation of a crosscutting concern. A crosscutting concern is some
characteristic of the system that applies across many different requirements.
Refactoring
An important design activity suggested for many agile methods, refactoring is a reorganization
technique that simplifies the design (or code) of a component without changing its function or
behavior. Fowler defines refactoring in the following manner: “Refactoring is the process of
changing a software system in such a way that it does not alter the external behavior of the
code [design] yet improves its internal structure.”
Object-Oriented Design Concepts
The object-oriented (OO) paradigm is widely used in modern software engineering. OO
design concepts such as classes and objects, inheritance, messages, and polymorphism, among
others.
Design Classes
The requirements model defines a set of analysis classes. Each describes some element of the
problem domain, focusing on aspects of the problem that are user visible. A set of design classes
32
that refine the analysis classes by providing design detail that will enable the classes to be
implemented, and implement a software infrastructure that supports the business solution.
Five different types of design classes, each representing a different layer of the design
architecture, can be developed:
• User interface classes define all abstractions that are necessary for human computer
interaction (HCI). The design classes for the interface may be visual representations of
the elements of the metaphor.
• Business domain classes are often refinements of the analysis classes defined earlier.
The classes identify the attributes and services (methods) that are required to implement
some element of the business domain.
• Process classes implement lower-level business abstractions required to fully manage
the business domain classes.
• Persistent classes represent data stores (e.g., a database) that will persist beyond the
execution of the software.
• System classes implement software management and control functions that enable the
system to operate and communicate within its computing environment and with the
outside world.
Arlow and Neustadt suggest that each design class be reviewed to ensure that it is “well-
formed.” They define four characteristics of a well-formed design class:
 Complete and sufficient. A design class should be the complete encapsulation of all
attributes and methods that can reasonably be expected to exist for the class. Sufficiency
ensures that the design class contains only those methods that are sufficient to achieve the
intent of the class, no more and no less.
 Primitiveness. Methods associated with a design class should be focused on
accomplishing one service for the class. Once the service has been implemented with a
method, the class should not provide another way to accomplish the same thing.
 High cohesion. A cohesive design class has a small, focused set of responsibilities and
single-mindedly applies attributes and methods to implement those responsibilities.
 Low coupling. Within the design model, it is necessary for design classes to collaborate
with one another. If a design model is highly coupled, the system is difficult to
implement, to test, and to maintain over time.
THE DESIGN MODEL
33
The design model can be viewed in two different dimensions. The process dimension
indicates the evolution of the design model as design tasks are executed as part of the software
process. The abstraction dimension represents the level of detail as each element of the analysis
model is transformed into a design equivalent and then refined iteratively. The design model has
four major elements: data, architecture, components, and interface.
Data Design Elements
Data design (sometimes referred to as data architecting) creates a model of data and/or
information that is represented at a high level of abstraction (the customer/user’s view of data).
This data model is then refined into progressively more implementation-specific representations
that can be processed by the computer-based system. The structure of data has always been an
important part of software design. At the program component level, the design of data structures
and the associated algorithms required to manipulate them is essential to the creation of high-
quality applications. At the application level, the translation of a data model into a database is
pivotal to achieving the business objectives of a system. At the business level, the collection of
information stored in disparate databases and reorganized into a “data warehouse” enables data
mining or knowledge discovery that can have an impact on the success of the business itself.
Fig : Dimensions of the design model

34
Architectural Design Elements
The architectural design for software is the equivalent to the floor plan of a house. The
floor plan depicts the overall layout of the rooms; their size, shape, and relationship to one
another; and the doors and windows that allow movement into and out of the rooms.
Architectural design elements give us an overall view of the software.
The architectural model is derived from three sources: (1) information about the
application domain for the software to be built; (2) specific requirements model elements such as
data flow diagrams or analysis classes, their relationships and collaborations for the problem at
hand; and (3) the availability of architectural styles and patterns.
The architectural design element is usually depicted as a set of interconnected
subsystems, often derived from analysis packages within the requirements model.
Interface Design Elements

The interface design for software is analogous to a set of detailed drawings for the doors,
windows, and external utilities of a house.
There are three important elements of interface design: (1) the user interface (UI); (2) external
interfaces to other systems, devices, networks, or other producers or consumers of information;
and (3) internal interfaces between various design components.
These interface design elements allow the software to communicate externally and enable
internal communication and collaboration among the components that populate the software
architecture.
Component-Level Design Elements
The component-level design for software is the equivalent to a set of detailed drawings
for each room in a house. These drawings depict wiring and plumbing within each room, the
location of electrical receptacles and wall switches, sinks, showers, tubs, drains, cabinets, and
closets.The component-level design for software fully describes the internal detail of each
software component. To accomplish this, the component-level design defines data structures for
all local data objects and algorithmic detail for all processing that occurs within a component and
an interface that allows access to all component operations.
Deployment-Level Design Elements
Deployment-level design elements indicate how software functionality and subsystems
will be allocated within the physical computing environment that will support the software.
Deployment diagrams begin in descriptor form, where the deployment environment is described
35
in general terms. Later, instance form is used and elements of the configuration are explicitly
described.
36
37

Se Unit Iii

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

Se Unit Iii

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Se Unit Iii

Uploaded by

Copyright:

Available Formats

UNIT- III

Software Project Management (SPM)- Project Management Process, Project size

Software Project Management (SPM)

Software Project Management consists of Several Different Types of Management:

Aspects of Software Project Management:

Project Management Process

The main phases of the project management process are:

Advantages of the project management process:

1. Provides a structured approach to managing projects.

Disadvantages of the project management process:

1. Can be time-consuming and bureaucratic

Project size estimation

Internal Logical Files 7 10 15

External Interface Files 5 7 10

System configuration management

below: Suppose after some

The key objectives of SCM are to:

The main advantages of SCM are:

The main disadvantages of SCM are:

1. Increased complexity and overhead, particularly in large software systems.

Organic 2.4 1.05 2.5 0.38

Semi-Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Capability maturity model (CMM)

Integrating Risk Management in SDLC

Steps in SDLC Model

In this step, you need to find out the organization’s objective

2. System Analysis and Requirement Definition

Role and Responsibilities of a software Project

Several Key Aspects of Software Maintenance

Several Types of Software Maintenance

Need for Maintenance

Categories of Software Maintenance

Software Design Concepts

Fig : Modularity and software cost

Fig : Dimensions of the design model

Interface Design Elements

You might also like