Chapter 1: Software & Software Engineering

1. What is Software & Software Engineering?

Answer:

Software is the product built and supported by software professionals.

Software engineering is (1) the application of a systematic, disciplined, quantifiable approach

to the development, operation, and maintenance of software; that is, the application of
engineering to software. (2) The study of approaches as in (1).

2. Why is Software Engineering important?

Answer: Software engineering is crucial because it allows us to develop complex
systems in a timely manner while ensuring high quality.

3. What is the work product of software?

Answer: From a software engineer's perspective, the work product is the set of programs, data
(content), and other related artifacts that constitute the software.

From the user's viewpoint, the work product is the resulting information that improves their world.

4. Describe the nature of software as a dual role.

Answer: For example, operating systems (software) are products, but they also serve
as the delivery vehicle for other application software.

5. Describe the characteristics of

software.
Answer: Characteristic of software:
 Software is developed or engineered; it is not manufactured in the classical
sense.
 Software does not wear out. But it does deteriorate.
 Although the current world is moving towards component-based construction,
most software continues to be custom-built.

1
 6. Describe the Bathtub Carve of software.
Answer:

The Bathtub Curve shows how software failure rates change over time. At first, failures are high
due to early bugs. Then, the software becomes stable with fewer issues. Later, as the software
ages or changes are made, failures increase again. Each update can cause new problems, so
the actual failure rate rises in spikes, unlike the smooth ideal curve.

7. Describe the Bathtub Carve of hardware?

Answer:

The Bathtub Curve for hardware shows how often hardware fails over time. At the beginning,
many parts fail quickly because of early problems like factory defects—this is called infant
mortality. After that, the failure rate becomes low and stays steady during the useful life of
the hardware, when it works well. Later, as the hardware gets old, it starts failing more often
again—this is the wear-out stage. The curve looks like a bathtub because of this shape: high
at the start, low in the middle, and high at the end.

2
 8. Difference between software and a hardware in terms of bathtub
Curve? Answer:

Hardware Software
Fails early due to factory defects (infant Fails early due to bugs in the code
mortality)
Works well for a long time (stable phase) Works well after bugs are fixed (stable
phase)

Fails later due to aging and wear-out Fails later when updates introduce new bugs
Failure caused by physical wear and tear Failure caused by code errors or changes
Gets old and breaks down over time Doesn’t age, but changes can make it
unstable
Bathtub curve is natural and predictable Bathtub curve depends on how often it’s
updated

9. Describe the 7 categories of software with example?

Answer:

Category Short Description Example

1. System Software Runs and manages computer Windows, Linux, Drivers
hardware and system tasks
2. Application Software Helps users do specific tasks MS Word, Excel, Chrome
[Link]/Scientific Used for technical and scientific MATLAB, AutoCAD
Software work
4. Embedded Software Built into devices to control Microwave software, Car
functions system
5. Product-Line Software Reusable software for different Tally, MS Office,
customers Photoshop
6. Web Applications Runs in a browser over the internet Gmail, Amazon, Google
Docs
7. AI Software Acts smart, like human thinking Siri, Face recognition,
Chatbots

10. What is Real-Time Manufacturing Process Control?

Answer: Real-Time Manufacturing Process Control is a system that monitors and
adjusts manufacturing operations instantly. It collects real-time data and makes quick
changes to maintain quality, reduce errors, and ensure safety.
Example: In a factory, it can adjust machine speed automatically if overheating is
detected.

11. What is legacy Software?(with Example)

Answer: Legacy software is outdated software that is still in use because it performs
important tasks, even though it may be hard to maintain or upgrade.
Example: COBOL based Banking Software, Windows XP, Windows 95, Windows 7
etc.

3
 12. Why is legacy Software still used?

Answer: Legacy software is still used because:

i. It works well for their system.

ii. Expensive to upgrade.
iii. Upgrading might hamper business (time consuming).
iv. Stable for a long time.

4
 13. What is Software Engineering according to Fritz Bauer?

Answer: Software engineering is the establishment and use of sound engineering

principles in order to obtain economically software that is reliable and works efficiently
on real machines.

14. Why is to Fritz Bauer definition is important?

Answer: According to F.L. Bauer at a 1968 NATO conference, software engineering

is defined as "the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and works efficiently on real machines."

15. What is Software Engineering according to IEEE?

Answer: According to IEEE,
"Software engineering is (1) the application of a systematic,
disciplined, quantifiable approach to the development, operation, and
maintenance of software; that is, the application of engineering to
software. (2) The study of approaches as in (1)."

16. What are the layers of Software Engineering? Describe with

example? Answer:

Software engineering can be viewed as having a layered approach, with quality at its core. These layers
work together to build high-quality software:
 A Quality Focus: This is the foundation, representing the organization's commitment to
delivering high-quality software.
 Process: The framework that defines the "how" of software development, including activities,
tasks, and workflow.
 Methods (Practice): Provide the technical "how-to's" for building software, encompassing tasks
like requirements analysis, design, code generation, and testing.
 Tools: Automated or semi-automated support for the process and methods.
 Example: For developing a new e-commerce platform:
o The team maintains a quality focus by adhering to coding standards and conducting
regular reviews.
o They follow an agile process with iterative development cycles.

5
 o The methods involve using user stories for requirements, object-oriented design
principles, and unit testing.
o The tools include an Integrated Development Environment (IDE), a version control
system, and automated testing frameworks.

Layer Description Example

Quality Layer Ensures the software is reliable, Quality assurance activities, code
efficient, and meets requirements. reviews, testing
Process Layer Defines how software is developed Software development life cycle
step-by-step. (SDLC) models like Waterfall or
Agile
Methods Layer The techniques and tools used to UML diagrams for design, coding
design, build, and test software. standards, testing methods
Tools Layer Software tools that help automate and IDEs like Visual Studio, testing tools
support the process and methods. like Selenium

17. Describe the generic process framework for software engineering?

Answer:

The generic process framework for software engineering defines five fundamental "framework
activities" that apply to all software projects:

1. Communication: Involves extensive collaboration with stakeholders to understand project

objectives and gather requirements.

2. Planning: Establishes the software project plan, outlining tasks, potential risks, necessary
resources, desired work products, and the project schedule.

3. Modeling: Creates models for both requirements and design. This includes building analysis
models to understand functional and non-functional requirements and design models for
architectural and component details.

4. Construction: Combines code generation (either manual or automated) and various levels of
testing to ensure functionality.

5. Deployment: Involves delivering the completed software to the customer, followed by

evaluation and gathering customer feedback. Additionally, "umbrella activities" are applied
throughout these framework activities.

6
 18. Describe the essence of Software Engineering practice by George Polya?

Answer: George Polya's problem-solving approach, adapted for software engineering

practice, involves four key steps:

1. Understand the problem: Deeply comprehending what needs to be solved, why it's important,
its context, and the desired outcome.

2. Plan a solution: Devising a plan to address the problem, considering different approaches and
alternatives.

3. Carry out the plan: Executing the selected plan.

4. Examine the result: Verifying if the implemented solution is correct, meets the requirements,
and truly solves the original problem.

19. When you are thinking of starting new software, how the business need is
expressed?

Answer: The business need usually begins as an informal conversation between managers
and stakeholders. It involves discussing the idea, market potential, technical feasibility, and
expected benefits of the software. This initial talk helps identify the problem or opportunity
the software will address and sets the direction for the [Link] example, a company may
discuss creating a new wireless device to control home appliances, exploring market demand,
costs, and revenue expectations before starting development.

7
 Chapter 2: Process model

1. What is Software Process?

Answer: A software process is a framework for the effective delivery of software
engineering and technology. It acts like a road map that guides software engineers to
create high-quality software on time. It includes steps like planning, designing,
coding, testing, and deployment.

2. Why is the Software Process important?

Answer: The Software process is important because it helps keep the work
organized, stable, and under control. Without a process, software development can
become quite chaotic. Modern software processes are also agile, meaning they are
flexible and only use the steps and tools that are needed for each project.

3. What are the steps of software Process?

