0% found this document useful (0 votes)
16 views15 pages

Software Project Planning Essentials

this is the note that how to plan a class note.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
16 views15 pages

Software Project Planning Essentials

this is the note that how to plan a class note.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Project/Software Project Planning

Software Project Planning is the process of defining the scope, objectives, and deliverables of a software
development project. It involves outlining the steps required to achieve the project's goals, allocating
resources, and creating a timeline for completion.

Key elements of software project planning:

• Project Scope: Defining the boundaries of the project, including what is included and what is
excluded.

• Objectives: Establishing clear and measurable goals for the project.

• Deliverables: Identifying the specific products or services that will be produced.

• Timeline: Creating a schedule for project activities and milestones.

• Resources: Allocating necessary resources, such as personnel, equipment, and budget.

• Risk Management: Identifying potential risks and developing strategies to mitigate them.

Effective software project planning:

• Increases efficiency: By providing a clear roadmap, it helps to avoid unnecessary delays and
rework.

• Reduces costs: By identifying and managing risks, it can help to prevent costly mistakes.

• Improves communication: A well-defined plan helps to ensure that everyone involved in the
project is on the same page.

• Enhances stakeholder satisfaction: By meeting expectations and delivering on time, it can lead
to greater satisfaction among stakeholders.

Common tools and techniques used in software project planning:

• Work Breakdown Structure (WBS): Breaking down the project into smaller, manageable tasks.

• Gantt Charts: Visualizing the project timeline and dependencies between tasks.

• PERT (Program Evaluation and Review Technique): Estimating project duration and identifying
critical path activities.

• Critical Path Method (CPM): Similar to PERT, but focuses on identifying the longest path through
the project.

By following sound project planning practices, software development teams can increase their chances
of success and deliver high-quality products on time and within budget.
Software Project Scope Planning: A Comprehensive Overview
Project Scope/Project deliverables are tangible outcomes, measurable results, or specific items that
must be produced to consider either the project or the project phase completed. Intermediate
deliverables, like the objectives, must be specific and verifiable.

All deliverables must be described in a sufficient level of detail so that they can be differentiated from
related deliverables. For example:

• A twin-engine plane versus a single engine plane

• A red marker versus a green marker

• A daily report versus a weekly report

• A departmental solution versus an enterprise solution

One of the project manager’s primary functions is to accurately document the deliverables of the project
and then manage the project so that they are produced according to the agreed-on criteria. Deliverables
are the output of each development phase, described in a quantifiable way.

Software project scope planning is the process of defining the exact boundaries and deliverables of a
software development project. It ensures that everyone involved in the project has a clear understanding
of what needs to be done, when it needs to be done, and how it will be done.

Key Components of Software Project Scope Planning:

1. Project Objectives: Clearly defined goals that the project aims to achieve.

2. Deliverables: The specific products or services that will be produced as a result of the project.

3. Scope Boundaries: The limits of the project, including what is included and what is excluded.

4. Scope Creep: The tendency for projects to expand beyond their original scope over time.

5. Scope Management: The process of controlling changes to the project scope to ensure it
remains within budget and on schedule.

The Importance of Effective Scope Planning:

• Reduces Risk: A well-defined scope helps to identify and mitigate potential risks.

• Ensures Success: A clear understanding of the project scope is essential for successful project
completion.

• Manages Expectations: It helps to manage expectations among stakeholders and prevents


misunderstandings.

• Controls Costs: A well-defined scope helps to control costs by preventing unnecessary work.
Common Challenges in Scope Planning:

• Vague or Ambiguous Requirements: Unclear or incomplete requirements can lead to scope


creep and project delays.

• Changing Business Needs: Business needs may change during the project, requiring adjustments
to the scope.

• Technical Constraints: Technical limitations can impact the project scope and feasibility.

• Stakeholder Misunderstandings: Misunderstandings among stakeholders can lead to scope


creep or scope reduction.

Best Practices for Scope Planning:

• Involve Stakeholders: Ensure that all relevant stakeholders are involved in the scope planning
process.

• Use Clear and Concise Language: Avoid ambiguity in project documentation.

• Create a Project Scope Statement: A formal document outlining the project objectives,
deliverables, and scope boundaries.

• Conduct Regular Reviews: Regularly review and update the project scope as needed.

• Use Scope Management Techniques: Employ techniques like change control and configuration
management to manage scope changes effectively.

