Spiral process model

The Spiral Model is a software development process model that combines

elements of both the waterfall and prototyping approaches, with a strong
focus on risk analysis.
How it works
Development proceeds through a series of spirals (iterations). Each spiral
typically consists of four phases:
Planning
Define objectives, requirements, and constraints.
Estimate costs and schedules.
Risk Analysis
Identify potential risks.
Evaluate and develop strategies to reduce or eliminate risks.
Engineering (Development and Testing)
Design, code, and test the product or prototype.
Evaluation
Review the results with stakeholders.
Decide whether to proceed to the next spiral.

Agile process model Advantages

Faster delivery of software.
Easily accommodates changing requirements.
Continuous customer involvement.
Early detection of issues.
Improved product quality.
Disadvantages
Requires active customer participation.
Less predictable cost and schedule.
Documentation may be lighter than traditional models.
Can be difficult for very large teams without strong coordination.

1. Agile Manifesto
The Agile Manifesto was created in 2001 and defines four core values:
Four Agile Values
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
The items on the right have value, but Agile values the items on the left more.
2. Agile Development
Agile Development is an iterative and incremental approach where software is
developed in small cycles (sprints) with continuous feedback from customers.
Characteristics
Short development iterations
Frequent releases
Continuous testing
Customer involvement
Adaptability to change
Team collaboration
Agile Cycle
Plan → Design → Develop → Test → Review → Release
↑ ↓
←──── Feedback ────────

3. Agility and Cost of Change

Agility
Agility is the ability of a development team to respond quickly and effectively to
changing requirements.
Benefits:
Faster response to market needs
Improved customer satisfaction
Reduced project risks
Cost of Change
In traditional models like Waterfall, the cost of fixing a requirement error
increases dramatically as the project progresses.
Agile aims to keep the cost of change lower through:
Continuous testing , Frequent feedback , Incremental development
Refactoring
Cost
^
| Traditional
| /
| /
| /
| /
| Agile /
|-----------/--------------> Time
The Agile philosophy is that changes are expected and should be handled
throughout development rather than avoided.
4. Pair Programming in Agile
Pair Programming is a practice commonly used in Extreme Programming (XP).
How It Works
Two programmers work together at one computer:
Driver
Writes the code.
Focuses on implementation.
Navigator
Reviews the code in real time.
Thinks about design, logic, and potential issues.
They frequently switch roles.
+-----------------------+
| Navigator |
| (Reviews & Guides) |
+-----------------------+
↓
+-----------------------+
| Driver |
| (Writes Code) |
+-----------------------+
Advantages
Fewer defects
Better code quality
Knowledge sharing
Faster problem solving
Improved team collaboration
Disadvantages
Higher short-term cost (two developers on one task)
May not suit all personalities
Requires good communication
Traditional Software
Feature Agile Development
Development (Waterfall)
Approach Sequential and linear Iterative and incremental
Can change throughout the
Requirements Fixed at the beginning
project
Customer Continuous involvement and
Limited, mainly at start and end
Involvement feedback
Adaptive planning throughout
Planning Extensive upfront planning
development
Frequent delivery of working
Delivery Product delivered at the end
software
Continuous testing during
Testing Performed after development
development
Software Engineering Process Framework Activities
The Software Engineering Process Framework provides a structure for
developing high-quality software. According to Roger S. Pressman, there are five
generic framework activities that are common to most software projects.
1. Communication
• Gather requirements from customers and stakeholders.
• Understand project goals and expectations.
• Define the problem to be solved.
Output: Software Requirements Specification (SRS).

2. Planning
• Estimate cost, effort, and resources.
• Create schedules and milestones.
• Identify risks and develop plans.
Output: Project Plan.

3. Modeling
• Analyze requirements.
• Create design models for the software.
• Define system architecture, data structures, interfaces, and components.
Output: Design Documents.

4. Construction
• Coding (implementation) of the software.
• Testing to identify and fix defects.
Output: Working software product.

5. Deployment
• Deliver software to the customer.
• Provide support and maintenance.
• Collect feedback for future improvements.
Output: Released software and user feedback.

Software Quality Framework