Answer: The steps in a software process can change depending on what kind of
software you're making. For example, building software for an airplane system needs
strict steps, while making a website can use a simpler and faster process.

But usually, the basic steps are:

 Communication – Talk with users to understand what is needed
 Planning – Make a plan to do the work
 Modeling – Design the software
 Construction – Write and test the code
 Deployment – Deliver the software to users

4. What is the work product of software process?

Answer: From the point of view of a software engineer, the work products are the
programs, documents, and data that are produced as a consequence of the activities
and tasks defined by the process.

5. As a developer, how do you ensure that you’ve done it right?

Answer: There are a number of software process assessment mechanisms that enable
organizations to determine the ―maturity‖ of their software process. However, the
quality, timeliness, and long-term viability of the product you build are the best
indicators of the efficacy of the process that you use.

i. Understanding the problem

ii. Plan a Solution
iii. Execute the Plan
iv. Examine The Results

8
 6. Describe Umbrella Activities of a software process?

Answer: Umbrella activities are tasks that support the main steps of the software process.
They happen throughout the entire project to help keep everything on track, improve quality,
and manage the work properly.

Key Umbrella Activities:

 Project Management: Plans and controls the project to meet time, cost, and goals.
 Quality Assurance (QA): Checks that the software is high-quality and meets
standards.
 Risk Management: Finds and solves problems early to avoid project failure.
 Configuration Management: Keeps track of all versions and changes in the project.
 Communication: Makes sure all team members and clients stay informed.
 Change Management: Handles changes in project scope or features smoothly.
 Measurement and Metrics: Collects data to measure progress and improve
performance.

Advantages:

 Helps control the project better.

 Keeps quality high and work consistent.
 Solves problems before they get worse.

Disadvantages:

 Takes extra time and resources.

 Can be hard to manage in large projects.

When to Use:

 In all software projects (small or big).

 Especially useful in large or complex systems.

7. What is Process Flow?

Answer: Process flow is the order or path that software development activities
follow from start to finish. It shows how tasks are connected and how the work
moves from one step to another.

8. Describe four types of Process Flow with figure?

Answer:

 Linear Process Flow:

A linear process flow follows a straightforward, step-by-step path where each step is
dependent on the previous one. The process moves in a clear, sequential order, from start to
finish.

9
Example: In a basic manufacturing process:

 Start → Design → Build → Test → Package → End.

This flow is ideal for processes with a fixed, predictable outcome.

 Iterative Process Flow:

An iterative process flow involves repeating steps or cycles, where each cycle brings
improvements or refinements. The process goes back to previous steps to adjust or modify
the outcome based on feedback.

Example: In software development (Agile methodology):

 Start → Planning → Development → Testing → Feedback → Refinement → Repeat

the cycle.

This allows for constant improvement over multiple iterations.

 Evolutionary Process Flow:

An evolutionary process flow builds the final product through progressive and adaptive
stages. Unlike iterative, this process continuously evolves, adapting to changing
requirements, feedback, or new information.

Example: In product development:

 Start → Concept Development → Initial Prototyping → Testing & Feedback →

Refinement & Scaling → Final Product.

10
It evolves step-by-step, but can go back and forth as new features or improvements emerge.

 Parallel Process Flow:

In a parallel process flow, multiple activities or tasks occur at the same time. The steps are
divided into parallel paths that can be worked on simultaneously, improving efficiency and
reducing overall time.

Example: In a project management scenario:

 Start → Design (done in parallel with Research) → Development (done in parallel

with Marketing) → Testing → Launch.

This is used when tasks can be done independently without waiting for each other to finish.

9. Describe different approaches to process assessment and improvement.

Answer: Process assessment helps software companies understand their current process and
improve it to deliver better software on time, on budget, and of good quality.

Below are some important approaches used in the software industry:

I. SCAMPI

(Standard CMMI Assessment Method for Process Improvement)

 A five-step method to assess and improve software processes.

 Steps:
1. Initiating
2. Diagnosing
3. Establishing
4. Acting
5. Learning

11
  Based on the CMMI model.

II. CBA IPI

(CMM-Based Appraisal for Internal Process Improvement)

 A method to measure the maturity of software processes in a company.

 Helps find strengths and weaknesses.
 Based on the older SEI CMM model.

III. SPICE

(ISO/IEC 15504 – Software Process Improvement and Capability Determination)

 An international standard.
 Helps in measuring the capability of a process.
 Gives objective feedback for improvement.

IV. ISO 9001:2000 (for Software)

 A quality management standard for all types of companies.

 Ensures the company follows good quality practices.
 Also applies to software organizations.

10. Why the process model are called prescriptive process model?

Answer: Prescriptive process models are called "prescriptive" because they give clear steps to
follow when making software. They tell you what to do, when to do it, and how to do it.
These models help keep the work organized and under control. They are useful when the
project is clear from the start and needs a planned, step-by-step method.

11. For Waterfall model, describe the structure, advantage, disadvantage and when
to use it?

Answer: The Waterfall Model is a linear and sequential software development process
where each phase must be completed before moving to the next one. It follows a strict step-
by-step approach, meaning there is no going back to a previous phase once it is completed.

Phases of the Waterfall Model:

12
Structure: A linear sequential flow that progresses through distinct phases: communication
(requirements gathering), planning, modeling (analysis and design), construction (coding and testing),
and deployment (installation and support). Each phase must be completed before the next begins, with
little to no iteration back to previous phases.

Advantages of the Waterfall Model

 Simple and easy to understand.

 Well-structured with clear steps.
 Best for projects with well-defined requirements.

Disadvantages of the Waterfall Model

 No flexibility – Once a phase is completed, changes are difficult.

 Late testing – Bugs are found at the end, making fixes costly.
 Not suitable for projects with changing requirements.

When to Use the Waterfall Model?

 Small projects with clear and fixed requirements.

 When all risks and functionalities are well understood in advance.
 When documentation is important.
Example: Certain Government or Critical Systems.

12. For Incremental process, describe the structure, advantage, disadvantage and
when to use it?

Answer: The Incremental Process Model is a software development approach where the
system is built gradually in small parts (increments). Each increment adds new
functionalities, making the software usable step by step instead of delivering it all at once.

Y-Axis (Vertical): Represents Software Functionality and Features, meaning the software
improves with each increment.
X- Axis (Horizontal): Represents Project Calendar Time, meaning development happens in
stages over time.
Colour Blocks: Represent different phases of development in each increment.

13
Phases in Each Increment:

Each increment goes through multiple phases before deployment:

1. Communication – Requirements gathering and discussion.
2. Planning – Project planning and scheduling.
3. Modeling – Analysis and design of the software.
4. Construction – Coding and testing of the software.
5. Deployment – Delivering the increment and gathering feedback.

How the Model Works in the Diagram:

 Increment 1: Software is developed and delivered first.

 Increment 2: Starts after the first delivery, adding new features.
 Increment n: continues this pattern, improving the software in stages.
 Each increment builds upon the previous one, gradually increasing software
functionality.

This process ensures that a basic version of the software is available early, with continuous
improvements over time.

Advantages

 Early Delivery – A working version of the software is available quickly.

 Easier to Manage – The project is divided into small, manageable parts.
 Flexible & Adaptable – Changes can be made in later increments without affecting
previous work.
 Early Bug Detection – Testing is done at every stage, reducing major defects.
 Better Customer Feedback – Users can provide feedback after each increment.
 Reduced Initial Cost – Development cost is spread across multiple phases.

Disadvantages

 Requires Careful Planning – Each increment must fit well with previous ones.
 More Testing Effort – Every new increment needs to be tested individually and as a
whole.
 Integration Issues – New increments must work smoothly with previous ones.
 Not Suitable for Small Projects – It can be complex for small-scale software.

When to Use the Incremental Model?

 When requirements are expected to change over time.

 When a working basic version is needed quickly.
 When a large project is too complex to develop all at once.
 When frequent user feedback is required for improvements.
 When high-risk projects need continuous testing and validation.

14
 13. For Rapid Application Development (RAD) model, describe the structure,
advantage, disadvantage and when to use it?

