AD

SMP Question Bank

Paper : 1
1. Define project. Explain project life cycle
ANS:
What is a Project?

A project is a temporary endeavor undertaken to create a unique product, service, or result. Projects
have specific objectives, a defined beginning and end, and are constrained by factors like time, cost,
and resources.

Key characteristics of a project include:

1. Temporary: Projects have a clear start and finish.
2. Unique: Each project delivers unique results or outputs.
3. Objective-driven: Projects are aimed at achieving specific goals.
Examples of projects include developing software, constructing a building, or designing a new
product.

What is a Project Life Cycle?

The project life cycle is a series of phases that a project goes through from initiation to closure.
These phases provide a framework for managing and controlling the project effectively.

Phases of the Project Life Cycle

1. Initiation Phase
◦ Defines the project at a high level.
◦ Key activities:

▪ Identify objectives and scope.

▪ Conduct feasibility studies.
▪ Develop a project charter.
▪ Stakeholder identification.
2. Planning Phase
◦ Establishes a detailed plan to achieve the project goals.
◦ Key activities:

▪ Define tasks, milestones, and deliverables.

▪ Allocate resources and assign roles.
▪ Create schedules and budgets.
▪ Risk assessment and management planning.
3. Execution Phase
◦ Implements the project plan by performing the defined tasks.
◦ Key activities:
▪ Coordinate team efforts.
▪ Monitor performance and progress.

1
AD
▪ Manage quality and changes.
▪ Communicate with stakeholders.
4. Monitoring and Controlling Phase
◦ Occurs simultaneously with execution to ensure the project stays on track.
◦ Key activities:
▪ Track project performance using metrics.
▪ Identify and mitigate risks.
▪ Manage changes to scope, schedule, and cost.
5. Closure Phase
◦ Formally completes and closes the project.
◦ Key activities:
▪ Deliver final outputs to stakeholders.
▪ Conduct post-project evaluation and lessons learned.
▪ Release resources and archive project documents.
Benefits of Understanding the Project Life Cycle

• Ensures systematic management and control.

• Improves resource allocation and risk management.
• Enhances communication and stakeholder satisfaction.
———X———X———X————

2. Explain in brief : Spiral Model.

ANS:
The Spiral Model is a risk-driven software development model that combines iterative
development with systematic risk analysis. It is ideal for large, complex, and high-risk projects.

Key Features of the Spiral Model

1. Iterative Development: The project is developed in repeated cycles (spirals), refining the
product with each iteration.

2. Risk Assessment: At each spiral, risks are identified, analyzed, and mitigated.
3. Flexibility: Incorporates feedback and changes easily into the development process.
4. Phased Approach: Combines aspects of the waterfall model and prototyping.

Phases in the Spiral Model

Each cycle in the Spiral Model has four main phases:

1. Planning:
◦ Define objectives, requirements, and constraints for the iteration.
◦ Estimate costs and schedules.
2. Risk Analysis:
◦ Identify potential risks (technical, financial, etc.).
◦ Develop strategies to mitigate these risks.
3. Engineering:
◦ Develop and validate the product or a prototype for that iteration.
◦ Perform tasks such as coding, testing, and integrating features.
2
 AD
4. Evaluation:
◦ Assess the current iteration's deliverables and gather feedback.
◦ Decide whether to proceed to the next cycle or terminate the project.

When to Use the Spiral Model

• Projects with uncertain or changing requirements.
• High-risk projects requiring constant evaluation and mitigation.
• Large and complex systems requiring iterative refinements.
Advantages
• Focus on risk management.
• Accommodates changing requirements.
• Provides early deliverables for evaluation.
• Suitable for complex projects.
Disadvantages
• Can be expensive and time-consuming.
• Requires expertise in risk analysis.
• Not suitable for small or low-risk projects.
The Spiral Model ensures a robust, flexible approach to software development, focusing on
minimizing risks and progressively refining the product.

———X———X———X————

3. Explain FTR.
ANS:
Formal Technical Review (FTR) is a key quality assurance activity aimed at improving software
quality by systematically reviewing artifacts, processes, or deliverables during the software
development lifecycle. It ensures adherence to project requirements, reduces errors, and enhances
communication among team members.

Role of FTR in SPM

1. Quality Assurance: FTR is used to identify defects in early stages, ensuring high-quality
deliverables.
2. Risk Mitigation: Detecting potential issues early reduces the risk of failure or rework later
in the project.
3. Process Control: Helps ensure the project adheres to prede ned standards and processes.
4. Cost Ef ciency: Early defect detection lowers the cost of correction compared to nding
issues during testing or after deployment.
5. Team Collaboration: Encourages active participation and knowledge sharing among team
members.

Steps of FTR in SPM

1. Initiation:

◦ Plan and schedule the review process.

◦ Select the artifact (e.g., design documents, code modules) to be reviewed.

3
fi
fi
fi
AD
2. Preparation:

◦ Team members examine the artifact individually before the formal meeting.
◦ Highlight potential issues or questions for discussion.
3. Review Meeting:

◦ Moderator facilitates the discussion.

◦ Reviewers present their ndings.
◦ Defects and improvement areas are identi ed and documented.
4. Rework:

◦ The author revises the artifact based on the feedback received.

5. Follow-Up:

◦ Verify that corrections are implemented and ensure the artifact is ready for its next
phase.

Advantages of FTR in SPM

• Early Error Detection: Minimizes the propagation of defects to later stages.

• Improved Planning: Helps project managers predict and control issues related to quality
and timelines.
• Documentation of Issues: Provides a record of defects and decisions for future reference.
• Process Standardization: Ensures deliverables meet organizational and project standards.
Example in SPM

• A project manager schedules an FTR for the system design document to ensure it aligns with
user requirements and technical standards before moving to the coding phase.
By incorporating FTR into software project management, projects are more likely to meet
deadlines, stay within budget, and achieve their quality goals effectively.

———X———X———X————

6. Define requirements engineering. Explain any two requirements elicitation

techniques.
ANS:
Requirements Engineering plays a critical role in ensuring that the project's scope is de ned, and
that the delivered software meets the needs of stakeholders. Within the context of SPM,
requirements engineering is viewed as an essential process for setting realistic project goals,
avoiding scope creep, and ensuring the ef cient use of resources throughout the software
development lifecycle.

Requirements Engineering in SPM

In SPM, Requirements Engineering ensures that the development team builds the right product
with clear objectives, user expectations, and project constraints in mind. Effective requirements
engineering helps in estimating project costs, planning the schedule, allocating resources, and
managing risks. It also establishes a baseline against which the project progress and success can be
measured.

Requirements engineering in SPM is typically divided into the following key activities:
4
fi
fi
fi
fi
 AD
1. Requirements Elicitation: Gathering the needs, expectations, and constraints of
stakeholders.
2. Requirements Analysis: Analyzing the gathered requirements to ensure that they are clear,
consistent, complete, feasible, and testable.
3. Requirements Speci cation: Documenting the requirements in a structured, clear, and
comprehensive way.
4. Requirements Validation: Ensuring that the requirements meet the stakeholders' needs and
that the system can realistically ful ll them.
5. Requirements Management: Handling changes in the requirements throughout the project
lifecycle, keeping track of any modi cations to scope, and ensuring the requirements remain
aligned with project goals.
Two Requirements Elicitation Techniques in SPM

In Software Project Management, the following two elicitation techniques are commonly used to
ensure that the project is aligned with stakeholders' needs:

1. Interviews

Interviews are one of the most common techniques used in requirements elicitation. In SPM, the
project manager or requirements engineer conducts interviews with stakeholders to capture detailed
insights about the system's needs, objectives, and expectations.

Advantages in SPM Context:

• In-depth Understanding: Direct communication allows for clarifying ambiguities and

obtaining a clear understanding of the stakeholders' needs.
• Address Speci c Stakeholder Concerns: Stakeholders may have unique requirements
based on their roles (e.g., end-users, business managers, technical teams), which can be
understood better through personalized interviews.
• Building Rapport: Interviews help build trust and rapport with stakeholders, which is
crucial for successful project execution.
Disadvantages in SPM Context:

• Time-Consuming: Interviews, especially when dealing with multiple stakeholders, can be a

lengthy process.
• Subjectivity and Bias: Stakeholders may have personal biases or perspectives, which can
affect the clarity and objectivity of the information collected.
2. Surveys/Questionnaires

Surveys and questionnaires are an effective technique for gathering requirements from a larger
group of stakeholders, especially when personal interviews may be impractical. This method
involves creating structured forms that ask stakeholders to answer speci c questions related to
system functionality, preferences, and needs.

Advantages in SPM Context:

• Cost and Time Ef ciency: Surveys can be distributed to a large number of stakeholders at
once, making it faster and less expensive than conducting individual interviews.
• Quanti able Data: Survey responses, particularly when using closed-ended questions,
provide easy-to-analyze quantitative data, which can help in decision-making processes.
• Wide Stakeholder Reach: Surveys can capture input from a diverse group of stakeholders,
including those who may not be available for interviews.
5
fi
fi
fi
fi
fi
fi
fi
 AD
Disadvantages in SPM Context:

• Limited Depth: Unlike interviews, surveys may not allow for in-depth exploration of issues
or clari cation of ambiguous responses.
• Risk of Misinterpretation: If the questions are not clear or well-structured, respondents
may misinterpret them, leading to inaccurate or incomplete data.
• Engagement Issues: Stakeholders may not fully engage with the survey, leading to
incomplete or biased responses, especially if the survey is long or too detailed.
———X———X———X————