By following these best practices, you can create a solid foundation for your software project and
increase the likelihood of successful completion.
Types of Requirements
Project Requirements:

After all the deliverables are identified, the project manager needs to document all the requirements of
the project. Requirements describe the characteristics of the final deliverable, whether it is a product or a
service. They describe the required functionality that the final deliverable must have or specific conditions
the final deliverable must meet in order to satisfy the objectives of the project. A requirement is an
objective that must be met. The project’s requirements, defined in the scope plan, describe what a project
is supposed to accomplish and how the project is supposed to be created and implemented. Requirements
answer the following questions regarding the as-is and to-be states of the business: who, what, where,
when, how much, and how does a business process work?

Requirements may include attributes like dimensions, ease of use, color, specific ingredients, and so on. If
we go back to the example of the company producing holiday eggnog, one of the major deliverables is the
cartons that hold the eggnog. The requirements for that deliverable may include carton design,
photographs that will appear on the carton, color choices, etc.

Requirements specify what the final project deliverable should look like and what it should do.
Requirements must be measurable, testable, related to identified business needs or opportunities, and
defined to a level of detail sufficient for system design. They can be divided into six basic categories:
functional, non-functional, technical, business, user, and regulatory requirements.

Business Requirements

Business requirements are the needs of the sponsoring organization, always from a management
perspective. Business requirements are statements of the business rationale for the project. They are
usually expressed in broad outcomes, satisfying the business needs, rather than specific functions the
system must perform. These requirements grow out of the vision for the product that, in turn, is driven by
mission (or business) goals and objectives.

Stakeholder requirements are the needs, expectations, and desires of individuals or groups who have an
interest in a project. These requirements can come from a variety of sources, including:

• Customers: The end-users of the project's output.

• Users: Individuals who will interact with the project's deliverables.

• Management: The individuals responsible for overseeing the project.

• Developers: The people who will be building the project.

• Other stakeholders: Anyone else who has a vested interest in the project's success.

Stakeholder requirements should be clearly defined and documented to ensure that the project meets
the needs of all involved parties.
Functional Requirements

Functional requirements describe the characteristics of the final deliverable in ordinary non-technical
language. They should be understandable to the customers, and the customers should play a direct role
in their development. Functional requirements are what you want the deliverable to do.

If you were buying vehicles for a business, your functional requirement might be: “The vehicles should be
able to take up to a one-ton load from a warehouse to a shop.”

For a computer system, “The system should store all details of a customer’s order.”

Non-Functional Requirements

Non-functional requirements specify criteria that can be used to judge the final product or service that
your project delivers. They are restrictions or constraints to be placed on the deliverable and how to build
it. Their purpose is to restrict the number of solutions that will meet a set of requirements. Using the
vehicle example, the functional requirement is for a vehicle to take a load from a warehouse to a shop.
Without any constraints, the solutions being offered might result in anything from a small to a large truck.
Non-functional requirements can be split into two types: performance and development.

To restrict the types of solutions, you might include these performance constraints:

• The purchased trucks should be American-made trucks due to government incentives.

• The load area must be covered.

• The load area must have a height of at least 10 feet.

Similarly, for the computer system example, you might specify values for the generic types of performance
constraints:

• The response time for information is displayed on the screen for the user.

• The number of hours a system should be available.

• The number of records a system should be able to hold.

• The capacity for growth of the system should be built in.

• The length of time a record should be held for auditing purposes.

For the customer records example, the constraints might be:

• The system should be available from 9 a.m. to 5 p.m. Monday to Friday.

• The system should be able to hold 100,000 customer records initially.

• The system should be able to add 10,000 records a year for 10 years.

• A record should be fully available on the system for at least seven years.
Technical Requirements

Technical requirements emerge from the functional requirements to answer the questions: how will the
problem be solved this time and will it be solved technologically and/or procedurally? They specify how
the system needs to be designed and implemented to provide required functionality and fulfill required
operational characteristics.

For example, in a software project, the functional requirements may stipulate that a database system will
be developed to allow access to financial data through a remote terminal. The corresponding technical
requirements would spell out the required data elements, the language in which the database
management system will be written (due to existing knowledge in-house), the hardware on which the
system will run (due to existing infrastructure), telecommunication protocols that should be used, and so
forth.

User Requirements