Answer: Rapid Application Development (RAD) Model is a software development

approach that focuses on quick development and delivery with user feedback at every stage.

Structure:

 Requirement Planning: Quick meetings with stakeholders to gather requirements.

 User Design: Users and developers work together to design the system using tools
like diagrams and prototypes.
 Construction: Developers quickly build working versions of the software using
reusable components and tools.
 Cutover: Final testing and deployment of the complete product.

Advantages:
 2-3 months' time period.
 Use of AI for automated code generation.
 Resources are available at all times.
 Reduced development time.
 Quick Initial Review
 Customer Review

Disadvantages:

 Only modularized software can use this.

 Most Costly
 Most skilled members
 Resources must be available at all times.
 A strong team with high skills is needed.

When to Use:

 When there is a high Budget

 When the project needs to be completed quickly.
 When requirements are known but may change.
 When users are available to give regular feedback.
 For small to medium-sized projects with low technical risks.

14. For Prototyping model, describe the structure, advantage, disadvantage and
when to use it?

Answer:

15
Definition:

 A quick prototype (sample version) of the software is built.

 Users review it and give feedback.
 The prototype is improved until a final version is developed.
 Most user involvement.

Advantages:

 Early and continuous customer involvement helps clarify requirements and reduce ambiguity.
 Reduces the risk of building the wrong product.
 Helps validate feasibility of design choices.
 Provides a tangible representation for stakeholders to evaluate.

Disadvantages:

 Customers might mistake the prototype for the final system, leading to unrealistic expectations.
 Developers might "throw away" the prototype without proper planning or attempt to evolve a
“quick-and-dirty” prototype into a production system, leading to poor quality.
 Can lead to an excessive number of iterations if not well-managed.

When to Use?

 When requirements are unclear and need exploration.

 When user feedback is important before finalizing the product.
 For UI/UX-heavy applications like mobile apps, websites, and games.

15. For Spiral model, describe the structure, advantage, disadvantage and when to
use it?

Answer:

16
Definition:

 Development happens in multiple loops (spirals), each including:

 Planning
 Risk Analysis
 Development & Testing
 User Evaluation
 Each loop improves the software and add new features.
Advantages:

 Risk Management – Early identification and mitigation of risks.

 Flexible & Adaptive – Changes can be made at any stage.
 Efficient for Large Projects – Handles complex and high-risk software
development.

Disadvantages:

 High Cost – More expensive than traditional models.

 Complex Management – Requires skilled project managers.
 Slow Initial Development – First versions take longer to release.

When to Use?

 When the project has high risks (e.g., financial, security, or safety risks).
 For large and complex projects (e.g., aircraft software, defense systems).
 When continuous testing and feedback are required.

16. What are the concerns on Prototype model?

Answer: The Prototype Model is helpful but has some problems:

 Users get confused: They may think the prototype is the final product.
 Missing important parts: It focuses more on the look than on deep system needs.
 Bad design: Quick work may lead to poor design and weak structure.
 High cost: Making many prototypes can increase the total cost.
 Not good for big systems: Prototypes may not work well when made larger.
 Too many changes: If users keep asking for changes, final work may get delayed.

17. What are the concerns on Evolutionary Process?

Answer: The concerns on Evolutionary Process are:

 Difficult to plan – It's hard to plan the full system at the beginning.
 Design issues – Frequent changes can make the design messy or inconsistent.
 Version control problems – Managing many versions becomes complicated.
 Customer confusion – Users may not know which version is the final product.
 Extra documentation effort – Changes require regular updates to documents.

17
 18. What is Unified Process (UP)?
Answer: The Unified Process (UP) is a framework for software development that
follows an iterative and incremental approach. It is architecture-centric and
focuses on risk reduction at every stage. It uses the concept of object-oriented
architecture.

19. Describe the UP-work products (work product of all phases)?

Answer:

Four Phases of Unified Process

 Inception Phase (Project Planning & Feasibility)

 Define the business case and feasibility of the project.

 Identify the key system requirements and risks.
 Develop an initial project plan and budget.

Outcome/Work Product:
✔ Initial project scope, rough timeline, and feasibility report.

 Elaboration Phase (Detailed Planning & Design)

 Perform detailed analysis and system design.

 Identify high-risk areas and resolve them early.
 Develop a baseline architecture for the system.

Outcome:
✔ A working prototype with core architecture.

 Construction Phase (Coding & Development)

 Actual coding, integration, and testing of the software.

 Features are developed in multiple iterations.
 The product evolves based on user feedback.

Outcome:
✔ A working version of the software with most of the functionality.
18
  Transition Phase (Deployment & User Training)

 Deploy the software to users.

 Conduct beta testing and gather final feedback.
 Provide training and documentation.

Outcome:
✔ Final software product ready for use.

Advantages & Disadvantages of Unified Process

Advantages:

 Flexible & Adaptive – Handles changing requirements well.

 Risk Reduction – Problems are addressed early.
 Continuous Testing – Ensures high software quality.
 Scalable & Efficient – Suitable for both small and large projects.

Disadvantages:

 Complex & Requires Expertise – Needs experienced developers.

 Costly for Small Projects – More effort is required for documentation and planning.
 Heavy Documentation – Requires detailed reports at every phase.

When to Use Unified Process?

 If a project incorporates the use of object-oriented concepts.

 Large-scale projects requiring risk management.
 When requirements are unclear and need refinement over time.
 Projects requiring high-quality architecture and scalability.

19
 Chapter 3: Agile Development

1. What is Agile Software Engineering?

Answer: Agile Software Engineering is a method of making software that is flexible and
fast. It works in small steps, welcomes changes, and involves customers often to make
sure the software meets their needs.

2. Why is it important?
Answer: The modern business environment that spawns computer-based systems and
software products is fast-paced and ever-changing. Agile software engineering
represents a reasonable alternative to conventional software engineering for certain
classes of software and certain types of software projects. It has been demonstrated to
deliver successful systems quickly.

3. As a developer, how do you ensure that you’ve done it right?

Answer: If the agile team agrees that the process works, and the team produces
deliverable software increments that satisfy the customer, you’ve done it right.

4. What is Agility?
Answer: Agility means being quick and flexible in software work. It helps teams handle
changes, talk well, work together, and deliver software fast in small steps.

5. What is Agile Team?

Answer: An Agile Team is a group of people, software engineers, project stakeholders

(managers, customers, end users), who work closely together, communicate well, and
quickly adapt to changes to build software. They focus on teamwork, flexibility, and deliver
small parts of working software often.

6. Describe the relation between agility and the cost of change?

Answer:

20
The cost of change in software development refers to how much effort, time, and money it
takes to make changes to the system as the project progresses.

The relationship between agility and cost of change is shown in the graph:

 Conventional Software Processes:

 In traditional approaches like the waterfall model, the cost of change increases
rapidly as development progresses.
 Changes made during later phases (e.g., after design or implementation) are
very expensive.
 Agile Software Processes:
 Agile methods aim to reduce the cost of change by using short iterations,
continuous testing, and regular customer feedback.
 As a result, changes can be made even in later stages with relatively lower cost
compared to traditional methods.
 Ideal Agile Cost (Dashed Line in the Graph):
 The ideal goal of agile is to keep the cost of change nearly constant throughout
the project.
 Though not always fully achievable, agile practices help move closer to this
ideal.

7. What is Agile Process?

Answer: Agile Process is a software development approach that emphasizes iterative
development, collaboration, flexibility, and customer feedback to deliver high-
quality software quickly and efficiently.

8. Describe the characteristic of Agile Process?

Answer: The characteristic of Agile Process:

i. Iterative development – Software is built in small, manageable parts.

ii. Customer collaboration – Frequent feedback from users.
iii. Flexibility – Easy to adapt to changing requirements.
iv. Continuous testing – Regular testing and integration.
v. Self-organizing teams – Team members manage tasks independently.
vi. Working software focus – Main goal is to deliver functional software.
vii. Face-to-face communication – Quick and clear team communication.
viii. Sustainable pace – Maintains steady progress without burnout.