6. What are the key elements included in the Project Closure process.
ANS:
The Project Closure process in Software Project Management (SPM) is the nal phase of the
project lifecycle. It involves formalizing the completion of the project, ensuring that all project
objectives have been met, and that the results are handed over to the relevant stakeholders. This
process ensures that the project is fully concluded, lessons are learned, and all contractual
obligations are ful lled.

The key elements included in the Project Closure process are:

1. Final Deliverables Handover

• De nition: The project deliverables (such as software, documentation, user manuals, etc.)
are formally handed over to the client or the intended end-users.
• Activities: Ensuring that all deliverables are complete, tested, and meet the agreed-upon
requirements.
• Purpose: To ensure that the project has delivered everything that was promised to
stakeholders and that the product is ready for production or operational use.
2. Stakeholder Sign-off

• De nition: Stakeholders, including the project sponsor, clients, and end-users, formally
approve the project's deliverables.
• Activities: Obtaining written sign-offs from all relevant stakeholders that they accept the
nal deliverables and con rm that the project objectives have been achieved.
• Purpose: To obtain formal approval from stakeholders that the project has met its goals and
requirements, which ensures a clear conclusion.
3. Final Project Report

• De nition: A comprehensive report is created to summarize the entire project, detailing

what was done, how it was achieved, and the nal outcome.
• Activities: Documenting the project’s objectives, milestones, achievements, issues
encountered, and solutions applied.
• Purpose: To provide a nal record of the project, which can be used for future reference,
audits, or knowledge sharing.
4. Release of Project Resources

• De nition: Resources (such as team members, tools, and equipment) are of cially released
from the project.
• Activities: Reassigning team members to new projects or other organizational duties,
returning equipment, and ensuring that all resources are accounted for and properly
reallocated.

6
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 AD
• Purpose: To ensure that resources are no longer tied to the project and are available for
other tasks within the organization.
5. Post-Implementation Review

• De nition: A review meeting or evaluation process to assess the overall success of the
project.
• Activities: Analyzing whether the project objectives were achieved, what went well, what
challenges were faced, and what could have been improved.
• Purpose: To learn from the project and identify any improvements or best practices that can
be applied to future projects.
6. Closing Contracts

• De nition: Ensuring that all contractual obligations have been ful lled and that contracts
with external vendors or partners are closed.
• Activities: Verifying that all payments, deliverables, and service level agreements (SLAs)
have been met and that the project team has signed off on the contract completion.
• Purpose: To ensure that legal, nancial, and other contractual obligations are ful lled, and
that the project is formally closed from a contractual perspective.
7. Archiving Project Documents

• De nition: Storing project-related documentation for future reference or audits.

• Activities: Ensuring that all important project documents, such as plans, designs, reports,
and communications, are archived properly and accessible if needed in the future.
• Purpose: To maintain a record of the project for historical purposes, knowledge sharing, and
possible future use (e.g., for audits or legal reasons).
8. Celebrating and Acknowledging Success

• De nition: Acknowledging the hard work and achievements of the project team.
• Activities: Organizing a project closure meeting, celebration, or recognition event for team
members and stakeholders to acknowledge their contributions and successes.
• Purpose: To boost team morale and foster a sense of accomplishment, as well as to build a
positive relationship for future projects.
9. Customer Feedback and Satisfaction Survey

• De nition: Gathering feedback from the client or users to assess their satisfaction with the
project outcome.
• Activities: Conducting surveys or interviews to understand the client’s views on the
project's success, areas for improvement, and overall satisfaction.
• Purpose: To gauge how well the project met stakeholder expectations and identify
opportunities for improvement in future projects.
10. Lessons Learned

• De nition: Documenting the lessons learned during the project to provide insights for future
projects.
• Activities: Identifying what worked well, what didn’t, and why. Documenting the key
takeaways and creating recommendations for future projects.
• Purpose: To capture valuable knowledge and insights that can be used to improve
processes, avoid repeating mistakes, and enhance the ef ciency and effectiveness of future
projects.
11. Financial Closure

• De nition: Ensuring that all nancial aspects of the project are nalized and closed.
7
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 AD
• Activities: Verifying that all invoices have been paid, all costs have been accounted for, and
the project’s nancial records are closed.
• Purpose: To ensure that the project’s nancials are properly settled, and no outstanding
nancial issues remain.
———X———X———X————

8. Write a short note on tools and techniques used in Quality Control.

ANS:
Quality Control (QC) is a process that ensures the quality of a product or service meets the required
standards and satis es customer expectations. It involves identifying defects, correcting errors, and
ensuring consistency. Various tools and techniques are used in QC to monitor and improve the
quality of outputs. Below are some common tools and techniques used in Quality Control:

1. Statistical Process Control (SPC)

De nition: SPC is a method of monitoring and controlling a process through the use of statistical
methods. It helps to detect and correct deviations in a process before defects occur.

• Control Charts: A tool used in SPC to track process behavior over time, identifying trends,
shifts, or variations that may indicate a quality issue.
• Process Capability Index: Measures how well a process is performing in relation to its
desired output.
Usage: SPC is widely used in manufacturing and service industries to ensure that processes remain
consistent and within speci ed limits.

2. Pareto Analysis

De nition: Pareto analysis, based on the Pareto Principle (80/20 Rule), helps identify the most
signi cant issues by recognizing that a small number of causes often contribute to a large portion of
the problems.

• Pareto Chart: A bar chart where issues are arranged in descending order of frequency or
impact, helping to prioritize the most signi cant problems.
Usage: Used to focus corrective efforts on the most critical defects or areas that will have the
greatest impact on quality improvement.

3. Fishbone Diagram (Ishikawa Diagram)

De nition: A graphical tool used to identify, explore, and display the possible causes of a speci c
problem or defect. It helps teams understand the root causes of issues.

•Categories: The diagram typically includes categories like Materials, Methods, Machines,
Manpower, and Environment (5Ms) to analyze the causes of quality problems.
Usage: Used in root cause analysis to trace issues back to their origin and identify potential areas
for improvement.

4. Control Charts

De nition: Control charts are a visual tool used to monitor the variation in a process over time.
They display the process data along with control limits, which help determine if a process is stable
and in control.
8
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 AD
• Types: X-bar chart, R-chart, p-chart, and np-chart.
Usage: Used in continuous monitoring of processes to detect any out-of-control conditions and take
corrective actions.

5. Histogram

De nition: A histogram is a graphical representation of the frequency distribution of a dataset. It is

used to visualize data distribution and identify patterns or deviations from the norm.

• Usage: Helps in analyzing the distribution of data and identifying trends, variations, or
anomalies in quality.
6. Flowchart

De nition: A owchart is a diagram that represents the sequence of steps in a process, helping to
visualize the work ow and identify potential problem areas.

• Usage: Used to map out processes and identify bottlenecks or inef ciencies that may affect
product or service quality.
7. Six Sigma Tools

De nition: Six Sigma tools are widely used to improve processes by identifying and eliminating
defects. They follow a data-driven approach to process improvement.

• DMAIC (De ne, Measure, Analyze, Improve, Control): A Six Sigma methodology used
for process improvement.
• Process Mapping: Used to visualize and understand process ow.
Usage: Commonly used in industries aiming for near-perfect quality levels (e.g., 99.99966% defect-
free products).

8. Inspection and Testing

De nition: Inspection and testing are fundamental techniques used in QC to identify defects before
products or services are delivered to customers.

• Types: Visual inspection, functional testing, performance testing, and destructive testing.
Usage: Employed to check if the product or service meets the speci ed quality standards and
speci cations.

9. Check Sheets

De nition: A check sheet is a structured form for collecting data in real-time at the location where
the data is generated. It helps in recording occurrences of speci c defects or problems.

• Usage: Used to identify patterns or frequency of issues and provides insights into areas
requiring attention.
10. Benchmarking

De nition: Benchmarking involves comparing a product, service, or process against industry best
practices or competitors to identify areas of improvement.

9
fi
fi
fi
fi
fi
fi
fi
fi
fl
fl
fl
fi
fi
fi
 AD
• Usage: Used to ensure that a product or process meets or exceeds industry standards for
quality.

———X———X———X————

9. Write a short note on Work Breakdown Structure.

ANS:
A Work Breakdown Structure (WBS) is a hierarchical decomposition of a project into smaller,
more manageable components. It is a key project management tool that helps organize and de ne
the total scope of a project. The WBS breaks the project into work packages, which are distinct
tasks or deliverables that can be easily planned, executed, and monitored.

Key Features of a WBS:

1. Hierarchical Structure:
◦ The WBS is structured in levels, starting from the highest level (the overall project)
and breaking down into smaller, more detailed components at lower levels.
◦ Each level of the WBS represents an increasingly granular level of detail about the
project’s scope.
2. Deliverable-Oriented:

◦
The WBS is organized by deliverables (what needs to be produced or completed)
rather than by tasks or activities. This helps focus on the outcomes of the project.
◦ Each deliverable can be broken down into smaller components until they reach a
level where they can be easily managed and assigned to team members.
3. Work Packages:

◦ The smallest units in a WBS are called work packages, which are the tasks that can
be assigned to speci c team members or groups.
◦ Work packages are de ned with clear goals, timelines, resources, and outputs.
Purpose and Bene ts of WBS:

1. Clari es Project Scope:

◦The WBS helps de ne and clarify the project scope by breaking down high-level
goals into speci c deliverables and tasks.
◦ It ensures that all aspects of the project are accounted for, reducing the risk of
missing critical work.
2. Improves Project Planning:

◦
By breaking down tasks into smaller components, the WBS aids in more accurate
estimation of time, cost, and resources.
◦ It helps in scheduling tasks, assigning responsibilities, and tracking progress.
3. Enhances Communication:

◦The WBS provides a clear structure that all stakeholders can refer to, improving
communication within the project team and with clients or sponsors.
4. Risk Management:

◦ It helps identify potential risks early by allowing the team to examine all the
components of the project.
10
fi
fi
fi
fi
fi
fi
fi
 AD
◦ Risks can be mitigated by addressing critical areas or dependencies identi ed
through the WBS.
Creating a Work Breakdown Structure:

1. De ne the Project Objectives: Understand the overall project goals and deliverables.
2. Identify Major Deliverables: Break the project into its major components or phases (e.g.,
planning, design, development).
3. Decompose Deliverables into Sub-deliverables: Continue breaking down each component
into smaller deliverables or tasks until the work is manageable.
4. Develop Work Packages: De ne the lowest-level tasks that can be assigned to individuals
or teams.
5. Assign Resources and Responsibility: Allocate resources to the work packages and assign
responsibilities.
Example of WBS:

For a software development project, the WBS could look like this:

1. Project Management
◦ 1.1 Planning
◦ 1.2 Monitoring & Control
2. Design
◦ 2.1 System Design
◦ 2.2 User Interface Design
3. Development
◦ 3.1 Frontend Development
◦ 3.2 Backend Development
4. Testing
◦ 4.1 Unit Testing
◦ 4.2 System Testing
◦ 4.3 User Acceptance Testing
5. Deployment
◦ 5.1 Production Deployment
———X———X———X————

6. What is SRS? Why it is important to develop SRS.

ANS:
A Software Requirements Speci cation (SRS) is a comprehensive, detailed document that
outlines the functional and non-functional requirements of a software system. It serves as a
blueprint for both the development team and stakeholders, providing a clear understanding of what
the software must do and how it should perform. The SRS document speci es the software's
behavior, user interface, system interfaces, performance, and other characteristics necessary for the
successful development and operation of the system.

Key Components of SRS:

1. Introduction:

◦ Overview of the software project, its objectives, intended audience, and scope.
◦ Includes background information and assumptions.
2. Functional Requirements:

11
fi
fi
fi
fi
fi
 AD
◦
Describes the system’s behavior, including speci c functionalities, features, and
interactions with users or other systems.
◦ Speci es what the system should do in terms of inputs, outputs, and processing.
3. Non-Functional Requirements:

◦ Includes performance, security, scalability, usability, and reliability requirements.

◦ Speci es "how" the system should perform rather than what it should do.
4. System and User Interfaces:

◦ De nes how the system interacts with users, other systems, and external devices.
◦ Includes user interface design, input/output formats, and interaction details.
5. Data Requirements:

◦
Describes the data that the system will use, including data types, storage, and
retrieval mechanisms.
6. Constraints:

◦
Speci es limitations or restrictions imposed on the system, such as hardware
constraints, software environment, or regulatory requirements.
7. Acceptance Criteria:

◦ De nes the conditions that must be met for the software to be accepted by
stakeholders or clients.
Importance of Developing an SRS:

1. Clear Communication:

◦
The SRS document serves as a communication tool between stakeholders (clients,
end-users, developers, and testers). It ensures that everyone has a clear and common
understanding of the system's objectives, functionalities, and constraints.
2. Foundation for Design and Development:

◦The SRS provides the groundwork for the design and development phases.
Developers use the requirements in the SRS to create the system architecture, choose
appropriate technologies, and write code that meets the speci cations.
3. Helps in Managing Scope:

◦
The SRS helps in de ning the scope of the software project by listing only the
required features and functionalities. It reduces the risk of scope creep by ensuring
that any change or addition to the system is carefully considered and documented.
4. Reduces Ambiguity:

◦The detailed nature of the SRS reduces ambiguity in the software development
process. Clear, precise requirements minimize the chances of misunderstandings
between developers, clients, and other stakeholders.
5. Aids in Testing and Validation:

◦The SRS includes acceptance criteria and performance standards that serve as a
foundation for testing the system. Testers can use the document to ensure that the
system behaves as expected and meets all requirements.
6. Cost and Time Ef ciency:

12
fi
fi
fi
fi
fi
fi
fi
fi
fi
 AD
◦ By documenting the requirements clearly upfront, the development team can avoid
costly rework and delays that may arise from misunderstandings or incomplete
requirements. A well-de ned SRS helps in creating accurate project timelines and
budgets.
7. Facilitates Change Management:

◦If changes or updates to the system are needed, the SRS provides a baseline to
evaluate the impact of those changes. It helps in controlling and managing
modi cations effectively, ensuring that new requirements are integrated without
disrupting the overall project.
8. Legal and Contractual Purposes:

◦The SRS serves as a formal contract between the client and the development team. It
ensures that the software delivered meets the agreed-upon speci cations, and can be
used to resolve any disputes that may arise during or after the development process.
9. Quality Assurance:

◦ The SRS helps ensure that the software meets quality standards by clearly de ning
functional and non-functional requirements. It serves as a guideline for creating
quality metrics and verifying that the system performs as expected.
———X———X———X————

7. Explain RAD and Agile Development Model in detail.

ANS:

RAD (Rapid Application

Aspect Agile Development
Development)
A software development methodology An iterative and incremental approach
De nition focused on rapid prototyping and user emphasizing exibility, collaboration, and
feedback. continuous improvement.
Development Focuses on building prototypes and Involves short, time-boxed sprints,
Approach re ning them through user feedback. delivering functional software increments.
High user involvement throughout the
User Continuous collaboration with the
development process, especially in
Involvement customer throughout the project.
prototyping.
Development in iterations or sprints
Prototyping in rapid cycles to gather
Iterations (usually 1-4 weeks), each delivering a
user feedback and re ne the product.
small, working feature.
Flexible, but typically best for smaller, Highly exible and adaptable, with
Flexibility
less complex systems. constant adjustments based on feedback.
Key Working prototypes that evolve into Incremental working software at the end
Deliverables nal software after multiple iterations. of each sprint, leading to a nal product.
1. Concept/Inception, 2. Iteration
1. Requirement Planning, 2. User Planning, 3. Design & Development, 4.
Phases
Design, 3. Construction, 4. Cutover. Testing, 5. Release & Delivery, 6. Review
& Retrospective.
Development Very fast, focusing on delivering Fast, with frequent releases and regular
Speed prototypes quickly. feedback loops.

13
fi
fi
fi
fi
fl
fl
fi
fi
fi
fi
fi
 AD
Typically lower cost due to reduced
Can be more cost-effective with frequent
Cost development time and reusable
releases and feedback.
components.
Limited testing early in development; Testing is integrated into each sprint, with
Testing
testing occurs after prototype iteration. continuous veri cation.
Potential risks include incomplete
Potential risks include scope creep, as
Risks functionality and quality issues due to
requirements may change frequently.
rapid development.
Small to medium projects with well- Projects with evolving requirements and a
Suitable For de ned user needs and high user focus on customer collaboration and
interaction. feedback.
- Rapid development - High exibility
Advantages - High user involvement - Frequent delivery of working software
- Quick feedback loop - Continuous improvement and adaptation
- Limited scalability for large systems - Requires continuous customer
Disadvantages - Risk of quality issues due to rapid involvement
prototyping - Scope creep risk due to frequent changes

———X———X———X————

8. Write a short note on Stakeholder Management.

ANS:
Stakeholder Management is the process of identifying, analyzing, and managing the interests,
expectations, and in uence of stakeholders throughout a project or organizational initiative.
Stakeholders are individuals, groups, or organizations that are affected by or have an interest in the
project's outcome. Effective stakeholder management ensures that all relevant parties are engaged,
informed, and their concerns are addressed, leading to a smoother project execution and increased
chances of success.

Key Elements of Stakeholder Management:

1. Identi cation of Stakeholders:
◦The rst step is to identify all stakeholders who may have an impact on the project or
be impacted by it. This includes internal stakeholders (e.g., project team,
management) and external stakeholders (e.g., customers, suppliers, regulatory
bodies).
2. Stakeholder Analysis:

◦Once stakeholders are identi ed, it is essential to analyze their interests, in uence,
and potential impact on the project. This can be done using tools like the Power/
Interest Grid, which classi es stakeholders based on their level of in uence and
interest in the project.
3. Developing a Stakeholder Engagement Plan:

◦ This plan outlines how stakeholders will be involved and communicated with
throughout the project. It should specify communication channels, frequency, and
methods for each stakeholder group.

14
fi
fi
fi
fl
fi
fl
fi
fi
fl
fl
 AD
4. Engagement and Communication:
◦ Ongoing communication with stakeholders is key to managing their expectations.
Regular updates, meetings, and reports help ensure stakeholders are informed and
their concerns are addressed promptly.
5. Monitoring and Managing Expectations:

◦ Stakeholder expectations should be managed carefully, ensuring that what is

promised is achievable and realistic. Regular feedback and transparent discussions
can help prevent misunderstandings or dissatisfaction.
6. Con ict Resolution:

◦ Con icts may arise between stakeholders with differing interests. Stakeholder
management includes resolving such con icts by balancing priorities and nding
solutions that align with the project’s objectives.
7. Feedback and Adjustment:

◦ Gathering feedback from stakeholders throughout the project is essential for making
adjustments and ensuring that stakeholder needs are met as the project evolves.
Importance of Stakeholder Management:
1. Builds Strong Relationships:
◦ Effective stakeholder management fosters strong, positive relationships between the
project team and stakeholders, promoting trust and cooperation.
2. Aligns Expectations:

◦ By engaging stakeholders early and frequently, project teams can ensure that
everyone has a clear understanding of the project goals, scope, and deliverables,
minimizing misunderstandings and misaligned expectations.
3. Reduces Risk:

◦ By addressing stakeholder concerns and mitigating issues early on, the likelihood of
con icts, delays, or project failure is reduced.
4. Increases Project Success:

◦ Projects are more likely to succeed when stakeholders are satis ed and engaged.
Their support can ensure that the project has the resources, funding, and
organizational backing needed.
5. Enhances Decision Making:

◦ Engaging stakeholders and collecting their input allows for better decision-making
by considering a wider range of perspectives and expertise.
———X———X———X————

9. Explain various steps involved in Risk Monitoring and Control.

ANS:
Risk Monitoring and Control is the process of tracking identi ed risks, monitoring residual risks,
identifying new risks, and ensuring that risk responses are effective. It involves the continuous
process of risk assessment throughout the project lifecycle to ensure that risks are being properly
managed and that the project is on track to meet its objectives. The goal of risk monitoring and
control is to minimize the impact of risks on the project’s success by proactively managing them.
15
fl
fl
fl
fl
fi
fi
fi
 AD

Steps Involved in Risk Monitoring and Control:

1. Identify New Risks:

◦ As the project progresses, new risks may emerge. These could be due to changes in
the project environment, new stakeholders, or external factors. Monitoring helps in
identifying any new risks that were not anticipated earlier.
◦ Action: Regular reviews, brainstorming sessions, and consultations with
stakeholders can help uncover new risks.
2. Track Existing Risks:
◦ Once risks have been identi ed, it is important to track them continuously to ensure
they are being monitored and managed according to the plan. This includes
observing any changes in risk likelihood, severity, or impact on the project.
◦ Action: Use tools such as risk registers or risk management dashboards to keep track
of risk status, response actions, and changes in the project’s risk pro le.
3. Assess Risk Impact and Probability:
◦ Continuously assess the probability and impact of identi ed risks to determine if
they have changed over time. Changes in the project environment or scope can
in uence these factors.
◦ Action: Periodically update risk assessments by re-evaluating risks using qualitative
and quantitative methods.
4. Evaluate Risk Responses:
◦ Monitor the effectiveness of the risk responses that have been implemented. Are the
actions taken to mitigate or avoid risks working as planned? If not, adjustments may
be necessary.
◦ Action: Assess the effectiveness of contingency plans, risk avoidance measures, and
risk mitigation strategies. Review response strategies for issues that have
materialized.
5. Monitor Residual Risks:
◦ Residual risks are the remaining risks after mitigation strategies have been applied.
It’s important to continue monitoring these risks to ensure that they do not escalate
or lead to further issues.
◦ Action: Keep an eye on any residual risks and evaluate whether additional responses
are needed.
6. Implement Corrective Actions:
◦ If risks are not being managed effectively or if the situation changes, corrective
actions should be taken. These may involve modifying risk management strategies,
adjusting resources, or revising the project plan.
◦ Action: If a risk response is failing, reassess the response and apply corrective
measures to reduce its impact.
7. Review and Update Risk Register:
◦ The risk register is an ongoing tool used to record, track, and evaluate risks. It should
be updated regularly to re ect new risks, changes in existing risks, and the status of
mitigation measures.
◦ Action: Update the risk register based on ndings from risk tracking and monitoring
activities. This should include any new risks, modi cations to current risks, and
progress on responses.
8. Report Risk Status:
◦ Regularly communicate the status of risks to stakeholders, including any signi cant
changes in the risk landscape and the effectiveness of responses. This helps ensure
that all parties are aware of the project’s risk situation and any required interventions.

16
fl
fl
fi
fi
fi
fi
fi
fi
AD
◦ Action: Provide risk status reports to project sponsors, team members, and other
stakeholders. Ensure that reports are clear and comprehensive, addressing both
current and future risk concerns.
9. Review Risk Management Processes:
◦ At certain milestones or after signi cant events, review the overall risk management
process. Assess whether the risk management framework, tools, and techniques are
working as expected.
◦ Action: Evaluate the ef ciency and effectiveness of the overall risk management
process and make improvements as necessary.
10. Close Risks:
• Once a risk has been resolved or mitigated successfully, it is important to formally close the
risk in the risk register. Similarly, risks that were identi ed but never materialized can also
be closed.
• Action: Document the closure of risks, including lessons learned and any changes made to
the risk management plan.

Tools and Techniques Used in Risk Monitoring and Control:

1. Risk Register:
◦ A key document used to track identi ed risks, their likelihood and impact, responses,
and current status.
2. Risk Breakdown Structure (RBS):
◦ A hierarchical structure that helps in identifying and categorizing risks.
3. Risk Audits:
◦ A structured process that involves reviewing and analyzing the effectiveness of risk
management activities.
4. Risk Reporting:
◦ Reporting tools such as dashboards, charts, or status reports to communicate the
current state of risks to stakeholders.
5. Variance and Trend Analysis:
◦ Techniques used to analyze project performance data and assess whether any risk
events are trending positively or negatively.
6. Expert Judgment:
◦ Involving subject matter experts to assess risks, review mitigation strategies, and
recommend corrective actions.

Importance of Risk Monitoring and Control:

1. Early Detection of Issues:
◦ Continuous monitoring helps identify potential issues before they escalate, giving the
team more time to act and adjust.
2. Proactive Risk Management:
◦ Allows the team to stay proactive by responding quickly to new risks or changes in
existing ones, improving overall project stability.
3. Improves Decision-Making:
◦ Provides stakeholders with real-time risk data, enabling informed decision-making
and timely intervention.
4. Ensures Project Success:
◦ Effective risk monitoring and control reduce the likelihood of major risks affecting
the project's outcome, ensuring project success.
———X———X———X————

17
fi
fi
fi
fi
AD
Paper : 2
Q.1)Write short notes on
a) Mc Calls quality Model
b) Role of Project Manager
c) Data Flow Diagram
d) Work Breakdown Structure
e) Leadership styles
f) Systems view of Project Management.
ANS:
1. McCall's Quality Model

McCall's Quality Model, introduced in 1977, is a framework used to evaluate the quality of a
software product. It focuses on 11 factors under three categories:

• Product Operation: Factors such as correctness, ef ciency, reliability, integrity, and

usability affect the performance of the product during operation.
• Product Revision: Factors like maintainability, exibility, and portability in uence the
ease of modifying the software over time.
• Product Transition: Factors such as reuse, interoperability, and adaptability assess how
well the software can adapt to different environments or be integrated with other systems.
McCall's model provides a basis for understanding and measuring software quality across these
areas, helping teams focus on key attributes for product success.

2. Role of Project Manager

The Project Manager (PM) is responsible for planning, executing, and closing projects while
managing the project team and resources. Key responsibilities include:

•Planning: De ning project scope, objectives, timelines, and resources.

•Execution: Leading and coordinating the team to achieve project milestones.
•Monitoring and Controlling: Tracking progress, identifying risks, and making adjustments
to ensure the project stays on course.
• Risk Management: Identifying potential risks and mitigating them.
• Communication: Ensuring smooth communication with stakeholders and team members.
• Closing: Finalizing the project and evaluating its success.
The PM ensures that the project is completed on time, within budget, and to the satisfaction of
stakeholders.

3. Data Flow Diagram (DFD)

A Data Flow Diagram (DFD) is a visual representation of how data moves through a system. It
shows data sources, processes, storage, and data ows. The main components include:

• Processes: Represented by circles, showing where data is transformed.

• Data Flows: Arrows indicating the movement of data between processes, external entities,
and data stores.
• Data Stores: Rectangles indicating where data is stored.
• External Entities: Squares representing systems or users that interact with the system.

18
fi
fl
fl
fi
fl
 AD
DFDs help in understanding the functional ow of information and are widely used in system
analysis and design.

4. Work Breakdown Structure (WBS)

The Work Breakdown Structure (WBS) is a hierarchical breakdown of the project scope into
smaller, manageable work packages. It helps in:

• Organizing tasks: The WBS breaks the project into more detailed components for easier
management.
• De ning deliverables: Ensures that all deliverables are clearly de ned and tracked.
• Assigning responsibilities: Clari es who is responsible for each task.
• Resource management and budgeting: Helps in resource allocation, cost estimation, and
project scheduling.
A well-structured WBS ensures that every aspect of the project is covered and helps manage
complexity effectively.

5. Leadership Styles

Leadership styles refer to the approaches leaders take to motivate and manage their teams.
Common styles include:

• Autocratic: The leader makes decisions unilaterally with little input from team members.
• Democratic: The leader encourages team involvement in decision-making.
• Laissez-Faire: The leader allows team members to make decisions with minimal
intervention.
• Transformational: Leaders inspire and motivate the team to exceed expectations and
embrace innovation.
• Transactional: Focuses on clear roles, rules, and expectations, with rewards or penalties
based on performance.
The leadership style used can signi cantly impact team dynamics, motivation, and project
outcomes.

6. Systems View of Project Management

The Systems View of Project Management treats a project as a system composed of

interconnected processes, people, and resources. Key aspects include:

• Holistic Approach: Recognizing that changes in one part of the project can affect the whole
system.
• Integration: Ensuring all project components (scope, time, cost, resources) are aligned with
the project's goals.
• Dynamic Interaction: Understanding that project factors evolve over time and require
ongoing adjustments.
• Feedback Loops: Continuous assessment and adjustment based on project performance.
This approach helps in understanding the interdependencies within the project, promoting better
decision-making and management.