User requirements describe what the users need to do with the system or product. The focus is on the
user experience with the system under all scenarios. These requirements are the input for the next
development phases: user-interface design and system test cases design.
Project Scope Input Techniques
JAD and QFD for Scope Input: A Collaborative Approach
Joint Application Development (JAD) and Quality Function Deployment (QFD) are powerful tools for
gathering and refining scope input in software projects. They promote collaboration, ensure stakeholder
alignment, and help to define a clear and comprehensive project scope.

JAD for Scope Input

• Collaborative Workshops: JAD involves facilitated workshops where stakeholders from various
departments come together to discuss project objectives, requirements, and constraints.

• Active Participation: Participants actively contribute to the discussion, ensuring that all
perspectives are considered.

• Consensus Building: The goal of JAD is to reach a consensus on the project scope, minimizing
misunderstandings and conflicts.

QFD for Scope Input

• House of Quality: QFD uses a visual tool called the "House of Quality" to map customer needs and
requirements to technical features and design elements.

• Prioritization: QFD helps to prioritize requirements based on their importance to customers and
their feasibility.

• Traceability: It ensures that requirements are traceable throughout the project lifecycle, from
initial planning to final delivery.

Delphi and Mind Mapping: Techniques for Scope Definition


Delphi and Mind Mapping are valuable tools for gathering and organizing information related to project
scope. They can be used in conjunction with other techniques like JAD and QFD to create a comprehensive
and well-defined project scope.

Delphi Technique

• Iterative Surveys: The Delphi technique involves a series of anonymous questionnaires or surveys
that are distributed to experts in the field.

• Consensus Building: Through multiple rounds of feedback, the goal is to reach a consensus on the
key issues or factors related to the project scope.

• Expert Opinions: The Delphi technique leverages the expertise of individuals to provide valuable
insights and perspectives.

Mind Mapping

• Visual Representation: Mind mapping is a graphical technique that uses a central concept or idea
as a starting point and branches out to related ideas.
• Non-Linear Thinking: Mind maps encourage non-linear thinking and allow for the exploration of
various possibilities.

• Visualization: The visual nature of mind maps makes it easier to see relationships between ideas
and identify potential gaps in the scope.
Mind Map Example: Planning a Vacation

Central Idea: Vacation Planning

• Destinations:

o Europe

▪ Italy

▪ France

▪ Spain

o Asia

▪ Japan

▪ Thailand

▪ Bali

o North America

▪ USA

▪ Canada
• Activities:

o Sightseeing

o Hiking

o Beach

o Shopping

• Budget:

o Flights

o Accommodation

o Food

o Activities

• Travel Companions:

o Family

o Friends

o Solo

• Timeframe:

o Summer

o Winter

o Spring

o Fall

In this example, the central idea of "Vacation Planning" branches out into different categories
(Destinations, Activities, Budget, Travel Companions, Timeframe). Each category is further divided into
subcategories, creating a hierarchical structure. This helps to visualize the various factors involved in
planning a vacation and identify potential connections between them.

Mind Map Example: Software Development Project

Central Idea: Software Development Project

• Requirements Gathering:

o User Interviews

o Surveys

o Workshops
o Document Analysis

• Design:

o Architecture Design

o User Interface Design

o Database Design

• Development:

o Coding

o Testing

o Debugging

• Deployment:

o Installation

o Configuration

o Integration

• Maintenance:

o Updates

o Bug Fixes

o Support

• Stakeholders:

o Customers

o Users

o Management

o Developers

o Testers

• Tools and Technologies:

o Programming Languages

o IDEs

o Version Control

o Testing Frameworks

o Project Management Tools


This mind map outlines the key stages and components of a software development project. It visually
represents the relationships between different phases and elements, helping to understand the overall
project structure and identify potential dependencies.
Approaches to Developing Work Breakdown Structures
1. Using Guidelines:

• Refer to industry standards or templates to structure your WBS.

• Provides a proven framework for breaking down projects.

2. The Analogy Approach:

• Use a similar project's WBS as a starting point.

• Adapts existing structures to fit the current project's needs.

3. The Top-Down Approach:

• Start with the overall project goal and break it down into major deliverables.

• Refine these deliverables into smaller, more manageable tasks.

4. The Bottom-Up Approach:

• Start with the most granular tasks and group them into larger components.

• Build the WBS from the bottom up to the project level.

5. The Mind-Mapping Approach:

• Create a visual representation of the project's components.

• Helps to identify relationships and potential dependencies between tasks.

You might also like