9. Describe the key principle of Agile Process?

Answer: The Agile Alliance has defined 12 key principles that guide Agile development.
These principles help ensure flexibility, customer satisfaction, and high-quality software
delivery.

i. Customer satisfaction through early and continuous delivery of valuable software.

ii. Welcome changing requirements, even late in development.
iii. Frequent delivery of working software (preferably every 2–4 weeks).

21
 iv. Daily collaboration between business people and developers.
v. Build projects around motivated individuals and trust them.
vi. Use face-to-face communication for effectiveness.
vii. Working software is the main measure of progress.
viii. Promote sustainable development with a constant pace.
ix. Focus on technical excellence and good design.
x. Emphasize simplicity – do only what is necessary.
xi. Let self-organizing teams create the best designs and solutions.
xii. Teams should reflect and improve their processes regularly.

10. Describe the Agility principles?

Answer:Same as answer 9
11. List all the methods of Agile Development?

Answer: The following are popular Agile development methods used in the software
industry:

i. Extreme Programming (XP)

ii. Scrum
iii. Adaptive Software Development (ASD)
iv. Dynamic Systems Development Method (DSDM)
v. Crystal
vi. Feature-Driven Development (FDD)
vii. Lean Software Development (LSD)
viii. Agile Modeling (AM)
ix. Agile Unified Process (AUP)

12. Describe the Process of XP?

Answer: Extreme Programming (XP) uses an object-oriented method as its preferred

development paradigm. Extreme Programming (XP) is an agile development method that
focuses on customer satisfaction, simplicity, and frequent releases. It has four key activities:

I. Planning:
In this phase, user stories are collected from the customer, prioritized, and estimated by
the development team. These guide the iteration and release plans.
 User stories values acceptance test criteria iterative plan.
II. Design:
XP encourages simple and clear design. CRC cards are used to assign responsibilities.
Developers may build prototypes (spike solutions) and refactor code to improve
structure.
 Simple and Clear Design
 CRC cards
 Spike Solutions Prototype
III. Coding:
Coding starts with writing unit tests. Pair programming and continuous integration are
used to maintain code quality and detect issues early.
 Pair Programming
 Continuous Integration

22
IV. Testing:
Automated tests check each feature. Regression and acceptance tests ensure new and
existing features work as expected and meet customer needs.
 Unit Test
 Acceptance Testing

13. What is the Key feature of XP?

Answer:
 User stories define requirements based on customer input.
 Frequent releases ensure working software is always available.
 Test-first development (TDD) emphasizes writing tests before code.
 Pair programming boosts code quality and real-time collaboration.
 Continuous integration avoids integration issues.
 Refactoring improves internal code quality without changing external behavior.
 Simple design avoids unnecessary complexity.
 Customer collaboration allows real-time feedback and changes.

14. Why do we need agile and when we have other software development method?
Answer: We need Agile because traditional methods like the Waterfall model are
rigid and less adaptive to changes. Agile offers flexibility, faster delivery, and better
customer involvement. It supports frequent feedback, continuous improvement,
and early detection of issues, which leads to higher-quality software that meets
users’ real needs.

23
 Chapter 4: Basic Concept of Software Quality
1. What is software testing?

Answer: Software testing is the process of evaluating a software system to check whether it
meets the specified requirements and to identify any bugs or errors. It ensures the quality,
reliability, and performance of the software.

2. Who does software testing?

Answer: Software testing is done by different people at different stages:

 Developers (Programmers): They perform unit testing to check if their own code
works properly.
 Testers (QA Engineers): They do system testing, integration testing, and
regression testing to ensure the whole software works correctly.
 Users (Customer or End-user): Sometimes, real users do acceptance testing to
see if the software meets their needs.

3. Why is it important?
Answer: Software testing is important because it helps find bugs, ensures quality,
improves performance, and makes sure the software works as expected before
releasing it to users.

4. What are the steps?

Answer: Steps of Software Testing (Simple Version)

 Understand Requirements: Know what the software is supposed to do.

 Plan Testing: Decide what to test and how to test it.
 Write Test Cases: Make a list of tests with inputs and expected results.
 Set Up Test Environment: Prepare the computer and software needed for testing.
 Run Tests: Check if the software works by running the test cases.
 Report Bugs: Tell developers about any problems found.
 Close Testing: Make a final report and finish testing after fixing bugs.

5. What is the work product?

Answer: A work product is any document, code, report, or item created during the software
development or testing process. It shows the progress and results of the work done.
Examples: Test cases, Bug reports, Design documents, Source code

24
 6. As a test member, how do you ensure that you’ve done it right?

Answer: As a test member, to ensure I’ve done it right:

 I follow the test plan carefully.

 I check that all test cases are executed.
 I verify that all defects are reported clearly.
 I review my work with the team.
 I confirm the software meets the requirements.

7. What do you need to focus on in an effective quality process?

Answer: To ensure good quality in a software product, an effective quality process should
focus on the following:

 Paying much attention to customers' requirements.

 Making efforts to continuously improve quality.
 Integrating the measurement process with product design and development.
 Pushing the quality concept to the lowest level of the organization.
 Developing a system level perspective with an emphasis on methodology and process.
 Eliminating waste through continuous improvement.

8. Describe five views of software quality according to Kitchenham and Pfleeger.

Example of each v
Answer: The five views of software quality according to Kitchenham and Pfleeger,
along with examples for each:
i. Transcendental View: Quality is something we can recognize but not easily
define(Feelings)

Example: A game feels fun and smooth, so you think it’s good quality.

ii. User View: How a user views the effectiveness and quality of the software.

Example: A simple text editor might be considered high quality by a user who only needs
basic typing and saving functionality, even if it lacks advanced features like spell-checking or
collaboration. However, a professional writer might deem it low quality due to these
omissions.

iii. Manufacturing View: High quality, if the software is built according to the
requirements and has few to no bugs at all.
Example: A piece of safety-critical software, like the control system for a nuclear reactor,
would be considered high quality from this perspective if it strictly adheres to its detailed
specifications and has undergone rigorous testing to eliminate potential failures or errors.

iv. Product View: Quality is seen as a set of inherent attributes that the software possesses. More
quality means more desirable attributes.
Example: A website that loads fast and is easy to use is good quality.

25
 v. Value-Based View: Trade-off between quality and attributes and cost. How much am I
getting from the software for the cost.

Example: A company might choose to develop a moderately feature-rich customer

relationship management (CRM) system that meets the core business needs within a
reasonable budget and timeframe, rather than investing significantly more time and resources
to build a system with every conceivable bell and whistle. The "value" lies in achieving a good
balance between functionality, usability, reliability, and cost.

9. What is quality factor?

Answer: A quality factor is a specific characteristic or feature that helps measure
how good a software product is. These factors reflect important aspects like how well
the software works, how easy it is to use, how secure it is, and how reliable it is.
10. Describe six quality factors with example.

Answer: Six Software Quality Factors (with Example):

i. Correctness: The software gives the right output.

Example: A calculator gives the correct answer.

ii. Reliability: It works properly without crashing.

Example: Online banking works safely all the time.

iii. Efficiency: Works fast and uses less memory.

Example: A mobile game runs smoothly.

iv. Testability: Software should be tested to all possible test cases.

v. Maintainability: Easy to fix bugs or update.

Example: Developers can change or fix the code easily.

vi. Reusability: Runs on different devices or systems.

Example: A website opens well on phone, tablet, and computer.

11. Describe Static and Dynamic Analysis with examples.

Answer:
Static analysis: Static analysis involves examining the code or related documents
without actually running the program. It helps find errors like syntax mistakes or
violations of coding standards by reviewing the code or using tools before execution.
An example of static analysis is a code review or using a static code analyzer to detect
potential problems.

Dynamic analysis: Dynamic analysis, on the other hand, requires running the
program with test inputs to observe its actual behavior. This helps identify issues such
as crashes, memory leaks, or incorrect outputs that occur during execution. For
example, running unit tests or functional tests on the software is a form of dynamic
analysis.

26
12. What is verification and validation?

Answer:

Verification: Checking if the software product of a development phase meets the

requirements set for that phase (like checking the design, code, or documents). It focuses on
―Are we building the product right?

Validation: Checking if the final software product meets the user’s needs and expectations. It
focuses on ―Are we building the right product?‖

13. Difference between verification and validation

Answer:

Verification Validation
Ensures the product is built according to Ensures the product fulfils its intended
specifications use
Performed during development phases (early) Performed after development (usually at
the end)
Involves reviews, inspections, and walkthroughs Involves actual testing with
users/customers
Checks the correctness of intermediate products Checks the final product’s functionality
(requirements, design, code) and performance
Static process (no execution of code needed) Dynamic process (involves execution
and testing)
Goal: Build the product right Goal: Build the right product
Example: Code review, design review Example: User acceptance testing
(UAT), system testing

14. What is error, fault/defect, and failure? Example.

Answer:

Error: A human mistake or misconception that leads to a defect

Example: A variable in the program has a wrong value during execution.

Fault/Defect: The cause of an error, like a bug in the code or a design

mistake.
Example: A typo in the code where a calculation uses + instead of -.

Failure: When the system behaves wrongly or stops working unexpectedly.

Example: The app crashes when you click a button because of a fault in the code.

***ErrorFault/Bug/DefectFailure

27
15. Describe the four objective of testing?

Answer: Objectives of Testing:

I. To check if it works: Programmers want to confirm that their code or system

works correctly in normal situations. This gives them confidence.
II. To find problems: After initial testing, more tests are done to try and make the
system fail, so faults can be found and fixed.
III. To reduce the risk of failure: By finding and fixing faults, the chances of the
system failing during real use go down.
IV. To reduce testing costs: Testing should be done efficiently to lower the costs of
designing, running, analyzing, and documenting tests.

16. What is a test case?

Answer: A test case is a simple pair of < input, expected outcome >.
If a program under test is expected to compute the square root of nonnegative
numbers, then four examples of test cases are as shown in below:
TB1 : < 0, 0 >,
TB2 : < 25, 5 >,
TB3 : < 40, 6.3245553 >,
TB4 : < 100.5, 10.024968 >.

17. Design a test case for Login Functionality?

Answer:

Test Case ID: TC_LOGIN_01

Title: Valid Login with Correct Username and Password
Objective: To verify that a user can log in with valid credentials

Preconditions:

 User account already exists

 User is on the login page

Test Steps:

1. Enter valid username

2. Enter valid password
3. Click on the Login button

Test Data:

 Username: user@[Link]
 Password: ValidPassword123

Expected Result:

 User is redirected to the dashboard/homepage

 A welcome message is displayed
28
 Actual Result:

 [To be filled after test execution]

Status:

 [Pass/Fail]

18. Design a test case for a calculator application.

Answer:

Test Case ID: TC_CALC_01

Title: Verify Addition Functionality
Objective: To ensure the calculator correctly performs addition

Preconditions:

 The calculator application is open and ready for input

Test Steps:

1. Enter number 8
2. Press the + button
3. Enter number 5
4. Press the = button

Test Data:

 Input 1: 8
 Input 2: 5
 Operation: +

Expected Result:

 Display shows result 13

Actual Result:

 [To be filled after test execution]

Status:

 [Pass/Fail]

29
19. Design a test case for a contract from submission.

Answer:

Test Case ID: TC_CONTACT_01

Title: Verify Contact Form Submission with Valid Data
Objective: Ensure that the contact form submits successfully with all valid inputs

Preconditions:
 User is on the Contact Us page
 Internet connection is active

Test Steps:

1. Enter "Shifa" in the Name field

2. Enter "shifa@[Link]" in the Email field
3. Enter "Need help with your services." in the Message field
4. Click the Submit button

Test Data:

 Name: Shifa
 Email: shifa@[Link]
 Message: Need help with your services.

Expected Result:

 Form is submitted successfully

 A confirmation message is displayed: "Your message has been sent!"
 Email confirmation (optional) is sent to the user

Actual Result:

 [To be filled after test execution]

Status:

 [Pass/Fail]

20. What is Expected Outcome?

Answer: Expected Outcome means the correct or desired result that a software
program should produce when given a specific input during testing.

30
21. Describe the four test levels with example.

Answer: The four test levels are:

I. Unit Testing: Tests individual program units (functions, methods).

Example: Test if the login () function returns true for the correct
username/password.

II. Integration Testing: Tests the interaction between multiple units/modules.

Example: Check if the login function connects properly with the database to
verify credentials.

III. System Testing: Tests the complete and integrated software system.
Example: Test the full login process, dashboard load, and user access flow of
an application.

IV. Acceptance Testing: Validates the software against user/business

requirements.
Example: A client tests if the employee leave management feature works as
per the contract before accepting the software.

22. Describe the categories of acceptance testing.

Answer: The main categories of acceptance testing are:

I. User Acceptance Testing (UAT): This testing is done by the end users or clients to
check if the software works according to their needs and expectations. For example, a
customer tests an online shopping site to see if adding items to the cart and t h e
checkout process is working properly.
II. Business Acceptance Testing (BAT): This testing is done by the business team or
stakeholders to ensure that the software meets the business goals and supports the
business processes. For example, the sales team testing a CRM system to confirm it
supports their sales activities.
III. Contract Acceptance Testing (CAT): Conducted based on the criteria and
specifications defined in a contract between the developer and the client.
IV. Regulation Acceptance Testing (RAT): Ensures that the software complies with
relevant regulations, legal requirements, or industry standards.
V. Alpha Testing: Conducted at the developer's site by a small group of end-users,
typically within the organization, before general release. It's an early form of
acceptance testing.
 Developers perform tests in a controlled environment.
 Test the application’s basic features.
 Report any issues found and fix them before moving to beta testing.
VI. Beta Testing: Conducted at customer sites by a larger group of real users in a real-
world environment. It's a public release for feedback and bug identification before the
final product launch.
 Develop a version of the software for a limited audience.

31
  Gather feedback, bug reports, and improvement suggestions.
 Analyze user experience, security, and performance issues.
 Fix critical bugs before the final release.

23. What is Regression testing?

Answer: Regression Testing is a type of testing done throughout the software’s life
cycle whenever a part of the system is changed or updated. The main purpose of
regression testing is to ensure that the recent changes have not caused any new
problems or faults in other parts of the system that were not modified. It is not
considered a separate level of testing but is done as part of unit testing, integration
testing, and system testing.

Figure: Regression testing at different software testing levels

24. Describe white-box & black-box testing?

Answer:

White Box Testing:

 Tester has full visibility into the source code and internal design.
 Tests are based on code structure, paths, branches, loops, and conditions.
 Requires programming knowledge to design and execute tests.
 The primary goal is to verify internal operations, logic, and security
vulnerabilities.
Black Box Testing:
 Tester has no visibility into the source code or internal logic of the
application/software.
 Tests focus on the software's functionality and user interface.
 Primarily concerned with whether the system meets business requirements.
 Test cases are derived from specifications,
requirements, and use cases.

25. Difference between white-box & black-box testing?

Answer:

White-box Testing Black-box Testing

Tests internal code and logic Tests functionality without code knowledge
Requires access to source code No access to source code needed
Done by developers Done by testers or QA teams
Focuses on control flow and paths Focuses on input and output
Also called structural testing Also called functional testing

32
 Chapter 5: Unit Testing

1. What is Unit Testing?

Answer: Unit Testing is the process of testing individual units or components of a
program (like a function or a method) to ensure that each part works correctly.

2. How to conduct unit test?

Answer: How to conduct unit testing:

i. Identify the smallest unit of code to test (e.g., a function).

ii. Write test cases with input values and expected results.
iii. Set up the testing environment or framework.
iv. Execute the unit with the test inputs.
v. Compare the actual output with the expected output.
vi. Fix any errors if the test fails.
vii. Repeat testing after corrections until the unit works correctly.

3. What is Abort () & Exit ()?

Answer:

Abort() is used for the abnormal termination of a program. It stops the

program immediately without cleaning up resources like closing files.