———X———X———X————

19
fi
fi
fi
fl
fi
 AD
Q.2) What is spiral model explain in detail. Write down its advantages.
ANS:
he Spiral Model is a risk-driven, iterative software development model that combines elements of
both Waterfall and Iterative models. It was introduced by Barry Boehm in 1986. The model is
designed to improve upon traditional development models by focusing on risk management and
incremental development. It emphasizes continuous re nement of the product through repeated
cycles, known as spirals, each of which involves planning, risk analysis, engineering, and
evaluation.

The model is particularly suitable for large, complex, and high-risk projects where requirements are
unclear or may evolve during the development process.

Phases of the Spiral Model

The Spiral Model consists of four major phases, which are repeated iteratively during each cycle
of the spiral:

1. Planning (or Conceptualization):

◦ This phase involves determining the project objectives, identifying risks, and
de ning the requirements for the system. The project team de nes what needs to be
done and develops a detailed plan for the project’s next steps.
◦ Key activities: Requirements gathering, feasibility study, and creating a project plan.
2. Risk Analysis (or Risk Assessment):

◦ This phase focuses on identifying and evaluating potential risks that could impact the
project’s success. Various risk mitigation strategies are considered, and alternatives
are proposed to address these risks.
◦ Key activities: Risk identi cation, analysis, and the development of strategies for
risk mitigation.
3. Engineering (or Development and Testing):

◦ The system is developed in this phase, following the speci cations outlined in the
planning phase. Prototypes may be developed, and features are tested to ensure that
they meet the de ned requirements. This phase involves actual coding and testing of
the software.
◦ Key activities: Design, coding, implementation, and testing of software components.
4. Evaluation (or Customer Evaluation):

◦ After development, the product is evaluated by stakeholders (including customers

and users) to ensure it meets the speci ed requirements and quality standards.
Feedback is gathered, which will guide the planning for the next iteration of the
spiral.
◦ Key activities: Customer evaluation, performance assessment, and feedback
collection.
Iterative Cycles

• The spiral model is composed of multiple iterations (or cycles), with each cycle producing
a version of the product. After completing the four phases in the rst cycle, the process is
repeated, re ning the product with each iteration based on feedback and new requirements.
• Each iteration typically involves creating a prototype, testing it, and re ning it based on user
feedback, thereby reducing risks progressively.
20
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 AD
• The model typically has four quadrants:
1. Goal setting
2. Risk analysis and prototyping
3. Engineering and development
4. Evaluation and review
Advantages of the Spiral Model

1. Risk Management:

◦ The Spiral Model focuses heavily on identifying and mitigating risks early in the
development process. Each iteration provides an opportunity to address new or
unforeseen risks, making it ideal for high-risk projects.
2. Flexibility and Adaptability:

◦ The iterative nature allows for exibility in changing requirements. If project goals
evolve or new requirements emerge, the system can be rede ned and updated during
each cycle.
3. Customer Feedback:

◦ Regular evaluations and prototypes allow customers to provide feedback at each

iteration. This ensures that the system meets customer expectations and reduces the
chance of developing features that aren’t needed.
4. Incremental Progress:

◦ The Spiral Model allows for incremental development, meaning that the system is
built step by step. With each cycle, the product is re ned and tested, which improves
the overall quality and usability.
5. Early Detection of Issues:

◦ Continuous testing and prototyping help detect issues and defects early in the
development process. This minimizes costly rework during later phases of
development.
6. Prototyping:

◦ Prototyping is an inherent part of the model, which allows users to visualize the end
product early on. This helps clarify requirements and re ne the design before
nalizing it.
7. Better Planning:

◦ The model helps in careful planning and ensures that each phase is reviewed and
assessed before moving forward. The iterative approach enables better resource
allocation and scheduling.
Disadvantages of the Spiral Model

1. Complexity:

◦ The Spiral Model can be more complex to manage than traditional models like
Waterfall. It requires careful monitoring and detailed risk analysis, which may
increase the effort required to manage the project.
2. High Cost:

21
fi
fl
fi
fi
fi
 AD
◦ The iterative cycles and continuous risk assessments can make the Spiral Model
more expensive compared to other models, especially in smaller projects with
limited resources.
3. Time-Consuming:

◦ Due to its iterative nature, the model can extend the development timeline, making it
less suitable for projects that need quick delivery.
4. Requires Expertise:

◦ The success of the Spiral Model depends on the project manager’s ability to assess
risks and manage the iterative process. It requires skilled professionals to ensure the
process is followed correctly.
5. Not Ideal for Small Projects:

◦ The Spiral Model is better suited for large, complex, and high-risk projects. For
smaller projects, the overhead of continuous planning and prototyping may not be
justi ed.
———X———X———X————
Q.3) Define quality. Explain pareto analysis in detail.
ANS:
In general, quality refers to the degree to which a product or service meets or exceeds the
expectations and requirements of its users or customers. It encompasses various attributes such as:

• Performance: How well the product or service performs its intended function.
• Reliability: The consistency and dependability of the product over time.
• Durability: The product’s ability to withstand wear and tear over its lifetime.
• Usability: The ease with which the product can be used by the end-users.
• Conformance to Requirements: How closely the product or service aligns with the
speci cations and requirements it was intended to meet.
Quality is not just about the product's functionality but also the processes and systems that ensure it
meets the desired standards, which is why quality management systems (like ISO 9001) play a key
role in ensuring consistent product and service quality.

Pareto Analysis

Pareto Analysis, also known as the 80/20 Rule, is a decision-making technique used to identify the
most important issues in a dataset or situation by focusing on the vital few problems that cause the
majority of the issues. It is based on Vilfredo Pareto’s observation that, in many cases, 80% of the
effects come from 20% of the causes.

In the context of quality management, Pareto Analysis helps organizations identify and prioritize
problems so that efforts can be focused on resolving the most signi cant issues rst, which will lead
to the largest improvements.

Steps in Pareto Analysis

1. Identify and List Problems or Issues:

◦ The rst step is to identify the problems, defects, or causes that need to be analyzed.
These could be related to customer complaints, product defects, process
inef ciencies, etc.

22
fi
fi
fi
fi
fi
fi
AD
2. Categorize the Problems:

◦ Group similar issues together. For example, if a company receives various types of
customer complaints, categorize them into groups like "Delivery Issues," "Product
Quality," "Customer Service," etc.
3. Count the Frequency of Each Problem:

◦ Count how often each problem occurs, based on the data gathered. This could be in
terms of the number of complaints, incidents, or defects.
4. Rank the Problems by Frequency:

◦ List the problems in descending order, with the most frequent problem at the top.
5. Calculate the Cumulative Percentage:

◦ After sorting the problems, calculate the cumulative percentage of total problems
that each issue represents. This helps in identifying the top contributors.
6. Create a Pareto Chart:

◦ A Pareto Chart is a bar chart where the problems are plotted on the x-axis (in
descending order of frequency), and the frequency (or cost, or time) is plotted on the
y-axis. The cumulative percentage is often represented by a line graph overlaid on
the bar chart. The chart will show which problems have the greatest impact.
7. Interpret the Results:

◦ The chart allows you to see that a small number of problems often contribute to the
majority of the issues. According to Pareto’s principle, focusing on resolving these
top issues will yield the greatest improvement.
Example of Pareto Analysis

Let’s say a company receives complaints from customers about its products. The complaints are
categorized into:

• Delivery Delays: 50 complaints

• Product Defects: 30 complaints
• Poor Customer Service: 15 complaints
• High Pricing: 5 complaints
The total number of complaints is 100.

To perform Pareto Analysis:

• Step 1: List and categorize the complaints.

• Step 2: Rank the problems by frequency.

◦ Delivery Delays: 50 complaints

◦ Product Defects: 30 complaints
◦ Poor Customer Service: 15 complaints
◦ High Pricing: 5 complaints
• Step 3: Calculate the cumulative percentage.

◦ Delivery Delays: 50 complaints (50% of total complaints)

◦ Product Defects: 30 complaints (30% of total complaints) → Cumulative: 80%

23
 AD
◦ Poor Customer Service: 15 complaints (15% of total complaints) → Cumulative:
95%
◦ High Pricing: 5 complaints (5% of total complaints) → Cumulative: 100%
• Step 4: Create a Pareto Chart.
The chart will show that 80% of complaints come from just 2 issues: Delivery Delays and
Product Defects. This allows the company to focus on these two main areas to make the
greatest improvement.

Advantages of Pareto Analysis

1. Focus on the Important Issues:

◦ By highlighting the most signi cant problems (the vital few), Pareto Analysis
ensures resources are allocated to address issues that have the largest impact.
2. Ef cient Problem Solving:

◦ It prevents the team from wasting time and resources on less critical problems and
encourages tackling the root causes that contribute to the majority of issues.
3. Data-Driven Decisions:

◦ Pareto Analysis is based on empirical data, which makes decision-making more

objective and aligned with the actual situation.
4. Improves Process and Product Quality:

◦ By focusing on the highest-priority issues, organizations can signi cantly enhance

quality and customer satisfaction.
5. Supports Continuous Improvement:

◦ Pareto Analysis can be used as part of a continuous improvement strategy, where

each cycle of analysis highlights new areas for improvement.

———X———X———X————

Q.4) Define project. Explain project management framework in detail

ANS:
A project is a temporary endeavor undertaken to create a unique product, service, or result. It has a
clear beginning and end, speci c objectives, and de ned constraints, such as time, cost, and
resources. Projects are typically characterized by:

• Uniqueness: Projects create a one-of-a-kind product or service.