A Software Quality Framework (SQF) establishes the structural foundation for
your SQA Plan. It standardizes how quality is measured, automated, and
improved. A robust framework typically incorporates: [1]
Quality Standards: Using established industry models like ⁠GeeksforGeeks SQA
Standards to measure the product's functionality, performance, usability, and security.
Automation Strategy: Tools and scripts integrated to run repetitive tests.
Metrics & KPIs: Data points like defect density, test coverage, and customer feedback
to drive continuous improvement.
Continuous Integration: Automated pipelines ensuring that new code changes do not
break existing features
SQA
A software quality assurance plan's main goal is to guarantee that the market's
product or service is trouble- and bug-free. Additionally, it must fulfill the
specifications listed in the SRS (software requirement specification).
ASQA plan
• Determining the QA duties assigned to the concerned team.
• A list of the areas that require review, audit, and examination.
• Determines the work products for SQA.
Importance of Software Quality Assurance Plan
• Quality Standards and Guidelines: The SQA Plan lays out the
requirements and guidelines to make sure the programme satisfies
predetermined standards for quality.
• Risk management: It is the process of recognizing, evaluating and
controlling risks in order to reduce the possibility of errors and other
problems with quality.
• Standardization and Consistency: The strategy guarantees consistent
methods, processes, and procedures, fostering a unified and well-
structured approach to quality assurance.
• Customer Satisfaction: The SQA Plan helps to ensure that the finished
product satisfies customer needs, which in turn increases overall
customer satisfaction.
Functional Non-Functional
Feature
Requirements Requirements
What the system does How the system performs
Focus
(features) (qualities)
Behind-the-scenes;
Directly visible and usable
Visibility measures overall user
to the end-user
experience
Pass or Fail (Feature Measurable via benchmarks
Measurement
exists or it doesn't) (e.g., uptime %, load time)
User registration, search Load time, system uptime,
Examples
bar, reporting, checkout security, accessibility

Requirement Elicitation
Requirement Elicitation is the process of gathering, discovering, and
understanding the needs and expectations of stakeholders for a software
system.
It is one of the most important activities in Requirements Engineering.
Objectives: 1]Understand customer needs.
• Identify system requirements.
• Resolve conflicts among stakeholders.
• Define the scope of the system
Elicitation Work Products
The outputs produced during requirement elicitation are called elicitation
work products.
Main Work Products
1. Statement of Need and Feasibility
• Describes the business problem.
• Explains why the system is required.
• Assesses project feasibility.
2. Bounded Scope Statement
• Defines system boundaries.
• Specifies what is included and excluded.
3. List of Customers, Users, and Stakeholders
• Identifies all people involved with the system.
4. Description of Technical Environment
• Hardware, software, network, and operational environment details.
Verification Validation
Checks whether the product is Checks whether the correct product is
built correctly built
"Are we building the product
"Are we building the right product?"
right?"
Process-oriented Product-oriented
Performed after development stages or
Performed during development
on completed features
Does not require software
Usually requires software execution
execution
Uses reviews and inspections Uses testing and evaluation

Software Requirements Specification (SRS)

A Software Requirements Specification (SRS) is a formal document that
describes all the functional and non-functional requirements of a software
system.
Objectives of SRS
• Clearly define software requirements.
• Provide a basis for design and development.
• Reduce misunderstandings between stakeholders.
• Facilitate testing and validation.
Advantages of SRS
• Acts as a blueprint for development.
• Helps estimate cost and schedule.
• Reduces development errors.
• Provides a basis for testing.
Tasks Included in Requirement Engineering
Requirement Engineering (RE) is the process of identifying, documenting,
analyzing, validating, and managing software requirements.
The major tasks in Requirement Engineering are:
1. Inception
Identify stakeholders.
Understand the problem and project goals.
Establish communication with customer
2. Elicitation
Gather requirements from stakeholders.
Discover user needs and expectations.
Techniques:
Interviews
Questionnaires
Observation
Workshops
Prototyping
3. Elaboration (Analysis)
Refine and analyze requirements.
Identify functional and non-functional requirements.
Develop use cases and models.
Resolve ambiguities and conflicts.
4. Negotiation
Resolve conflicts among stakeholders.
Prioritize requirements.
Agree on project scope and constraints.
5. Specification
Document requirements formally.
Prepare the Software Requirements Specification (SRS).
6. Validation
Check requirements for:
Correctness
Completeness
Consistency
Feasibility
Testability
7. Requirements Management
Track and control changes to requirements.
Maintain requirement traceability.
Manage versions and updates.
.
Normal Requirements Exciting Requirements
Expected by customers Not expected by customers
Usually stated explicitly Usually unstated
Absence does not cause
Absence causes dissatisfaction
dissatisfaction
Better implementation increases Presence creates a strong
satisfaction gradually positive reaction
Example: AI-based
Example: Secure login
recommendations