Exit() is used for normal (graceful) termination of a program. It closes open files
and returns a status code to the operating system.

4. What is Inspection & Walkthrough?

Answer:
Inspection: It is a step-by-step peer group review of a work product, with each step
checked against predetermined criteria.

Walkthrough: It is a review where the author leads the team through a manual or
simulated execution of the product using predefined scenarios.

33
 5. Describe the steps of code review process in static unit testing?

Answer: Code Review Process Steps in Static Unit Testing:

1. Readiness:
i) Completeness
ii) Minimal Functionality
iii) Readability
iv) Complexity
v) Requirements and Design Documens
vi) Moderator
vii) Author
viii) Presenter
ix) Recordkeeping
x) Reviewer
xi) Observers
2. Preparation:
i) List of questions
ii) Potential change requests(CRs)
iii) Suggested improvement opportunities
3. Examination: Choose the CRs
4. Rework: Author makes changes according to CRs
5. Validation: If it meets desired requirements.
6. Exit: After Completion, write a report.

Figure: Steps in the code review process.

34
 6. What is code review metrics?

Answer: Code review metrics are the measurement of data collected during the code review
process to evaluate its effectiveness. These metrics help in improving the review strategy,
estimating resources for future projects, and ensuring early detection of defects to improve
software quality.

Examples of code review metrics include:

 Number of Lines Of Code (LOC) reviewed per hour

 Number of Change Requests (CRs) per 1000 lines of code (KLOC)
 Number of CRs generated per hour
 Number of CRs generated per project
 Number of hours spent on code review per project

These metrics make the code review process measurable and valuable as a testing strategy.

7. Difference between Static & Dynamic unit

testing? Answer:

Static Unit Testing Dynamic Unit Testing

Tests code without executing it Tests code by executing it
Involves code reviews, walkthroughs, or analysis Involves writing and running test cases
It is used in the verification process It is used in the validation process.
Can be performed before compilation Can be performed after compilation
No actual code execution occurs Code is executed to observe behavior
Cost of finding and fixing faults/bugs is less Cost of finding and fixing faults/bugs is high.

8. Write a C program for finding the square root of any number and then design a
series of unit test cases to test if it gives the correct result for every possible
input.
Answer:
Source Code:
#include<bits/stdc++.h>
using namespace std;

int main(){
double n;
cin>>n;
if(n<0) cout<<"Square root of "<<n<<" not possible"<<endl;
else cout<<"Square root of: "<<n<<" is = "<<sqrt(n)<<endl;
return 0;
}

Test Case 1:
Sample Input: 0
Expected Output: 0
Received Output: 0

35
 Status: Pass

Test Case 2:
Sample Input: 1
Expected Output: 1
Received Output: 1
Status: Pass

Test Case 3:
Sample Input: 4
Expected Output: 2
Received Output: 2
Status: Pass

Test Case 4:
Sample Input: 7
Expected Output: 2.6458
Received Output: 2.6458
Status: Pass

Test Case 5:
Sample Input: -5
Expected Output: Square root of -5 not possible
Received Output: Square root of -5 not possible
Status: Pass

9. Write a C program for Odd-Even numbers and then design a series of unit
test cases to test if the program gives the correct output for every possible input.
Answer:
Source Code:
#include<bits/stdc++.h>
using namespace std;
int main(){
long long n;
cin>>n;
if(n==0) cout<<"Zero"<<endl;
else if(n%2==0) cout<<n<<" is even number"<<endl;
else cout<<n<<" is odd number"<<endl;
return 0;
}
//logic janite chahiya lojja diben na

Test Case 1:
Sample Input: 0
Expected Output: Zero
Received Output: Zero
Status: Pass

Test Case 2:
Sample Input: 1
Expected Output: 1 is odd number

36
Received Output: 1 is odd number
Status: Pass

Test Case 3:
Sample Input: 4
Expected Output: 4 is even number
Received Output: 4 is even number
Status: Pass

Test Case 4:
Sample Input: 1000000001
Expected Output: 1000000001 is odd number
Received Output: 1000000001 is odd number
Status: Pass

Test Case 5:
Sample Input: 100000000006
Expected Output: 100000000006 is even number
Received Output: 100000000006 is even number
Status: Pass

Test Case 6:
Sample Input: -5
Expected Output: -5 is odd number
Received Output: -5 is odd number
Status: Pass

Test Case 7:
Sample Input: -6
Expected Output: -6 is even number
Received Output: -6 is even number
Status: Pass

Test Case 8:
Sample Input: -5000000001
Expected Output: -5000000001 is odd number
Received Output: -5000000001 is odd number
Status: Pass

Test Case 9:
Sample Input: -500000006
Expected Output: -500000006 is even number
Received Output: -500000006 is even number
Status: Pass

Test Case 10:

Sample Input: 9223372036854775807
Expected Output: 9223372036854775807 is odd number
Received Output: 9223372036854775807 is odd number
Status: Pass

Test Case 11:

37
 Sample Input: -9223372036854775808
Expected Output: -9223372036854775808 is even number
Received Output: -9223372036854775808 is even number
Status: Pass

10. Write a C program for converting into capital/small and then design a series of
unit test cases to test if it gives the correct output for every possible input.
Answer:
Source Code:
#include<bits/stdc++.h>
using namespace std;
int main(){
char n, m;
cin>>n;
if(n>='A' && n<='Z') m=n+32;
else if(n>='a' && n<='z') m=n-32;
else{
cout<<n<<" is not an alphabet"<<endl;
return 0;
}
cout<<m<<endl;
}
//logic janite chahiya lojja diben na

Test Case 1:
Sample Input: a
Expected Output: A
Received Output: A
Status: Pass

Test Case 2:
Sample Input: z
Expected Output: Z
Received Output: Z
Status: Pass

Test Case 3:
Sample Input: A
Expected Output: a
Received Output: a
Status: Pass

Test Case 4:
Sample Input: Z
Expected Output: z
Received Output: z
Status: Pass

Test Case 5:

38
 Sample Input: 5
Expected Output: 5 is not an alphabet
Received Output: 5 is not an alphabet
Status: Pass

11. Write a C program for +, -, *, and / user-defined functions and then design a
series of unit test cases to test if it gives the correct output for every possible
input.
Answer:
Source Code:
#include<bits/stdc++.h>
using namespace std;
int main(){
double n, m;
cin>>n>>m;
char op;
cin>>op;
if(op=='+') cout<<n+m<<endl;
else if(op=='-') cout<<n-m<<endl;
else if(op=='*') cout<<n*m<<endl;
else if(op=='/') {
if(m==0) cout<<"Division by zero not possible"<<endl;
else cout<<n/m<<endl;
}
else if(op=='%') {
if(m==0) cout<<"Division by zero not possible"<<endl;
else cout<<(int)n%(int)m<<endl;
}
else cout<<"Invalid operator"<<endl;
}
//logic janite chahiya lojja diben na

Test Case 1:
Sample Input: 5 6 +
Expected Output: 11
Received Output: 11
Status: Pass

Test Case 2:
Sample Input: 5 6 -
Expected Output: -1
Received Output: -1
Status: Pass

Test Case 3:
Sample Input: 5 6 *
Expected Output: 30
Received Output: 30
Status: Pass

Test Case 4:

39
Sample Input: 5 6 /
Expected Output: 0.8333
Received Output: 0.8333
Status: Pass

Test Case 5:
Sample Input: 5 6 %
Expected Output: 5
Received Output: 5
Status: Pass

Test Case 6:
Sample Input: 4 0 /
Expected Output: Division by zero not possible
Received Output: Division by zero not possible
Status: Pass

Test Case 7:
Sample Input: 4 0 %
Expected Output: Division by zero not possible
Received Output: Division by zero not possible
Status: Pass

40
 Chapter 6: System Testing

1. What is System testing?

Answer: System Testing is the process of testing a complete and integrated software
system to verify that it meets the specified requirements. It checks the system’s
overall behavior and ensures that all components work together correctly in the real
environment before delivery to the customer.

2. Describe the types of system test?

