MODULE - 1

1. What is Software Engineering?

SOFTWARE ENGINEERING is defined as a systematic, disciplined, and quantifiable approach for the development,
operation and maintenance of software.
or
It is a process, collection of methods, array of tools used by professionals to create high quality computer software
or
Software Engineering is the product of two words, software, and engineering.
Software is more than just a program code. A program is an executable code, which serves some computational
purpose. Software is considered to be a collection of executable programming code, associated libraries and
documentations. Software, when made for a specific requirement is called a software product.
Engineering on the other hand, is all about developing products, using well-defined, scientific principles and
methods.

2. Software Processes:
• Communication (Communicate with Stakeholders)
• Planning (creating a software project plan)
• Modelling (Creating a Model or Sketch before starting the project)
• Construction (combines code generation and the testing)
• Deployment (S/w is delivered and it’s tested and feedback is given)

3. Waterfall Model:

The Waterfall Model, also called the classic life cycle, is a systematic, sequential approach to software development.
It begins with the customer specifying requirements and progresses through the following stages:
1. Communication: Understanding and gathering customer requirements.
2. Planning: Creating a project plan and defining resources, timelines, and objectives.
3. Modeling: Refining requirements into detailed technical representations.
4. Construction: Coding and implementing the software.
5. Deployment: Delivering the software and providing ongoing support.
Key Characteristics:
• It is the oldest paradigm for software engineering.
• The process flows linearly, resembling a waterfall, from one phase to the next.
• A variation called the V-model includes quality assurance activities aligned with the development phases.
Verification and validation actions are performed after each phase to ensure quality.
Advantages:
• Works well when requirements are well-defined and stable.
• Suitable for projects with clear objectives, like adaptations or enhancements to existing systems.
Disadvantages:
1. Real projects rarely follow a strictly linear flow, and indirect iteration can cause confusion.
2. Difficult to accommodate incomplete or uncertain requirements.
3. Customers must wait until late in the process to see a working version, increasing the risk of undetected
major errors.
4. Blocking states may occur, where some team members wait for others to complete dependent tasks, leading
to inefficiencies.

Use Case:
The Waterfall Model is appropriate for projects with fixed requirements and where work can proceed linearly to
completion. It is less suitable for fast-paced environments with frequent changes.

4. Software engineering process framework activities

1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).

5. V - Model

The V-Model is a variation of the waterfall model that emphasizes the relationship between quality assurance actions
and the steps associated with communication, modeling, and early construction activities in software development.
It visualizes the process as a "V" shape, with the following characteristics:
• Left Side of the V: Represents the refinement of problem requirements into progressively more detailed and
technical representations of the problem and its solution.
• Right Side of the V: Represents the validation and verification activities performed after code generation.
This includes a series of tests to validate each of the models created during the left-side activities.
The V-Model provides a structured way to link verification and validation activities to earlier engineering steps. While
it is similar to the classic waterfall model, the V-Model explicitly visualizes the integration of quality assurance actions
at every stage.
Key Features:
1. Progression Downward (Left Side): Detailed understanding and specification of the problem and solution.
 2. Progression Upward (Right Side): Validation and testing of the software against the requirements and
design.
3. Focus on Quality Assurance: Emphasizes systematic validation of each step to ensure alignment with initial
requirements.
Although there is no fundamental difference between the classic life cycle and the V-Model, the latter highlights the
role of quality assurance in the development process.

6. The Incremental Process Model

The Incremental Process Model is a software development approach that combines linear and parallel process flows
to produce the software in increments. It is particularly useful when initial requirements are well-defined, but the full
scope of development is too large for a purely linear process, or when there is a need to deliver functionality quickly
and refine it over time.
Key Features:
1. Delivery in Increments:
a. The software is built and delivered in smaller, manageable increments, each representing a subset of the
overall functionality.
b. Early increments provide basic, operational versions of the product, while later increments add additional
features and refinements.
2. Core Product First:
a. The first increment often includes a core product with basic requirements addressed.
b. Subsequent increments modify and enhance the core product based on user feedback and evaluation.
3. User Evaluation:
a. After each increment is delivered, users evaluate the product. This feedback helps refine future
increments.
4. Risk Management:
a. Early increments can be planned to address technical risks or dependencies, such as delays in new
hardware availability.
5. Flexible Staffing:
a. Initial increments can be implemented with fewer staff, and additional team members can be added for
later increments if needed.
Example:
In developing a word processor:
• The first increment might include file management, basic editing, and document production.
 • The second increment adds advanced editing and document production features.
• The third increment introduces spelling and grammar checking.
• The fourth increment provides advanced page layout capabilities.
Advantages:
• Delivers a working product early, even if incomplete.
• Provides a platform for user evaluation and feedback.
• Supports gradual development, enabling flexibility and risk mitigation.
• Useful when complete implementation cannot be achieved by the initial deadline.
Use Case:
The Incremental Process Model is ideal when quick delivery of functionality is required, when resources are limited
initially, or when technical risks need to be managed systematically.7
Example:
In developing a word-processing software:
1. First Increment:
a. Delivers basic functionality such as file management, basic editing, and simple document production.
2. Second Increment:
a. Adds more sophisticated editing capabilities and enhanced document production features.
3. Third Increment:
a. Introduces spelling and grammar checking functionality.

4. Fourth Increment:
a. Provides advanced page layout capabilities, such as headers, footers, and multiple-column layouts.
Each increment builds upon the previous one, with the core product delivered first and enhanced features added in
subsequent releases based on user feedback and evolving requirements.

7. The Spiral Model:

The Spiral Model, proposed by Barry Boehm, is an evolutionary software process model that combines the iterative
nature of prototyping with the structured and systematic approach of the Waterfall Model. It is particularly suited for
large-scale, complex systems and projects with significant risks.
Key Features:
1. Cyclic and Iterative Approach:
a. The software is developed through a series of evolutionary releases.
 b. Early iterations may produce prototypes or models, while later iterations yield progressively more
complete and functional versions of the software.
2. Risk-Driven Model:
a. The Spiral Model focuses on identifying and managing risks at every stage of development.
b. Each revolution around the spiral involves assessing and reducing risks before progressing further.
3. Anchor Point Milestones:
a. These are defined checkpoints that ensure stakeholder commitment to feasible and mutually satisfactory
solutions.
4. Framework Activities:
a. The spiral is divided into segments representing generic software engineering activities such as planning,
risk analysis, development, and evaluation.
b. Each cycle around the spiral consists of these activities and moves clockwise, starting from the centre.

5. Continuous Evolution:
a. The model allows the process to adapt throughout the software’s lifecycle, even after initial development
is complete.
b. It can represent concept development, new product development, or product enhancement.
Example Process:
1. First Circuit:
a. Develop a product specification or initial concept.
2. Subsequent Circuits:
a. Create prototypes and progressively more sophisticated versions of the system.
3. Later Circuits:
a. Develop the complete system, and later iterations may focus on product enhancements or adaptations.
Advantages:
• Facilitates better understanding of customer needs and technical risks.
• Provides flexibility to incorporate changes at any stage.
• Suitable for large and complex projects.
• Encourages continuous feedback and iterative improvement.
• Helps in managing risks effectively through prototyping and iterative analysis.
Disadvantages:
• Requires significant expertise in risk assessment.
• May be challenging to convince stakeholders of its controllability, especially in contract-based projects.
• Unmanaged risks can lead to project issues.
Use Case:
The Spiral Model is ideal for projects with evolving requirements, high risks, and large-scale systems where iterative
refinement and risk management are crucial. It remains active throughout the software lifecycle, adapting to changes
such as product enhancements or updates.

8. Software Challenges:
• Open-world Computing:
o What it is: This is about making software that helps different machines (like phones, computers, or servers)
communicate over large networks, such as the internet or wireless systems.
o Challenge: Making sure these machines can work together smoothly, even if they’re different types and
located far apart.
• Net Sourcing:
o What it is: This involves creating software that works over the internet and can be used by people all over
the world.
 o Challenge: Building apps that are easy to use globally and can handle a lot of users, while making sure they
work well in different countries and on different devices.
• Open Source:
o What it is: This is when the code of a software is shared for free, so others can modify and improve it.
o Challenge: Keeping the software reliable and secure while allowing anyone to contribute to it. Plus,
figuring out how to make money from free software.