Requirement Validation Techniques

1. Requirement Reviews
• Stakeholders, customers, analysts, and developers examine the
requirements.
• Errors, omissions, and inconsistencies are identified.
2. Walkthroughs
• Requirements are presented step-by-step to stakeholders.
• Feedback is collected and corrections are made.
3. Prototyping
• A prototype or mock-up is created.
• Users verify whether the proposed system meets their expectations.
4. Test Case Generation
• Test cases are created from requirements.
• If a requirement cannot be tested, it may be unclear or incomplete.
5. Consistency Checking
• Verify that requirements do not contradict each other.
6. Feasibility Analysis
• Check whether requirements can be implemented within available
technology, budget, and schedule constraints.

PSP vs TSP Comparison

PSP TSP
Personal Software Process Team Software Process
Focuses on individual engineers Focuses on development teams
Improves personal productivity Improves team productivity
Individual planning and tracking Team planning and coordination
Individual defect management Team quality management
Basis for TSP Built on PSP principles
Importance of XP
1. Improves Software Quality
• Continuous testing helps detect defects early.
• Frequent code reviews improve code quality.
2. Adapts to Changing Requirements
• XP welcomes requirement changes even during development.
• Makes the process flexible and customer-focused.
3. Enhances Customer Satisfaction
• Customers are actively involved throughout development.
• Frequent releases provide quick feedback.
4. Faster Development
• Small iterations deliver working software quickly.
• Reduces delays in identifying problems.
5. Better Team Communication
• Encourages close collaboration among team members.
• Promotes knowledge sharing.
1. Refactoring
Refactoring is the process of improving the internal structure of existing code
without changing its external behavior or functionality.
Objectives
• Improve code readability.
• Reduce complexity.
• Remove duplicate code.
• Improve maintainability.
• Make future changes easier.
Examples of Refactoring
• Renaming variables and methods.
• Breaking large functions into smaller functions.
• Removing redundant code.
• Simplifying complex logic.
Benefits
• Cleaner code.
• Easier debugging and maintenance.
• Better software quality.
• Improved code reuse.
Agile Principles
The Agile Principles are guidelines that support Agile software development.
1. Customer satisfaction through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development.
3. Deliver working software frequently (weeks rather than months).
4. Business people and developers work together daily.
5. Build projects around motivated individuals.
Tool Set for Agile Process
1. Project Management Tools
Used for sprint planning, task tracking, and backlog management.
Examples:
• Jira ,Trello
2. Version Control Tools
Used to manage source code changes.
Examples:
• Git , Apache Subversion
3. Continuous Integration (CI) Tools
Used to automatically build and test code.
Examples:
• Jenkins , GitHub Actions
4. Testing Tools
Used for automated and manual testing.
Examples:
• Selenium ,JUnit

Software Testing Metrics

Software testing metrics are measurable indicators used to evaluate the
progress, quality, and efficiency of the testing process. They enable
continuous improvement through data-driven decision-making
Core Importance of Software Testing Metrics
• Early Defect Identification: Spotting defect patterns and arrival trends
early minimizes expensive down-the-line code fixes.
• Resource Optimization: Teams can easily pinpoint complex or fragile
modules requiring heavier QA allocation.
• Objective Release Decisions: Data answers the critical question: "Are we
legally and structurally safe to push this build to production?"
• Process Improvement: Highlights team roadblocks, test execution speed,
and tool efficiency
Scrum Approach to Project Management
Scrum is an Agile project management framework used to develop and
deliver software in short, iterative cycles called Sprints.
The Scrum approach emphasizes teamwork, customer feedback, continuous
improvement, and rapid delivery of working software.
Scrum Roles
1. Product Owner
• Represents the customer.
• Defines and prioritizes requirements.
• Maintains the Product Backlog.
2. Scrum Master
• Facilitates the Scrum process.
• Removes obstacles faced by the team.
• Ensures Scrum practices are followed.
3. Development Team
• Designs, develops, and tests the software.
• Self-organizing and cross-functional.
Scrum Artifacts
Product Backlog
• List of all desired features and requirements.
Sprint Backlog
• Tasks selected for the current sprint.
Product Increment
• Working software produced at the end of a sprint.
Scrum Events
1. Sprint Planning
• Team selects backlog items for the sprint.
• Sprint goals are defined.
2. Sprint
• Time-boxed iteration (usually 1–4 weeks).
• Team develops and tests features.
3. Daily Scrum
• Short daily meeting (about 15 minutes).
4. Sprint Review
• Demonstrate completed work to stakeholders.
• Collect feedback.
5. Sprint Retrospective
• Discuss what went well and what can be improved.
Scrum Process Flow
• Product Backlog
↓
Sprint Planning Advantages of Scrum
↓ Faster delivery of working software.
Sprint Backlog Better customer involvement
↓ Easy adaptation to changing requirements.
Sprint (1–4 Weeks) Improved team collaboration.
↓
Daily Scrum
↓
Product Increment
↓
Sprint Review
↓
Sprint Retrospective
↓
Next Sprint