Answer: The types of system test:
 Basic tests provide evidence that the system can be installed, configured,
and brought to an operational state.

 Functionality tests provide comprehensive testing across the full range of

requirements within the system's capabilities.

41
  Robustness tests determine how well the system recovers from various
input errors and other failure situations.

 Interoperability tests determine whether the system can interoperate with

other third-party products.
 Performance tests measure the performance characteristics of the system,
for example, throughput and response time, under various conditions.
 Scalability tests determine the scaling limits of the system in terms of user
scaling, geographic scaling, and resource scaling.
 Stress tests put a system under stress to determine the limitations of a
system and, when it fails, to determine how the failure occurs.
 Load and stability tests demonstrate that the system remains stable for an
extended period under full load.
 Reliability tests measure the ability of the system to keep operating for a
long time without developing failures.
 Regression tests determine that the system remains stable as it cycles
through the integration of other subsystems and through maintenance tasks.
 Documentation tests ensure that the system’s user guides are accurate and
usable.
 Regulatory tests ensure that the system meets the requirements of
government regulatory bodies in the countries where it will be deployed.

3. What is reliability testing?

Answer: Reliability testing checks if software works correctly and consistently over a
long time without failures. It ensures the system is stable and dependable under
expected conditions.
4. For a given data of {Failure no, Time between failures-hours, Repair time hours}
Find:
i. Mean time to Failure (MTTF).

42
 [Link] time to Repair(MTTR)
[Link] time Between Failure (MTBF).
iv. System availability
v. How many failures would occurs on average if the system is expected to
run 300 hours?
5. During the system testing phase of a software product, developers recorded the
time
intervals between system failures and the repair times required to
restore the system after each failure. The recorded data is as follows:
Failure No. Time Between Failures (hours) Repair Time (hours)
1 5 1.0
2 6 1.5
3 7 2.0
4 4 1.2

Questions:
i. Calculate the Mean Time To Failure (MTTF).
ii. Calculate the Mean Time To Repair (MTTR).
iii. Calculate the Mean Time Between Failures (MTBF).
iv. Determine the system availability as a percentage. If the system is
expected to run for 300 hours continuously, estimate how many
failures would occur on average based on the MTBF.

Answers:

Given Data:

Failure No. Time Between Failures (t₁, t₂, ...) Repair Time (r₁, r₂, ...)
1 5 1.0
2 6 1.5
3 7 2.0
4 4 1.2

2. Calculate MTTR (Mean Time To

Repair):
1. Calculate MTTF (Mean Time To
Failure) MTTR = (r1 + r2 + r3 + r4)/4

MTTF = (t1 + t2 + t3 + t4)/4 = (1.0 + 1.5 + 2.0 + 1.2) / 4

= (5 + 6 + 7 + 4) / 4 = 5.7 / 4

= 22 / 4 = 1.425 hours

= 5.5 hours

43
3. Calculate MTBF (Mean Time Between Failures):

MTBF = MTTF + MTTR

= 5.5 + 1.425

= 6.925 hours

5. Estimate Expected Failures in 300 Hours:

Expected Failures = Total Time/ MTBF

= 300 / MTBF

= 300 / 6.925

≈ 43.32

≈ 43 failures Final Answers: MTTF = 5.5 hours

MTTR = 1.425 hours MTBF = 6.925 hours Availability = 79.42% Expected

Failures = 43

4. Calculate System Availability:

Availability = MTTF / MTBF

= 5.5 / 6.925

≈ 0.7942

= 79.42

44
 Chapter 7: Product Metrics

1. What are Product Metrics? Describe.

Answer: Product Metrics are quantitative measurements that describe the
features and quality of a software product. They help software engineers analyze,
evaluate, and improve the software being developed or maintained. The
characteristics of product metrics are:

 Size
 Complexity
 Design Features
 Performance
 Quality Level
 Reusability
 Functionality

These measurements help the developer understand how big, complex, and reliable
the software is, and how well it performs.

2. Why it is important?

Answer: Product metrics are important because they:

 Help measure software quality and performance

 Provide objective data for decision-making
 Support better design, coding, and testing

3. Describe the categories of product Metrics?

Answer: Product metrics are divided into three main categories:

I. Size Metrics: These measure the size of software.

Example: Lines of Code (LOC), Function Points.
→ Help in effort, cost, and time estimation.

II. Complexity Metrics: These measure how complex the code or logic is.
Example: The Complexity of a code is O(n^2).
→ Useful to evaluate code maintainability.

III. Design Features Metrics: The attributes of a software.

Example: Cohesion (e.g., highly cohesive modules), Coupling (e.g., loosely
coupled modules).
→ Help in evaluating the structural quality of the design, impacting
maintainability, reusability, and testability.

IV. Performance Metrics: These evaluate the run-time behavior of software under
various conditions.
Example: Server response time, number of concurrent users supported.
→ Help in assessing the system's efficiency, scalability, and responsiveness under
expected and extreme loads.

45
 V. Quality Metrics: These evaluate the quality of the product.
Example: Defect Density, Mean Time Between Failures (MTBF).
→ Help track reliability and performance.

VI. Reusability Metrics: These measure the extent to which software components or
design elements can be repurposed/reused.
Example: Number of times a component is reused, percentage of system built from
existing components.
→ Help in promoting efficient development by identifying and leveraging components
that can be used across multiple projects, reducing development time and cost.

VII. Functionality Metrics: These quantify the capabilities and features provided by
the software to satisfy user needs.
Example: Function Points.
→ Help in measuring the scope of features delivered, assessing completeness of
requirements, and tracking progress.

4. You are analyzing a module of a software system written in C. The following

data is collected from the module:
 Total number of lines of code (LOC): 420
 Number of functions: 12
 Total number of operators: 180
 Total number of operands: 220
 Number of unique operators: 15
 Number of unique operands: 25
 Total number of detected defects: 6
 Execution time measured: 1.5 seconds
 Memory usage during execution: 45 MB

Questions

Calculate the Halstead Volume using the formula: Volume = 𝑁 × log2(𝑛) where
i. Calculate the average LOC per function.
ii.

46
 𝑁=Total operators + Total operands

𝑛=Unique operators + Unique operands

iii. Calculate the Defect Density (defects per 1000 LOC).

iv. Based on execution time and memory usage, evaluate whether the performance
is acceptable if the target is:

• Execution time ≤ 2.0 sec

• Memory usage ≤ 50 MB

Answer

Given Data:

• LOC = 420

• Number of functions = 12

• Total operators = 180

• Total operands = 220

• Unique operators = 15

• Unique operands = 25

• Defects = 6

• Execution time = 1.5 sec

• Memory usage = 45 MB

i. Average LOC per Function

Average LOC per function = Total LOC/Number of functions

= 420/12

= 35

ii. Halstead Volume

Volume = 𝑁 × log2(𝑛)

𝑁 = Total operators + Total operands

= 180 + 220

= 400

𝑛 = Unique operators + Unique operands

47
 = 15 + 25

= 40

Volume = 400 × log2(40)

= 400 × {log10(40)/ log10(2)}

= 2128.7712

iii. Defect Density

Defect Density = (Number of Defects/ LOC) × 1000

= (6/ 420) × 1000

= 14.2857 defects per KLOC

iv. Performance Evaluation

Given Targets:

• Execution Time ≤ 2.0 sec

• Memory Usage ≤ 50 MB

Measured:

• Execution Time = 1.5 sec

• Memory Usage = 45 MB

Both conditions are satisfied. So the performance is acceptable

48
 Chapter 8: Project Scheduling

1. What is Project Scheduling?

Answer: Project Scheduling is the process of planning and organizing software development
tasks in a sequence, assigning resources, and setting timelines to ensure the project is
completed on time.

2. Describe two methods of project scheduling.

Answer: Two methods closely related to project scheduling are:

 CPM(Critical Path Method): CPM is a project management technique that focuses on