9. Software Myths
Management Myths:
1. (Book of Standards is enough to build software)
Myth: We already have a book full of standards and procedures for building software. Won’t that provide my
people with everything they need to know?
Reality: A book of standards may exist, but it may not be used, might not reflect modern practices, be
complete, adaptable, or streamlined for quality and time-to-delivery.
2. (If project behind schedule then hire more programmers)
Myth: If we get behind schedule, we can add more programmers and catch up.
Reality: Adding people to a late project makes it later because existing team members must spend time
training new people, reducing productive work time.
3. (If I want to outsource a project, I will let them do it and me relax)
Myth: If I decide to outsource the software project to a third party, I can just relax and let that firm build it.
Reality: If the organization doesn't understand how to manage and control software projects internally,
outsourcing will lead to struggles and poor results.
Customer Myths:
1. (General Statement of objectives is enough to write code)
Myth: A general statement of objectives is sufficient to begin writing programs—we can fill in the details
later.
Reality: An ambiguous statement of objectives can lead to disaster. Clear, unambiguous requirements must
be developed through continuous communication.
2. (Software is flexible and can accommodate changes easily)
Myth: Software requirements continually change, but change can be easily accommodated because software
is flexible.
Reality: While software can accommodate change, the cost of change increases dramatically as the project
progresses, especially once design and code are underway.
Practitioner’s Myths:
1. (Once program is written then job is considered done)
Myth: Once we write the program and get it to work, our job is done.
Reality: Most effort in software development is spent after the program is delivered to the customer for the
first time, not during the initial development.
2. (Quality is not important only running code is enough)
Myth: Until I get the program "running" I have no way of assessing its quality.
Reality: Quality can be assessed early through technical reviews, which are more effective than testing in
finding certain defects.
3. (For delivery of project only the working program is enough)
Myth: The only deliverable work product for a successful project is the working program.
Reality: A working program is only one part of the project. Models, documents, and plans are also crucial for
successful engineering and support.
4. (Thinking that documentation will slow down the process)
Myth: Software engineering will make us create voluminous and unnecessary documentation and will
invariably slow us down.
Reality: Software engineering isn't about creating excessive documentation; it's about delivering a quality
product. Higher quality leads to reduced rework and faster delivery times.

10. Unique nature of Web Apps.