What are Function-Oriented Metrics?

Function-oriented metrics is a method that was developed by Albrecht in
1979 for IBM (International Business Machine). He suggested a measure
known as Function points that are derived using an empirical relationship
based on countable measures of software’s information or requirements
domain and assessments of the complexity of software.
1. Function-oriented metrics are used to assess the software size and
complexity based on the functionality provided by the software to its
users.
2. Function-Oriented Metrics are also known as Function Point Models.

Purpose of Function-Oriented Metrics

Function-Oriented metrics have several important purposes:
1. Size Estimation: They provide a standard method to measure the size of
software based on the functionality instead of Lines of Code (LOC) or any
other implementation details.
2. Project Planning and Management: They aid in project planning by
providing insights into the complexity and scope of the project.
3. Cost Estimation: They aid in estimating the size of the software in terms of
functionality, thus contributing to cost estimation for software
development.
 Software metrics
Software metrics are quantitative measures used to evaluate the attributes of
software, processes, and projects. They enable managers to estimate costs,
track progress, control quality, and optimize development methodologies
throughout the entire Software Development Life Cycle (SDLC). [1, 2, 3, 4, 5]
Advantages of Software Metrics
Tracking metrics provides vital insights that translate directly to team
performance and product success. Key benefits include: [1, 2]
• Cost & Budget Reduction: Helps optimize resource allocation, preventing
scope creep and lowering overall development expenses.
• Enhanced Product Quality: Highlights error-prone modules and
complexity, allowing the team to test and refine the code early.
• Improved Project Planning: Facilitates highly accurate estimations for
timelines, required effort, and budget for future projects.
• Progress Monitoring: Gives software managers objective visibility into
development phases so they can provide continuous, data-driven
feedback.
• Resource Optimization: Guides managers on how best to deploy testing
teams and development resources where they are needed most.

Classification of Software Metrics