• De ned objectives: The project has speci c goals to achieve.
• Temporary nature: Projects have a de ned start and end.
• Constraints: Projects are constrained by factors such as time, cost, resources, and scope.
• Progressive elaboration: Projects are often planned and executed in stages with increasing
detail.
Project Management Framework

The Project Management Framework (PMF) is a structured approach used to manage a project
from its initiation to its completion. The framework helps to ensure that all aspects of the project are
planned, executed, monitored, and closed effectively. It encompasses the processes, tools, and
techniques that guide the project manager and team throughout the project lifecycle.

24
fi
fi
fi
fi
fi
fi
fi
fi
 AD
The framework is typically divided into two main components:

1. Process Groups
2. Knowledge Areas
Let’s dive deeper into these components.

1. Process Groups in Project Management

The Project Management Institute (PMI) de nes ve process groups that are applied throughout
the project lifecycle. These are:

1.1 Initiating

This is the rst phase of a project where the project is formally authorized and de ned. In this
phase, the project's goals, objectives, and scope are identi ed, and the project manager is appointed.
Key processes include:

• Develop Project Charter: Creating the formal document that authorizes the project and
identi es the key stakeholders.
• Identify Stakeholders: Identifying individuals or groups who have an interest in the project
and de ning their requirements.
1.2 Planning

The planning phase involves setting detailed plans for how the project will be executed, monitored,
and closed. It involves creating various plans for scope, time, cost, quality, and risk management.
Key processes include:

• Develop Project Management Plan: De ning how the project will be executed, monitored,
and closed.
• De ne Scope: Establishing the boundaries of the project.
• Create WBS (Work Breakdown Structure): Breaking down the project deliverables into
smaller, manageable parts.
• Plan Schedule, Budget, and Resources: Creating detailed plans for time, cost, and resource
allocation.
• Plan Risk Management: Identifying and assessing potential risks and planning for risk
mitigation.
1.3 Executing

The executing phase focuses on coordinating people, resources, and tasks to meet the project
objectives. It is where most of the work happens. Key processes include:

• Direct and Manage Project Work: Ensuring the work is being performed according to the
project plan.
• Manage Project Knowledge: Using existing knowledge to enhance project performance
and sharing new knowledge created.
• Acquire Resources: Ensuring the necessary resources (human, physical, or nancial) are
available to perform the project work.
• Manage Stakeholder Engagement: Engaging stakeholders to meet their needs and
expectations.

25
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 AD
1.4 Monitoring and Controlling

In this phase, project performance is tracked, and any deviations from the plan are corrected.
Monitoring ensures that the project stays on track and meets its objectives. Key processes include:

• Monitor and Control Project Work: Tracking the progress of the project and identifying
any issues.
• Perform Integrated Change Control: Managing changes to the project scope, schedule,
and costs.
• Validate Scope: Ensuring that the project deliverables meet the agreed-upon requirements.
• Control Schedule, Cost, Quality, Risks: Managing and controlling these project aspects to
maintain alignment with the project plan.
1.5 Closing

The closing phase involves nalizing all project activities, formally completing the project, and
ensuring that all aspects have been completed. Key processes include:

• Close Project or Phase: Completing all activities related to the project or a project phase
and obtaining stakeholder acceptance.
• Close Procurements: Finalizing contracts and ensuring all contractual obligations have
been met.
2. Knowledge Areas in Project Management

There are 10 knowledge areas in project management that help ensure all aspects of the project are
managed. These knowledge areas are integrated throughout the ve process groups:

2.1 Project Integration Management

This area involves making sure that the various elements of the project are properly coordinated. It
ensures that all processes work together to meet project goals. Key processes include:

• Developing the project charter

• Developing the project management plan
• Directing and managing project work
2.2 Project Scope Management

Scope management involves de ning and controlling what is included and excluded in the project.
It ensures that the project delivers the intended results without scope creep. Key processes include:

• De ning the scope

• Creating a work breakdown structure (WBS)
• Verifying scope
2.3 Project Time Management

Time management focuses on ensuring that the project is completed on schedule. It involves
de ning activities, sequencing them, estimating resources, and controlling the project schedule. Key
processes include:

• De ning and sequencing activities

• Estimating activity durations
• Developing and controlling the project schedule

26
fi
fi
fi
fi
fi
fi
AD
2.4 Project Cost Management

Cost management ensures that the project is completed within the approved budget. It involves
estimating, budgeting, and controlling project costs. Key processes include:

• Estimating costs
• Determining the budget
• Controlling costs
2.5 Project Quality Management

Quality management ensures that the project meets the required quality standards. It involves
planning, controlling, and ensuring quality throughout the project lifecycle. Key processes include:

• Planning quality management

• Performing quality assurance
• Controlling quality
2.6 Project Resource Management

This knowledge area focuses on managing human and physical resources ef ciently. It involves
ensuring that the right people and equipment are available for the project. Key processes include:

• Planning resource management

• Acquiring resources
• Developing and managing the project team
2.7 Project Communications Management

Communications management ensures that timely, relevant, and accurate information is

disseminated to stakeholders. Key processes include:

• Planning communications
• Managing communications
• Monitoring communications
2.8 Project Risk Management

Risk management involves identifying, analyzing, and responding to project risks to minimize the
impact of negative events. Key processes include:

• Planning risk management

• Identifying risks
• Performing qualitative and quantitative risk analysis
• Planning risk responses
• Monitoring and controlling risks
2.9 Project Procurement Management

Procurement management involves acquiring goods and services from outside the organization. Key
processes include:

• Planning procurement management

• Conducting procurements
• Controlling procurements

27
fi
AD
2.10 Project Stakeholder Management

Stakeholder management ensures that all stakeholders are identi ed, and their needs and
expectations are managed throughout the project. Key processes include:

• Identifying stakeholders
• Planning stakeholder engagement
• Managing stakeholder engagement
• Monitoring stakeholder engagement
———X———X———X————
Q.5) Explain project implementation plan in detail.
ANS:
A Project Implementation Plan (PIP) is a detailed roadmap that outlines how a project will be
executed, monitored, and controlled to achieve its objectives. It provides a structured approach for
managing the project from the planning phase through to completion. The plan de nes all the
necessary steps, timelines, resources, responsibilities, and processes involved in implementing the
project successfully.

A well-developed Project Implementation Plan ensures that the project progresses smoothly and that
the deliverables meet the intended goals, quality standards, and timelines.

Key Components of a Project Implementation Plan

Here are the critical components that are typically included in a Project Implementation Plan:

1. Project Scope and Objectives

This section clearly de nes what the project aims to achieve and the scope of the work. It answers
questions like:

• What are the project’s speci c objectives?

• What deliverables need to be produced?
• What are the project’s boundaries (scope)?
• What are the key success criteria?
Example: If the project involves developing a new software application, the objectives might
include developing a user-friendly app with speci ed features, within a budget, and meeting
performance benchmarks.

2. Project Deliverables

Deliverables are tangible or intangible outputs that the project must produce. This section lists all
the deliverables required to complete the project successfully, with speci c details like:

• Description of each deliverable

• Quality standards
• Expected completion dates
Example: For a construction project, deliverables might include the completed building, electrical
systems, plumbing, etc.

28
fi
fi
fi
fi
fi
fi
 AD

3. Project Milestones

Milestones are signi cant points of progress that mark the completion of key tasks or phases. This
section de nes critical milestones that indicate when a major part of the project is completed.

• What key tasks or phases need to be completed?

• When should each milestone be achieved?
• What are the success criteria for each milestone?
Example: For software development, milestones might include "Alpha version release," "User
Acceptance Testing (UAT) completed," and "Go-live."

4. Roles and Responsibilities

The implementation plan must specify who will be responsible for each task. It outlines the roles of
the project team members, stakeholders, and other involved parties. A RACI matrix (Responsible,
Accountable, Consulted, Informed) is often used to clarify roles and ensure accountability.

Example:

• Project Manager: Oversee the overall project execution.

• Developer: Code and develop software modules.
• Quality Assurance (QA): Test the deliverables for quality.
5. Resource Allocation

This section outlines the resources required for the project, including:

• Human Resources: Team members, their roles, and expertise.

• Physical Resources: Equipment, of ce space, or other physical items required.
• Financial Resources: Budget, funding, and cash ow management.
• Technological Resources: Software, hardware, or other tools needed for the project.
Example: A software development project may require servers for deployment, software
development tools like IDEs, and a project budget for licensing.

6. Timeline and Scheduling

A detailed timeline and project schedule are critical for tracking progress and ensuring timely
completion. The plan should include:

• Start and end dates

• Detailed schedule with start and nish dates for each task or phase
• Gantt Chart or Critical Path Method (CPM) diagram to visually represent project tasks
and their dependencies.
Example: If the project is to develop a mobile app, the timeline might be broken down into tasks
like market research (week 1-2), prototype design (week 3-4), development (week 5-8), and testing
(week 9).

7. Budget and Cost Management

This section provides a detailed breakdown of the project’s budget, including:

• Estimated costs for each phase or activity

29
fi
fi
fi
fi
fl
AD
• Contingency plans for unanticipated expenses
• Cost tracking mechanisms to ensure the project stays within budget.
Example: The budget for a marketing campaign might include costs for advertising, creative
design, promotional materials, and media buys.

8. Risk Management Plan

A risk management plan identi es potential risks that may impact the project and outlines strategies
to mitigate those risks. This plan involves:

• Identifying risks: External, internal, technical, nancial, etc.