1. Network Intensive: Web apps run on networks and need to work for many users, whether it's the internet
(for global use) or a private network (like a company's internal network).
2. Concurrency: Many users might use the Web app at the same time, and each user may do different things.
3. Unpredictable Load: The number of users can change a lot. For example, one day there might be 100 users,
and the next day 10,000.
4. Performance: If the Web app takes too long to load or respond, users might leave and find another app.
5. Availability: Users want Web apps to be available all the time, 24/7, although it's unrealistic to expect them
to work perfectly all the time.
6. Data-Driven: Web apps often show text, images, videos, and other content. They may also get data from
other databases for things like online shopping or banking.
7. Content Sensitive: The quality and design of the content on the Web app matter a lot. Good content makes
the app more enjoyable and useful.
8. Continuous Evolution: Web apps are constantly updated, unlike traditional apps that get updates at set
times.
9. Immediacy: Web apps often need to be launched quickly, sometimes in just a few days or weeks, to meet
market demands.
 MODULE - 2
Negotiating requirements
In an ideal world, the process of understanding and defining customer needs (requirements engineering) would be
clear and straightforward. But in reality, it often involves a negotiation between the software team and the
stakeholders (e.g., customers, users, managers). These stakeholders must balance the desired features, performance,
and other aspects of the product with constraints like time, cost, and resources.
The goal of these negotiations is to create a plan that meets everyone's needs, while also being realistic about what
can be achieved given the available resources.
Here’s a simple breakdown of the negotiation process:
1. Identify Stakeholders: Find out who the key people (stakeholders) are that have a say in what the software
should do.
2. Understand Stakeholder Goals: Understand what each stakeholder needs from the system or software. What
are their "win conditions" (what will make them happy with the outcome)?
3. Negotiate and Find Common Ground: Work with the stakeholders to balance their goals and come up with a
solution that works for everyone, including the software team. This process should aim for a "win-win"
situation where both the customer and the software team get what they need.
The result of this negotiation is a set of agreed-upon requirements and expectations that guide the development of
the software.

Validating requirements
Validating requirements is the process of ensuring that the requirements are complete, consistent, and clear, and
that they align with the goals of the system. Each part of the requirements model is reviewed carefully to identify and
resolve any issues before moving forward in the development process.
Key Questions for Validation:
• Consistency with Objectives:
o Does each requirement align with the overall goals of the product or system?
• Appropriate Detail:
o Are the requirements at the right level of detail?
o Some requirements may include too much technical detail that isn’t needed at this stage.
• Necessity:
o Is the requirement truly needed, or is it an extra feature that doesn’t add significant value?
• Clarity and Boundaries:
o Are the requirements clear, well-defined, and free of ambiguity?
• Attribution:
 o Is the source of each requirement documented (e.g., a specific person or group)?
• Conflict-Free:
o Do any requirements contradict or overlap with each other?
• Feasibility:
o Can each requirement be realistically implemented given the current technical environment and
constraints?
• Testability:
o Once implemented, can the requirement be tested to verify that it works as expected?
• Model Accuracy:
o Does the requirements model correctly represent the necessary information, functions, and behavior of
the system?
• Partitioning:
o Is the model divided into sections that progressively reveal more detailed information?

• Patterns:
o Have reusable requirements patterns been used?
o Are these patterns validated and aligned with customer needs?
Outcome:
The goal of these steps is to ensure that the requirements model:
• Reflects stakeholder needs accurately.
• Provides a reliable foundation for the design phase.
By asking and addressing these questions, you can reduce errors, avoid rework later, and ensure a smoother
development process.

Key Steps in Establishing the Groundwork for a Successful Software Engineering Project
1. Identifying Stakeholders
Sommerville and Sawyer define a stakeholder as “anyone who benefits in a direct or indirect way from the
system which is being developed.” Stakeholders may include business operations managers, product
managers, marketing personnel, internal and external customers, end users, consultants, product engineers,
software engineers, and support and maintenance engineers.
• Each stakeholder has a different view of the system, benefits differently from its success, and faces
different risks in case of failure.
• At inception, create a list of people who will contribute input as requirements are elicited. This list will
grow as stakeholders are contacted.
2. Recognizing Multiple Viewpoints
o Requirements will be explored from multiple perspectives, such as:
▪ Marketing focusing on marketable functions and features.
▪ Business managers interested in budgets and timelines.
▪ End users preferring ease of use and familiarity.
▪ Engineers concerned with infrastructure and maintainability.
o Stakeholder information (including inconsistent and conflicting requirements) should be categorized to
allow decision-makers to choose an internally consistent set of requirements.
3. Working Toward Collaboration
• Stakeholders may have conflicting opinions about requirements.
• The requirements engineer identifies commonalities and resolves conflicts or inconsistencies.
• A strong project champion (e.g., a business manager or senior technologist) may make final decisions
about requirements.
 4. Asking the First Questions
Questions at project inception should be context-free and fall into three categories:
• Questions about stakeholders, goals, and benefits:
▪ Who is behind the request for this work?
▪ Who will use the solution?
▪ What will be the economic benefit of a successful solution?
• Questions to understand the problem and solution environment:
▪ How would you characterize “good” output from the solution?
▪ What problem(s) will the solution address?
▪ Will performance issues or constraints affect the solution approach?
• Meta-questions to ensure effective communication:
▪ Are you the right person to answer these questions?
▪ Are my questions relevant?
▪ Should I be asking anything else?
These steps help “break the ice,” initiate essential communication, and prepare for more detailed elicitation and
specification.

Requirements Engineering
Requirements engineering is the structured process of understanding, defining, and managing the requirements for a
software system. It builds a bridge between the initial customer needs and the design and construction of the
software. The process involves the following tasks:
1. Inception
o Projects begin with a business need or an opportunity in a new market or service.
o Stakeholders define a business case, conduct feasibility analysis, and describe the project scope.
o The focus is on establishing a basic understanding of the problem, the desired solution, and the
stakeholders involved.
2. Elicitation
o The objective is to gather requirements by understanding customer and user objectives.
o Challenges include problems of scope (ill-defined system boundaries), understanding (stakeholders'
incomplete knowledge or communication difficulties), and volatility (changing requirements over time).
o Requirements gathering must be approached in an organized manner to address these issues.
3. Elaboration
o Information from inception and elicitation is refined to create a detailed requirements model.
o User scenarios drive the identification of analysis classes, their attributes, and required services.
o Relationships and collaborations between classes are identified, often supported by supplementary
diagrams.
4. Negotiation
o Conflicts among requirements, often due to limited resources or differing stakeholder priorities, are
reconciled.
o Stakeholders rank requirements, and iterative discussions prioritize them based on cost, risk, and
importance.
o The goal is a compromise that provides satisfaction to all parties.
5. Specification
o Requirements are documented in various formats, such as written documents, graphical models,
mathematical models, usage scenarios, or prototypes.
o For large systems, a combination of natural language descriptions and graphical models is used, while
smaller systems may rely solely on scenarios.
o Flexibility is important, but consistency in presentation can enhance understanding.
 6. Validation
o Ensures requirements are unambiguous, consistent, complete, and aligned with standards.
o The primary mechanism is technical reviews involving software engineers, customers, users, and other
stakeholders.
o The review identifies errors, clarifies ambiguities, and resolves inconsistencies or conflicts.
7. Requirements Management
o As requirements change throughout the system's lifecycle, this task helps the team identify, control, and
track these changes.
o Activities align with software configuration management practices to ensure consistency and traceability.
Requirements engineering provides a structured approach to understanding customer needs, analyzing feasibility,
specifying solutions, and managing changes, creating a strong foundation for successful software development.
Summary:
In this example, the restaurant owner and the app developers go through the requirements engineering process to
make sure they build an app that meets customer needs and can evolve over time. The process includes:
• Inception: Clarifying the business need.
• Elicitation: Gathering input from users and stakeholders.
• Elaboration: Creating a detailed plan and design.
• Negotiation: Resolving conflicts and prioritizing features.
• Specification: Writing down the requirements clearly.
• Validation: Ensuring the requirements are correct and complete.
• Requirements Management: Handling changes as the project moves forward.
This structured approach helps avoid confusion, ensures the right features are built, and makes sure the app is
successfully delivered to meet everyone’s expectations.

Camera surveillance via Internet – display camera views function (Activity and Swimlane diagram)

Activity Diagram
The activity diagram illustrates the process flow for accessing and viewing camera surveillance via the Internet. It
follows the steps below:
1. Enter Password and User ID:
 o The user begins by entering their user ID and password credentials.
2. Validation of Credentials:
o If the entered user ID and password are valid, the system proceeds to the next step.
o If the credentials are invalid, the system prompts the user for reentry. If the user exhausts all attempts,
access is denied.
3. Selecting Major Functionality:
o Once logged in, the user is presented with major functional options. In this case, the user selects the
"Surveillance" functionality.

4. Choosing a Camera:
o The user has two options to view cameras:
▪ Thumbnail Views: Select this to see snapshots from all cameras at once.
▪ Specific Camera Icon: Select a specific camera by choosing its icon from a displayed floor plan.
5. Viewing the Camera Output:
o After selecting a camera, the system displays a labeled window showing the camera's video output at a
frame rate of one frame per second.
6. Prompt for Another View:
o Once the user views the selected camera feed, they are prompted if they want to view another camera. If
yes, the process loops back to camera selection.
o If the user opts not to view another camera, the function exits.

Swimlane Diagram
The swimlane diagram depicts the same functionality as the activity diagram but organizes the process flow into
distinct lanes that represent different actors or components involved in the system. These lanes clarify the
responsibilities of each entity—Homeowner, Camera, and Interface—in the process.
Swimlanes and Process Flow
1. Homeowner:
o The homeowner initiates the process by entering their user ID and password in the system.
o After successful authentication, they select the desired major function (in this case, "Surveillance").
o They then decide between viewing all cameras as thumbnails or selecting a specific camera icon from the
house's floor plan.
o Once the desired camera is chosen, they view the camera output in a labeled window.
o Finally, they are prompted to either view another camera or exit the function.
2. Interface:
o The system validates the user ID and password:
▪ If the credentials are valid, it allows access to the major functions.
▪ If the credentials are invalid, the system prompts for reentry. If all input attempts are exhausted,
access is denied.
o The interface displays available major functions to the user.
o It also manages the interaction by presenting either the thumbnails of all cameras or the house's floor
plan with selectable camera icons.
o The interface handles the output, displaying the video feed in a labeled window and presenting prompts
for further actions (e.g., viewing another camera or exiting).
3. Camera:
 o The camera component comes into play when a specific camera is selected. It generates the video
output, which is displayed in the labeled window.
Key Features of the Swimlane Diagram
• Role-based Responsibilities: The swimlanes clearly delineate the roles of the homeowner (user interactions),
interface (system validation, interaction management), and camera (data generation).
• Sequential Flow: The flow of actions from the homeowner to the system and back ensures clarity in the
interaction between user actions and system responses.
• Decision Points: The diagram incorporates decision points for validation (valid/invalid credentials), viewing
options (thumbnails or specific camera), and continuation (view another camera or exit).

Class-Based Modeling and Identifying Analysis Classes

Class-based modeling helps us represent the objects a system will work with, the actions (or methods) that will be
performed on them, their relationships, and how they interact with each other. The key parts of a class-based model
include classes, objects, attributes, operations, and relationships between the classes.
Identifying Analysis Classes
To identify analysis classes in a system, we begin by examining the use cases (scenarios describing how the system
will work). We focus on nouns or noun phrases in these use cases because they typically represent potential classes
in the system. After identifying these nouns, we classify them into categories based on their role in the system (such
as objects, events, roles, etc.).
The classes we are looking for may appear in several ways:
o External entities: These can be systems, devices, or people that either produce or consume information in the
system.
o Things: These are objects in the problem domain (like reports or signals).
o Occurrences or events: These are actions or events that happen in the system (e.g., a property transfer).
o Roles: These represent the roles played by people interacting with the system (e.g., manager or engineer).
o Organizational units: These represent groups, teams, or divisions relevant to the system.
o Places: Locations that provide context for the system (e.g., a manufacturing floor).
o Structures: These represent systems of objects (e.g., sensors or computers).
In general, we avoid using procedural names (like "InvertImage") as classes because the goal is to separate data
(objects) from operations (methods) on that data.
Example: SafeHome Security System
Let's look at how analysis classes are identified in the SafeHome security system:
The SafeHome system includes various components like sensors, alarms, and control panels. By going through a
grammatical parse of the system’s narrative, we can extract potential classes:
o Homeowner: A person who interacts with the system (role).
o Sensor: A device that detects changes (external entity).
o Control panel: A device that allows the homeowner to interact with the system (external entity).
o System: The core security system itself (thing).
o Sensor event: An occurrence when a sensor is triggered (event).
o Audible alarm: A device that produces an alarm sound (external entity).
o Monitoring service: An external service that monitors the system (organizational unit).
Once we've identified potential classes, we must evaluate them based on six characteristics:
o Retained information: Does the class hold important information the system needs to function?
o Needed services: Does the class perform operations or services (methods)?
o Multiple attributes: Does the class have multiple attributes (properties)?
o Common attributes: Do all instances of the class share similar attributes?
 o Common operations: Do all instances of the class have similar operations?
o Essential requirements: Is the class essential for the system to operate?
Using these criteria, we assess the classes:
o Homeowner: Rejected because it does not hold significant information or perform operations.
o Sensor: Accepted because it holds information and performs important operations.
o Control panel: Accepted because it has multiple attributes and operations.
o System: Accepted as it is central to the SafeHome security system.
o Sensor event: Accepted as it represents an important event.
o Audible alarm: Accepted due to its role in the system’s operation.
o Monitoring service: Rejected as it doesn't provide necessary services.

MODULE - 3
Agile Process and its principles
An Agile Process is a software development approach designed to handle unpredictability in project requirements,
customer priorities, and technical needs. It emphasizes adaptability and collaboration, enabling teams to respond to
changes effectively while maintaining progress.
Agile processes acknowledge the following challenges in software projects:
1. It is hard to predict which software requirements will stay the same and which will change. Customer
priorities also evolve during the project.
2. Design and construction activities are often interwoven and should be done together to validate the design as
it is created.
3. Planning for analysis, design, construction, and testing is less predictable than desired.
To address these challenges, agile processes focus on adaptability. However, adapting without progressing is
unproductive, so agile development uses incremental adaptation—delivering small, executable portions of the
software (prototypes or operational parts) within short timeframes.
This approach ensures regular feedback from customers, allowing teams to refine the software to meet evolving
requirements. Through frequent deliveries and iterations, agile methods enable continuous evaluation,
improvement, and alignment with customer needs.
The Agile Alliance has outlined 12 principles for achieving agility:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the
customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the
shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust
them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-
to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self–organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly.
The Extreme Programming Process

EXTREME PROGRAMMING (XP)

Extreme Programming (XP) is one of the most widely used agile software development approaches. While the ideas
and methods associated with XP emerged in the late 1980s, the seminal work on XP was written by Kent Beck in the
1990s. A variant of XP, called Industrial XP (IXP), has been developed for large organizations, refining XP to better suit
the needs of such environments.

XP Values

1. Communication
o Effective communication is essential in XP. To ensure that developers and stakeholders (e.g., customers) are
aligned, XP promotes close, informal (verbal) collaboration.
o A key communication tool in XP is the use of metaphors. In this context, a metaphor is a simple, shared
story that everyone—customers, programmers, and managers—can use to understand how the system
works. This helps ensure everyone is on the same page regarding the system’s design and functionality.
o XP also emphasizes continuous feedback over extensive documentation as a means of communication.

2. Simplicity
o In XP, the focus is on designing for immediate needs rather than anticipating future requirements. The
goal is to create the simplest design that can be easily implemented.
o If future needs arise, the design can be refactored later. The emphasis on simplicity helps keep the
codebase clean and manageable, reducing the complexity of the system and avoiding unnecessary
features that may never be needed.

3. Feedback
o XP encourages continuous feedback from multiple sources:
o The software itself: Feedback is gathered through testing (unit tests for code functionality) to
ensure the software behaves as expected.
o The customer: Feedback is collected from the customer on delivered increments, using user stories
or use cases as the basis for acceptance tests. This helps gauge the software’s alignment with
customer needs and expectations.
o The development team: Feedback is provided by team members to each other to improve the
overall software quality and team collaboration.
o Regular feedback helps the team make adjustments early, ensuring the software stays on track and
aligned with customer needs.

4. Courage
o XP requires courage to stick to certain practices, even when faced with challenges. For example, there is
often pressure to design for future requirements. Many teams might argue that designing for tomorrow’s
needs will save time in the long run. However, XP advocates for designing only for today’s needs,
understanding that future requirements will likely change.
 o By adhering to this principle, teams avoid the risk of overcomplicating the design and creating
unnecessary code that may never be used. This courage to stick to the immediate needs allows for
flexibility and adaptability as requirements evolve.

5. Respect
o Respect is integral to the XP process. It fosters a positive environment within the team and between
stakeholders. Respect is developed through the team's interactions, such as giving constructive feedback
and acknowledging each other's contributions.
o As the team successfully delivers software increments and sees the value of their collaboration, mutual
respect grows, which strengthens the process and team cohesion.

XP Process
Extreme Programming (XP) follows an object-oriented approach and organizes development into four key activities:
planning, design, coding, and testing. Here’s a summary of each activity:

• Planning: The planning phase begins with listening to gather requirements and create "user stories" that
describe software features. Each story is assigned a business value and estimated cost (in development
weeks). If a story is too large, it’s split into smaller ones. The customer and developers prioritize stories for
the next release, focusing on value, risk, or immediate implementation. After each release, the XP team
computes project velocity to guide future estimations. Customers can modify stories throughout the project.
• Design: XP prioritizes simplicity in design. The design is minimal, supporting only what’s necessary for the
current stories. CRC (Class-Responsibility-Collaborator) cards help organize the object-oriented classes
relevant to the release. If a design issue arises, an operational prototype (spike solution) is created to validate
the design. Refactoring plays a key role in improving internal code structure without altering external
behavior. Design is iterative and evolves as the code is written.
• Coding: Before coding, unit tests are developed for each story to guide the implementation. Coding is done
using pair programming, where two developers work together at one workstation—one focuses on coding,
while the other ensures adherence to standards and tests. Code is integrated regularly, often daily, to avoid
compatibility issues.
• Testing: Unit tests are created before coding begins, and they are automated for continuous regression
testing. The entire system undergoes daily integration and validation testing, providing early feedback on
progress and issues. Customer-defined acceptance tests verify that the software meets the required
functionality.

Tool Set for Agile Process

The Agile philosophy emphasizes tools that foster collaboration, communication, and team efficiency. These tools are
categorized into several key areas:

• Social Tools: These tools aid in team-building activities, starting from the hiring stage. For example, a
prospective team member might pair program with an existing member to assess their compatibility and
skills immediately.

• Collaborative and Communication Tools: Generally low-tech, these tools support active and passive
communication among team members. Examples include physical tools like whiteboards, sticky notes, and
poster sheets for team interaction, as well as information radiators (e.g., flat panel displays) that passively
show project statuses.

• Project Management Tools: Agile teams use tools that de-emphasize traditional Gantt charts and instead
employ earned value charts, test progress graphs, and other visual aids that track development and testing
progress effectively.
 • Environment Optimization Tools: Tools that improve team culture and working environments are crucial.
Examples include optimized meeting spaces, collocated teams, and devices like electronic whiteboards to
enhance collaboration.

• Process Enhancement Tools: Tools that promote core Agile practices like pair programming and time-boxing
are integral to maintaining agility and efficiency in development processes.

In essence, tools in Agile are not limited to technology; they include any mechanisms that facilitate teamwork,
enhance productivity, and improve the quality of the final product.

Principles that guide each Framework Activity

i. Communication Principles
1. Listen: Focus on the speaker's words without preparing your response in advance. Ask for clarification
when needed but avoid interrupting or reacting negatively.
2. Prepare: Understand the problem and research business jargon before meetings. If you're leading,
prepare an agenda.
3. Facilitate: Assign a leader to guide discussions, mediate conflicts, and ensure effective communication.
4. Face-to-Face Communication: Communicate directly when possible, using drawings or documents to
aid discussions.
5. Document Decisions: Assign someone to take notes and record important points and decisions.
6. Collaborate: Use team knowledge to describe functions or features, fostering trust and shared goals.
7. Stay Focused: Keep discussions modular and resolve one topic before moving to the next.
8. Use Visuals: Sketch or draw to clarify concepts when words are insufficient.
9. Move On: Agree or disagree quickly, and revisit unclear topics later to maintain momentum.
10. Negotiate Fairly: Approach negotiations as a win-win, aiming for compromises that align with team
goals.

ii. Planning Principles (Simplified Points)

1. Understand Project Scope: Define where the project is headed to guide the team effectively.
2. Involve Stakeholders: Include stakeholders to set priorities, constraints, and negotiate delivery
timelines.
3. Planning is Iterative: Plans should adapt to changes and feedback throughout the project lifecycle.
4. Estimate with Available Information: Base effort, cost, and duration estimates on current
understanding.
5. Consider Risks: Account for high-impact risks and adjust the plan with contingencies.
6. Be Realistic: Factor in human limitations, communication challenges, and inevitable changes.
7. Adjust Granularity: Use detailed plans for short-term tasks and broader plans for long-term goals.
8. Ensure Quality: Clearly define and schedule quality assurance practices like reviews or pair
programming.
9. Accommodate Change: Plan for how and when changes will be assessed and implemented.
10. Track Progress Frequently: Monitor daily, address issues promptly, and adjust the plan as needed.

iii. Modeling Principles (Simplified Points)

1. Focus on Building Software: Models should aid software delivery without slowing it down.
2. Keep Models Minimal: Create only necessary models to avoid wasting time and effort.
3. Simplify Models: Use simple models to make software easier to understand, test, and maintain.
4. Design for Change: Build models with the assumption that changes will occur but maintain quality.
5. Define Model Purpose: Create models only when there is a clear and justified need for them.
 6. Adapt Models to the System: Tailor modeling techniques to suit the specific application.
7. Strive for Usefulness Over Perfection: Build effective models without overinvesting in unnecessary
details.
8. Prioritize Communication: Focus on conveying information over strict adherence to model syntax.
9. Trust Your Instincts: If a model feels wrong, investigate further even if it looks fine on paper.
10. Seek Early Feedback: Have team members review models to identify and fix issues quickly.

iv. Construction Principles (Key Points)

Coding Principles
1. Preparation:
a. Fully understand the problem and design principles before starting.
b. Choose the appropriate programming language and tools.
c. Design unit tests before coding begins.
2. Programming:
a. Use structured programming practices.
b. Employ pair programming if beneficial.
c. Select suitable data structures and interfaces aligned with architecture.
d. Simplify logic and loops for readability and testability.
e. Use meaningful variable names, follow coding standards, and write self-documenting code.
f. Apply clean formatting for easy comprehension.
3. Validation:
a. Conduct code walkthroughs as necessary.
b. Perform unit tests and address any discovered errors.
c. Refactor to improve code quality.

Testing Principles
1. Trace to Requirements:
a. All tests should be designed to ensure software meets customer requirements.
2. Plan Early:
a. Begin planning tests as soon as the requirements model is completed.
b. Design detailed test cases after solidifying the design model.
3. Pareto Principle:
a. Focus on the critical 20% of components that likely contain 80% of the errors.
4. Progressive Testing:
a. Start testing with small, individual components and gradually test larger integrated systems.
5. Exhaustive Testing is Impossible:
a. Aim for adequate path coverage rather than attempting every possible path combination.

v. Deployment Principles
Overview of Deployment Activities
Deployment involves delivery, support, and feedback. It is an ongoing process due to the incremental nature of
modern software development models. Each deployment provides operational increments, ensuring iterative
refinement and responsiveness to user needs.
1. Manage Customer Expectations:
a. Clearly communicate what will be delivered in each increment.
b. Avoid overpromising or underdelivering, as this leads to dissatisfaction and morale issues.
c. Align deliverables with customer expectations through careful communication.
2. Assemble and Test a Complete Delivery Package:
a. Include executable software, support files, documentation, and installation scripts in the delivery
package.
 b. Conduct comprehensive beta testing with real users and configurations to ensure compatibility and
reliability.
3. Establish a Support Regime:
a. Plan and organize support in advance.
b. Provide accurate responses to user queries or issues through prepared materials and structured record-
keeping.
c. Analyze support trends to improve future increments.
4. Provide Instructional Materials:
a. Deliver user-friendly training aids and troubleshooting guides.
b. Include documentation on updates and changes in new increments for clarity.
5. Fix Bugs Before Delivery:
a. Ensure software is high quality by addressing bugs before release.
b. Avoid relying on post-delivery fixes, as poor quality erodes user trust and satisfaction.

Software Engineering Knowledge

Software engineering knowledge encompasses the principles, methods, tools, and practices used to design, develop,
test, and maintain high-quality software systems efficiently and effectively. It combines insights from computer
science, project management, quality assurance, and systems engineering to produce reliable, maintainable, and
scalable software.
Software engineering knowledge refers to two types of knowledge:
1. Knowledge of specific technologies: This includes understanding details about technologies like Java, Perl, C,
Linux, Windows NT, etc. This knowledge is necessary for performing tasks like programming.
2. Software engineering principles: These are foundational ideas or core principles that guide software
engineers in their work. Unlike technology-specific knowledge, these principles do not become obsolete
quickly and are expected to remain useful throughout a professional programmer’s career. McConnell
suggests that the core principles represent about 75% of the knowledge needed to develop complex systems.

Core Principles
Software engineering knowledge encompasses the principles, methods, tools, and practices used to design, develop,
test, and maintain high
Principles That Guide Process
1. Be agile: Emphasize simplicity, concise work products, and local decision-making, regardless of the process
model you choose.
2. Focus on quality at every step: Ensure that every process activity results in high-quality work products.
3. Be ready to adapt: Adapt your process approach as needed based on the project's constraints, people, and
problems.
4. Build an effective team: Create a self-organizing team built on mutual trust and respect.
5. Establish mechanisms for communication and coordination: Address management issues to prevent
information gaps and ensure successful collaboration.
6. Manage change: Implement processes to manage how changes are requested, assessed, approved, and
implemented.
7. Assess risk: Identify potential issues in software development and establish contingency plans.
8. Create work products that provide value for others: Produce work products that deliver clear, useful
information for the next stage in the process.
Principles That Guide Practice
1. Divide and conquer: Break down large problems into smaller, manageable concerns that can be developed
and validated independently.
 2. Understand the use of abstraction: Use simplified representations of complex elements to communicate
meaning and gradually refine these models during analysis and design.
3. Strive for consistency: Maintain consistency in elements like design, user interfaces, and code to make
software easier to use and understand.
4. Focus on the transfer of information: Pay close attention to interfaces, ensuring that information transfer is
clear and accurate, minimizing errors or ambiguities.
5. Build software that exhibits effective modularity: Design software in modules that focus on one specific
aspect and ensure they interact simply with low coupling to other modules.
6. Look for patterns: Identify recurring problems in software development and use patterns to provide proven
solutions and create a shared understanding within the development community.
7. Represent the problem and its solution from different perspectives: Examine problems and solutions from
multiple viewpoints to gain deeper insight and uncover errors.
8. Remember that someone will maintain the software: Consider long-term maintenance when designing
software, ensuring it is easy to correct, adapt, and enhance over time.

Other Agile Process Models

• Adaptive Software Development (ASD)
• Scrum
• Dynamic Systems Development Method (DSDM)
• Crystal
• Feature Drive Development (FDD)
• Lean Software Development (LSD)
• Agile Modeling (AM)
• Agile Unified Process (AUP)

Adaptive Software Development (ASD)

• ASD focuses on human collaboration and team self-organization.
• Phases: Speculation, Collaboration, and Learning.
• Speculation: Defines release cycles using customer input and project constraints.
• The plan changes after each cycle based on new information.
• Collaboration emphasizes trust, teamwork, and individual creativity.
• Trust allows for constructive criticism, assistance, and effective communication.
• Learning helps teams improve understanding through focus groups, reviews, and postmortems.
• ASD’s emphasis on collaboration and learning increases project success chances.

SCUM
• Scrum is an agile software development method created by Jeff Sutherland in the 1990s, with further
development by Schwaber and Beedle.
• Principles align with the agile manifesto, guiding activities like requirements, analysis, design, evolution, and
delivery.
• Work tasks are organized into sprints, which are defined and adapted in real-time by the Scrum team.
• Backlog: A prioritized list of project requirements that provide business value and can be updated at any time.
 • Sprints: Short-term, stable work units aimed at achieving backlog requirements within a predefined time-box
(typically 30 days).
• Scrum meetings: Daily 15-minute meetings where team members answer three key questions about their
progress, obstacles, and plans.
• A Scrum master leads the meetings, helping uncover problems and promoting a self-organizing team.
• Demos: Deliver software increments to customers for evaluation, with available functionality within the time-
box.
• Scrum assumes chaos and uses process patterns to work effectively in uncertain environments.

Dynamic Systems Development Method (DSDM)

• DSDM (Dynamic Systems Development Method) is an agile approach for building systems under tight time
constraints, using incremental prototyping.
• The 80/20 rule: 80% of an application can be delivered in 20% of the time required to complete the full
application.
• DSDM is iterative, with each increment requiring only enough work to progress to the next increment,
completing details later as more requirements emerge.
• The DSDM life cycle includes:
o Feasibility study: Assesses business requirements and application viability.
o Business study: Defines functional and information requirements, architecture, and maintainability.
o Functional model iteration: Creates incremental prototypes for customer feedback and requirement
gathering.
o Design and build iteration: Refines prototypes to ensure they provide operational business value.
o Implementation: Deploys software increment into the operational environment, with potential
changes to be addressed.
• DSDM can be combined with XP for a stronger process model, integrating XP practices with DSDM’s
lifecycle.
• Collaboration and self-organizing teams from ASD can also be adapted into this combined approach.

Crystal
• Crystal is a family of agile methods created by Alistair Cockburn and Jim Highsmith, focused on
"maneuverability" in software development.
• It treats software development as a cooperative game, aiming to deliver useful, working software and
prepare for the next project phase.
• The Crystal family offers different methodologies, each with common core elements but unique roles,
processes, work products, and practices tailored to specific project needs.
• Teams can select the most appropriate Crystal methodology based on their project type and environment.

Lean Software Development (LSD)

• Lean Software Development (LSD) adapts principles from lean manufacturing to software engineering.
• Key lean principles for LSD include: eliminate waste, build quality in, create knowledge, defer commitment,
deliver fast, respect people, and optimize the whole.
• Eliminating waste in software projects means avoiding unnecessary features, streamlining processes,
improving communication, and minimizing delays in decision-making.
 • The approach aims to create more efficient software development by reducing inefficiencies and focusing on
value delivery.

What is Agility?
Agility is the ability to respond quickly and effectively to changes while maintaining focus on delivering value. In
software development, it refers to the capability of teams to adapt to evolving requirements, feedback, and
technological advancements, ensuring high-quality, customer-centric outcomes. Agility emphasizes flexibility,
iterative progress, and collaboration to meet the demands of dynamic environments.

Agility and the Cost of Change

• In traditional software development, the cost of change increases nonlinearly as a project progresses.
• Changes are easier and less costly early in the project, during the requirements gathering phase.
• As the project advances, especially during testing, making changes becomes much more expensive, requiring
significant modifications to design, components, and tests.
• Agile proponents argue that agile processes help flatten the cost of change curve, making it easier to
accommodate changes late in the project.
• Incremental delivery, continuous unit testing, and pair programming in agile development help reduce the
impact of changes on time and cost.
 MODULE - 4

Project Management Life Cycle

1. Project Initiation
Definition
This is the foundational phase where the project’s feasibility, objectives, and scope are determined. It involves
conceptualizing the project and assessing its viability.
Key Activities
1. Concept Development: Identify the software’s characteristics, scope, constraints, and expected benefits.
2. Feasibility Study: Evaluate the technical and financial feasibility of the project.
3. Business Case Development: Create a business case outlining the benefits and justifications for undertaking
the project.
4. Charter and Team Formation: Prepare a project charter, appoint a project manager, and form the project
team.
5. W5HH Principle: Answer the following questions to define key project characteristics:
o Why is the software being built?
o What will be done?
o When will it be done?
o Who is responsible?
o Where are the resources located?
o How will it be done technically and managerially?
o How much effort or cost is required?
2. Project Planning
Definition
In this phase, detailed plans are developed to guide project execution. This includes timelines, budgets, resources,
and risk management strategies.
Key Activities
1. Define tasks, milestones, and deliverables.
2. Develop a project schedule with timelines and dependencies.
3. Allocate resources and estimate costs.
4. Create risk management and quality assurance plans.
5. Plan for communication and stakeholder engagement.
3. Project Execution
Definition
This phase involves implementing the project plan to achieve the project objectives. Resources are utilized, and
deliverables are created during this phase.
Key Activities
1. Coordinate team activities and manage workflows.
2. Ensure quality through testing and reviews.
3. Resolve conflicts and issues that arise during execution.
4. Communicate progress to stakeholders regularly.
4. Project Monitoring and Controlling
Definition
This phase ensures that the project stays on track by continuously monitoring progress and addressing deviations.
Key Activities
1. Track performance against the project plan.
2. Implement corrective measures for variances.
3. Update stakeholders about progress and changes.
4. Perform quality control to ensure deliverables meet requirements.
5. Project Closure
Definition
This is the final phase where the project is completed, and deliverables are handed over to the client or stakeholders.
It includes evaluating project performance and extracting lessons for future projects.
Key Activities
1. Finalize all project deliverables.
2. Conduct post-project evaluation and gather feedback.
3. Release project resources, including team members and equipment.
4. Document lessons learned and best practices.
Project Bidding (Within the Initiation Phase)
Definition
Project bidding is the process of inviting external vendors or contractors to propose solutions based on cost and
performance criteria. It is used when the project requires external expertise or services.
Types of Bidding Techniques
1. Request for Quotation (RFQ)
o Issued when the scope and requirements are clear.
o Example: A company purchasing specific IT hardware may issue an RFQ with detailed specifications.
2. Request for Proposal (RFP)
o Used when the organization understands the problem but needs vendors’ expertise for solutions.
o Example: A business looking to implement a CRM system may issue an RFP for vendor proposals.
 3. Request for Information (RFI)
o Used to gather preliminary information about vendors' capabilities.
o Example: A government agency seeking to shortlist vendors for a new transportation system may issue
an RFI.

Activities covered by software project management

1. Feasibility Study
o Assesses if the project has a valid business case and is worth starting.
o Gathers information on requirements, costs, and benefits.
o Handles complexities in requirements elicitation and aligns with stakeholders' goals.
o May be a standalone project or part of a broader strategic planning exercise.
2. Planning
o Begins after a positive feasibility study outcome.
o For large projects, involves an outline plan for the whole project and detailed plans for the first stage.
o Later stages are planned incrementally as more information becomes available.
3. Project Execution
o Involves sub-phases such as design and implementation.
o Design focuses on decisions about product form (e.g., user interface and internal architecture).
o Planning specifies activities to create products and is influenced by design decisions.
o For instance, a product with five major components requires activities tailored to each component.

Various stages of contract management.

Contract management in the context of ICT projects involves collaboration between the client organization and
external developers. The client organization appoints a project manager to supervise the contract and ensure the
project remains on budget and on schedule. This manager delegates technical decisions to contractors, focusing on
overarching goals rather than specific technical details, such as estimating the effort for individual software
components.
On the supplier side, project managers address technical issues to ensure that the development process aligns with
the contract's requirements. This book focuses on the responsibilities of these technical project managers, who are
instrumental in navigating the technical aspects of project execution while meeting the contract's goals.

Risk Evaluation
Every project involves risks. Here, we focus on business risk, which relates to the potential for the project’s outcomes
to be unprofitable, distinct from project risks, which prevent the project from being completed.
Risk Identification and Ranking:
To evaluate risks, it's important to identify them and assess their impacts. One way to do this is by creating a project
risk matrix, where risks are ranked based on their importance and likelihood. For instance, some risks may be severe
but unlikely, while others are less severe but highly likely. This helps prioritize risks that are most important. A sample
risk matrix for an e-commerce project is shown, categorizing risks as high (H), medium (M), low (L), or exceedingly
unlikely (-).
The matrix helps evaluate projects by comparing risks, where projects with higher risks might be less favoured.
Risk and Net Present Value (NPV):
When evaluating risky projects, it’s common to apply a higher discount rate for calculating NPV. For example, a safer
project might have an additional 2% rate, while a riskier one may have 5%. This creates a consistent way to
incorporate risk into the decision-making process.
Cost-Benefit Analysis:
A more advanced method involves estimating the probability of different outcomes and their potential value. Instead
of using a single cash flow forecast, this approach considers multiple possible outcomes, each with a corresponding
probability. By summing the weighted costs or benefits, you get a clearer picture of the project’s value. This method
works well for large projects, like building highways, where certain variables (e.g., traffic volume) are uncertain.
However, this approach might not fully account for worst-case scenarios. It’s better suited for evaluating a portfolio
of projects, where profitable projects balance out the less successful ones.
Risk Profile Analysis:
To address concerns with cost-benefit averaging, sensitivity analysis can be used to understand how sensitive the
project’s profitability is to different factors. By changing key assumptions (e.g., cost estimates) and recalculating the
expected results, you can identify the most critical factors affecting the project. This allows you to manage or mitigate
risks more effectively.
Using Decision Trees:
Unlike previous methods, decision trees allow active decision-making. They help evaluate the potential outcomes of
different choices and the impact on future project profitability. For example, a company may be deciding when to
replace its sales system. The decision depends on market growth, which is uncertain. If the market grows, replacing
the system now could lead to a higher benefit, but if the market doesn't grow, it might cause a loss. By assigning
probabilities to these outcomes, a decision tree helps calculate the expected value of each choice, guiding the
company in making the most profitable decision.
In the example, the expected value of extending the system is £40,000, while replacing it now has an expected value
of £10,000. Therefore, the company should choose to extend the existing system.

Cost-benefit Evaluation Techniques

• Net Profit:
o Net profit is the difference between a project’s total costs and total income over its entire life.
o Project 2 shows the highest net profit, but it needs a big investment.
o If we had £1 million, we could invest in other projects that give a higher net profit.
o Net profit doesn’t consider the timing of cash flows, which can change how good a project really is.
• Payback Period:
o The payback period is the time it takes for a project to recover its initial investment.
o The project with the shortest payback period is usually preferred because it gets out of debt quickly.
o It’s simple to calculate and doesn’t get affected much by small forecasting mistakes.
o However, it ignores the total profitability of the project and any income after breaking even.
• Return on Investment (ROI):
o ROI compares the profit a project makes to the money invested.
o Formula:
ROI=Average annual profit/Total investment×100
o ROI is easy to calculate but doesn’t consider the timing of cash flows.
o It also doesn’t account for bank interest rates or how money grows over time, which can be misleading.
• Net Present Value (NPV):
o NPV takes into account both the profitability of a project and the timing of cash flows.
o The basic idea is that receiving money now is better than receiving it later.
o Formula:
Present value=Value in year t / (1+r)^t
 o Future cash flows are discounted (made smaller) to reflect their current value.
o NPV helps compare projects by considering when the money comes in.
o Even if two projects have the same net profit, their NPV can be different because of when the money is
received.
• Choosing a Discount Rate for NPV:
o The discount rate should reflect current interest rates or borrowing costs.
o It’s important to use the same discount rate when comparing multiple projects.
o Small changes in the discount rate shouldn’t drastically change the project rankings.
• Internal Rate of Return (IRR):
o IRR is the rate at which the project’s NPV becomes zero.
o It’s a percentage that tells us how good the return on investment is, like an interest rate.
o A higher IRR is better.
o However, IRR doesn’t show the size of the return—only the percentage.
o Sometimes, a project might have more than one IRR, but the lowest one should be considered.
• Limitations of NPV and IRR:
o NPV and IRR don’t tell you everything you need to know about a project.
o You also need to think about how to fund the project and whether you can pay back any loans.
o Projects with high IRR might be risky, and their future earnings may not be as reliable.
o It’s important to think about how the project fits into the overall financial plan of the organization.

Differences Between Software Projects and Other Types of Projects

Aspect Software Projects Other Types of Projects

Visibility Progress is invisible; requires management Progress is tangible and can be physically
to make progress visible. observed (e.g., a bridge).

Complexity High complexity for the cost, with many Less complexity for the cost, governed by
interdependent components. physical laws.

Nature of Intangible deliverables like code, Tangible deliverables like buildings, products,
Deliverables applications, and systems. or events.
Flexibility Highly flexible; requirements can evolve Less flexible; requirements are usually well-
during the development lifecycle. defined and fixed upfront.
Requirements Often ambiguous or incomplete; requires Typically well-defined and measurable
Definition iterative clarification and validation. before the project begins.
Development Iterative and incremental; Agile, Scrum, or Linear or sequential; follows fixed phases like
Process Waterfall methods are common. planning, execution, and closure.
Measurement of Progress is harder to measure; depends on Progress is easily measurable (e.g.,
Progress completed functionality and quality. percentage of physical construction
completed).
Resource Relies heavily on skilled human resources Requires both skilled and unskilled labor,
Requirements (developers, designers, testers). along with physical resources and materials.
Risk and High due to intangible deliverables, evolving Moderate to low; risks are more predictable
Uncertainty requirements, and technology challenges. and based on physical constraints.
Quality Control Includes code reviews, testing, and Includes inspections, physical testing, or
debugging; heavily relies on automation adherence to standards like ISO.
tools.
Change Changes are frequent and expected; Changes are costly and disruptive; require
Management managed through version control and agile formal approvals and redesign efforts.
practices.
Customer Requires ongoing customer involvement for Limited customer involvement after initial
Involvement feedback and requirement adjustments. requirements are finalized.
 Tools and Specialized tools like IDEs, CI/CD pipelines, Tools and machinery specific to the domain,
Techniques version control, and testing frameworks. such as construction equipment or event
software.
Cost Estimation Challenging; subject to variability due to Easier to estimate due to standardized
uncertain requirements and technology processes and materials.
changes.
Delivery Deadlines are flexible; scope adjustments Deadlines are stricter; often tied to external
Timeframe may extend timelines. events or physical constraints.
Lifecycle Ongoing maintenance and updates after Minimal post-delivery involvement except
delivery (e.g., bug fixes, feature for repairs or warranties.
enhancements).

Procedure for Setting Objectives for Successful Completion of a Software Project:

1. Define the Objectives:
Objectives should define what the project team must achieve for the project to be considered successful.
These objectives focus on the desired outcomes (the "post-conditions") rather than specific tasks within the
project. For example, an objective could be "customers can order our products online" rather than just "build
an e-commerce website."
2. Align Stakeholder Interests:
Different stakeholders, such as users from various business areas, may have different motivations, but the
objectives should reflect shared intentions for the project. A project authority (often a steering committee or
project board) should be explicitly identified to oversee and ensure that the project objectives align with the
interests of all stakeholders.
3. Break Down the Objectives into Sub-Objectives:
Sub-objectives or goals should be defined as steps towards achieving the broader project objective. These
are smaller, manageable tasks that can be directly controlled by individuals or teams. For example, a business
objective might be to reduce operational costs, but for software developers, a more specific sub-objective
might be to keep development costs within a certain budget.
4. Ensure Objectives Follow the SMART Criteria:
Objectives should meet the SMART criteria to ensure they are well-defined and achievable:
• Specific: Objectives should be clear and well-defined. For example, instead of vague aspirations like
"improve customer relations," the objective should be concrete, such as "reduce customer complaints."
• Measurable: There should be measurable indicators to determine if the objective has been met, such as
the completion of a task by a set date.
• Achievable: The objective must be within the capabilities of the team or individual.
• Relevant: The objective should be relevant to the true purpose of the project.
• Time-bound: There should be a defined timeframe within which the objective must be completed.
5. Use Measures of Effectiveness:
Measures of effectiveness are practical methods for checking if the objective has been met. These could
include performance measurements like "mean time between failures" (MTBF) for system reliability.
Additionally, predictive measures such as error detection during code inspections can help forecast potential
problems, ensuring the project is on track to meet its objectives.

Categorizing Software Projects

1. Compulsory vs. Voluntary Users:
• Compulsory Users:
In workplaces, there are systems that staff must use if they want to perform certain tasks, such as recording a
sale. These systems are mandatory for employees to use in order to complete their work.
 Example: A sales recording system in a retail store where employees are required to use the system to record
transactions and manage inventory.
• Voluntary Users:
The use of some systems is voluntary, such as in the case of computer games, where users choose to use the
system for personal enjoyment or entertainment. In this case, it is difficult to elicit precise requirements from
potential users as we can with business systems.
Example: A computer game where players choose to engage based on their interest, and the system’s
development depends more on the creativity of developers, along with techniques like market surveys, focus
groups, and prototype evaluations.
2. Information Systems vs. Embedded Systems:
• Information Systems:
A traditional distinction has been made between information systems, which enable staff to carry out office
processes, and embedded systems. Information systems typically support administrative or business
functions.
Example: A stock control system used to track inventory, manage orders, and process transactions in a retail
environment.
• Embedded Systems:
Embedded systems, on the other hand, control machines or devices. These systems are integrated into the
hardware they manage, such as controlling the functioning of physical machinery or equipment.
Example: A process control system embedded in air conditioning equipment in a building that regulates
temperature and airflow. Some systems may combine elements of both information and embedded systems.
Example: A stock control system that also manages an automated warehouse, where the system both tracks
inventory and controls the movement of goods through automated processes.
3. Outsourced Projects:
• Outsourced Software Projects:
In large projects, companies may outsource certain parts of the work to other companies. This can be due to a
lack of expertise or because the company determines that parts of the project can be developed more cost-
effectively by another firm.
Example: A company may outsource the development of a mobile app for its software product while focusing
on the core software development in-house.
Outsourced projects are generally smaller in scope and need to be completed within a few months. Managing
outsourced projects presents special challenges due to the external involvement and coordination required.
Example: Indian software companies, which are known for executing outsourced software projects, often face these
challenges but have built a reputation in this field.
Revenue Implication: Outsourced projects typically provide one-time revenue, while developing a generic software
product provides a continuous stream of revenue over several years.
4. Objective-Driven Development:
• Product-Driven Projects:
Some projects aim to create a product based on specific details provided by the client. The client is
responsible for justifying the product’s need and ensuring that the product meets their requirements.
Example: A client may request the development of a custom inventory management system, where the
details of the product (features, functionalities) are specified in advance by the client.
• Objective-Driven Projects:
In contrast, some projects focus on meeting broader objectives, which may be achieved in various ways. The
goal is to solve a problem or meet specific objectives, but the path to the solution is not predefined.
Example: An organization may have an issue (e.g., operational inefficiencies) and asks specialists to
recommend a solution. This can involve two stages:
1. The first stage involves providing recommendations, such as identifying the need for a new software
system.
 2. If the recommendations are accepted, the second stage would involve developing the actual software
product based on the agreed-upon solution.
This two-stage process is useful when the user needs are unclear at the start, and an external group produces a
preliminary design before the final implementation.

Activity Planning in Software Project Management

1. Breaking Down Activities
The project is divided into smaller, manageable tasks, making it easier to assign responsibilities and monitor
progress.
Example: For an e-commerce website, tasks include requirement analysis, design, development, testing, and
deployment.
2. Estimating Activity Duration
Accurate time estimates for each task ensure realistic scheduling. Techniques like Expert Judgment and
Analogous Estimation are commonly used.
3. Sequencing Activities
Activities are arranged in a logical order based on dependencies. Tools like Gantt Charts and PERT Charts are
used to visualize and manage the sequence of tasks.
Example Dependencies:
o Finish-to-Start (FS): Development starts only after design completion.
4. Identifying the Critical Path
The Critical Path Method (CPM) identifies the sequence of tasks that directly impact project completion
time. Delays in these tasks will delay the entire project.
5. Resource Allocation
Resources (team members, tools, etc.) are assigned to tasks efficiently to avoid over-allocation and ensure
timely completion of tasks.
6. Risk Management
Risks affecting task completion are identified early on, and contingency plans are developed to minimize
their impact and ensure the project stays on track.
7. Monitoring and Adjustments
Progress is tracked regularly to ensure tasks remain on schedule. Adjustments are made to handle delays,
changes in requirements, or unexpected obstacles.
 MODULE - 5
Define Software Quality and explain the place of software quality in project management
Software quality refers to the degree to which a software product meets specified requirements, customer
expectations, and industry standards. It encompasses various attributes such as functionality, reliability, usability,
efficiency, maintainability, and portability. High-quality software performs its intended functions with minimal defects
and provides value to its users over its lifecycle.

Step 1: Identify Project Scope and Objectives

• In this step, quality-related objectives for the application are defined.
Step 2: Identify Project Infrastructure
• Focuses on establishing installation standards and procedures, with quality considerations integrated.
Step 3: Analyze Project Characteristics
• Involves assessing any specific quality requirements, like safety-critical needs.
• For critical applications, activities such as n-version development might be introduced.
Step 4: Identify Products and Activities of the Project
• Identifies the entry, exit, and process requirements for each activity, including those related to quality.
Step 5: Review and Publicize Plan
• The project plan undergoes a review of its overall quality aspects to ensure quality is embedded throughout
the project.

Software Quality Models

Software Quality Models are tools that help us measure how good software is. Since "quality" can be a vague idea,
these models break it down into smaller, measurable parts. This makes it easier to understand, improve, and ensure
the software meets its goals. Let’s look at some well-known models in simple terms:
1. Garvin’s Quality Dimensions
Garvin explained quality using 8 main features that apply to all products, including software:
• Performance: How well does the software do its job?
• Features: Does it have the tools and options users need?
• Reliability: Can it work without problems for a long time?
• Conformance: Does it meet the requirements?
• Durability: How long will it last before needing replacement?
• Serviceability: How easy is it to fix or update?
• Aesthetics: Does it look good and feel easy to use?
• Perceived Quality: What do users think about it?
2. McCall’s Model
McCall broke quality into three main areas:

• Running the software (how it works day-to-day).

• Changing the software (how easy it is to fix or improve).
• Adapting the software (how well it works in different places).
Each area is measured using specific features:
• Correctness: Does it meet the requirements?
• Reliability: Does it work well over time?
• Efficiency: Does it use resources wisely?
• Integrity: Does it protect its data?
• Usability: Is it easy for people to use?
• Maintainability: Is it easy to fix and improve?
• Flexibility: Can it handle changes easily?
 • Testability: Is it easy to test for problems?
• Portability: Can it work on different systems?
• Reusability: Can parts of it be reused in other projects?
• Interoperability: Can it work with other software?

3. Dromey’s Model
Dromey said software quality depends on four big ideas:
• Correctness: Does it do what it’s supposed to?
• Internal Characteristics: How well-built is it on the inside (e.g., is it simple and clean)?
• Contextual Characteristics: Does it fit well in the environment it’s used in?
• Descriptive Properties: Are the instructions and design documents clear?
These ideas are broken down into smaller, measurable features.

4. Boehm’s Model
Boehm focused on how useful software is to users and developers. He looked at three main things:
• As-Is Utility: Is it easy, reliable, and efficient to use?
• Maintainability: Can it be easily understood, updated, or fixed?
• Portability: How hard is it to use on different systems?
Boehm’s model digs deeper into these areas, focusing on how maintainable the software is.
Differentiate between Product and Process Quality Management.
Aspect Product Quality Management Process Quality Management
Definition Focuses on ensuring the final deliverable Focuses on ensuring the processes used to
(product) meets quality standards and user create the product are efficient and adhere to
expectations. quality standards.
Objective Deliver a high-quality product that satisfies Establish and maintain efficient, consistent, and
customer requirements. repeatable processes.
Scope Concerned with the outcomes or results of Concerned with the methods and workflows
the process (the product). used to produce the outcomes.
Measurement Quality is measured through functional Quality is measured through compliance with
Criteria testing, usability, performance, and process standards, efficiency, and defect
reliability of the product. prevention.
Techniques Used - Testing (unit, integration, system, - Process audits and evaluations
acceptance) - Statistical process control (SPC)
- Customer feedback - Process performance metrics (e.g., cycle time,
- Inspections and audits defect rate)
Standards Adheres to product-specific standards (e.g., Adheres to process standards (e.g., ISO 9001
ISO/IEC 25010 for software product quality). for quality management systems, CMMI for
software processes).
Focus Area The end deliverable and its features. The methods and procedures used to produce
the deliverable.
Responsibility Primarily the responsibility of product Primarily the responsibility of process
teams, testers, and quality assurance managers, process engineers, and quality
specialists. control teams.
Impact on Directly impacts customer satisfaction and Indirectly impacts product quality by improving
Quality market acceptance of the product. the efficiency and reliability of production
processes.
Examples - Ensuring software meets performance - Standardizing coding practices.
benchmarks. - Establishing a consistent testing protocol.
- Validating a product against customer
requirements.

Decomposition Techniques in Software Project Estimation

Decomposition techniques are used in software project estimation to break down a project into smaller, manageable
components. This approach allows for more accurate and detailed estimation by analyzing individual components
and aggregating their estimates. Decomposition techniques are widely used to estimate project size, effort, cost, and
schedule.
• Software Sizing
o “Fuzzy logic” sizing.
o Function point sizing.
o Standard component sizing.
o Change sizing.
• Problem-Based Estimation
o LOC (Lines of Code)
o FP (Functional Point)
• Process based Estimation
 o Most common technique for estimating project is to estimate on the process that will be used.
o The process is decomposed into a relatively small set of tasks and the effort required to accomplish each
task is estimated.
o Once problem functions & process activities are decided, the planner estimates the effort (e.g., person-
months) that will be required to accomplish each software process activity for each software function.
• Estimation with Use Cases
o Understand Use Cases (Use cases describe how users interact with a system.)
o Organize Use Cases in a Hierarchy
o Collect Key Metrics
o Use Historical Data for Estimation
o Apply an Estimation Formula

Software Project Estimation

• Challenges in Estimation:
Software cost and effort estimation will never be an exact science. Many variables—human, technical,
environmental, political—can impact the cost and effort.
• Estimation Options:
a. Delay estimation until late in the project (accurate but impractical).
b. Base estimates on completed, similar projects.
c. Use decomposition techniques to break the project into parts for estimation.
d. Use empirical models for cost and effort estimation based on past data.
• Timing and Accuracy:
Delaying estimation improves accuracy because more is known later in the project. However, practical
constraints demand early estimation.
• Combining Techniques:
Ideally, decomposition and empirical models should be applied together to cross-check estimates.
• Automated Tools:
Tools that use decomposition techniques or empirical models can be used to estimate based on the
characteristics of the organization and project.
• Importance of Historical Data:
Reliable estimation depends on good historical data. Without it, estimates are on shaky ground.