Metrics are broadly classified into three main categories based on what they
are measuring: [1, 2]
1. Product Metrics
These metrics measure the characteristics, attributes, and state of the
software itself. They focus on the product's design, size, and complexity.
[Examples: Lines of Code (LOC), Cyclomatic Complexity, Defect Density, and
Code Coverage
2. Process Metrics
These metrics evaluate the development methodology, workflows, and
techniques used to build the software. Their goal is to enhance the long-term
efficiency of the team and organization. [1, 2]
• Examples: Defect Injection Rate, Lead Time, and Process Cycle Time.
3. Project Metrics
These metrics describe the overarching project characteristics,
encompassing project timelines, costs, and team productivity. They are
crucial for project managers tracking deliverables. [1, 2]
• Examples: Effort Variance, Schedule Variance, Cost Variance, and
Resource Utilization.
Software quality
Software quality is the degree to which a software product meets established
requirements, user needs, and expectations. It is measured by both its
external attributes (how it performs for the end-user) and its internal
structural design (how easily it can be maintained and scaled by developers).
Key Factors (Attributes) Affecting Software Quality
1. Product Operation Factors
These dictate how well the software performs in real-time and how users
interact with it. [1]
• ⁠Usability: The ease with which different classes of users (novice to
expert) can learn, operate, prepare input, and interpret the output of the
software. [1]
• Reliability: The probability that the software will perform its required
functions under stated conditions without failure for a defined period. [1]
• Efficiency: How optimally the software uses system resources like CPU
time, memory, disk space, and network bandwidth. [1]
• Correctness: The extent to which the software satisfies its specified
requirements as outlined in the initial design documents. [1]
2. Product Revision Factors
These evaluate how easily the software can be modified, updated, and tested.
• Maintainability: The effort required to locate and fix bugs, add new
functions, or adapt the software to changing environments.
• Testability: The effort required to test the software to ensure it performs
its intended functions.
• Flexibility: The ease with which the software can be modified to
accommodate changes in requirements or operational conditions. [1, 2, 3,
3. Product Transition Factors
These determine how well the software adapts to new environments and
interacts with other systems. [1, 2]
• Portability: The ability of the software to be easily transferred from one
hardware or software environment to another.
• Reusability: The degree to which parts of the software can be used in
other applications or products.
• Interoperability: The ability of the software to seamlessly communicate
and exchange information with other systems or applications
 Feature PERT Chart Gantt Chart
Visual Network diagram with boxes Horizontal bar chart on a
Style and arrows. calendar timeline.
Task sequences,
Primary Schedule, start/end dates,
dependencies, and the
Focus and task durations.
"critical path".
Planning complex projects Tracking daily progress and
Best Used
where task times are managing operational day-
For
uncertain. to-day work.
Highly flexible; easy to
Difficult to change once the
Flexibility drag/drop and update as
project is underway.
things change.

Cost Estimation Techniques

• Analogous (Top-Down) Estimating: Uses historical data and expert
judgment from similar past projects to estimate the current one. It is fast
and inexpensive but less precise, making it best for early-stage planning.
• Parametric Estimating: Applies statistical modeling and historical data to
calculate costs based on measurable units (e.g., cost per square foot for
construction, or cost per user for software). It offers a good balance
between speed and accuracy. [1]
• Bottom-Up Estimating: Breaks the project down into individual work
packages or tasks, estimates the cost for each, and "rolls them up" to find
the total budget. It is highly accurate but time-intensive. [1, 2]
• Expert Judgment: Relies on the experience and insight of senior
professionals or industry experts. It is quick but can be subjective and
prone to bias. [1]
•
Core Estimating Tools
• Cost Estimating Software: Dedicated programs used for process
planning and product costing. Examples include Costimator for
manufacturing and Kreo Software for construction takeoffs. [1]
• Project Management Tools: Platforms that allow teams to assign costs to
specific tasks and resources. Popular options include Smartsheet, Asana,
and [Link]. [1, 2, 3, 4]
• Historical Databases: Repositories of past project data that help drive
parametric and analogous estimates. [1, 2, 3]
• Estimation Frameworks: Standardized methodologies (such as
COCOMO for software engineering) to calculate effort and duration.
Work Breakdown Structure
A Work Breakdown Structure includes dividing a large and complex project
into simpler, manageable, and independent tasks. The root of this tree
(structure) is labeled by the Project name itself. For constructing a work
breakdown structure, each node is recursively decomposed into smaller sub-
activities, until at the leaf level, the activities become undividable and
independent. It follows a Top-Down approach.
Steps Work Breakdown Structure:
Step 1: Identify the major activities of the project.
Step 2: Identify the sub-activities of the major activities.
Step 3: Repeat till undividable, simple, and independent activities are created

Project Scope Management

Scope management ensures that all the work—and only the work required to
complete the project—is successfully executed. It keeps the project focused
and directly prevents "scope creep" (the uncontrolled expansion of project
requirements).
Core Processes:
1. Plan Scope Management: Creating a scope management plan that
documents how scope will be defined, validated, and controlled.
2. Collect Requirements: Documenting stakeholder needs, wants, and
expectations to meet project objectives.
3. Define Scope: Developing a detailed description of the project and its
deliverables, clearly stating the boundaries and limits of what will be done.
4. Create WBS (Work Breakdown Structure): Subdividing major project
deliverables into smaller, more manageable components.

Project Initiation
Initiation sets the foundation for your entire project before you invest
significant time and resources. It ensures that the initiative aligns with
overarching business goals.
Key Steps in Initiation:
• Identify Stakeholders: Recognize individuals, teams, or clients who will
be impacted by the project and understand their expectations. [1]
• Conduct Feasibility Analysis: Evaluate if the project is practical and
achievable by reviewing technical, operational, and financial constraints. [
• Create the Project Charter: This is the ultimate output of initiation. It is an
official document that formally authorizes the project, defines its high-
level objectives, and empowers the project manager to use organizational
resources. [1]
What is Software Project Management (SPM)?
Software Project Management (SPM) is all about planning, organizing, and
observing the software development process to make sure the project is
completed successfully, on time, and within budget

Need for Software Project Management

1]Software is a non-physical product. Software Development is a new
stream in business, and there is very little experience in building software
products.
2]Such types of business and environmental constraints increase Risk in
Software Development hence it is essential to manage software projects
efficiently.

Types of Management in SPM

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 to dealing with the transition
or transformation of an organization's goals, processes, or technologies. The
purpose of 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
System Configuration Management (SCM) is an arrangement of exercises
that 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
Importance of Software Configuration Management
1. Effective Bug Tracking: Linking code modifications to issues that have
been reported, makes bug tracking more effective.
2. Continuous Deployment and Integration: SCM combines with continuous
processes to automate deployment and testing, resulting in more
dependable and timely software delivery.
3. Risk management: SCM lowers the chance of introducing critical flaws by
assisting in the early detection and correction of problems.
objectives of SCM
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.
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.
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
What is Software Maintenance?
Software maintenance is a continuous process that occurs throughout the
entire life cycle of the software system.
• 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.

Types of Software Maintenance

1. Corrective Maintenance: This involves fixing errors and bugs in the
software system.
2. 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.
3. 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.
4. Perfective Maintenance: This involves improving functionality,
performance, and reliability, and restructuring the software system to
improve changeability.
5. Preventive Maintenance: This involves taking measures to prevent future
problems, such as optimization, updating documentation, reviewing and
testing the system

Need for Maintenance

• Correct faults.
• Improve the design.
• Implement enhancements.
• Interface with other systems.

Project Risk Management

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.
Importance of Risk Management
• Helps organizations prepare for unexpected situations, from minor issues
to major crises.
• Protects financial health and ensures smooth and continuous operations.
• Effective risk management requires proper resources and a structured,
systematic approach.
• Supports better identification, assessment, and mitigation of major risks.
Benefits of Risk Management
Here are some benefits of risk management:
• Helps protect against potential losses.
• Improves decision-making by considering risks.
• Reduces unexpected expenses.
• Ensures adherence to laws and regulations.
Limitation of Risk Management
Here are Some Limitation of Risk Management:
• Too much focus on risk can lead to missed opportunities.
• Implementing risk management can be expensive.
• Risk models can be overly complex and hard to understand.
• Having risk controls might make people feel too safe.

• What are Software Processes?

• Software processes in software engineering refer to the methods
and techniques used to develop and maintain software.

Software myth
Software myths are persistent misconceptions about software development
that lead to unrealistic expectations, project delays, and budget overruns.
They are generally categorized into three distinct groups: Management,
Customer, and Developer myths.
1. Management Myths
Management myths revolve around budgets, team dynamics, and deadlines.
Myth: Adding more people to a late project speeds it up.
Myth: Strict adherence to standards guarantees success.
Myth: Outsourcing inherently cuts costs.

2. Customer Myths
Customers, stakeholders, and product managers often hold misbeliefs
regarding requirements and delivery.
• Myth: A rough statement of objectives is enough to get started.
• Myth: Software changes can be accommodated at any time because
code is flexible.
• Myth: Delivery means the project is done.
•
3. Developer Myths
Practitioners and developers fall into traps regarding code quality, testing, and
technology.
• Myth: Writing more lines of code indicates better software.
Myth: Perfect, bug-free code can be written the first time.
• Myth: Testing only at the end is sufficient.
What are DevOps tools?
• Version control tools: Version control software (VCS) is also known as
source control or source code management (SCM). These tools track and
manage any changes made to a software’s code.
• DevOps automation tools: DevOps automation tools remove the burden
of repetitive tasks from the workflow. Some focus on specific processes
like testing or deployment, while others may be end-to-end tools. The term
end-to-end refers to the entire development process, from
conceptualization to deployment and continued monitoring.
• Performance monitoring tools: These DevOps tools monitor application
performance and help manage the infrastructure as a whole. They typically
have robust reporting capabilities and artificial intelligence (AI) for defect
detection.

Extreme programming practices:

• Code Review: Helps identify and fix errors quickly. XP promotes pair
programming, where two developers work together and regularly switch
roles.
• Testing: Improves reliability by removing errors. XP follows Test-Driven
Development (TDD), where tests are written before the actual code.
• Incremental Development: Software is built in small parts, allowing
frequent feedback and continuous improvement after each iteration.
• Simplicity: Keeping the design simple makes the code easier to develop,
test, and maintain.
• Design: Continuous attention to design ensures better quality software.
• Integration Testing: Frequent integration and testing help detect issues
early. XP supports continuous integration by testing multiple times a day.
 User Requirements
User requirements focus on user expectations, goals, and the overall
business value. They are usually documented in a User Requirements
Document (URD).
• Target Audience: Clients, stakeholders, business analysts, and non-
technical end-users.
• Language: High-level, abstract, and written in natural language, often
accompanied by simple diagrams or workflows.
• Focus: What the user sees and interacts with.
• Example: "The system must allow employees to easily submit and track
their vacation requests.
System Requirements
System requirements serve as a detailed blueprint for the software engineers
and developers. They are often compiled in a technical Software
Requirements Specification (SRS). [
• Target Audience: Software developers, system architects, and QA testers.
• Language: Precise, technical, and quantifiable, covering exact data
formats, logic, and hardware configurations.
• Focus: How the product works and the technical constraints required to
make the user requirement a reality.
• Example: "The system will use a PostgreSQL database to store vacation
requests and must respond to user queries in under 2 seconds. The
approval logic must automatically send an email to the HR department via
the SMTP server

The Lines of Code (LOC) is a software metric used to measure the size of a
computer program by counting the total number of lines in its source text. It is
widely used for high-level effort estimation, cost projection, and monitoring
codebase growth
Types of LOC Metrics
Physical LOC: Counts every physical line in the text file, including blank lines and
comments.
Logical LOC (SLOC): Counts only the executable statements and declarations, ignoring
comments and blank lines. [1, 2]
Advantages
Simplicity: It is cheap to collect, easy to compute, and understandable even to non-
technical stakeholders.
High-Level Benchmarking: Provides an approximate baseline to compare the size of
different iterations of the same project. [1, 2]
Disadvantages
Not a Productivity Metric: Measuring lines of code produced per day is a poor metric
because it incentivizes developers to write bloated, inefficient code rather than concise
solutions.
Ignores Complexity: Two programs can have the same LOC but vastly different levels of
architectural complexity or runtime performance
Function Point (FP) metrics measure the size and complexity of a software system
from a user's perspective. They are commonly used to estimate project timelines,
development effort, and costs, independent of the programming language used.
components:
• External Inputs (EI): Data entering the system (e.g., input screens, forms).
• External Outputs (EO): Data leaving the system (e.g., reports, error messages).
• External Inquiries (EQ): Interactive inputs requesting immediate data retrieval
without updating the system.
• Internal Logical Files (ILF): Major data stores completely within the system's
boundary.
• External Interface Files (EIF): Data referenced by your system but maintained
by entirely different applications. [1, 2, 3, 4, 5]
How It's Calculated
1. Classify and Weigh: Each of the five parameters is counted and evaluated as
either Simple, Average, or Complex, resulting in a weighted value. [1, 2, 3]
2. Calculate Unadjusted Function Points (UFP): Sum all the weighted values
derived in step 1.
3. Apply Value Adjustment Factor (VAF): The UFP is multiplied by a complexity
formula (\(0.65 + 0.01 \times \sum F_i\)) based on 14 general system
characteristics, like performance, reusability, and distributed data. [1, 2, 3, 4, 5]
Function Point vs. Lines of Code (LOC)
• Technology Independence: Unlike LOC, which heavily depends on the
programming language, FPs remain constant whether you code in Java, Python,
or C++.
• Business Focused: FPs measure what the software actually does for the user
rather than how many lines of text the developers write. [1, 2]
Project scheduling
Project scheduling is the dynamic process of mapping out your project’s
tasks, timelines, and resource requirements. It is the cornerstone of project
management, ensuring that teams hit deadlines, optimize available
resources, and communicate effectively without causing staff burnout.
The Importance of Project Scheduling
• Prevents Delays & Bottlenecks: Identifies task dependencies early so
you know exactly which tasks must be completed before the next ones
begin. [1, 2]
• Optimizes Resource Allocation: Ensures teams are not overburdened
and equipment is used efficiently without last-minute panic or added
costs. [1, 2]
• Enhances Stakeholder Communication: Provides a single, clear
reference point that keeps team members, clients, and management
aligned. [1, 2]
• Proactive Risk Mitigation: By laying out the entire project timeline, you
can identify potential roadblocks and build buffer times before they derail
the budget or deadline. [1, 2]
Project Scheduling Techniques
1. Critical Path Method (CPM)
CPM identifies the longest sequence of dependent tasks that dictate the
shortest possible completion time of a project. [1]
• Best for: Well-defined projects with clear task dependencies.
• How it works: It calculates the "earliest" and "latest" a task can start and
finish without causing delays (also known as total float or slack). Any delay
to tasks on the critical path directly pushes back the project deadline.
2. Program Evaluation and Review Technique (PERT)
PERT is a probabilistic technique used to estimate project durations when
there is high uncertainty or variability in task times. [1]
• Best for: Complex, non-repetitive projects in research, development, or
tech.
• How it works: Instead of a single time estimate, it uses a three-point
estimating method to find a weighted average: Optimistic (\(O\)),
Pessimistic (\(P\)), and Most Likely (\(M\)) durations
3. Gantt Charts
Gantt charts are visual, horizontal bar charts that plot project activities
against a timeline. They provide an intuitive, high-level view of what work is
happening, when it starts and ends, and how tasks overlap. [1, 2]
• Best for: Communicating project status to stakeholders and tracking
baseline progress.
• How it works: Each bar represents a distinct task, and its length
corresponds to its duration. They are widely used in software platforms to
manage dependencies. [1, 2, 3]
 Project mngt tool
 Cause-and-Effect (Fishbone/Ishikawa) Diagrams: Visualizes all potential causes of
a problem to identify the actionable root cause.
 Check Sheets: Simple, structured forms used to collect data on the frequency of
errors, defects, or specific values.
 Control Charts: Graphs used to monitor processes over time, establishing an average
(mean) to detect if a process is stable or experiencing variance.
 Histograms: Bar charts that display the statistical distribution and central tendency
of a given set of measurements.
 Pareto Charts: A hybrid bar/line graph based on the 80/20 rule, helping teams
visualize and prioritize the biggest causes of errors.
 Scatter Diagrams: X-Y plots that help teams identify a correlation or relationship
between two variables.

Types of Risk in Project Management

1. Scope Creep
This occurs when project requirements continuously expand beyond the original
scope. It leads to delays as additional work is added, resulting in resource
overruns and potential quality issues. S
2. Resource Constraints
A project may be delayed and not finished on schedule if there are insufficient
personnel, funds, electricity, or other resources available. A shortage of
resources can occur due to bad distribution of them low budgets or unexpected
deficits which will affect the ability for the project’s objectives within allocated
resources.
3. Schedule Slippage
Delays in project timelines can occur due to unforeseen circumstances,
insufficient planning, or external dependencies. Schedule slippage may result
from underestimated task durations, dependencies on external factors beyond
the project team's control, or changes in project scope, leading to missed
deadlines and increased project duration.
4. Budget Overruns
It is a common risk in projects that go over budget to have been caused by
incorrect estimates, changes in scope, or unforeseen costs. If expenses exceed
income this can lead to financial stress, lowered project quality, and the need for
more money to be raised to finish the work which will also affect organizational
stakeholder confidence.
5. Technical Risks
Projects dealing with difficult technology, infrastructure, or technical parts face
technical risks that can affect project delivery. Such dangers may comprise
technological breakdowns, compatibility problems, or unproven technologie's
dependence which will need expertise in this field as well as different solutions
to mitigate potential interruptions.
.
Aspect Forward Engineering Reverse Engineering

In reverse engineering or
In forward engineering, the
backward engineering, the
application are developed with
information are collected from
the given requirements.
Process the given application.

Reverse Engineering or
Forward Engineering is a high
backward engineering is a low
proficiency skill.
Skill Level proficiency skill.

While Reverse Engineering or

Forward Engineering takes more backward engineering takes
Development time to develop an application. less time to develop an
Time application.

The nature of reverse

The nature of forward
engineering or backward
engineering is Prescriptive.
Nature engineering is Adaptive.

In forward engineering, In reverse engineering,

Production production is started with given production is started by taking
Start Point requirements. the existing products.

The example of forward

An example of backward
engineering is the construction
engineering is research on
of electronic kit, construction of
Instruments etc.
Examples DC MOTOR , etc.