• Assessing risks: Likelihood and impact of each risk.
• Mitigating actions: Strategies to minimize or avoid risks.
• Contingency planning: How to respond to risks if they occur.
Example: If there’s a risk of delays due to external vendors, mitigation might involve having
backup suppliers or creating buffer time in the schedule.

9. Quality Assurance and Control

This section outlines how the quality of the project deliverables will be monitored and controlled. It
ensures that the nal product meets the required quality standards. The plan should include:

• Quality criteria: What de nes success in terms of quality?

• Testing and inspections: Procedures for evaluating the quality of deliverables.
• Review processes: Regular checks and audits to ensure quality standards are met.
Example: For software projects, quality assurance could involve conducting regular code reviews,
user testing, and performance testing to ensure that the software is bug-free and meets user
expectations.

10. Communication Plan

The communication plan outlines how information will be shared among project stakeholders, team
members, and others involved in the project. Key aspects include:

• Communication channels: Email, meetings, project management tools, etc.

• Frequency of updates: How often updates will be provided.
• Stakeholder reporting: What information will be communicated to stakeholders and how
often.
• Escalation procedures: How issues or con icts will be communicated and resolved.
Example: Weekly team meetings, monthly stakeholder updates, and emergency alerts for critical
issues.

11. Monitoring and Reporting

This section de nes how the project's progress will be monitored and evaluated, and how reports
will be generated. It speci es:

• Key Performance Indicators (KPIs): Metrics to measure project performance (e.g.,

schedule adherence, cost performance, quality).
• Reporting tools: Software or systems used to track and report on progress (e.g., project
dashboards).
30
fi
fi
fi
fi
fi
fl
fi
AD
• Progress reviews: Regularly scheduled reviews to assess whether the project is on track.
Example: A project management software tool like Microsoft Project or Jira could be used to
track progress, and weekly reports could be sent to stakeholders.

12. Change Management Plan

Changes are inevitable in most projects. A change management plan outlines how changes to scope,
timeline, or resources will be handled. It typically includes:

• Change request process: How requests for changes are submitted, reviewed, and approved.
• Impact assessment: How the impact of changes on the project’s cost, time, and scope will
be evaluated.
• Approval procedures: Who has the authority to approve changes.
Example: If additional features are requested by the client during the development phase, this
section would de ne how to evaluate the change, assess the impact, and modify the timeline
accordingly.

———X———X———X————
Q.6) What is FTR and why it is required?
ANS:
A Formal Technical Review (FTR) is a structured, formalized process where a team of experts or
stakeholders review and evaluate a product or component of a project to ensure its technical
correctness, completeness, and adherence to prede ned requirements and standards. FTRs are
typically conducted during different stages of the software or system development life cycle, such
as during the design, coding, or testing phases. The primary goal is to identify defects,
inconsistencies, or issues early in the development process, before the product reaches a later stage
or is delivered to the customer.

Key Objectives of an FTR

• Identify errors or issues: Spot potential errors in the design, code, or other technical
aspects early in the project.
• Ensure compliance: Check that the product meets technical standards, project
requirements, and best practices.
• Improve quality: The review process helps improve the overall quality of the product by
catching defects early and ensuring the technical aspects are robust.
• Validate requirements: Ensure that the technical solution aligns with the speci ed
requirements.
FTR Process

The FTR process typically involves the following steps:

1. Preparation:
◦ Identify the review objectives, scope, and participants.
◦ Collect and distribute the material to be reviewed, such as design documents, code,
or test plans.
2. Review:
◦ Conduct the review meeting where the team of experts examines the material in
detail.
◦ Identify issues, risks, and suggestions for improvement.
3. Reporting:
31
fi
fi
fi
AD
◦ Document the ndings and categorize issues by severity (e.g., critical, minor, or
optional).
◦ Assign action items for the resolution of identi ed issues.
4. Follow-up:
◦ Track the resolution of identi ed issues and con rm that changes have been
implemented correctly.
Why FTR is Required

1. Early Detection of Defects: FTR helps to detect defects early in the development process,
which reduces the cost and time needed for xing issues later. It's more cost-effective to
address problems in the earlier stages rather than during or after implementation.

2. Ensures Technical Correctness: FTRs provide a structured review process that helps
ensure the technical solutions, such as designs or code, are aligned with the project goals,
functional requirements, and technical standards.

3. Improves Communication: FTR encourages collaboration among team members, subject

matter experts, and stakeholders. This process improves communication, as team members
get the opportunity to discuss technical solutions and share knowledge.

4. Compliance and Standardization: FTRs ensure that the product adheres to industry
standards, best practices, and organizational guidelines, improving its overall quality and
maintainability.

5. Reduces Risks: By identifying issues early, FTR helps reduce the risk of costly errors,
delays, or non-compliance. It helps ensure that the product or system will meet the necessary
quality standards before moving to the next phase.

6. Improves Documentation and Traceability: The formal nature of the review ensures that
detailed documentation is created for any issues identi ed, decisions made, and resolutions
implemented. This improves traceability and accountability in the project.

7. Increases Stakeholder Con dence: Conducting formal reviews provides stakeholders with
assurance that the project is being handled properly, which builds con dence in the process
and the quality of the nal product.

———X———X———X————
Q.7) What are different Risk analysis and assessment technique. Explain any one
technique in detail.
ANS:
Risk analysis and assessment are crucial for identifying, evaluating, and managing potential risks
that may affect the success of a project. There are several techniques used for risk analysis and
assessment, which can be broadly categorized into qualitative and quantitative approaches:

1. Qualitative Risk Analysis Techniques:

◦ Risk Probability and Impact Matrix: This technique helps categorize risks based
on their likelihood of occurrence and their potential impact. It is used to prioritize
risks by combining the probability of their occurrence with their severity.
◦ SWOT Analysis: This technique helps identify the project’s internal strengths and
weaknesses, as well as external opportunities and threats. It is used to better
understand the context in which the project operates.
32
fi
fi
fi
fi
fi
fi
fi
fi
fi
 AD
◦ Expert Judgment: Involves consulting with experienced professionals to identify
and assess risks. The insights from experts help in making informed decisions.
◦ Risk Categorization: Risks are grouped into categories, such as technical, external,
organizational, etc. This helps to manage risks more systematically.
2. Quantitative Risk Analysis Techniques:

◦ Monte Carlo Simulation: A statistical method that uses random sampling to

simulate the impact of risk on project outcomes. It provides a range of possible
outcomes, helping to understand the uncertainty involved in the project.
◦ Decision Tree Analysis: A graphical model used to evaluate different decision
options and their potential risks and outcomes. It helps in choosing the best course of
action based on the analysis of possible outcomes.
◦ Sensitivity Analysis: This technique helps evaluate how sensitive the project
outcomes are to changes in speci c variables, such as time, cost, or resource
availability.
Explanation of Monte Carlo Simulation in Detail

Monte Carlo Simulation is a quantitative risk analysis technique that uses statistical sampling and
probability distributions to model the uncertainty in a project. It allows project managers to simulate
multiple risk scenarios and generate a range of possible outcomes.

Steps in Monte Carlo Simulation:

1. De ne the Problem and Variables:

◦ First, identify the key variables that are uncertain, such as task durations, costs, or
resource availability. These variables are represented using probability
distributions (e.g., normal, triangular, or uniform distributions).
2. Build the Model:

◦ Create a mathematical or computational model representing the project, which

incorporates the identi ed uncertainties. The model could focus on different aspects,
such as project timelines, cost estimation, or resource allocation.
3. Run Simulations:

◦ The Monte Carlo simulation runs multiple iterations (often thousands) with each
iteration randomly selecting values for the uncertain variables according to their
probability distributions. Each iteration produces a potential outcome based on the
selected values.
4. Analyze the Results:

◦ After running the simulations, the results are analyzed to generate a probability
distribution of the possible outcomes. This distribution helps project managers
understand the likelihood of completing the project within speci c parameters, such
as time or cost.
5. Interpret the Results:

◦ The results provide valuable insights into the risk pro le of the project. For example,
you can assess the likelihood of completing the project on time, staying within
budget, or meeting other critical objectives.
Advantages of Monte Carlo Simulation:

33
fi
fi
fi
fi
fi
AD
• Comprehensive Risk Assessment: It provides a more complete understanding of the
potential risks by evaluating various possible outcomes, rather than just focusing on a single
estimate.
• Quantitative Insights: The technique generates numeric outputs, such as probability
distributions, which allow for data-driven decision-making.
• Scenario Analysis: It enables the simulation of different “what-if” scenarios, helping to
explore the impact of different risk factors on project outcomes.
• Identifying Key Risks: The simulation helps identify which risks have the greatest potential
impact on the project, allowing project managers to focus on those risks that matter most.
Limitations of Monte Carlo Simulation:

• Complexity: Setting up and running a Monte Carlo simulation requires advanced

knowledge of statistical modeling and computational tools. It may also require signi cant
computing resources, especially for large projects.
• Data Sensitivity: The accuracy of the results depends heavily on the quality of the input
data and the assumptions made about the probability distributions of uncertain variables.
Inaccurate data can lead to misleading results.
• Time and Cost: The process can be time-consuming and may involve additional costs,
particularly if specialized software or expertise is required.
Example:

Consider a project where the duration of a task is uncertain. The task might take between 5 to 10
days, with a most likely duration of 7 days. Using Monte Carlo simulation, the task duration is
represented by a triangular distribution (5, 7, 10). The simulation runs multiple iterations,
randomly selecting values within this range for each iteration and calculating the overall project
completion time based on different combinations of durations. The result is a probability
distribution of potential project completion times, helping you understand the likelihood of nishing
the project within different timeframes.