identifying the longest sequence of dependent activities (the "critical path") that determines the
minimum time required to complete the project. It uses a network diagram (often an Activity-
On-Node or AON diagram) to visualize tasks and their dependencies. CPM helps identify the
earliest and latest start and finish times for each activity and calculates the "float" or "slack" (the
amount of time an activity can be delayed without delaying the project).
Example:
Path1: T1T2T3T5T6T7=25 days
Path2: T1T2T4T5T6T7=28 days
Hence, Critical Path is Path2 (Longest Sequence/Zero Slack).

 Time-Line Charts (Gantt Charts): These charts are a common method for representing a
project schedule. They illustrate the duration of each task on a timeline, often showing start and
end dates, and can visually represent task dependencies. They are valuable for tracking progress
and assessing if the project is falling behind schedule.

3. What is Time-Line chart for a demo project?

Answer: A Time-Line chart shows the order of tasks and their start and end times on a
line. It helps to see when each task happens and keeps the project on track.
49
4. Draw a Time-line chart for a demo
project? Answer:

50
5. What is Project table?
Answer: A Project Table is a simple chart that shows the list of all project tasks,
who will do them, how much time each task will take, and the deadline. It helps to
plan and track the progress of a project step by step.
6. Draw a project table for a demo
project? Answer:

7. For a demo project where {Task-ID, Task Name,Duration-days,Depending} is

given. Find:
a. Draw a project schedule showing the start and end day of each
task(assume no holidays or weekends)
b. Draw a Gantt chart?
c. Critical path
d. Total time required to complete the project
8. You are part of a software development team that has been assigned to build a
Library Management System for a university. The project must be completed
within 6 weeks. The tasks, estimated durations, and dependencies are as follows:
Task ID Task Name Duration (Days) Depends On
T1 Requirements Gathering 4 --
T2 System Design 3 T1
T3 Database Setup 4 T2
T4 Backend Development 6 T3
T5 Frontend Development 5 T3
T6 Integration 3 T4,T5
T7 Testing & Debugging 4 T6
T8 Deployment 2 T7

Questions:
I. Create a project schedule showing the start and end day of each task
(assume no holidays or weekends).
II. Draw a Gantt chart or a task schedule table to represent the project
visually.

51
 III. Identify the critical path of the project.
IV. Calculate the total time required to complete the

project. Answers:

Given,

Task ID Task Name Duration (Days) Depends On

T1 Requirements Gathering 4 --
T2 System Design 3 T1
T3 Database Setup 4 T2
T4 Backend Development 6 T3
T5 Frontend Development 5 T3
T6 Integration 3 T4,T5
T7 Testing & Debugging 4 T6
T8 Deployment 2 T7

I. Calculate Start & End Dates

We assume Day 1 is the project start date.
Task ID Task Name Duration Start Day End Day
T1 Requirements Gathering 4 1 4
T2 System Design 3 5 7
T3 Database Setup 4 8 11
T4 Backend Development 6 12 17
T5 Frontend Development 5 12 16
T6 Integration 3 18 20
T7 Testing & Debugging 4 21 24
T8 Deployment 2 25 26

II. Gantt Chart (Text-based Representation)

Day Tasks in Progress
1-4 T1: Requirements Gathering
5-7 T2: System Design
8-11 T3: Database Setup
12-17 T4: Backend Development
12-16 T5: Frontend Development
18-20 T6: Integration
21-24 T7: Testing & Debugging
25-26 T8: Deployment

Gantt Chart (Visual Representation)

52
III. Critical Path
A critical path is the longest sequence of dependent tasks that
determine the project duration.
Dependency Path 1:

T1 → T2 → T3 → T4 → T6 → T7 → T8
Durations: 4 + 3 + 4 + 6 + 3 + 4 + 2 = 26 days

Dependency Path 2:

T1 → T2 → T3 → T5 → T6 → T7 → T8
Durations: 4 + 3 + 4 + 5 + 3 + 4 + 2 = 25 days

Critical Path = Path 1 (26 days). Any delay in tasks on this path will
delay the entire project.
IV. Total Time to Complete Project
The total time required = 26 days, based on the critical path.
Final Answers:

Question Answer
Start/End of Each Task See task table above
Gantt Chart Visual or text version (shown above)
Critical Path T1 → T2 → T3 → T4 → T6 → T7 → T8
Total Time Required 26 days

53
 Sample Questions from Cost-Benefit Analysis

Scenario 1

A company is planning to implement a new information system to improve customer service

operations. The management has narrowed it down to two possible projects:

Project A: Cloud-Based CRM System

 Initial Cost: $50,000

 Annual Operating Cost: $10,000
 Expected Benefits: $30,000 per year in improved efficiency and customer retention
 Project Lifespan: 5 years

Project B: On-Premise CRM System

 Initial Cost: $80,000

 Annual Operating Cost: $5,000
 Expected Benefits: $25,000 per year in improved efficiency and customer retention
 Project Lifespan: 5 years

Assume a discount rate of 10% for the purpose of calculating Present Value Analysis (PVA).

Question 1

Based on the information provided, perform a Cost Benefit Analysis for both Project A and
Project B.

1. Calculate the Present Value Analysis (PVA) of both projects.

2. Which project should the company choose based on the PVA? Explain your
reasoning.
3. What non-financial factors should also be considered before making a final decision?

Scenario 2

A university is considering automating its course registration system. Two options are being
evaluated:

Project X: Custom-Built Web-Based System

 Initial Development Cost: $120,000

 Annual Maintenance: $15,000
 Expected Savings/Benefits: $50,000 annually due to reduced administrative
workload and faster student processing
 Lifespan: 4 years

Project Y: Off-the-Shelf Software

54
  Initial Cost: $60,000
 Annual Licensing & Maintenance: $25,000
 Expected Savings/Benefits: $40,000 annually
 Lifespan: 4

years Use interest rate of

8%.

Question 2

1. Calculate the Present Value Analysis of both Project X and Project Y.

2. Based on your calculations, which project is financially more viable? Explain.
3. Identify different types of cost and benefit associated with the above two projects.

Scenario 3

A logistics company wants to invest in a new routing optimization software to reduce fuel
costs and delivery times. They have two choices:

Project Alpha: AI-Based Dynamic Routing System

 Initial Investment: $150,000

 Annual Operating Costs: $20,000
 Estimated Annual Savings: $70,000 in fuel and time
 Lifespan: 3 years

Project Beta: Rule-Based Routing System

 Initial Investment: $90,000

 Annual Operating Costs: $15,000
 Estimated Annual Savings: $50,000
 Lifespan: 3 years

Assume a discount rate of 12%.

Question 3

1. Perform a Cost Benefit Analysis to determine the PVA of both Project Alpha
and Project Beta.
2. Which project offers a better return on investment?
3. Aside from the PVA, what other criteria should management consider before
selecting a project?

Scenario 4

55
Suppose a company is planning to undertake one project this year. There are a total two
projects to choose from. The decision is very crucial as it is directly associated with
company’s reputation with customers as well as finance. The following table represents year
wise benefits and costs.

Year Project I Project II

Cost Benefit Cost Benefit

1st 40 45 22 25

2nd 45 50 30 40

3rd 60 88 100 155

4th 40 55 25 44

Question 4

1. Examine which project the company should choose by applying cost benefit
analysis techniques?

Sample questions From Design Phases:

Question 1
A food delivery application allows users to create an account, place orders, track deliveries, and make
payments. The system notifies delivery drivers of new orders and allows them to update delivery
status. Admins manage user accounts and view reports.

a. Identify the main actors and use cases.

b. Draw a use case diagram showing relationships.
c. Explain the purpose of "include" and "extend" relationships in this context

Question 2
A school management system has classes for Student, Course, and Instructor. A student can
enroll in multiple courses, and each course can have one instructor.

a. Draw a class diagram showing relationships among the classes.

b. Identify the types of relationships used.
c. Add three attributes to each class and one method per class.

Question 3
A university wants to develop a Student Enrollment System. Students submit applications, which
are processed by the admissions office. Once accepted, students pay fees and receive enrollment
confirmation. The system interacts with the finance department for payment verification.

56
a. Identify the external entities, processes, data flows, and data stores.
b. Draw a level one DFD for the system.

57