———X———X———X————
Q.8) Write short notes on
i) COCOMO Model
ii) Staffing level estimation
ANS:
a) COCOMO Model (Constructive Cost Model)

The COCOMO Model is a software cost estimation model that helps predict the cost, effort, and
time required to complete a software development project. Developed by Barry Boehm in 1981, it is
based on a regression analysis of project data and provides a systematic way to estimate the
resources required for software projects based on the size of the project (measured in thousands of
lines of code - KLOC).

Key Features of COCOMO:

1. Effort Estimation: COCOMO uses the size of the software (in KLOC) as the primary input,
along with cost drivers like complexity, team experience, and project constraints, to estimate
effort in person-months.

2. Three Levels:

34
fi
fi
 AD
◦ Basic COCOMO: Provides a rough estimate of effort based on the size of the
project.
◦ Intermediate COCOMO: Includes additional cost drivers like product reliability
and personnel experience.
◦ Detailed COCOMO: Takes into account more speci c factors like software
architecture, schedule constraints, and tools used.
3. Cost Drivers: These are factors that in uence the effort, such as software reliability, the
complexity of the system, and the experience of the development team.

Advantages:

• Provides a structured approach to cost estimation.

• Allows for estimation at different levels of detail.
• Can be used to compare different project scenarios.
Disadvantages:

• Accuracy depends on the availability of historical data.

• It may not account for all project-speci c factors.
COCOMO is widely used for estimating the effort and time needed for software development
projects, especially for larger systems.

b) Staf ng Level Estimation

Staf ng level estimation is the process of determining the number of people required for a project to
complete it on time and within scope. It is essential for managing resources ef ciently and ensuring
the project meets its objectives.

Methods of Estimation:

1.
Expert Judgment: Relies on the knowledge of experienced personnel to estimate resource
needs based on past projects.
2. Top-Down Estimation: Senior management estimates the overall staf ng needs, and the
resources are allocated to tasks from there.
3. Bottom-Up Estimation: Detailed estimates are made for each task, and then these are
aggregated to determine the total staf ng requirements.
4. COCOMO Model: Uses historical data and a mathematical model to estimate staf ng
levels based on project size and complexity.
5. Historical Data: Past project data is used to estimate resource needs for similar projects.
6. Parametric Estimation: Uses mathematical relationships and data from previous projects to
calculate staf ng needs based on project parameters.
7. Work Breakdown Structure (WBS): Breaks down the project into smaller tasks and
estimates staf ng needs for each work package.
Factors In uencing Staf ng:

• Project Size and Complexity

• Timeline and Deadlines
• Skill Set and Experience
• Technology and Tools
• Resource Availability
Ef cient staf ng level estimation helps ensure the project has enough resources without
overstaf ng, contributing to its success.
35
fi
fi
fi
fi
fl
fi
fi
fi
fi
fi
fl
fi
fi
fi
fi
fi
 AD

———X———X———X————
Q.9) What are different requirement elicitation techniques? Explain in detail.
ANS:
Requirement elicitation is the process of gathering the requirements for a system from various
stakeholders. It is a critical part of the software development life cycle, as it ensures that the system
will meet the needs of its users and other stakeholders. There are several techniques used in
requirement elicitation, each suited to different project needs and environments. These techniques
are typically classi ed into direct and indirect methods, and can involve interviews, workshops,
observations, and document analysis.

Here are some common requirement elicitation techniques:

1. Interviews

De nition: Interviews are one-on-one or group interactions where the requirements analyst or
project manager asks stakeholders speci c questions to gather information about their needs and
expectations for the system.

Types:

•Structured Interview: Involves a pre-de ned set of questions that are asked in a speci c
order.
• Unstructured Interview: More informal, with open-ended questions that allow the
interviewee to express their thoughts freely.
• Semi-structured Interview: A combination of structured and unstructured formats, with a
set of prede ned questions but exibility for further discussion.
Advantages:

• Allows for in-depth discussions and clari cations.

• Can help uncover hidden requirements.
• Provides direct insights from stakeholders.
Disadvantages:

• Time-consuming.
• Relies on the interviewer’s skills and ability to ask the right questions.
• Potential biases in interpreting the responses.

2. Surveys and Questionnaires

De nition: Surveys or questionnaires are tools used to gather information from a large group of
stakeholders. They consist of written questions that stakeholders can answer on their own.

Types:

•Open-ended Questions: Allow stakeholders to provide detailed responses.

•Closed-ended Questions: Provide prede ned options for responses, such as multiple-choice
or Likert scale.
Advantages:

• Can reach a large number of stakeholders quickly.

36
fi
fi
fi
fi
fl
fi
fi
fi
fi
fi
 AD
• Useful for collecting data from geographically dispersed teams.
• Provides a structured format for responses, which can be easily analyzed.
Disadvantages:

• Limited ability for follow-up or clari cation.

• Can result in incomplete or unclear responses.
• Respondents may not provide detailed answers, especially to open-ended questions.

3. Workshops

De nition: Workshops are facilitated group discussions where stakeholders come together to
discuss their needs and prioritize requirements. They may involve brainstorming, collaborative
analysis, and group exercises to identify and clarify requirements.

Types:

• Focus Groups: Small groups of stakeholders discuss speci c topics.

• Joint Application Development (JAD): A facilitated workshop where both business and
technical teams collaborate intensively to de ne requirements.
Advantages:

• Encourages collaboration among stakeholders.

• Helps resolve con icts and prioritize requirements.
• Provides a platform for feedback and consensus building.
Disadvantages:

• Requires signi cant time and effort to organize and facilitate.

• May be dif cult to manage large groups of stakeholders.
• Risk of dominating voices, which can bias the output.

4. Observation

De nition: Observation involves watching how users interact with an existing system or perform
tasks related to the system. It helps in understanding their needs and work ows.

Types:

• Passive Observation: The analyst watches users without interrupting or interacting with
them.
• Active Observation: The analyst actively engages with users and asks questions while
observing their activities.
Advantages:

• Provides real-time insights into actual user behavior and work ows.
• Helps uncover implicit requirements that users may not verbalize.
Disadvantages:

• May be time-consuming.
• Users may behave differently when being observed (Hawthorne effect).
• Does not capture users' expectations or needs that are not re ected in current behavior.

5. Document Analysis
37
fi
fi
fi
fi
fl
fi
fi
fi
fl
fl
fl
 AD
De nition: Document analysis involves reviewing existing documentation such as business plans,
technical speci cations, user manuals, and system requirements to identify requirements.

Advantages:

• Can provide a wealth of information from existing systems or previous projects.

• Helps understand regulatory or compliance-related requirements.
• Non-intrusive and can be done independently.
Disadvantages:

• The documents may be outdated or incomplete.

• It may be dif cult to extract requirements from vague or ambiguous documents.
• Does not always capture the current needs of stakeholders.

6. Use Cases and User Stories

De nition: Use cases and user stories are both methods for capturing functional requirements in the
form of scenarios or narratives that describe how users will interact with the system.

•
Use Cases: Describe a sequence of actions between the system and the user that achieves a
speci c goal.
• User Stories: Short, simple descriptions of a feature from the user's perspective, often
written in the format: “As a [user], I want [feature] so that [bene t].”
Advantages:

• Focuses on user interactions and system behavior.

• Helps in de ning system functionality in user-friendly language.
• Use cases are detailed, while user stories are more concise and exible.
Disadvantages:

• Use cases can become overly detailed and complex.

• User stories may lack detail for complex functionality.

7. Brainstorming

De nition: Brainstorming is a group technique used to generate a wide range of ideas and solutions
for system requirements. It typically involves a facilitator who encourages stakeholders to freely
suggest ideas without judgment.

Advantages:

• Encourages creativity and a wide range of ideas.

• Helps stakeholders think outside the box.
• Fosters collaboration among stakeholders.
Disadvantages:

• Can lead to an overwhelming number of ideas, making it dif cult to prioritize.

• Risk of dominant participants in uencing the process.
• May not be structured enough to yield actionable results without follow-up.

8. Prototyping

38
fi
fi
fi
fi
fi
fi
fi
fl
fi
fl
fi
 AD
De nition: Prototyping involves creating an early version or model of the system (a prototype) to
demonstrate its functionality. This prototype is then re ned based on feedback from users and
stakeholders.

Advantages:

• Provides stakeholders with a tangible representation of the system.

• Allows for early validation and feedback on requirements.
• Helps clarify unclear requirements and expectations.
Disadvantages:

• Can lead to scope creep if stakeholders focus too much on the prototype rather than the
actual requirements.
• Time-consuming to develop prototypes.
• May not be feasible for all types of systems or projects.

9. Storyboarding

De nition: Storyboarding involves creating visual representations of user interactions with the
system through a series of images or diagrams. It’s often used to illustrate how users will interact
with different screens or features.

Advantages:

• Provides a visual understanding of the system from the user’s perspective.

• Useful for capturing user interfaces and interactions.
• Helps stakeholders better visualize the system.
Disadvantages:

• May not capture all requirements, especially non-visual aspects of the system.
• Requires graphic design skills to create detailed storyboards.

10. Reverse Engineering

De nition: Reverse engineering is the process of analyzing an existing system or product to extract
design and requirement information. It is typically used when there is little or no documentation for
an existing system.

Advantages:

• Helps to understand legacy systems or products.

• Provides insights into functionality that stakeholders may have forgotten.
Disadvantages:

• Can be time-consuming and costly.

• May not reveal all hidden requirements or business needs.

———X———X———X————

39
fi
fi
fi
fi