Lecture Notes on Software Development Fundamentals:

Software Process and Project Management Process Groups

3. Processes

3.1 Software Process

When building a product or system, it's essential to follow a series of predictable steps, known as
the software process. This process acts as a road map, guiding the creation of a high-quality
product in a timely manner. Here's an overview:

 Definition: A software process is a framework of tasks required to build high-quality

software.
 Adaptability: Software engineers and managers adapt the process to their specific needs.
 Role of Stakeholders: Individuals or groups requesting the software play a role in the
software process.
 Benefits: Provides stability, control, and organization, preventing chaos.
 Process Variation: Depends on the type of software being developed (e.g., avionics
system vs. website).
 Work Products: Programs, documents, and data produced as a consequence of software
engineering activities.

Software Process Assessment

 Maturity Models: Various mechanisms assess the maturity of a software process.

 Indicators of Efficacy: Quality, timeliness, and long-term viability of the product.

Common Process Framework

A common process framework involves:

 Framework Activities: Applicable to all software projects, regardless of size or

complexity.
 Task Sets: Collections of software engineering tasks, milestones, work products, and
quality assurance points.
 Umbrella Activities: Overarching activities like software quality assurance, software
configuration management, and measurement.

Software Process vs. Software Engineering

 Software Process: Defines the approach taken to engineer software.

 Software Engineering: Includes technologies (methods and tools) used within the
process, and is performed by creative, knowledgeable people.

Software Engineering Layers

Software engineering is a layered technology:

1. Quality Focus: Organizational commitment to quality.

2. Process Layer: Foundation that defines the framework for key process areas.
3. Methods: Technical how-to’s for building software, encompassing tasks like
requirements analysis, design, program construction, testing, and support.
4. Tools: Automated or semi-automated support for the process and methods, integrated to
form a Computer-Aided Software Engineering (CASE) environment.

3.2 PM Process Groups

Project management processes are organized into five groups:

1. Initiating Processes: Authorizing the project or phase.

2. Planning Processes: Defining and refining objectives, selecting the best course of action
to achieve these objectives.
3. Executing Processes: Coordinating people and resources to carry out the plan.
4. Controlling Processes: Ensuring project objectives are met by monitoring and
measuring progress, identifying variances, and taking corrective action.
5. Closing Processes: Formalizing acceptance of the project or phase and bringing it to an
orderly end.

Each process is described by its inputs, tools & techniques, and outputs.

3.3 PM Process Links

 Linked by Results: The outcome of one process often becomes the input to another.
 Iterative Links: Planning provides executing with a documented project plan early on
and updates it as the project progresses.
 Overlapping Activities: These processes overlap and vary in intensity throughout each
phase.

3.4 PM Phase Interactions

 Cross-Phase Interactions: Closing one phase provides input to initiating the next.
 Example: Closing a design phase requires customer acceptance of the design document,
which then defines the product description for the implementation phase.
 Rolling Wave Planning: Planning is iterative and ongoing, detailing current and future
phase activities.

MCQs

1. What is the primary purpose of a software process?

o A) To reduce development costs
o B) To provide a road map for creating high-quality software
o C) To increase development speed
 o D) To train software engineers

Answer: B) To provide a road map for creating high-quality software

2. Which activity is an example of an umbrella activity in a software process?

o A) Requirements analysis
o B) Program construction
o C) Software quality assurance
o D) System testing

Answer: C) Software quality assurance

3. In project management, which process group involves coordinating people and

resources to carry out the plan?
o A) Initiating processes
o B) Planning processes
o C) Executing processes
o D) Controlling processes

Answer: C) Executing processes

4. What is the role of the process layer in software engineering?

o A) To provide automated tools for development
o B) To define a framework for key process areas
o C) To ensure the highest quality of software products
o D) To establish milestones and project timelines

Answer: B) To define a framework for key process areas

5. Which of the following best describes rolling wave planning?

o A) Planning only the initial phase of the project
o B) Detailed planning of the current phase and preliminary planning of future
phases
o C) Planning at the end of each phase
o D) Immediate execution without planning

Answer: B) Detailed planning of the current phase and preliminary planning of future
phases

Lecture 21
Lecture Notes on Software Development Fundamentals:
Initiating and Planning Processes
3. Processes

3.5 Initiating Process

The initiating process sets the foundation for a software project by defining key inputs, outputs,
and utilizing specific tools and techniques. Here’s an overview:

Inputs:

 Product Description: Detailed information about the product to be developed.

 Strategic Plan: Overall strategy aligning the project with organizational goals.
 Selection Criteria: Criteria for selecting the project among alternatives.
 Historical Information: Data from past projects to inform current project decisions.

Outputs:

 Project Charter: A document formally authorizing the project.

 Project Manager Assignments: Allocation of a project manager to oversee the project.
 Constraints: Limitations and restrictions affecting the project.
 Assumptions: Factors assumed to be true for planning purposes.

Tools and Techniques:

 Project Selection Methods: Techniques for choosing the project (e.g., cost-benefit
analysis).
 Expert Judgment: Involvement of experienced individuals to guide the process.

Tasks Performed for Project Initiation:

1. Requirement Gathering: Collecting both spoken and unspoken customer requirements

and translating them into technical specifications.
2. Scope Determination: Defining the combination of product and services to be delivered,
breaking down deliverables into manageable activities, and identifying the technology
required.
3. Resource Allocation: Identifying and allocating resources (people, components, tools)
based on scope, and estimating the cost to prepare the project budget.
4. Initial Project Plan: Creating a draft project plan that includes initial risk analysis, start
and end dates, activity durations, and sequencing.

3.6 Planning Process

Planning involves devising and maintaining a workable scheme to meet the project’s business
needs. This process includes setting directions, guiding the system to follow the direction, and
carrying out activities in a specific sequence.

Phases of Planning:

 Goals: Specific accomplishments required to achieve overall results (outputs of the

system).
 Strategies or Activities: Methods or processes required to achieve the goals (processes
in the system).
 Objectives: Specific accomplishments needed to achieve goals, often acting as
milestones.
 Tasks: Assigned activities to implement the plan, particularly in small organizations.
 Resources (and Budgets): People, materials, technologies, and money required to
implement strategies, often depicted as a budget.

SMARTER Goals and Objectives:

 Specific: Clear and specific goals (e.g., "Write a paper" vs. "Work harder").
 Measurable: Quantifiable goals (e.g., "Write a 30-page paper").
 Acceptable: Goals that are acceptable to those responsible for achieving them.
 Realistic: Achievable goals (e.g., "Write a 30-page paper in one week").
 Time Frame: Defined timeline (e.g., "Write one page a day for 30 days").
 Extending: Goals that stretch capabilities (e.g., writing on a challenging topic).
 Rewarding: Goals that provide a reward for the effort.

MCQs

1. What is an output of the initiating process?

o A) Project Plan
o B) Project Charter
o C) Resource Allocation
o D) Risk Analysis

Answer: B) Project Charter

2. Which input is crucial for the initiating process to align the project with
organizational goals?
o A) Historical Information
o B) Strategic Plan
o C) Product Description
o D) Selection Criteria

Answer: B) Strategic Plan

3. Which tool is commonly used during the initiating process to guide decisions?
 o A) Gantt Charts
o B) Expert Judgment
o C) SWOT Analysis
o D) Critical Path Method

Answer: B) Expert Judgment

4. In the planning process, what term is used for specific accomplishments needed to
achieve the goals?
o A) Strategies
o B) Objectives
o C) Resources
o D) Tasks

Answer: B) Objectives

5. What characteristic of SMARTER goals ensures they push the performer’s

capabilities?
o A) Specific
o B) Measurable
o C) Extending
o D) Rewarding

Answer: C) Extending

Lecture 22

Lecture Notes on Software Development Fundamentals:

Planning, Executing, Controlling, and Closing Processes
3. Processes

3.6 Planning Process

The planning process involves a series of tasks to ensure a project is well-defined and resources
are appropriately allocated. Here's a breakdown of the planning tasks:

Planning Process Tasks:

1. Scope Planning: Develop a written scope statement to guide future project decisions.
2. Scope Definition: Break down major project deliverables into smaller, manageable
components.
3. Activity Definition: Identify specific activities needed to produce project deliverables.
4. Activity Sequencing: Document the dependencies between activities.
 5. Activity Duration Estimating: Estimate the number of work periods required to
complete each activity.
6. Resource Planning: Determine what resources (people, equipment, materials) are
needed and in what quantities.
7. Cost Estimating: Approximate the costs of the resources required for project activities.
8. Cost Budgeting: Allocate overall cost estimates to individual work packages.
9. Schedule Development: Analyze activity sequences, durations, and resource
requirements to create the project schedule.
10. Quality Planning: Identify relevant quality standards and determine how to meet them.
11. Communications Planning: Define the information and communication needs of
stakeholders: who needs what information, when, and how it will be delivered.
12. Organizational Planning: Identify, document, and assign project roles, responsibilities,
and reporting relationships.
13. Staff Acquisition: Obtain the human resources needed and assign them to the project.
14. Procurement Planning: Determine what to procure, how much, and when.
15. Project Plan Development: Compile the results of other planning processes into a
consistent, coherent document.

3.7 Executing Process

The executing process involves performing the work defined in the project plan to achieve the
project's objectives.

Executing Process Tasks:

1. Project Plan Execution: Carry out the project plan by performing the included activities.
2. Quality Assurance: Regularly evaluate overall project performance to ensure it meets
quality standards.
3. Team Development: Enhance individual and group skills and competencies to improve
project performance.
4. Information Distribution: Provide necessary information to project stakeholders in a
timely manner.
5. Solicitation: Obtain quotations, bids, offers, or proposals.
6. Source Selection: Choose among potential sellers.
7. Contract Administration: Manage the relationship with the seller.

3.8 Controlling Process

The controlling process ensures project objectives are met by monitoring and measuring progress
and taking corrective actions as necessary.

Controlling Process Tasks:

1. Integrated Change Control: Coordinate changes across the entire project.

2. Scope Verification: Formalize acceptance of the project scope.
3. Scope Change Control: Control changes to the project scope.
 4. Schedule Control: Control changes to the project schedule.
5. Cost Control: Control changes to the project budget.
6. Quality Control: Monitor specific project results to ensure they comply with quality
standards and identify ways to eliminate unsatisfactory performance.
7. Performance Reporting: Collect and disseminate performance information, including
status reports, progress measurement, and forecasting.
8. Risk Response Control: Track identified risks, monitor residual risks, identify new
risks, ensure the execution of risk plans, and evaluate their effectiveness.

3.9 Closing Process

The closing process formalizes acceptance of the project or phase and brings it to an orderly end.

Closing Process Tasks:

 Contract Closeout: Complete and settle the contract, including resolving any open
items.
 Administrative Closure: Generate, gather, and disseminate information to formalize
phase or project completion. This includes evaluating the project and compiling lessons
learned for future projects or phases.

Key Concepts for Easy Understanding

1. Scope Planning: Writing down what the project will deliver to guide decisions.
2. Scope Definition: Breaking down the project into smaller parts for better management.
3. Activity Definition: Listing out all tasks needed to complete the project.
4. Activity Sequencing: Organizing tasks in the order they need to be done.
5. Activity Duration Estimating: Estimating how long each task will take.
6. Resource Planning: Identifying and assigning resources like people and materials.
7. Cost Estimating: Estimating how much the project will cost.
8. Cost Budgeting: Dividing the budget among different project parts.
9. Schedule Development: Creating a timeline for the project.
10. Quality Planning: Ensuring the project meets quality standards.
11. Communications Planning: Planning how to communicate project information.
12. Organizational Planning: Defining roles and responsibilities.
13. Staff Acquisition: Getting the right people for the project.
14. Procurement Planning: Planning what needs to be bought and when.
15. Project Plan Development: Compiling all planning activities into one document.

MCQs

1. What is the first task in the planning process?

o A) Activity Definition
o B) Scope Planning
o C) Resource Planning
o D) Cost Estimating
 Answer: B) Scope Planning

2. Which task involves identifying specific activities for project deliverables?

o A) Activity Sequencing
o B) Resource Planning
o C) Activity Definition
o D) Cost Budgeting

Answer: C) Activity Definition

3. What is the main goal of quality planning?

o A) To create the project schedule
o B) To meet relevant quality standards
o C) To communicate with stakeholders
o D) To allocate resources

Answer: B) To meet relevant quality standards

4. What does the controlling process ensure?

o A) Project objectives are met
o B) Resources are allocated
o C) The project plan is executed
o D) Contracts are closed

Answer: A) Project objectives are met

5. Which task is part of the closing process?

o A) Scope Verification
o B) Contract Closeout
o C) Schedule Development
o D) Team Development

Answer: B) Contract Closeout

Lecture 23 Planning

Lecture #23: Planning in Software Project Management

4. Planning

Planning is crucial in software project management, involving continuous efforts throughout the
project lifecycle. It begins with project planning activities.

Key Points:
  Preliminary planning starts early, even in the pre-project phase.
 Planning should be transparent and inclusive.
 Planning requires approval and support from stakeholders.

4.1 Project Planning Objectives

The objectives of software project planning are to provide a framework for making reasonable
estimates of:

 Resources
 Cost
 Schedule

These estimates should be updated regularly and consider best and worst-case scenarios.

Key Estimates:

1. Cost of the project

2. Duration of the project
3. Required personnel
4. Potential risks

4.2 Project Planning Definition

What is it?
Software project planning involves estimating the necessary resources, effort, cost, and time to
build a software product.

Who does it?

Software project managers, using input from customers, software engineers, and historical data.

Work Product:
A table outlining tasks, functions, costs, efforts, time, and resources required.

Ensuring Accuracy:
Follow a systematic approach, use historical data, apply multiple estimation methods, and
consider complexity and risks.

4.3 Project Planning: Key Tasks

1. Set goal and scope

2. Select lifecycle
3. Form the organization team
4. Start team selection
5. Determine risks
6. Create Work Breakdown Structure (WBS)
 7. Identify tasks
8. Estimate size and effort
9. Identify task dependencies
10. Assign resources
11. Schedule work

4.4 Project Management Process

The process includes the organization and resource planning to develop the product. The
development schedule is critical, answering "what" and "when" while detailing the "how."

Key Questions:

 Why is the system being developed?

 What will be done, and by when?
 Who is responsible for each function?
 Where are they organizationally located?
 How will the job be done technically and managerially?
 How much of each resource is needed?

4.5 Planning Puzzle

i. Scope Planning:
Documenting the project work to produce the product.

ii. Risk Planning:

Planning how to manage risks to ensure appropriate visibility and management.

iii. Schedule Development:

Analyzing activity sequences, durations, and resource requirements to create the project
schedule.

iv. Cost Estimating:

Approximating the costs of resources needed for project activities.

v. Project Control:
Continuous objective to take remedial actions or risk avoidance measures to protect the project
integrity.

4.6 Primary Planning Steps

1. Project Plan: Activities, tasks, dependencies, timeframes.

2. Resource Plan: Labor, equipment, materials required.
3. Financial Plan: Costs of labor, equipment, materials.
4. Quality Plan: Quality targets, assurance, control measures.
5. Risk Plan: Potential risks and mitigation actions.
 6. Acceptance Plan: Criteria for customer acceptance.
7. Communications Plan: Information distribution to stakeholders.
8. Procurement Plan: Products to be sourced externally.

4.7 The Software Development Plan (SDP)

The project development plan details how the project will be developed, resources required, and
their usage. It ensures project activities are well-charted before development begins.

Information Needs:

1. Introduction and status of the plan

2. Authorization procedures
3. Statement of project objectives
4. Statement of requirement
5. Deliverables in the project
6. Work Breakdown Structure
7. Project milestones
8. Resource requirements
9. Interdependencies of work
10. Timetable of events
11. Staffing, organization, and responsibilities
12. Development methods and toolsets
13. Source documentation
14. Resource and financial summary

Steps/Items Required:

 Adapt the contents to the project size.

 Include an overview of the project in the first section.
 Provide references for additional details.
 Standards like IEEE 1058.1 and US DOD standard 2167 may guide the plan's structure.

Inputs to Software Development Planning (SDP) encompass a variety of elements that guide the
creation of a coherent and consistent project plan. These inputs are critical in ensuring the plan
can effectively direct both the execution and control of the project. Here’s a breakdown of the
primary inputs to SDP:

1. Other Planning Outputs

 Base Documents: Outputs from other planning processes, including documents like the
Work Breakdown Structure (WBS), are essential inputs.
 Supporting Details: Detailed information supporting the base documents, such as
schedules, resource requirements, and risk assessments, are necessary for comprehensive
planning.
  Application Area-Specific Inputs: Specific projects may require additional inputs like
cash-flow forecasts, especially for major projects.

2. Historical Information

 Estimating Databases: Historical data on past projects, including cost estimates, time
estimates, and resource usage.
 Records of Past Project Performance: Information on how past projects performed in
terms of timeline, budget, and scope can help in verifying assumptions and assessing
alternatives.

3. Organizational Policies

 Quality Management: Policies related to process audits and continuous improvement

targets must be considered.
 Personnel Administration: Guidelines for hiring, firing, and employee performance
reviews.
 Financial Controls: Procedures for time reporting, expenditure reviews, disbursement
reviews, accounting codes, and standard contract provisions.

4. Constraints

 Budget Constraints: Predetermined budgets that may limit options regarding project
scope, staffing, and schedule.
 Contractual Provisions: Constraints that arise when projects are performed under
contract, including legal and regulatory requirements.

5. Assumptions

 Planning Assumptions: Factors considered to be true for planning purposes, such as

specific start dates for key resources. These assumptions need to be documented and
validated as they typically involve some degree of risk.

ools and Techniques for Software Development Planning (SDP)

6. Project Planning Methodology

 Structured Approach: Utilizes standard forms, templates, and tools, which can range
from simple forms to complex simulations like Monte Carlo analysis of schedule risk.
 Combination of Tools: Employs both "hard" tools (e.g., project management software)
and "soft" tools (e.g., facilitated startup meetings) to guide the project team in plan
development.

7. Stakeholder Skills and Knowledge

  Utilizing Stakeholder Expertise: Engages stakeholders' skills and knowledge, fostering
an environment where they can contribute effectively.
 Varied Contributions: Contributions depend on the project's needs and stakeholders'
expertise. For example, a cost engineer might contribute during proposal preparation,
while individual contributors might help refine duration and effort estimates.

8. Project Management Information System (PMIS)

 Integration and Dissemination: A PMIS gathers, integrates, and disseminates project

management process outputs, supporting all project phases from initiation to closure.
 Manual and Automated Systems: May include both manual and automated systems to
facilitate project management.

9. Earned Value Management (EVM)

 Integration and Measurement: Integrates the project's scope, schedule, and resources to
measure and report performance throughout the project's lifecycle.

Outputs from Software Development Planning (SDP)

1. Project Plan

 Formal Document: An approved document used to manage project execution, listing

planned dates for activities and milestones.
 Distribution: Distributed as defined in the communications management plan. Different
stakeholders may require varying levels of detail.
 Dynamic Nature: Expected to change over time as more information becomes available.
Performance measurement baselines change less frequently and usually only in response
to approved scope or deliverable changes.

SDP Execution

Coordination and Direction

 Execution Process: Coordinating and directing technical and organizational interfaces to

create the project’s product.
 Performance Monitoring: Continuously monitoring performance against the project
baseline to take corrective actions as needed.
 Forecasting: Periodically forecasting final cost and schedule results to support ongoing
analysis.

Inputs to SDP Execution

1. Project Plan
  Subsidiary Management Plans: Includes plans like scope, risk, procurement,
configuration management, and performance measurement baselines.

2. Supporting Detail

 Additional Information: Detailed information that supports the project plan and
execution.

3. Organizational Policies

 Formal and Informal Policies: Policies of all organizations involved in the project that
may affect execution.

4. Preventive Action

 Risk Reduction: Actions taken to reduce the probability of potential project risk events.

5. Corrective Action

 Alignment with Plan: Actions taken to align future project performance with the project
plan, completing the feedback loop for effective management.

Tools and Techniques for SDP Execution

1. General Management Skills

 Essential Skills: Leadership, communication, and negotiation skills are crucial for
effective project plan execution.

2. Product Skills and Knowledge

 Appropriate Skill Set: Ensuring the project team has the necessary skills and knowledge
about the project’s product.

3. Work Authorization System

 Formal Procedure: A system to authorize project work, ensuring tasks are done at the
right time and sequence. Can range from written authorizations to verbal approvals for
smaller projects.

4. Status Review Meetings

 Regular Updates: Scheduled meetings to exchange project information, typically held at

various frequencies and levels (e.g., weekly for the project team, monthly with the
customer).
5. Project Management Information System

 Support System: Provides the tools and techniques for managing project information
throughout the execution phase.

6. Organizational Procedures

 Useful Procedures: Formal and informal procedures from involved organizations that
aid project execution.

Outputs from SDP Execution

1. Work Results

 Activity Outcomes: Results from activities performed to accomplish the project,

including both tangible deliverables (e.g., buildings) and intangible results (e.g., trained
personnel).

2. Change Requests

 Scope, Budget, and Schedule Modifications: Requests for changes identified during
project execution to modify scope, cost, or schedule estimates.

Elements of Software Development Planning (SDP)

Phases of Project Plan

1. Preliminary
2. Final

The Software Project Plan is developed iteratively through the Concept and Requirements Phase.
Initial estimates are refined as the scope and requirements become clearer.

Key Elements of the Software Project Plan:

a) Scope Planning

 Progressive Elaboration: Documenting the project work that produces the project’s
product.
 Initial Inputs: Product description, project charter, and initial constraints and
assumptions.
 Outputs: Scope statement and scope management plan with supporting details.
 Scope Statement: Forms the basis for agreement between the project and the customer,
identifying project objectives and deliverables.

b) Objectives – Business Requirements

  Mission Statement: Defines business objectives for the project.
 Business Case: Includes the NPV model and a detailed description of assumptions.

c) Technical Approach

 System Development Description: Technologies, in-house vs. consultants, use of

existing models, architectural layout.
 Technologies: Describes the technologies to be used.
 Architectural Layout: Layers of the new system.

d) Contractual Aspects

 External Needs: Consultants, software suppliers, hardware suppliers,

network/infrastructure suppliers.
 Types of Contracts:
1. Cost-Plus: Developer is paid for service cost plus an agreed profit margin.
2. Fixed Price: Developer commits to provide a product/service for an agreed fee
within a set schedule.

e) Schedules

 Milestones: Defines specific dates for project milestones.

 Work Breakdown Structure (WBS): Detailed breakdown of project tasks.
 Scheduling Tools: Tools like MS Project to manage schedules.

f) Resource Allocation

 Resources: Licenses, servers, software, and hardware.

 Personnel: Initial estimates of the number and type of people needed, and for how long.

g) Evaluation Methods

 Performance Validation: Methods for testing adherence to specifications and

monitoring usage.
 Monitoring Tools: Web trends, database logs, transaction logs.
 Review Schedule: Set up schedules for periodic reviews.

h) Overview of Project Management

 Problem Identification: Identifying potential problems like new technologies, business

risks, and resources.
 Contingency Plans: Plans for development methods and actions if issues arise.

Summary of Elements

1. Scope Planning: Defines and documents project work.

 2. Objectives – Business Requirements: Business objectives, mission statement, and
business case.
3. Technical Approach: Development description, technologies, architectural layout.
4. Contractual Aspects: External needs, cost-plus, and fixed price contracts.
5. Schedules: Milestones, WBS, and scheduling tools.
6. Resource Allocation: Resources and personnel.
7. Evaluation Methods: Performance validation, monitoring tools, and review schedules.
8. Overview of Project Management: Problem identification and contingency plans.

Life Cycle Models in Software Development

Life Cycle Models Overview To ensure the successful execution of a project, it is necessary to
break it down into multiple manageable tasks, performed in a series using processes. A process is
a collection of related tasks with specific milestones, arranged and executed in sequence to
ensure smooth progress. Different process models provide approaches that guide software
development from project conceptualization to formal termination.

1. The Waterfall Model

 Traditional Life Cycle Model: Assumes sequential execution of phases.

 Phases: Each phase must be completed before the next begins.
 Characteristics: Linear and straightforward, but inflexible to changes once a phase is
completed.

2. The Prototyping Model

 Iterative Cycle: Involves gathering customer requirements, producing a prototype, and

validating it with the customer.
 Characteristics: Builds on the prototype from the previous iteration, allowing for
refinement based on customer feedback.

3. The Incremental Model

 Evolutionary Life Cycle Model: Combines linear and iterative elements.

 Development in Increments: Divides the development life cycle into multiple linear
sequences, each producing an increment of the final product.
 Builds: Software is developed in self-contained units called builds, each with a specific
set of features.

4. The Spiral Model

 Combination of Waterfall and Prototyping Models: Divides the project life cycle into
phases, executed iteratively.
 Phases: Each phase is revisited in every iteration, focusing on risk assessment and
reduction.
5. The RAD (Rapid Application Development) Model

 Focus on Quick Development: Emphasizes rapid prototyping and iterative delivery.

 Phases: Defined processes and structured approach to sequence phases and identify
requirements efficiently.
 Flexibility: Adaptable to changes, allowing for frequent iterations and adjustments based
on user feedback.

Process Models and Organizational Adaptation A process model defines the overall processes
an organization follows to manage a project efficiently. It helps organize, monitor, and execute a
project by defining structured approaches to sequence phases and identify requirements.

 Flexibility: Process models do not follow rigid implementation rules; organizations can
deploy new models or customize existing ones.
 Example: An organization using a confidential defense applications model (Process
Model A) might merge it with a simpler model (Process Model B) to create an evolved
process model with consistent SDLC phases.

Summary of Key Points

 Life Cycle Models: Different models like Waterfall, Prototyping, Incremental, Spiral,
and RAD offer various approaches to software development.
 Sequential and Iterative Approaches: Models range from linear, sequential approaches
(Waterfall) to iterative, evolutionary approaches (Spiral, Incremental).
 Flexibility and Adaptation: Process models can be customized to fit organizational
needs, ensuring efficient project management and execution.

This overview provides a foundational understanding of various life cycle models and their
application in software development projects.

Choosing the Lifecycle Model

When selecting a lifecycle model for your project, consider several factors to ensure the chosen
model aligns with project requirements and constraints. Here are key considerations and criteria
to guide the selection process:

Factors to Consider:

1. Understanding of Requirements: Are the requirements well-defined at the beginning,

or are they likely to change during the project?
2. System Architecture: Is the system architecture clear, or are changes anticipated?
3. Level of Reliability: What level of reliability is required for the project?
4. Re-design for Future Versions: Is there a need for re-design in future versions?
5. Risk Level: What is the risk level associated with the project?
 6. Predefined Schedule: Is there a strict schedule that must be adhered to?
7. Midcourse Corrections: Is there a need for midcourse corrections based on feedback or
new information?
8. Customer Involvement: How informed and involved is the customer throughout the
project?
9. Visible Management: Is there a need for visible management and control throughout the
project?
10. Modification Needs: How much modification does the chosen model require?

Criteria for Selecting a Process Model:

1. Business Goals of the Organization:

o Organizations with a history of well-defined plans might prefer the Waterfall
model.
o Organizations equipped to handle financial, technological, and personnel risks
might choose the Spiral model.
o Organizations that work in an experimental and feedback mode might prefer the
Prototyping model.
2. Expected Size of the Project:
o Large projects with clear requirements might use the Waterfall model.
o Projects delivered in phases or increments might use the Incremental model.
o Projects with uncertain sizes might use the Prototyping or Spiral models.
3. Client and Project Requirements:
o Well-defined and stable requirements suit the Waterfall or Incremental models.
o Uncertain and evolving requirements suit the Spiral or Prototyping models.
4. Availability of Funds and Development Staff:
o Projects with predetermined resources might use the Waterfall or Prototyping
models.
o Projects expecting additional resources over time might use the Incremental or
Spiral models.
5. Risks Perceived in the Project:
o Low-risk projects might use the Waterfall or Incremental models.
o High-risk projects might use the Spiral model.

When to Use Specific Models:

Waterfall Model:

 Use when the project is large, clearly divided into discrete phases, and each phase has
defined inputs and outputs.
 Ideal for projects with clear and unchanging requirements.
 Drawbacks include inflexibility, high documentation requirements, and potential delays
due to blocking states.

Prototyping Model:
  Use when the client is unclear about requirements or when there is conflict in client
requirements.
 Suitable for projects needing frequent client feedback and where the requirements are
likely to evolve.
 Types of prototyping include rapid, reusable, and modular prototyping.

Incremental Model:

 Use when human resources are scarce and the project can be divided into modules
developed and delivered independently.
 Suitable for projects where resources become available over time, allowing phased
development and delivery.

Spiral Model:

 Use when the project involves high risks and uncertainties.

 Suitable for projects requiring extensive risk analysis and iterative development based on
client feedback.
 Ideal for complex projects with evolving requirements and where client involvement is
high.

Example Scenarios:

Waterfall Model:

 A large-scale project with well-defined phases and clear requirements, such as banking
software or airline reservation systems.
 Drawbacks: Not suitable for projects requiring frequent changes or those lacking clear
initial requirements.

Prototyping Model:

 A project where the client is unsure of the requirements or there is a need to clarify and
refine requirements through iterations.
 Example: Developing a new user interface where the design is unclear and needs to be
refined based on user feedback.

Incremental Model:

 A project with scarce human resources, requiring phased development and delivery.
 Example: Developing an HR system in multiple independent modules, allowing early
deployment of core functionalities.

Spiral Model:
  A high-risk project with uncertain requirements, requiring iterative development and
frequent client feedback.
 Example: Developing a VOIP telephony system with no prior experience, requiring
continuous risk analysis and prototype development.

In software project management, selecting the appropriate planning documents is crucial for the
successful execution and delivery of the project. Below is an overview of key planning
documents, categorized and described based on their role in the project lifecycle:

1. Requirements Phase Documents

Software Requirements Specification Document

 Purpose: To detail the functional and non-functional requirements of the software.

 Importance: Serves as the baseline for all subsequent project phases, ensuring all
stakeholders have a clear understanding of what the software will deliver.

Project Planning Documents

1. Project Development Plan

o Purpose: Outlines the approach, resources, schedule, and tasks necessary to
complete the project.
o Components: Scope, timelines, resource allocation, milestones, and risk
management strategies.
2. Software Test Plan
o Purpose: Defines the testing strategy, objectives, resources, schedule, and
deliverables for the testing phase.
o Importance: Ensures that the software meets quality standards and functional
requirements.

2. Statement of Requirement (SOR)

 Purpose: To provide a clear and detailed description of the project requirements.

 Key Characteristics:
o Unambiguous
o Fully defined and complete
o Verifiable deliverables
o No conflicts
o Consistent
o Auditable
 Role: Serves as the basis for change control and aligns closely with the contract to avoid
conflicts of interest.

3. System Specification
  Purpose: To provide a comprehensive description of the system’s scope before the
project planning begins.
 Importance: If available, it simplifies the planner's task by providing essential attributes
and boundaries for estimation.

4. Design Specification

 Purpose: To provide a detailed plan on how the requirements will be implemented.

 Components: Project development plan, requirements specification, design specification.
 Role in Risk Analysis: Helps identify potential problems related to dependencies,
implementation decisions, and external sources.

5. Data Item Descriptions (DID s)

 Purpose: To define the documentation standards for all phases of software development.
 Key Documents:
o Software development plan
o System/segment specification
o Software requirements specification
o Software design document
o Interface requirements specification
o Software test plan and descriptions
o Release manuals
o Maintenance documentation and source code
 Flexibility: Allows for tailoring of the document format and presentation styles.

6. Software Configuration Management Plan (SCMP)

 Purpose: To manage configuration control activities, resources, standards, procedures,

and policies.
 Components:
o Organization structure
o Standards, procedures, and policies
o Configuration identification and methods
o Change control procedures
o Version control
o Storage, handling, and delivery of project media
 Role: Ensures proper documentation, control of software components, and smooth
handling of configuration changes.

7. Statistical Software Process Improvement (SSPI)

 Purpose: To enhance process metrics and improve software quality through rigorous
analysis.
 Process:
o Categorize errors and defects by origin
 o Record the cost to correct each error and defect
o Analyze data to identify high-cost categories
o Develop plans to eliminate or reduce costly errors and defects
 Outcome: Leads to continuous process improvement and higher quality software
systems.

Tailoring the Standard

 Principles:
o Deletion of non-applicable requirements
o Carried out by the contracting agency
 Process:
o Review standard requirements
o Identify non-applicable items
o Justify deletions
o Submit tailoring request early in the project lifecycle

9. Configuration Control of Subcontractors, Vendors, and Suppliers

 Additional Control:
o Miscellaneous control procedures
o Project-specific control (e.g., security)

10. Configuration Status Accounting

 Configuration Audits and Reviews

 Configuration Structure Reporting Procedures

11. Configuration Management Major Milestones

12. Tools, Techniques, and Methodologies

8. Communications Management Plan

A comprehensive document detailing the communication strategy for a project. Key components
include:

 Collection and Filing Structure: Methods for gathering and storing information,
including updates.
 Distribution Structure: Specifies to whom and how information will be distributed,
aligning with the project organization chart.
 Description of Information: Format, content, level of detail, and conventions.
  Production Schedules: Timelines for each type of communication.
 Methods for Accessing Information: Between scheduled communications.
 Updating the Plan: Methods for refining the plan as the project progresses.

9. Software Quality Assurance Plan (SQAP)

A critical component ensuring quality in project development, typically integrated into the
overall project plan. Elements include:

 Quality Control Organization

 Standards and Methods
 Quality Control Procedures: Aligned with the Work Breakdown Structure (WBS).
 Quality Milestones
 Unusual Features
 Change Control and Configuration Management
 Acceptance Procedures
 Quality Assurance Procedures The SQAP can be a separate document or a section
within the project development plan, encompassing resources, standards, and procedures.
It must cover all involved parties, including subcontractors and vendors.

10. RMMM Plan (Risk Mitigation, Monitoring, and Management Plan)

Documents risk analysis and management strategies, either as part of the software project plan or
a separate document. Key objectives:

 Risk Mitigation: Avoidance activities.

 Risk Monitoring: Assessing risk occurrence, applying aversion steps, and gathering
information for future analysis.

11. Project Development Budget

Prepared by the project manager during the initial stages, covering:

 Development Budget
 Schedule
 Required Resources: Staff, equipment, etc. Final budgeting and adjustments occur
alongside integration and testing, including user training, site preparation, and team size
reduction.
12. Maintenance Documents

Key documents created during the software development phase include:

 Programmer's Notebook: Coding decisions, unit tests, problem resolutions.

 Maintenance Plan and Documentation
 Initial User Documentation: Reference manuals, operator guides. Finalized documents
include:
 Maintenance Documentation
 Final User Documentation
 Updated Development Documentation
 Test Documentation and Reports

13. Statement of Work (SOW)

The basis for the contract between proposer and customer, detailing all work to be performed.
Components include:

 Referenced Documents
 Software Deliverables
 Equipment and Hardware Deliverables
 Training Requirements
 Market Research
 Procurement
 Supervision of Subcontractors
 Documentation Needs
 Testing Phases
 Installation and Maintenance Services The SOW should be clear, complete, and
concise, covering all agreed work.

14. Responsibility Assignment Matrix (RAM)

Defines project roles and responsibilities, ensuring each work element is assigned. It links the
project organization to the work breakdown structure, clarifying who is responsible for specific
tasks and phases.

15. Project Charter

A formal document issued by senior management authorizing the project and granting authority
to the project manager.
16. Risk Management Plan

Describes how risk management will be structured and performed, including:

 Methodology
 Roles and Responsibilities
 Budgeting
 Timing
 Scoring and Interpretation
 Thresholds
 Reporting Formats
 Tracking

4.10 Scheduling

Scheduling is vital for project completion, detailing:

 Development Activities
 Project Resources (People) The plan should be adhered to and updated as necessary,
using methods like:
 Precedence Network Diagrams (PERT)
 Gantt Charts
 Milestones Lists

4.11 Guidelines for Successful Planning

 Involve the Right People

 Write Down and Communicate Plans
 SMARTER Goals: Specific, Measurable, etc.

Lecture #27: Organization

5.1 Basic Definition

An organization is a group of people intentionally structured to achieve a common goal or set of

goals. These entities can vary in size from small teams to large corporations. Interpretations of an
organization can differ based on values and perspectives, viewing them as machines, organisms,
families, or groups.

Organizations are managed through a hierarchical structure based on four core principles:
  Delegation: Assigning tasks and responsibilities.
 Authority: Granting decision-making power.
 Responsibility: Accountability for assigned tasks.
 Supervision: Overseeing and guiding the performance.

Projects are often organized into teams with specific roles depending on the nature and expertise
required. A project manager must choose the appropriate structure based on the project's needs.

5.2 Organization as a System

Viewing organizations as systems can be helpful. A system consists of interconnected parts

designed to achieve an overall goal. Key elements include:

 Inputs: Resources such as materials, money, technology, and people.

 Processes: Activities that align and coordinate inputs.
 Outputs: Tangible results like products or services.
 Outcomes: Benefits to consumers and society.

Feedback mechanisms ensure alignment with goals, coming from within the organization
(employees, clients) and from external influences (government, economy). Subsystems within an
organization, such as departments or teams, operate to achieve their specific goals, contributing
to the overall system.

5.3 Structural Dimensions

The design of an organization affects how it achieves its goals. Key dimensions include:

 Centralization: The degree to which functions are dispersed or centralized.

 Formalization: The extent of documented policies and procedures.
 Hierarchy: Levels and configuration of the organizational structure.
 Routinization: Standardization of processes.
 Specialization: Refinement of activities.
 Training: Development of members' knowledge and skills.

5.4 Organizational Systems

Organizations that are project-based focus on managing projects. There are two main types:

1. Revenue-Based: Organizations that primarily earn from project work, such as

architectural firms or consultants.
2. Management by Projects: Organizations with systems designed to manage multiple
projects efficiently.

Non-project-based organizations may struggle with project management due to less developed
project-oriented systems, though some departments may function as project-based units.
5.5 Organizational Cultures and Styles

Organizational culture includes shared values, norms, beliefs, and practices that influence project
outcomes. For instance:

 Aggressive Organizations: More likely to approve high-risk projects.

 Participative vs. Authoritarian Styles: Project managers' effectiveness can vary based
on organizational culture.

Organizational structures impact resource availability and project management. Structures range
from functional to projectized, with matrix structures in between. The type of structure affects
project management authority, team roles, and resource allocation.

5.6 Traditional Structures of Business Organization

1. Functional Structure:
o Central office oversees various departments (e.g., HR, sales).
o Suitable for small, centralized organizations.
o Limits project scope to departmental boundaries.
2. Projectized Structure:
o Central office with divisions dedicated to specific products or services.
o Divisions operate with their own functional structures.
o Ideal for large, dispersed organizations with diverse offerings.
o Project managers have high authority and independence.
3. Matrix Structure:
o Combines functional and projectized characteristics.
o Employees report to both functional and product managers.
o Facilitates coordination across functions but can create reporting complexities.
o Weak Matrix: Functional focus with project manager as coordinator.
o Balanced Matrix: Equal authority between functional and project managers.
o Strong Matrix: Project-focused with significant authority for project managers.
4. Project Office:
o Varies from support functions to full project responsibility.
o Even functional organizations may have project teams with characteristics of
projectized structures.

Lecture #28: Organization

5.7 Organizational Planning

Organizational planning is essential for defining, documenting, and assigning roles,

responsibilities, and reporting relationships within a project. This planning helps ensure that
everyone involved in the project knows their roles and how they fit into the larger structure. It
often involves both internal and external stakeholders.

Key Aspects of Organizational Planning:

  Roles, Responsibilities, and Reporting Relationships: Can be assigned to individuals
or groups, and might include internal teams (like engineering or marketing) or external
entities.
 Review and Adjustment: The organizational structure should be reviewed regularly and
adjusted as necessary to remain effective throughout the project lifecycle.
 Link to Communications Planning: The organizational structure influences the
communication requirements of the project.

5.7.1 Inputs to Organizational Planning

i. Project Interfaces

 Organizational Interfaces: These are formal and informal reporting relationships among
different organizational units. They can be complex or simple, depending on the project's
scale and nature.
o Example: Coordinating numerous subcontractors for a telecommunications
system vs. fixing a programming error in a single-site system.
 Technical Interfaces: Reporting relationships among different technical disciplines
within and between project phases.
o Example: Ensuring site design by civil engineers aligns with structural design by
structural engineers.
 Interpersonal Interfaces: Reporting relationships among individuals working on the
project, often involving both formal and informal interactions.
o Example: An architect explaining design considerations to a construction
contractor.

ii. Staffing Requirements

 Defines the competencies needed from individuals or groups and their timelines.
 A subset of overall resource requirements identified during resource planning.

iii. Constraints

 Factors that limit the project team's organizational options:

o Organizational Structure: E.g., a strong matrix means a stronger role for the
project manager.
o Collective Bargaining Agreements: Contracts with unions may dictate certain
roles or reporting relationships.
o Preferences of the Project Management Team: Past successes can influence
preferred structures.
o Expected Staff Assignment: Organizational decisions often depend on the
competencies of specific individuals.

5.7.2 Tools and Techniques for Organizational Planning

i. Templates
  Utilizing role definitions and reporting relationships from similar past projects to speed
up planning.

ii. Human Resource Practices

 Leveraging organizational policies and guidelines related to management roles, such as

the "coach" role.

iii. Organizational Theory

 Familiarity with literature on organizational structure helps the project management team
adapt to project requirements.

iv. Stakeholder Analysis

 Identifying and analyzing stakeholder needs to ensure their requirements are met.

5.7.3 Outputs from Organizational Planning

i. Role and Responsibility Assignments

 Assigning who does what and who decides what, often using a Responsibility
Assignment Matrix (RAM). RAMs can be at various levels:
o High-Level RAM: Defines which group or unit is responsible for each
component of the work breakdown structure.
o Lower-Level RAMs: Assign specific tasks to individuals within groups.

ii. Staffing Management Plan

 Describes how and when human resources will be added or removed from the project
team. Includes:
o Resource Histograms: Visual representations of resource needs over time.
o Reassignment Procedures: Ensures effective reallocation of team members to
reduce costs and improve morale.

iii. Organization Chart

 A graphical representation of project reporting relationships, which can vary in detail

based on the project’s size.
o Organizational Breakdown Structure (OBS): Shows which units are
responsible for which work packages.

iv. Supporting Detail

 Additional information that aids in organizational planning, such as:

o Organizational Impact: Alternatives excluded by the chosen structure.
 o Job Descriptions: Outlines of competencies, responsibilities, and authority for
each role.
o Training Needs: Identifying and addressing gaps in competencies required for
the project.

Staff Acquisition and Team Development

5.8 Staff Acquisition

Staff acquisition involves obtaining the necessary human resources for the project. This can be
challenging when the best resources are not available, so the project management team must
ensure that available resources meet project requirements.

5.8.1 Inputs to Staff Acquisition

i. Staffing Management Plan

 Includes the project’s staffing requirements and outlines how to acquire the needed
personnel.

ii. Staffing Pool Description

 Previous Experience: Assess if potential staff have relevant experience and have
performed well.
 Personal Interests: Determine if individuals or groups are interested in the project.
 Personal Characteristics: Evaluate if the team members are likely to work well
together.
 Availability: Check if the desired individuals or groups will be available when needed.
 Competencies and Proficiency: Identify the required competencies and their required
levels.

iii. Recruitment Practices

 Adhere to organizational policies, guidelines, or procedures that may govern staff

assignments and act as constraints.

5.8.2 Tools and Techniques for Staff Acquisition

i. Negotiations

 Negotiate staff assignments with functional managers and other project management
teams to ensure the best fit for project needs.
o Example: A functional manager might prefer to assign available staff who don’t
meet all project requirements due to incentives for staff utilization.

ii. Pre-assignment
  Staff may be pre-assigned if promised in a proposal or defined in the project charter.

iii. Procurement

 Use project procurement management to acquire the services of specific individuals or

groups when in-house staff are insufficient.

5.8.3 Outputs from Staff Acquisition

i. Project Staff Assigned

 Ensures that appropriate individuals are assigned to work on the project, either full-time,
part-time, or on a variable basis.

ii. Project Team Directory

 A directory listing all project team members and stakeholders, which can vary in
formality and detail based on project needs.

5.9 Team Development

Team development focuses on enhancing both individual and team performance. This process is
crucial for meeting project objectives and involves managing dual reporting relationships
effectively.

5.9.1 Inputs to Team Development

i. Project Staff

 Defines available competencies and team dynamics based on staff assignments.

ii. Project Plan

 Provides the technical context for the team's operation.

iii. Staffing Management Plan

iv. Performance Reports

 Offer feedback on performance relative to the project plan.

v. External Feedback
  Provides insights from outside the project to gauge the team's alignment with external
expectations.

5.9.2 Tools and Techniques for Team Development

i. Team-Building Activities

 Activities designed to improve team performance and interpersonal relationships. These

can range from brief agenda items to extensive, professionally facilitated sessions.

ii. General Management Skills

 Important for effective team development and management.

iii. Reward and Recognition Systems

 Formal systems to promote desired behavior by linking performance to rewards. Should

consider cultural differences and ensure clarity in the link between performance and
rewards.

iv. Co-location

 Placing team members in the same physical location to enhance collaboration. If not
possible, frequent face-to-face meetings may be an alternative.

v. Training

 Includes formal and informal activities to enhance team competencies, with direct or
indirect costs often borne by the performing organization.

5.9.3 Outputs from Team Development

i. Performance Improvements

 May include enhanced individual skills, improved team behaviors, and better ways of
performing project tasks.

ii. Input to Performance Appraisals

 Staff should provide feedback for appraisals of colleagues they interact with significantly.

5.10 Organizational Management Tools

i. Management Development
  Focuses on developing skills in responsibility, authority, competence, resource
distribution, and more.

ii. Supervisory Training

 Includes training on field operations, procedural details, and resource management.

iii. Team Building

 Involves evaluating skills and forming support groups to enhance team functionality.

iv. Vital Statistics

 Includes historical facts, technical data, and lessons learned.

v. Progress Reporting

 Covers various types of reports, including mandatory periodic and exception reports, and
involves analysis and review processes.

vi. Compliance of Rule of Business

 Ensures adherence to financial, procedural, and administrative rules, with justifications

for deviations.

vii. Trade-Offs

 Balances quality, scope, and deliverables against constraints and targets.

viii. Quality Assurance

 Involves standard procedures and task-specific controls to ensure quality.

ix. Beneficiaries Concern

 Addresses acceptance, enthusiasm, and comfort for beneficiaries, focusing on building

confidence and reliability.

5.11 Contractual Obligations

A contract is a legally binding agreement that obligates the seller to provide a product or service
and the buyer to pay for it. Contracts vary in complexity based on the product or service. Key
aspects include:
  Types of Contracts: Can include agreements, subcontracts, purchase orders, or
memorandums of understanding.
 Approval Process: Contracts typically undergo a more extensive review to ensure they
meet the identified needs.
 Delegation of Procurement Authority: Defines who can sign agreements on behalf of
the organization.

Types of Contracts in Software Development

1. Cost-Plus Contract

Definition: In a cost-plus contract, the developer is reimbursed for the actual costs incurred plus
an additional fee representing profit. This is akin to paying for a car rental where you cover
usage costs and expenses like insurance and gas.

Example: Company Alpha hires Company Beta to develop a software system. Company Beta
bills $80 per hour for engineering work and adds 20% for overheads and other expenses. Any
additional costs (like equipment or travel) are reimbursed by Company Alpha.

Advantages:

 Suitable for projects with uncertain requirements.

 Provides flexibility in project scope.
 Developer bears minimal financial risk.

Disadvantages:

 Potential for higher costs due to lack of motivation for efficiency.

 Requires detailed tracking and documentation of expenses.
 May lead to disputes over expenses and project scope.

When to Use:

 For projects with poorly defined requirements.

 When customer wants to retain control over development.
 When initial phases are cost-plus, with later phases fixed price.

2. Fixed Price Contract

Definition: A fixed price contract involves an agreed total fee for delivering a well-defined
product or service within a specified schedule, similar to buying a bus ticket for a set price and
destination.

Example: Company Alpha and Company Beta agree on a fixed price of $100,000 for a software
project. Company Beta must deliver the completed project by a specific deadline without
additional compensation for overruns.
Advantages:

 Provides clear budget for the customer.

 Developer assumes most of the financial and development risk.
 Encourages efficiency as profit is tied to managing costs.

Disadvantages:

 Risk of underbidding and potential losses for the developer.

 Limited flexibility for requirement changes.
 Disputes may arise over project scope and completion criteria.

When to Use:

 When project requirements are well-defined and stable.

 When a fixed budget is crucial for the customer.
 When developer seeks to manage the project within defined constraints.

3. Cost-Reimbursable Contract

Definition: Cost-reimbursable contracts involve payment for actual costs incurred plus a fee.
Costs are classified as direct (e.g., salaries) or indirect (e.g., overhead).

Types:

 Cost Plus Fixed Fee: A fixed fee plus reimbursed costs.

 Cost Plus Incentive Fee: Reimbursed costs plus an incentive for achieving targets.
 Cost Plus Award Fee: Reimbursed costs plus a performance-based award.

Advantages:

 Flexibility to adjust scope and costs.

 Useful for projects with uncertain requirements.

Disadvantages:

 Less control over final costs.

 Potential for disputes over costs and performance.

When to Use:

 For projects with uncertain requirements or risks.

 When customer requires flexibility in project scope and costs.

4. Time and Material (T&M) Contract

Definition: T&M contracts combine elements of cost-reimbursable and fixed-price contracts.
The buyer pays for labor at agreed rates plus material costs.

Advantages:

 Flexibility in project scope and requirements.

 Provides transparency on time and costs.

Disadvantages:

 Can lead to increased costs if not carefully managed.

 Requires detailed tracking of time and materials.

When to Use:

 When the project scope is not well-defined.

 When flexibility is needed for changes in requirements.

5. Other Customer-Developer Relationships

 Combinations of Fixed Price and Cost-Plus: Hybrid contracts that may apply fixed
price for certain phases and cost-plus for others.
 Joint Ventures: Shared risks and rewards, often used for large or complex projects.
 Royalty Agreements: Developers receive a percentage of revenues from the project,
aligning their interests with the project's success.
 Long-Term Commitments: Ensures ongoing work and income for the developer, often
beneficial for both parties in extending project scope.

6. Statement of Work (SOW)

Definition: The SOW outlines the work to be performed under the contract. It serves as a
detailed description of the project's deliverables, timelines, and other specifics.

Key Elements:

 Scope of Work: Detailed description of tasks, hardware, software, and work nature.
 Location of Work: Specifies where work will be performed.
 Period of Performance: Timelines, working hours, and billing details.
 Deliverables Schedule: Specific deliverables with deadlines.
 Applicable Standards: Relevant industry or company standards.
 Acceptance Criteria: Criteria for evaluating the work.
 Special Requirements: Any specific requirements such as certifications or testing.

Example SOW Outline:

1. Referenced Documents
 2. Software Deliverables
3. Equipment and Hardware Deliverables
4. Training
5. Market Research
6. Procurement
7. Supervision of Subcontractors
8. Documentation
9. Testing
10. Installation
11. Maintenance Services
12. Other Services and Deliverable Items
13. Method of Delivery

Lecture #29: Estimation

6.1 Estimation - Concepts

Importance of Estimation: Watts Humphrey's quote, “If you don’t know where you are, a map
won’t help,” emphasizes the importance of accurate estimation in software projects. Accurate
estimates of cost, effort, risks, and resources are crucial for:

 Understanding the size of the project

 Estimating the project’s cost, effort, and duration
 Planning resources and scheduling

Historical Context: In the early computing days, software costs were relatively small compared
to the overall system cost. Today, software often constitutes the largest part of the cost in
computer-based systems. Errors in estimating software costs can significantly impact
profitability, making accurate estimation even more critical.

Challenges of Estimation: Software estimation is inherently uncertain due to various

influencing factors:

 Human factors
 Technical complexities
 Environmental conditions
 Political influences

Options for Estimation:

1. Delay Estimation: While waiting until the end of the project would provide accurate
estimates, it's impractical as estimates are needed up front.
2. Base on Similar Projects: This approach works well if current projects are similar to
past ones, but historical performance is not always a reliable indicator of future results.
3. Decomposition Techniques: Break the project into smaller, more manageable parts to
estimate cost and effort.
 4. Empirical Models: Use empirical models to estimate software cost and effort.
Combining multiple techniques and cross-checking them can improve accuracy.

Estimation Process:

 Estimate Product Size: Determine the size of the software product.

 Estimate Effort: Calculate the effort required in man-months.
 Estimate Schedule: Estimate the timeline for project completion.

Note: Not all steps are always explicitly performed in practice.

6.2 Estimation – A Critical Factor

Key Factors in Estimation:

 Cost
 Effort
 Risks
 Resources

Accurate estimation involves:

 Experience
 Access to historical data
 Courage to make quantitative predictions with limited qualitative information

Factors Affecting Estimation Risk:

1. Project Complexity: Complexity impacts uncertainty. Familiarity with the type of

project reduces perceived complexity. Quantitative measures can be applied at design or
code levels, while subjective assessments are used earlier in planning.
2. Project Size: Larger projects involve more interdependencies and complexities, making
estimation more challenging. As the project grows, the likelihood of encountering
problems increases.
3. Degree of Structural Uncertainty: Refers to the clarity of requirements, ease of
function compartmentalization, and hierarchical data processing. High structural
uncertainty increases estimation risk.
4. Availability of Historical Information: Past project metrics help in making more
reliable estimates and reducing risk. Comprehensive metrics allow for better planning and
risk management.
5. Risk: Measured by the uncertainty in estimates for resources, cost, and schedule. Poorly
understood project scope and changing requirements increase risk.

Best Practices for Estimation:

  Ensure complete function, performance, and interface definitions are specified in the
System Specification.
 Recognize that variability in requirements leads to instability in cost and schedule.

Lecture #30: Estimation

6.3 Decomposition Techniques

Overview: Decomposition is a crucial technique in software project estimation. Given the

complexity of estimating a software project, it is often necessary to break the problem into
smaller, more manageable parts. This approach allows for more accurate and practical
estimation.

Understanding Software Sizing: Accurate estimation depends on:

1. Proper estimation of the software size.

2. Translating size into effort, time, and cost using historical metrics.
3. Aligning the project plan with the team's capabilities.
4. The stability of requirements and the working environment.

Sizing Methods:

1. Fuzzy Logic Sizing:

o Uses approximate reasoning techniques to estimate the size based on qualitative
scales.
o Involves identifying the type and magnitude of the application, refining estimates
with historical data.
2. Function Point Sizing:
o Estimates based on the information domain characteristics.
o Measures the functional size of the software by evaluating its functionalities.
3. Standard Component Sizing:
o Estimates based on standard components of the software, such as modules,
screens, and reports.
o Uses historical data to estimate the size of each component. For example, if 18
reports are required and historical data shows each report needs 967 lines of code,
the total size can be estimated as 17,000 lines of code.
4. Change Sizing:
o Estimates the size of changes required to existing software.
o Includes modifications such as reuse, adding, changing, or deleting code.
o Uses effort ratios for different types of changes to estimate the size.

6.4 Estimation – Tools

Work Breakdown Structure (WBS):

a) Dividing into Logical Units/Tasks:

  The WBS technique divides a project into smaller, manageable tasks or logical units.
 Essential for accurate estimation of effort, size, and cost.
 Helps in conceptualizing the project into distinct units. For example, tasks related to
marketing can be grouped under a common category.

b) Benefits of Using a WBS:

 Size and Complexity: Provides insight into the project's size and complexity.
 Planning and Scheduling: Facilitates realistic planning, scheduling, and monitoring by
setting measurable targets for each task.

Tools for Project Planning and Scheduling:

 Program Evaluation and Review Techniques (PERT): Analyzes the tasks involved in
completing a project.
 Critical Path Method (CPM): Identifies the longest path of tasks and helps in
scheduling project tasks.
 Timeline Charts: Visual representation of the project schedule.
 Gantt Charts: Displays project tasks against a timeline, showing start and end dates.

Measuring Effort for a Project

Accurate effort measurement is crucial for creating realistic project plans and avoiding cost
overruns. Incorrect effort estimates can lead to project delays and significant budget
discrepancies. Here are the key techniques for measuring project effort:

Quantitative Estimation Techniques

1. Source Lines of Code (SLOC)

o Definition: Measures the number of lines of code (LOC) in a software project.
Effort is expressed in terms of thousands of lines of code (KLOC).
o Procedure: Counts the actual lines of code written by the development team,
excluding test drivers, support software, and comments.
o Advantages:
 Objective and straightforward.
 Provides a direct measure of project size.
o Disadvantages:
 Language-dependent; the effort required can vary significantly between
programming languages.
 Does not account for code quality or complexity.
2. Function Point (FP)
o Definition: Measures the functionality delivered by the software from the user's
perspective.
o Procedure:
1. Identify unadjusted function points based on various components like
internal files, external interfaces, user inputs, outputs, and inquiries.
 2. Calculate General System Characteristics (GSCs).
3. Compute the Value Adjustment Factor (VAF).
4. Apply the formula to determine Adjusted Function Points (AFP).
o Advantages:
 Language and technology-independent.
 Reflects user functionality rather than the implementation specifics.
 Useful for projects with evolving requirements.
o Disadvantages:
 Requires historical data for accurate estimation.
 Estimates can be imprecise, leading to potential deviations between
estimated and actual effort.
3. Constructive Cost Model (COCOMO)
o Definition: A widely-used empirical model that estimates software development
effort based on project characteristics.
o Procedure:
 Uses historical data and a set of cost drivers to predict the effort required.
o Advantages:
 Provides detailed cost estimates based on various project parameters.
 Has well-established calibration from past projects.
o Disadvantages:
 Requires accurate input data and calibration.
 Can be complex to apply and interpret.

Human-Based Technique

4. Delphi Technique
o Definition: A consensus-based technique that gathers estimates from a panel of
experts through iterative rounds of discussion and feedback.
o Procedure:
 Experts provide estimates and rationales anonymously.
 Feedback is shared, and estimates are refined in subsequent rounds.
o Advantages:
 Incorporates diverse expert opinions.
 Can account for complex, subjective factors.
o Disadvantages:
 Time-consuming and dependent on expert availability.
 Subject to biases and may require multiple iterations to reach consensus.

Summary

 SLOC is useful for straightforward, language-specific projects but may not capture the
full complexity of the project.
 Function Points provide a user-centered measure of software size and are applicable
across different technologies but require accurate historical data and can be imprecise.
 COCOMO offers a detailed empirical approach but can be complex and data-dependent.
  Delphi Technique leverages expert judgment and is useful for complex or uncertain
projects but can be time-consuming and subjective.

Measuring Effort for a Project

Estimating effort accurately is crucial for project management to ensure that project plans, costs,
and schedules are realistic. Here’s a breakdown of the different estimation techniques:

a) Source Lines of Code (SLOC) Technique

Overview:

 Definition: SLOC measures the size of a software project based on the number of source
lines of code.
 Measurement: Effort is expressed in terms of thousands of lines of code (KLOC).
 Application: Useful when the programming language and technology are known and
stable.

Steps:

1. Count Lines of Code: Calculate the number of lines of code in the software.
2. Estimate Effort: Use historical data or predefined constants to estimate the effort
required per KLOC.

Considerations:

 Inclusions: Only the code written by the development team is included; test drivers and
support software are excluded.
 Exclusions: Comments and code generated by applications are not counted.

Disadvantages:

 Language Dependency: Effort varies significantly across different programming

languages. For instance, a task might require more lines of code in assembly language
than in higher-level languages like Visual Basic.

b) Function Points (FP) Technique

Overview:

 Definition: FP measures the functionality provided by the software from the user’s
perspective.
 Application: Suitable for projects where requirements are well-defined and technology is
not a limiting factor.

Steps:
 1. Identify Unadjusted Function Points (UFP): Evaluate internal files, external interfaces,
user inputs, outputs, and inquiries.
2. Calculate General System Characteristics (GSC): Assess the complexity and
characteristics affecting the project.
3. Determine Value Adjustment Factor (VAF): Adjust UFP based on GSC ratings.
4. Compute Adjusted Function Points (AFP): Apply the formula AFP=UFP×VAFAFP =
UFP \times VAFAFP=UFP×VAF.

Advantages:

 Language and Technology Independent: Function points are not affected by the
programming language or technology used.
 Predictive Accuracy: Useful for projects with uncertain requirements or those
undergoing frequent changes.

Disadvantages:

 Data Dependence: Requires historical data and past project experience for accurate
estimation.
 Estimation Precision: FP may provide broad estimates and may not always be precise.

c) Constructive Cost Model (COCOMO)

Overview:

 Definition: COCOMO, developed by Dr. Barry Boehm, estimates effort based on lines
of code and cost driver attributes.
 Levels: Basic, Intermediate, and Advanced, with increasing complexity.

Basic COCOMO:

 Application: For rough estimates based on KLOC.

 Formula: E=a1×(KLOC)a2E = a_1 \times (KLOC)^{a_2}E=a1×(KLOC)a2
o Variables: a1a_1a1 and a2a_2a2 are constants depending on the project type
(Organic, Embedded, or Semidetached).

Intermediate COCOMO:

 Additional Step: Includes calculating the Effort Adjustment Factor (EAF) based on 15
cost driver attributes.
 Formula: E=EAF×EiE = EAF \times EiE=EAF×Ei

Advanced COCOMO:

 Enhancement: Applies cost driver attributes to each SDLC phase (e.g., analysis, design).
Applicability:

 Suitable For: Complex projects with extensive requirements and where the development
environment is unfamiliar or lacking baseline data.

d) Delphi Technique

Overview:

 Definition: A human-based estimation technique that involves multiple experts providing

estimates independently.
 Application: Useful when relying on human experience and judgment.

Steps:

1. Identify Participants: Involve estimation experts, a coordinator, and an author.

2. Project Details Presentation: The author presents project details and requirements to
experts.
3. Consensus on Variance: Agree on acceptable variance for estimates.
4. Task List Creation: Distribute tasks to experts for independent estimation.
5. Estimate Collection: Collect and summarize estimates.
6. Review Variances: Discuss tasks with high variance and revise estimates as needed.
7. Repeat: Reiterate steps until estimates stabilize within acceptable variance.

Advantages:

 Expert Insight: Combines expertise and collective judgment for more accurate
estimates.
 Flexibility: Adaptable to various types of projects and uncertainties.

Disadvantages:

 Time-Consuming: The process can be lengthy and may require multiple rounds of
estimation.
 Expert Dependence: Relies heavily on the experience and knowledge of the participants.

Lecture #32: Work Breakdown Structure (WBS)

7. Work Breakdown Structure

7.1 WBS Preview

i. Salient Features:

 The Work Breakdown Structure (WBS) is a technique to decompose a project into

smaller, more manageable components.
  It helps in organizing and managing work by breaking down large, complex projects into
smaller, defined "work packages" and tasks.
 A WBS provides a framework for defining project scope, organizing Gantt schedules,
and estimating costs.
 The WBS structure starts from the end objective and breaks it down into components,
tasks, subtasks, and work elements.
 It serves as a technical data-gathering structure to measure and analyze progress against a
formal baseline plan.
 The WBS is used throughout the project for managing, scheduling, and reporting on
project costs.

ii. WBS- What is it?

 The WBS is a deliverable-oriented grouping of project elements that organizes and

defines the total scope of the project.
 Each descending level represents an increasingly detailed definition of the project’s work.
 It is an outline of work, created by those performing the work, including all functional
stakeholders.

iii. WBS- What it Contains:

 Maps contractual obligations (Statement of Work - SOW) regarding deliverables.

 Details project objectives and performance (measurable) objectives.
 Includes built-in WBS and Project Plan review and update mechanisms.

iv. WBS- When is it Produced?

 The WBS is created after the scope statement and before the project schedule.
 It acts as a "bridging" document between the scope and schedule.

v. Uses of WBS:

 Defines 100% of the project scope and communicates it effectively to stakeholders.

 Clarifies boundaries, deliverables, and refines the project scope.
 The WBS is not a single document but a framework that complements the project plan,
schedule, and scope statement.

7.2 WBS - A Mandatory Management Tool

i. WBS as a Project Management Tool:

a. Manage Risk:

 Provides insight into technical aspects of project management, aiding in risk

management.
b. Manage Costs:

 Helps make management decisions related to costs and identifies tradeoffs if costs are too
high.

c. Assign Work:

 Useful for determining acquisition strategies and assigning tasks, helping in the creation
of statements of work.

d. Schedule and Track Activities:

 Defines tasks across project categories (software development, installation, maintenance,

etc.) and tracks their completion.

e. Align with Terms of Reference and Scope:

 Ensures all work aligns with the WBS and helps monitor progress, identify new tasks,
and revise estimates.

f. Report Expense:

 Acts as a budgetary tool for planning and monitoring expenditure. It integrates with
computerized utilities for scheduling and monitoring tasks.

Summary: The Work Breakdown Structure is essential for breaking down and managing large
projects by dividing them into smaller, more manageable components. It provides a framework
for organizing tasks, managing costs, scheduling activities, and aligning work with the project’s
scope and objectives. The WBS is a vital tool for effective project management throughout the
project lifecycle.

Lecture #33: Work Breakdown Structure (WBS)

7.3 WBS - A Mandatory Management Tool

i. The WBS as a Project Management Tool

g) Mapping WBS for Cost Management

 Cost Accounts:
o In a product-oriented WBS, functional categories of work are grouped into "cost
accounts" within WBS elements.
o Each cost account is managed by a cost account manager responsible for its
functional area's contribution.
o Cost accounts from various departments or functions may merge into a single
WBS element.
  Work Packages:
o Internal planning for a cost account is done through individual work packages.
o Each work package has its own budget and schedule.
o Work packages should be small enough to be handled by individuals or small
groups and completed in a short duration. For example, a small project might set a
maximum work package size of two weeks, while larger projects may have bigger
work packages.
 WBS Implementation:
o The project manager decides how detailed the WBS should be based on the
project's size and complexity.
o For small projects, a formal WBS may not be necessary, but as projects grow in
size or complexity, a detailed WBS becomes more valuable.
o As project management environments mature, the WBS can evolve from simple
task lists to complex, time-phased activity lists, task lists organized by
deliverables, or an end-product-focused WBS integrated with cost accounts and
work packages.
 Software Tools:
o When using project management software like MS-Project, the WBS is often
displayed as a vertical list with indents to show hierarchy. This format is
compatible with Gantt chart data entry.
o Some software provides a separate WBS view. Alternatively, you can create a
WBS in a word processor and then import it into your project management
software.

Word of Caution:

 The WBS must be continuously updated to remain useful.

 It should be revised periodically alongside the project development plan and schedule.
 Expect tasks in the WBS to be added, modified, or removed as the project progresses.

Lecture #34: Work Breakdown Structure (WBS)

7.4 WBS - A Mandatory Management Tool

h) Characteristics of a High-Quality WBS

1. Review and Signoff from Top to Bottom:

o Ensures that all levels of the WBS are reviewed and approved by relevant
stakeholders.
2. Logical Flow and Hierarchical Nature:
o The WBS should be structured logically and presented in a hierarchical format.
3. Clear and Concise:
o Each element in the WBS should be defined clearly and concisely.
4. Ability to Roll-up Information:
o Information can be aggregated from lower levels to higher levels, aiding in
project management and reporting.
 5. 100% Team Buy-in:
o The entire project team should agree and commit to the WBS.
6. At Least Two Levels:
o Level 1 defines 100% of the service/product/result.
o Level 2 defines the deliverables in terms of work groupings.
7. Project Management at Level 2:
o Level 2 should include project management and sub-contract management.
8. Matching Deliverables and Scope:
o The deliverables in the WBS must align with the project scope or contract.
9. Accounting for All Deliverables:
o Every deliverable should be included in the WBS, regardless of who is
responsible for it.
10. Clear Definition of WBS Elements:
o Each element should be clearly defined or clarified in the WBS Dictionary.
11. Key Features:
o Contains 100% of the work defined by the scope or contract.
o Developed with input from the entire project team.
o Deliverable-oriented.
o Captures all deliverables (internal, external, interim) in terms of work to be
completed.
12. Usefulness:
o Defines the project's context and clarifies the work to be completed.
o Communicates project scope to all stakeholders.
o Aligns with the scope statement and project schedule.
o Allows for continual improvement and updating to maintain relevance throughout
the project.
13. What WBS Is Not:
o Not a single document that substitutes for the project schedule or project plan.
o Not the project schedule.
o Not merely a listing of tasks or activities.

i) Types of WBS

1. Program Work Breakdown Structures:

o Covers the acquisition of a specific defense materiel item and is related to
contractual effort.
o Tailored to each specific program.
o Prepared and maintained by the Government.
o Provides a basis for developing the Contract WBS.
o Typically consists of the upper three levels.
 WBS Levels:
 Level 1: The entire defense materiel item.
 Level 2: Major elements of the defense materiel item.
 Level 3: Elements subordinate to Level 2 elements.
2. Contract Work Breakdown Structures:
 o Extends the Program WBS to a lower level to provide management and cost
information to the Government.
o Includes all elements for products (hardware, software, data, services) that are the
contractor's responsibility.
o Consistent with the Program WBS.
o Can be extended by contractors to the necessary level for managing the program.
o Used to define work packages, which are discrete portions of the project
chargeable to a single organization.
o Updated if changes are made to the Program WBS.

j) Sample WBS

1. Design and Engineering

2. Project Management
3. Documentation
4. Training & BPR
5. Software System
o Software Project
o Web-based Classroom
o Hands-on Training
o Considerations:
 Requirements
 Prototyping
 Testing
 User Acceptance
 Life-cycle Management
 Warranty
o Examples:
 Product WBS:
 Hardware (1.1)
 Software (1.2)
 System Engineering (1.3)
 Project Management (1.4)
 System Test (1.5)
 Data Management (1.6)
 System Development Projects:
 Hierarchical structure with multiple levels indicating different
aspects of the project.

Reading References

For detailed reading, refer to:

1. Chapter 6, "How to Handle Large Projects: Divide and Conquer" from "Software Project
Management – A Practitioner Approach" by E. M. Bennatan.
 2. Chapter 5, "Software Project Planning" from "SE – A Practitioner Approach" by Roger S.
Pressman.
3. Chapter 7, "Software Project Estimation: Tools and Techniques" by NIIT.

Lecture #34: Work Breakdown Structure (WBS)

Integration of WBS, Schedule, and Budget

The primary objective of the Work Breakdown Structure (WBS) is to integrate the WBS,
schedule, and budget into a cohesive written plan. The WBS reflects activities associated with
overall project management, requirements, design, implementation, transition management,
testing, training, installation, and maintenance.

Responsibilities of the Project Manager

 Defining Top-Level Tasks: The project manager is responsible for defining all top-level
tasks associated with a project.
 Decomposing Tasks: These tasks are further decomposed as planning continues,
ensuring a comprehensive breakdown of all project activities.

Presentation of Activities List

An activities list, or WBS, can be shown in two primary ways:

1. Outline Format:
2. Graphical Format:

Sample WBS - Outline Example 1

1.0 MANAGEMENT

1.1 Plan Project

 1.1.1 Develop Project Plan

 1.1.2 Update Project Plan

1.2 Track Project

 1.2.1 Prepare status reports

 1.2.2 Collect/analyze project metrics

1.3 Perform Quality Activities

 1.3.1 Prepare QA Plan

 1.3.2 Conduct Reviews
 1.3.3 Conduct Audits
1.4 Perform Configuration Management

 1.4.1 Prepare CM Plan

 1.4.2 Develop Project Library
 1.4.3 Manage Change Board
 1.4.4 Maintain Configuration Items

2.0 DESIGN

2.1 Prepare Preliminary Design

 2.1.1 Develop Enterprise Architecture

 2.1.2 Prepare Data Flow Diagrams
 2.1.3 Prepare Logical Data Model

2.2 Prepare Detailed Design

 2.2.1 Prepare Physical Data Model

 2.2.2 Prepare Data Dictionary

2.3 Document Design

 2.3.1 Develop Design Specification

2.4 Review Design

3.0 DEVELOPMENT/INTEGRATION

3.1 Develop Software

 3.1.1 Develop Server Application

 3.1.2 Develop User Interface
 3.1.3 Develop XYZ Interface

3.2 Procure Hardware

 3.2.1 Procure Server

 3.2.2 Procure Workstations

3.3 Procure Software Packages

 3.3.1 Procure Database

 3.3.2 Procure User Interface Building Tool
 3.3.3 Procure Operating System

3.4 Perform Integration Testing

3.5 Convert Data

 3.5.1 Develop Conversion Plan

3.6 Develop User Manual

3.7 Transition Management

4.0 ACCEPTANCE TESTING

4.1 Plan Acceptance Test

4.2 Conduct Acceptance Test

4.3 Develop Test Report

5.0 INSTALLATION

5.1 Develop Installation Plan

5.2 Site Preparation

5.3 Install at Locations

 5.3.1 Headquarters
 5.3.2 Site 1

6.0 MAINTENANCE

6.1 Hardware Maintenance

6.2 Software Maintenance

Sample WBS - Outline Example 2

0.0 Retail Web Site

1.0 Project Management

2.0 Requirements Gathering

3.0 Analysis & Design

4.0 Site Software Development

 4.1 HTML Design and Creation

  4.2 Backend Software
o 4.2.1 Database Implementation
o 4.2.2 Middleware Development
o 4.2.3 Security Subsystems
o 4.2.4 Catalog Engine
o 4.2.5 Transaction Processing
 4.3 Graphics and Interface
 4.4 Content Creation

5.0 Testing and Production

Sample WBS - Graphical Example

Key Considerations

 The WBS must be continually updated to reflect changes in the project scope, schedule,
and budget.
 It should clearly communicate the project scope to all stakeholders.
 The WBS should be in sync with the scope statement and project schedule, allowing for
continual improvement and updates.

Reading References

For detailed reading, refer to:

1. Chapter 6, "How to Handle Large Projects: Divide and Conquer" from "Software
Project Management – A Practitioner Approach" by E. M. Bennatan.
2. Chapter 5, "Software Project Planning" from "SE – A Practitioner Approach" by
Roger S. Pressman.
3. Chapter 7, "Software Project Estimation: Tools and Techniques" by NIIT.

Lecture #34: Work Breakdown Structure (WBS) - Major Steps

a) Project Decomposition

Project decomposition involves breaking down a complex project into simpler, more manageable
components. This step is crucial for estimating the work involved and monitoring the activities
of various development teams.

Key Points:

1. Complex to Simple: Just as complex chemical compounds are broken down into simpler
molecules and atoms, complex projects are divided into smaller components.
2. Method of Decomposition: The approach to decomposition depends on the project
manager's objective:
o Functional Decomposition: Focuses on the user's perspective.
 o Design Decomposition: Focuses on the project's programming components or
modules.

Iterative Process:

 Stepwise Refinement: Decomposition is refined in successive steps, providing more

detail each time.

Figures:

 Figure 1: Illustrates stepwise refinement, where each component is further divided into
lower-level components.

Types of Diagrams:

 Hierarchical System Chart: Shows the hierarchical relationship between components.

 Stepwise Refinement Diagram: A higher-level component is a name given to a group of
real components below it.

Controlled Access System Example:

 Figure 2(a): Decomposition of high-level components into low-level components.

 Figure 2(b): Hierarchical structure chart.

Stepwise Refinement Benefits:

 Facilitates easier management of large, complex tasks by dividing them into smaller,
manageable units.

WBS and Statement of Work (SOW):

 The WBS list of project tasks is derived from the SOW, defining the scope of the project.

b) Functional Decomposition

Functional decomposition divides the system into operational components from the user's
perspective, typically occurring during the requirements phase.

Example: Automatic Bank Teller System

 Functional Characteristics: Communication between remote tellers and the central

computer.
 Design Characteristics: Method of transmission and communication protocol.

Functional Decomposition Diagram:

  Figure 3: Shows the functional decomposition of an automatic bank teller system.

Functional Decomposition Benefits:

 Provides a starting point for the initial design of the system.

 Often precedes design decomposition.

c) Design Decomposition

Design decomposition divides the system into lower-level components corresponding to actual
software components.

Design Decomposition Components:

 High-Level Components: Group lower-level components.

 Low-Level Modules: Actual software components implemented.

Automatic Bank Teller System Example:

 Figure 4: Design decomposition diagram.

 Figure 5: Stepwise refinement technique.

Developing Project Tasks:

 WBS tasks are derived by asking, "What tasks need to be done to accomplish the project
objective?"
 The WBS structure reflects the project manager's preferences and judgment.
 As WBS levels become lower, the scope, complexity, and cost of each subtask decrease.
 Lowest level tasks, or work packages, are independent and manageable units planned,
budgeted, scheduled, and controlled individually.

WBS Evolution:

 The WBS evolves over the course of planning, and its structure may change as
scheduling, estimation, and resource allocation portions of the plan are completed.

IT Projects:

 Small projects may have a single development phase.

 Large or complex projects often have multiple development phases to meet different
functional requirements and reduce risks.

Conclusion

The WBS is an essential tool for project management, providing a structured approach to
breaking down a project into manageable components. This process involves project
decomposition, functional decomposition, and design decomposition, each serving a specific
purpose in the project lifecycle. By using stepwise refinement, project managers can gradually
provide more detail, making it easier to manage and understand the project.

ork Breakdown Structure (WBS) - Major Steps

e) Define Project Development Phases

For large systems, early decomposition into smaller components is crucial. Understanding the
rationale for decomposition ensures consistent results. Different reasons for decomposition can
yield different outcomes:

 User Needs: A phase might cross multiple functional areas.

 Risk Reduction: Phases might represent the completion of entire functional areas.

Phases are often handled as top-level WBS elements, with associated tasks defined for each
phase.

f) Define Task Relationships

The WBS should reflect the project's phases, denoting a hierarchy of task relationships:

 Subtask Completion: Rolls up into task completion, leading to project completion.

 Horizontal Dependencies: Note relationships between tasks that are not within the
outlined hierarchy to minimize dependencies and optimize task structuring.

The project scope is an iterative process done by the project team using the WBS to capture and
decompose all work. A WBS organizes and defines the total project scope; work not in the WBS
is outside the project scope. Each level represents increasingly detailed project deliverables.

g) Defining Deliverables

Deliverables are shown in the WBS and reflected in the Project Plan's Deliverables section. A
sample template lists all deliverables, their due dates, responsible personnel, and the actual
delivery dates. This comparison helps measure how well the project team meets deadlines.

Tracking deliverables separately helps keep the project on track and serves as a communication
tool with stakeholders and the project team.

Deliverables Template Example:

Product Name Due Date Date Delivered Author/POC

Requirement Specification 4/1/96 4/1/96 ABC
Design Specification 8/1/96 XYZ
Test Plan 8/1/96 DEF
 Product Name Due Date Date Delivered Author/POC
Implementation Plan 11/1/96 ...
Source Code 12/1/96 ...
Test Report 1/30/97 ...

h) Creating a Work Breakdown Structure

A project, like a large system, consists of multiple independent tasks. Each task can be
subdivided into subtasks, known as work packages. Creating a WBS involves:

1. Brainstorming Broad Tasks: Organize a meeting with senior managers, system

analysts, and prospective developers to brainstorm and list broad tasks.
2. Refining Broad Tasks: Assess feasibility, eliminate conflicts, and arrange tasks
logically.
3. Categorizing Tasks into Logical Headers: Group related tasks under appropriate
headers.

Example: XYZ Inc. Brainstorming Session

In a session to divide tasks for the analysis phase, project managers and analysts list tasks based
on prior experience and client requirements:

 Determine project scope

 Draft software specifications
 Secure project resources
 Prepare initial project budget
 Estimate project timeline

Assign personnel responsible for each task and arrange subtasks in execution order.

Figure 6: Analysis Phase Subtasks

1. Prepare questionnaire
2. Arrange client meeting or document feedback
3. Begin SRS document preparation (after preceding tasks are complete)

These steps ensure that each subtask is organized and executed in a logical sequence, facilitating
smooth project progression.

Work Breakdown Structure (WBS) Implementation

i. Implementation Strategy
When setting up a project WBS, consider how it will be used throughout the project. Early
planning should address WBS organization, schedule format, manager assignments, and charge
numbers. Mapping charge numbers, managers, and task groups can help track costs and progress.

 Use of MS-Project: If using MS-Project, insert "text" columns for project charge
numbers and manager names.
 Grouping Items: Follow your project's specific environment conventions for grouping
WBS items.
 WBS Design Goals:
o Align with work execution and cost/schedule management.
o Highlight important or risky work efforts.
o Map requirements, plans, testing, and deliverables.
o Clarify ownership by managers and task leaders.
o Provide performance measurement and historical data.
o Be understandable to workers and accountants.

There are multiple ways to design a WBS for a project. Ensure discussions are concise and reach
closure efficiently.

ii. Methodology

 Mapping Activities to Lifecycle: Each lifecycle has different sets of activities.

o Planning, configuration, and testing are integral processes.
o Operations and maintenance phases are typically post-project.
o Spiral and other iterative models might be “straightened” for WBS.
o Deliverables of tasks vary by methodology.

Guidelines for Decomposition of Work Tasks

i. General Guidelines

 Understandability: WBS should be easy to understand, possibly adhering to corporate

standards.
 Accuracy: Break down tasks until accurate time and cost estimates are possible. Ensure
each element corresponds to a deliverable.
 Detail Level: Not as detailed as the final MS-Project plan. Each level should have no
more than 7 items. It can evolve over time.
 Tools: Use tools like Excel, Word, Project, or specialized apps. Templates can be reused
if available.
 Standardization: Many organizations have standard or semi-standard WBS templates.
 Verification: Ensure decomposition correctness and that tasks are clearly defined and
can be scheduled and budgeted.
 Inclusion: WBS includes management, procurement, installation, and software
development activities.

ii. High-Level WBS Tasks

A typical high-level WBS task list includes:

 Software Development:
o Requirements analysis
o Prototype development (specification, design, implementation)
o Design (top-level, detailed)
o Implementation (coding, unit test)
o Integration (software, hardware/software)
o Testing (alpha, beta, acceptance)
o Installation/Maintenance (error correction, software enhancement)
 Management:
o Planning
o Staffing
o Budget administration
o Quality assurance
o Configuration management
 Training/Procurement:
o Acquisition of development tools and system components
o Equipment selection
o Vendor selection
 Documentation:
o Technical writing
o Development documentation (deliverable and non-deliverable)
o Maintenance/User documentation

iii. Management and Administration Tasks

 Mandatory Management Tasks:

o Planning
o Estimates preparation
o Risk analysis and management
o Scheduling
o Personnel management
o Task assignment and delegation of authority
o Assignment of development resources
o Quality assurance and control
o Configuration management and control
o Reporting
 Non-Mandatory Tasks: (depending on project specifics)
o Budget analysis and administration
o Customer interface and coordination

Ensure all team members are assigned WBS tasks. Follow a rule: if the task is not on WBS,
it is not worked on.

Remember:
  Projects are dynamic; maintain WBS flexibility.
 Functional decomposition should consider design for the next development phase.
 Good modular design leads to small, simple, independent modules.

8. Scheduling

8.1 Understanding Schedule

i. Salient Features:

Fred Brooks, in "The Mythical-Man-Month" [BRO95], succinctly explained how software

projects fall behind: "One day at a time." This highlights the importance of daily vigilance in
project management.

A technical project, whether building a hydroelectric plant or developing an operating system,

comprises hundreds of small tasks. Some tasks are non-critical and do not impact the project
completion date, while others lie on the "critical" path. Delay in critical tasks jeopardizes the
entire project's timeline.

The project manager's goal is to:

 Define all project tasks

 Build a network showing task interdependencies
 Identify critical tasks
 Track progress daily to recognize delays promptly

A well-defined schedule at a detailed level enables effective monitoring and control of the
project. Software project scheduling allocates estimated effort across the planned project
duration to specific tasks.

During early project planning, a macroscopic schedule is developed, identifying major activities
and associated product functions. As the project progresses, this schedule is refined into a
detailed schedule with specific tasks and timelines.

Software project scheduling can be viewed from two perspectives:

1. Fixed End-Date: An end-date is established, and effort is distributed within the

prescribed timeframe.
2. Flexible End-Date: Rough chronological bounds are discussed, and the end-date is set
after careful analysis.

The first situation, where an end-date is fixed, is more common.

As a project manager, you need to:

 Assign durations to all activities

  Monitor progress
 Plan activity order, start, and end dates
 Create a project schedule

This includes scheduling development activities and project resources, particularly people. Tools
like Gantt charts and network-scheduling techniques aid in this process. A schedule is only
effective if adhered to and updated as circumstances change.

ii. Need for Project Scheduling:

Software projects can easily spiral out of control due to the multitude of activities requiring
monitoring, tracking, and control. When a project loses control, it impacts deadlines, budget, and
effort, affecting both the product and the team's credibility.

iii. What Delays Software Projects:

Reasons for project delays include:

 Incorrect initial effort and resource estimates

 Changing customer requirements without schedule adjustments
 Unmitigated known risks
 Unforeseen technical difficulties
 Human difficulties, such as interpersonal issues
 Management's failure to recognize delays and take corrective action
 Unrealistic initial deadlines

Aggressive deadlines, often set externally, are a fact of life in software projects. While
sometimes legitimate, these deadlines must be realistic for the team to meet them effectively.

iv. How to Prevent Delays:

To prevent delays:

 Study past projects for similar situations and use historical data for current estimates
 Use an incremental process model to create a realistic schedule
 Present schedules and projected delays to clients, explaining the reasons
 Use incremental models to deliver modules as they are completed

Balancing limited resources and client commitments requires creating realistic schedules based
on past projects or incremental models.

8.2 Scheduling Fundamentals

i. Scheduling Basics:
A small percentage of activities impact the project's on-time completion. Identifying and
ensuring the availability of inputs for these critical activities is crucial. The goal is to determine
the project's duration and phases, distributing the estimated effort accordingly.

To create a project schedule:

1. Group similar activities

2. Determine activity dependencies
3. Allocate time and resources
4. Define roles, responsibilities, outputs, and validation criteria

a) Classification: Grouping similar tasks using tools like Work Breakdown Structure (WBS) and
decomposition technique helps in successfully managing a software project. This allows you to
divide the project into phases and activities, organizing the schedule accordingly.

b) Interdependence: Activities within a project are linked, with some needing to be completed
before others can start. As a project manager, you must determine and manage these
interdependencies.

c) Time and Effort Allocation: Assign start and end dates to activities and allocate appropriate
effort, managing within time and effort constraints to ensure project success.

d) Validation Criteria: Set validation criteria to ensure optimal resource allocation. For
example, avoid over-allocating resources to an activity requiring less effort.

e) Defined Responsibilities and Outputs: Assign roles and responsibilities, defining the
hierarchy within the team and linking roles to expected results. This helps track individual efforts
and activity progress.

Creating a well-structured and detailed schedule is essential for managing a software project
effectively, ensuring timely completion and resource optimization.

.3 Scheduling Tools

i. Gantt Charts

Introduction:

A Gantt chart is a widely used tool in project management that visually represents the timeline of
project activities. Named after Henry L. Gantt, who developed it, this chart provides a
straightforward and effective way to schedule and track project tasks.

Structure of a Gantt Chart:

 Horizontal Axis (Time): Represents the project timeline.

 Vertical Axis (Activities): Lists all the project activities.
  Horizontal Bars: Represent the duration of each activity. The position of a bar indicates
the start and end times, while the length of the bar shows the duration of the activity.

Example:

In a Gantt chart, you might see something like this:

 Activity D: Starts on day 1 and is planned to last 20 days. The lighter shaded bar
represents the planned duration, and the darker shaded bar shows the current status. If the
current status is 19 days, the activity is one day short of completion.
 Activity C: Planned for completion by day 40 but shows a smaller length in the chart,
indicating it is behind schedule.

Usage:

A Gantt chart allows you to easily see which activities should be ongoing at any given time. It
helps in comparing planned versus actual progress, identifying delays, and managing project
timelines.

Example Table:

Table 1 might display the following activities and their start and end times:

Activity Start Date End Date

A Day 1 Day 10
B Day 5 Day 15
C Day 12 Day 30
D Day 1 Day 20

From this table, you can create a Gantt chart that visually represents these activities. The chart
helps track progress and ensures that tasks are completed on schedule.

Advantages of Gantt Charts:

 Clarity: Provides a clear visual representation of the project timeline and task durations.
 Tracking Progress: Easily shows whether tasks are on schedule, ahead, or behind.
 Resource Allocation: Helps in managing resources and scheduling tasks efficiently.
 Communication: Facilitates better communication among team members by providing a
common reference point.

Figure 1: Sample Gantt Chart

The sample Gantt chart would illustrate the duration and progress of activities, with planned and
actual durations indicated through color shading. This visual representation aids in quickly
assessing the status of the project and identifying any deviations from the plan.
In summary, Gantt charts are a valuable tool for project scheduling, offering a visual and
intuitive way to manage and track project activities.

4o mini

8.3 Scheduling Tools (Continued)

Gantt Charts (Continued)

Understanding the Status Line:

In a Gantt chart, a status line helps track the progress of the project on a specific day. Here’s how
it works:

 Left of the Line: Indicates completed tasks.

 On the Line: Shows ongoing activities.
 Right of the Line: Displays future tasks.

You can extend the bars weekly to reflect the work completed, providing an updated status of the
project at any given time.

Automated Tools:

While manual creation of Gantt charts was common in the past, modern software tools have
automated this process. For example, Microsoft® ProjectTM 2000 allows for automatic creation
and updating of Gantt charts, making it easier to manage project schedules.

Detailed Gantt Charts:

Figure 3 demonstrates a more detailed Gantt chart with high-level activities and significant
milestones such as:

 SRR: Software Requirements Review

 POR: Preliminary Design Review
 COR: Critical Design Review
 TRR: Test Readiness Review
 ATP: Acceptance Test Procedure

In Figure 3, you can see overlapping phases and high-level activities, giving a clear picture of the
project timeline. For more granularity, detailed Gantt charts can include the names of engineers
and equipment needed, although this might clutter the chart.

Levels of Detail:
As the project evolves, Gantt charts can become more detailed. For example, Figure 4 breaks
down high-level activities into specific tasks. This detailed chart provides continuity between
various levels of the project, ensuring that specific tasks align with overall project phases.

Limitations:

Gantt charts do not provide details on resource allocation or dependencies between tasks. For
instance, if an activity like integration requires varying numbers of engineers over time, this
might not be accurately reflected in a basic Gantt chart.

Network Scheduling Techniques

To complement Gantt charts, network scheduling techniques like PERT (Program Evaluation
and Review Technique) and CPM (Critical Path Method) are used to plan and analyze project
activities.

Common Components:

1. Activities: Basic tasks that consume time and resources. Each activity is represented with
an arrow in network schedules.
2. Nodes: Points in the network schedule where activities begin or end. Tail nodes mark the
start, and head nodes mark the end.
3. Network: A graphical representation showing all activities and nodes in a project.
4. Critical Path: The longest path through the network, representing the maximum duration
of the project. Activities on this path are crucial, as delays in these activities will directly
delay the entire project.

Network Schedule Rules:

1. Preceding and Succeeding Nodes: Each activity must have a preceding and succeeding
node.
2. Distinct Node Numbers: Nodes should be numbered such that the head node has a
higher number than the tail node.
3. No Loops: The network schedule should not contain loops.
4. Unique Events: Each activity must have unique preceding and succeeding events.

Example Figures

1. Figure 2: Illustrates a Gantt chart with a status line indicating progress.

2. Figure 3: High-level Gantt chart with major milestones.
3. Figure 4: Detailed Gantt chart showing breakdowns of high-level activities.
4. Figure 5: Activity with expected duration.
5. Figure 6: Activity connecting two nodes.
6. Figure 7: Sample network schedule.
7. Figure 8: Network schedule with the critical path identified.
8. Figure 9: Example of a network loop (not permitted).
 9. Figure 10: Example of activities with common preceding and succeeding events (not
allowed).

Gantt Charts and Network Scheduling Techniques

Gantt Charts

A Gantt chart is a visual tool used for project management, providing a timeline view of a
project. The chart displays the status of tasks at a specific point in time, with the following key
elements:

 Completed Tasks: Represented on the left side of the status line.

 Ongoing Tasks: Cross the status line.
 Future Tasks: Lie to the right of the status line.

To update a Gantt chart, extend the bars weekly to reflect the proportion of work completed.
Modern software, like Microsoft® ProjectTM 2000, can automate this process.

Example Symbols in Gantt Charts:

 Inverted triangle: Indicates major milestones such as software requirements review

(SRR), preliminary design review (PDR), critical design review (CDR), test readiness
review (TRR), and acceptance test procedure (ATP).

High-Level Gantt Chart:

 Demonstrates phase overlaps and key milestones.

 Typically includes a limited number of activities for clarity.

Detailed Gantt Chart:

 Breaks down high-level activities into lower-level tasks.

 Can include details such as assigned engineers and required equipment, though too much
detail may clutter the chart.

Network Scheduling Techniques

Network scheduling techniques, like PERT (Program Evaluation and Review Technique) and
CPM (Critical Path Method), trace the completion of predetermined activities in a project. These
techniques offer a way to analyze individual activities and their dependencies.

Common Components of PERT and CPM:

 1. Activities: Basic building blocks of a network schedule, consuming resources like time
and money.
2. Nodes: Points in time where activities begin or end.
3. Network: Graphic representation of all activities and nodes.
4. Critical Path: Longest path through the network, determining the project's maximum
duration.

Rules for Creating a Network Schedule

1. Each activity must have a preceding and a succeeding node.

2. Nodes must have distinct numbers, with the head node's number greater than the tail
node's.
3. Network schedules cannot have loops.
4. Each activity must have a unique preceding and succeeding event.

Example Network Components:

 Activity: Represented by an arrow with its duration below it (e.g., "A, 15 Days").
 Nodes: Represented by circles, indicating start and end points.
 Critical Path: Depicted by a double line, representing the sequence of activities that
determine the project's duration.

Key Takeaways

 Gantt Charts provide a timeline view and are useful for quick schedule information.
 Network Scheduling Techniques offer a detailed analysis of activities and their
dependencies.
 Following the basic rules ensures the accuracy and effectiveness of network schedules.

These tools and techniques are essential for effective project management, helping to plan,
schedule, and monitor project activities efficiently.

Introduction to Dummy Activities in Network Schedules

Dummy activities are used in network schedules to represent dependencies between parallel
activities. They are imaginary tasks that have no duration or description but help in organizing
the network schedule by showing relationships. For instance, in Figure 11, activities A and B are
parallel and need to be completed before starting activity C. A dummy activity, shown as a
dashed arrow, is introduced to represent this dependency.

css
Copy code
B
|
A | C
1---2---3
PERT: Program Evaluation and Review Technique

PERT was developed in 1957 for the Polaris Fleet Ballistic Missile project by the US
government. It is a probabilistic technique used for projects with uncertainty, such as complex
software projects.

Time Estimates in PERT

PERT uses three time estimates to account for uncertainty:

 Optimistic Time (T0): The shortest time an activity can take if everything goes well.
 Pessimistic Time (Tp): The longest time an activity can take if everything goes wrong.
 Most Likely Time (Tm): The most realistic estimate of the time required.

The expected time (Te) for an activity is calculated using the formula: Te=T0+4Tm+Tp6T_e =
\frac{T_0 + 4T_m + T_p}{6}Te=6T0+4Tm+Tp

Example Calculation

For the activity "Requirement analysis and project planning":

 Optimistic time (T0) = 7 days

 Most likely time (Tm) = 10 days
 Pessimistic time (Tp) = 13 days

The expected time (Te) is: Te=7+4(10)+136=606=10 daysT_e = \frac{7 + 4(10) + 13}{6} =
\frac{60}{6} = 10 \text{ days}Te=67+4(10)+13=660=10 days

Table of Estimated Times

Optimistic Most Likely Pessimistic Expected Time

Tasks
Time (days) Time (days) Time (days) (Te) (days)
Requirement analysis and
7 10 13 10
project planning
Setting up the
3 6 9 6
environment
Software construction 48 83 100 79
Unit testing 20 28 33 28
User training 4 5 6 5
System testing 10 15 20 15
User documentation 23 28 45 31
Data migration 18 18 30 21
Conducting user
14 21 22 20
acceptance test
PERT Network Schedule

A PERT network schedule is created using the expected times for activities. It visually represents
the sequence of activities and their dependencies. Figure 12 shows a PERT network schedule for
the activities listed in the table.

Enhancements and Tools for PERT

Enhanced versions of PERT charts include additional features like:

 Personnel Assignment: Assigning team members to activities.

 Resource Allocation: Ensuring resources are available when needed.
 Cost Analysis: Estimating costs based on various factors.

Flow Graph Representation

Developed by Riggs and Jones (1990), flow graph representation extends PERT by incorporating
life cycle cost analysis. It includes detailed information about quantities, unit costs, time
variables, staffing costs, and learning curves.

Computerized PERT Utilities

Modern software tools simplify the creation and management of PERT charts. They help with:

 Preparing and updating PERT charts.

 Analyzing planning activities.
 Simulating "what if" scenarios.
 Allocating resources efficiently.

These tools save time and reduce the manual effort required to maintain PERT charts, allowing
project managers to focus more on managing the project actively.

Lecture #39: Risk and Change Management

9.1 Introduction to Risk

 Definition: Risk is the possibility of loss, the inability to achieve program objectives
within defined cost, schedule, and technical constraints.
 Types of Risks:
o Development Process Risks: Developer errors, natural disasters, disgruntled
employees, poor management objectives.
o Product-Related Risks: Incomplete requirements, unclear project deliverables
and objectives, complexity of the product.

Risk Management Process

  Steps:
1. Risk Identification: Identifying risks through discussions with team members
about requirements, technology, resources, and project-related factors.
2. Risk Analysis: Assessing the probability of risk occurrence and its potential
impact.
3. Risk Mitigation: Developing a plan to manage risks with high probability and
impact.
 Key Concepts:
o Contingency Planning: Developing alternative plans if the original plan fails.
o Risk Mitigation Monitoring and Management (RMMM) Plan: A plan that
outlines the approach to managing identified risks.

9.2 Risk Management Concepts

 Importance of Planning: Similar to insuring valuables, planning for uncertainties in a

project can minimize losses.
 Conceptual Definition by Robert Charette:
o Risk concerns future happenings.
o Risk involves change.
o Risk involves choice and the uncertainty it entails.

Types of Risks

 Development Process Risks: Issues arising from the development process itself,
including:
o Developer Errors: Poor training, inadequate skills, ergonomic problems.
o Natural Disasters: Floods, cyclones, fire, storms.
o Disgruntled Employees: Unauthorized access, sabotage.
o Poor Management Objectives: Ambiguous objectives, lack of contingency
plans, incomplete cost estimates.
 Product Risks: Issues related to the product being developed, such as:
o Changing Requirements: Incomplete or unclear requirements, problems meeting
design specifications.
o Technical Issues: Issues with technical data, size, and complexity of the product.

Risk Management Process

 Steps:
1. Risk Identification: Gathering information about potential risks and creating a
risk log.
2. Risk Analysis: Quantifying the level of uncertainty and degree of loss.
3. Risk Mitigation: Avoiding, monitoring, and planning for risks.
 Risk Identification Techniques:
o Brainstorming: Team discussions about requirements, technology, manpower,
and environment.
 o Risk Identification Questionnaire: A tool to identify and categorize potential
risks.
 Risk Analysis Techniques:
o Risk Probability and Impact: Assigning probability values (0-1) and impact
values (1-10) to each risk.
o Risk Factor Calculation: Multiplying probability by impact to prioritize risks.
 Risk Mitigation Strategies:
o Risk Avoidance: Preparing a risk management plan before the project begins.
o Risk Monitoring: Monitoring the top 20% of identified risks and mitigation
steps.
o Contingency Planning: Developing alternative plans for when mitigation efforts
fail.

Managing Risks: Case Study

 Scenario: A software development project for a bus transport company, involving a new
platform and a large volume of data.
 Challenges:
o New platform for the team.
o Large volume of data management.
o Need for intensive training for the project team.
 Risk Management:
o Risk Identification: Identifying training needs and data management challenges.
o Risk Analysis: Assessing the impact of inadequate training and data
management.
o Risk Mitigation: Developing training programs and data management strategies.

Risk Management Plan for Schedule Adherence System

1. Introduction

This risk management plan outlines the strategies for managing potential risks associated with
the project aimed at building a schedule adherence system. The project has a high confidentiality
requirement and a performance target of less than fifteen seconds for all popular browsers. It is
anticipated that numerous requirement changes will occur during the development process, and
the system will be implemented across several states in the country. The project starts on May 15
and should be completed by November 15.

2. Potential Risks

Table 6.4 identifies potential risks involved in the project:

 Risk Factor
Risk Probability Impact Mitigation Start End
(Probability Responsibility
Description (0-1) (1-10) Steps Date Date
x Impact)
Conduct training
sessions before
Inexperienced Project May July
0.8 3 2.4 the
staff Manager 15 15
commencement
of the project
Massive tuning
of architecture
Performance during the
risk due to design phase May End of
0.6 7 4.2 Architect
high volume and conducting 15 project
of data proof of
concepts for the
design
Using the lowest
Cross-
compatible May End of
browser 0.6 5 3.0 Developer
browser for 15 project
compatibility
development
Ensuring all
details
pertaining to the
Involvement technology are
Project May End of
of new 0.5 5 2.5 available and
Manager 15 project
technology keeping in close
touch with the
technology
vendor
Designing a
flexible
Design architecture that
changes can May End of
0.6 8 4.8 Architect
during accommodate 15 project
development future changes
and
enhancements

3. Risk Analysis

Risks are analyzed by estimating their probability of occurrence and their impact on the project.
The risk factor is calculated by multiplying the probability by the impact. Risks with higher
values are prioritized and require close monitoring.

High Priority Risks

 1. Design changes during development: Risk Factor = 4.8
2. Performance risk due to high volume of data: Risk Factor = 4.2
3. Cross-browser compatibility: Risk Factor = 3.0

Medium Priority Risks

1. Inexperienced staff: Risk Factor = 2.4

2. Involvement of new technology: Risk Factor = 2.5

4. Mitigation Plan

4.1 Inexperienced Staff

 Probability: 0.8
 Impact: 3
 Risk Factor: 2.4
 Mitigation: Conduct training sessions for staff before the project commencement.
 Responsibility: Project Manager
 Timeline: May 15 - July 15

4.2 Performance Risk due to High Volume of Data

 Probability: 0.6
 Impact: 7
 Risk Factor: 4.2
 Mitigation: Massive tuning of the architecture during the design phase and conducting
proof of concepts for the design.
 Responsibility: Architect
 Timeline: May 15 - End of project

4.3 Cross-browser Compatibility

 Probability: 0.6
 Impact: 5
 Risk Factor: 3.0
 Mitigation: Using the lowest compatible browser for development.
 Responsibility: Developer
 Timeline: May 15 - End of project

4.4 Involvement of New Technology

 Probability: 0.5
 Impact: 5
 Risk Factor: 2.5
 Mitigation: Ensure all details pertaining to the technology are available and maintain
close communication with the technology vendor.
  Responsibility: Project Manager
 Timeline: May 15 - End of project

4.5 Design Changes During Development

 Probability: 0.6
 Impact: 8
 Risk Factor: 4.8
 Mitigation: Design a flexible architecture that can accommodate future changes and
enhancements.
 Responsibility: Architect
 Timeline: May 15 - End of project

5. Monitoring and Contingency Planning

High-priority risks need continuous monitoring. Contingency plans should be ready to address
issues if they arise. For instance, involvement of new technology, despite being a low-priority
risk, requires a contingency plan due to its relatively high probability.

Contingency Plan for New Technology

 Mitigation: Discuss with the vendor regarding a workaround for potential issues. Ensure
a backup plan is in place for system failures due to user load exceeding expectations.

6. Conclusion

This risk management plan provides a comprehensive strategy to identify, analyze, and mitigate
risks associated with the project. Continuous monitoring and proactive management of high-
priority risks will ensure the project remains on track and meets its objectives. Regular reviews
and updates of the RMMM plan will be conducted to adapt to any changes during the project
lifecycle.

Risk Management Process and Techniques

In software project management, understanding and managing risks are critical to the success of
a project. The following sections outline the key steps and concepts involved in the risk
management process.

1. Risk Identification and Prioritization

Risk Table Creation:

 Identify potential risks and list them in a table with columns for risk description,
probability of occurrence, and impact.
  Sort the table by probability and impact, with high-probability and high-impact risks at
the top.
 Draw a cutoff line to separate high-priority risks (above the line) from low-priority ones
(below the line).

Risk Evaluation:

 Re-evaluate risks below the cutoff line for second-order prioritization.

 Consider risks with high impact but very low probability as less concerning for
immediate management attention.

2. Risk Assessment

Risk Probability:

 Determine risk probability using individual estimates or more sophisticated techniques

(e.g., qualitative scales like impossible, improbable, probable, frequent).
 Associate mathematical probabilities with qualitative values for accurate risk estimation.

Risk Impact:

 Assess the consequences of each risk by considering its nature, scope, and timing.
 Calculate the risk exposure (RE) using the formula: RE=P×CRE = P \times CRE=P×C
where PPP is the probability of occurrence and CCC is the cost if the risk occurs.

3. Risk Refinement and Analysis

Condition-Transition-Consequence (CTC) Format:

 Refine risks into detailed sub-risks using the CTC format:

Given that <condition>, there is concern that (possibly) <consequence>.\text{Given that
<condition>, there is concern that (possibly)
<consequence>.}Given that <condition>, there is concern that (possibly) <consequence>.
 Break down general risks into specific sub-conditions to facilitate easier mitigation and
management.

4. Risk Mitigation, Monitoring, and Management (RMMM)

Risk Mitigation:

 Develop strategies to avoid or reduce risks. For example, addressing high staff turnover
through better working conditions, competitive compensation, and team organization.

Risk Monitoring:

 Continuously monitor risk factors and the effectiveness of mitigation steps.

  Assess whether risks are becoming more or less likely and ensure risk aversion steps are
being followed.

Risk Management:

 Implement contingency plans if risks materialize despite mitigation efforts.

 Use a proactive approach to manage the impact of risks and adjust project resources and
schedules accordingly.

5. Risk Assessment and Control

Risk Referent Level:

 Define risk referent levels for performance, cost, support, and schedule.
 Develop relationships between risk components and referent levels to predict project
termination points.

6. Safety Risks and Hazards

Post-Development Risks:

 Consider risks that may occur after software delivery, especially in safety-critical systems
(e.g., nuclear reactors, flight control).
 Conduct software safety and hazard analysis to identify and control potential hazards.

7. RMMM Plan

Documentation:

 Create a Risk Mitigation, Monitoring, and Management Plan to document all risk
analysis work.
 Alternatively, use Risk Information Sheets (RIS) to manage risks individually in a
database for easy analysis and tracking.

Continuous Improvement:

 Revisit the risk table regularly to update risk probabilities and impacts.
 Add new risks, remove irrelevant ones, and adjust the priority of existing risks.

Lecture Notes on Software Development Fundamentals:

Risk Management Process
Risk Management Process
The risk management process begins during the analysis phase of the software development life
cycle and continues throughout the product development phase. It is a dynamic process that deals
with activities that are yet to happen. The primary goals of risk management are to prevent risks
from occurring and to handle risks that do materialize. The process involves pre-empting risks,
planning for resolving them, and executing these plans.

Steps in the Risk Management Process

1. Risk Identification
2. Risk Analysis
3. Risk Mitigation

9.4 Risk Management Process

i. Risk Identification

Risk Identification involves:

 Identifying risks that may occur in a project.

 Determining which risks might affect the project.
 Documenting their characteristics.

Participants in risk identification can include:

 Project manager
 Project team leaders
 Project team
 Risk management team (if assigned)
 Subject matter experts (SMEs) from outside the project team
 Customers
 End users
 Other project managers
 Stakeholders
 Outside risk management experts

Risk Identification is an iterative process as new risks may become known as the project
progresses. The project team should be involved to develop a sense of ownership and
responsibility for risks and associated risk response actions.

The Risk Identification process usually leads to the Qualitative Risk Analysis process or directly
to the Quantitative Risk Analysis process when conducted by an experienced risk manager.
Sometimes, simply identifying a risk may suggest its response, which should be recorded for
further analysis and implementation in the Risk Response Planning process.

Steps in Risk Identification:

  Gather information about potential risks in the project.
 Plan strategies for avoiding or controlling risks.
 Conduct brainstorming sessions and discussions about the requirements document,
available technology, manpower, environment, and project-related factors.
 Create a risk log from these discussions.
 Hold meetings to discuss the risk log and mitigation plans.
 Use questionnaires and checklists for effective risk identification.

Risk Item Checklist:

1. Product Size: Risks associated with the size of the software.

2. Business Impact: Risks related to management or marketplace constraints.
3. Customer Characteristics: Risks related to customer sophistication and communication.
4. Process Definition: Risks related to the definition and adherence to the software process.
5. Development Environment: Risks related to the availability and quality of tools.
6. Technology to be Built: Risks related to the complexity and newness of the technology.
7. Staff Size and Experience: Risks related to the technical and project experience of the
team.

Sample Risk Identification Questionnaire

A. Risk Description

1. Are requirements changing continuously during product development?

2. Do the changing requirements affect quality, functionality, schedule, integration, design,
or testing?
3. Are the external interfaces changing?
4. Are requirements missing or incompletely specified?
5. Are there any missing requirements?
6. Can these requirements be incorporated into the system?
7. Does the client have unwritten requirements or expectations?
8. Is there a way to capture these requirements?
9. Are requirements unclear or in need of interpretation?
10. Are you able to understand the requirements as written?
11. Will the requirements lead to the product the client wants?
12. Are there any requirements that may not specify what the client really wants?

B. Product Design

1. Do you encounter problems in meeting functionality requirements?

2. Are there any specified algorithms that may not satisfy the requirements?
3. Will the design and/or implementation be difficult to achieve?
4. Are there any requirements or functions that are difficult to design?

C. Reusability
 1. Are you reusing the program?
2. Do you foresee any problems in documentation?
3. Do you foresee any problems in performance?
4. Do you foresee any problems in functionality?

Outcome of the Questionnaire:

The answers to these questions allow the project manager to estimate the impact of risks.
Comparing information from this table with past results helps estimate the criticality of risk. Risk
identification is a systematic attempt to specify threats to the project plan. By identifying known
and predictable risks, the project manager takes steps to avoid or control them.

There are two types of risks:

1. Generic Risks: Potential threats to every software project.

2. Product-Specific Risks: Identified by those with a clear understanding of the project's
specific technology, people, and environment.

During risk identification, answers to the following queries are obtained:

 Why is the risk important?

 What information is needed to track the status of the risk?
 Who is responsible for the risk management activity?
 What resources are needed to perform the activity?
 What is the detailed plan to improve or mitigate the risk?

Risk Analysis in Software Project Management

Understanding Risk Characteristics

Risk is characterized by two main factors: uncertainty and loss. Uncertainty refers to the
potential occurrence of an event, while loss measures the potential negative impact if the event
does occur. When analyzing risks, a project manager quantifies these factors to plan effectively
for schedules and costs. This process transforms risk information into actionable decision-
making data, allowing the project manager to focus on the most critical risks.

Risk Analysis Process

The process of risk analysis involves several key tasks:

1. Identify Risks: Define potential risks related to the product, process, organization, client,
or infrastructure.
2. Evaluate Risks: Assess the probability of occurrence and potential impact of each risk.
3. Quantify Risks: Use a scale from 0 to 1 for probability and 1 to 10 for impact to
calculate the risk factor (Probability x Impact).
 4. Prioritize Risks: Rank risks based on their calculated risk factors to determine which
require the most attention.

Risk Analysis Table

Risk Probability of Impact on Project Risk Factor (Probability x

Description Occurrence (0–1) (1–10) Impact)
Example Risk 0.4 5 2.0

Risk Mitigation Strategies

Mitigation involves strategies to avoid or reduce risks, which include:

1. Risk Avoidance: Develop a risk management plan before the project begins, identifying
and prioritizing risks, and preparing management plans.
2. Risk Monitoring: Continuously monitor top risks and mitigation steps, adjusting plans
based on real-time data.
3. Contingency Planning: Create alternative plans for the top risks, setting triggers to
activate these plans when necessary.

Risk Management Plan

A structured risk management plan includes:

 Identification: Recognize and assess potential risks.

 Estimation: Determine the probability and impact of each risk.
 Mitigation Steps: Develop strategies to reduce or avoid risks.
 Responsibility Assignment: Assign team members to manage specific risks.
 Timeline: Establish start and end dates for mitigation actions.

Example of a Risk Management Plan

Risk
Risk Probability Impact Mitigation Start End
Factor Responsibility
Description (0–1) (1–10) Steps Date Date
(PxI)
Inexperienced Conduct training Project May
0.8 3 2.4 July 15
Staff sessions Manager 15
Tune
Performance
architecture, May End of
risk due to high 0.6 7 4.2 Architect
conduct proof- 15 project
data load
of-concepts
Cross-browser Develop using May End of
0.6 5 3.0 Developer
compatibility lowest 15 project
 Risk
Risk Probability Impact Mitigation Start End
Factor Responsibility
Description (0–1) (1–10) Steps Date Date
(PxI)
compatible
browser
Ensure
availability of
Involvement of Project May End of
0.5 5 2.5 technology
new technology Manager 15 project
details, liaise
with vendor
Design changes
Design flexible May End of
during 0.6 8 4.8 Architect
architecture 15 project
development

Risk Components and Drivers

The U.S. Air Force's guidelines categorize risks into four components:

 Performance Risk: Uncertainty in meeting requirements.

 Cost Risk: Uncertainty in maintaining the budget.
 Support Risk: Uncertainty in ease of correction, adaptation, and enhancement.
 Schedule Risk: Uncertainty in maintaining the project timeline.

Impact Assessment

Components/Categor
Performance Support Cost Schedule
y
Major
Major delays/increased Unavoidabl
Catastrophic Mission failure financial
costs (> $500K) e delays
shortages
Significan
Significant Non- t financial Possible
Critical degradation/questionab responsive/unsupportab shortages schedule
le success le software (up to slippage
$500K)
Some
Recoverable Realistic
Degradation of financial
Marginal costs/schedule slips achievable
secondary mission resource
($1K to $100K) schedule
shortages
Possible Early
Inconvenience or non- Minor cost/schedule
Negligible budget achievable
operational impact impact (< $1K)
under run schedule

Developing a Risk Table

A risk table helps in risk projection and management. Here is an example:

Risks Category Probability Impact RMMM

Size estimate may be significantly low PS 60% 2 ...
Larger number of users than planned PS 30% 3 ...
Less reuse than planned PS 70% 2 ...
End-users resist system BU 40% 3 ...
Delivery deadline will be tightened BU 50% 2 ...
Funding will be lost CU 40% 1 ...
Customer will change requirements PS 80% 2 ...
Technology will not meet expectations TE 30% 1 ...
Lack of training on tools DE 80% 3 ...
Staff inexperienced ST 80% 2 ...
Staff turnover will be high ST 60% 2 ...

Using the above guidelines, project managers can systematically analyze, mitigate, and manage
risks to ensure successful project completion.

mpact Values:

 1: Catastrophic
 2: Critical
 3: Marginal
 4: Negligible

Steps for Risk Management:

1. List All Risks:

o Begin by listing all potential risks in the first column of the risk table.
o Use risk item checklists for a comprehensive risk list.
2. Categorize Risks:
o Assign a category to each risk (e.g., PS for project size risk, BU for business risk).
3. Estimate Probability of Occurrence:
o Team members individually estimate the probability of each risk.
o Use round-robin polling until the assessment converges.
4. Assess Impact:
o Assess each risk's impact on performance, support, cost, and schedule.
o Average these to determine an overall impact value.
5. Prioritize Risks:
o Sort the risk table by probability and impact.
o High-probability, high-impact risks should be prioritized.
6. Define Cutoff Line:
o Draw a horizontal cutoff line to focus on significant risks.
 o Re-evaluate risks below the line for second-order prioritization.

Risk Impact and Management Concern:

 High-impact but low-probability risks should not consume much management time.
 High-impact and high-probability risks require attention and should proceed to further
analysis.
 Low-impact and high-probability risks should also be carried forward.

Risk Mitigation, Monitoring, and Management (RMMM):

1. Proactive Risk Strategy:

o Identify potential risks early.
o Assess probability and impact.
o Rank risks by importance.
o Develop a risk management plan to avoid and handle risks.
2. Risk Mitigation:
o Develop strategies to reduce the likelihood and impact of risks.
o Example for high staff turnover:
 Determine causes and mitigate them.
 Assume turnover will happen and plan for continuity.
 Organize teams to ensure knowledge dispersion.
 Establish documentation standards and peer reviews.
3. Risk Monitoring:
o Monitor factors indicating risk likelihood (e.g., team attitude, interpersonal
relationships).
o Monitor the effectiveness of mitigation steps.
4. Risk Management and Contingency Planning:
o Assume mitigation efforts fail and prepare for risks becoming reality.
o Example for staff turnover:
 Ensure backups and documentation.
 Focus resources on fully staffed functions.
 Use departing staff for knowledge transfer.

RMMM Costs:

 Implementing RMMM steps incurs additional costs.

 Evaluate the cost-benefit of RMMM steps.
 Use the Pareto 80-20 rule: 80% of risk is from 20% of identified risks.

Safety Risks and Hazards:

 Risks can occur post-development, often related to software failures in safety-critical

systems.
 Perform software safety and hazard analysis to identify and control potential hazards.
RMMM Plan:

 Document RMMM strategy as part of the project plan or as a separate document.

 Some teams use a Risk Information Sheet (RIS) for documenting individual risks.

Risk Monitoring Objectives:

1. Assess if predicted risks occur.

2. Ensure proper application of risk aversion steps.
3. Collect information for future risk analysis.

Notes:

 Problems in a project can often be traced to multiple risks.

 Allocate origin of risks to understand their impact on problems throughout the project.

This structured approach ensures that risks are identified, prioritized, and managed effectively,
minimizing their impact on the project's success.

Lecture #42: Quality Assurance in Software Development

10.1 Quality Concept

What is it?

 Definition: Explicitly define what is meant by 'software quality.'

 Activities: Create activities ensuring high-quality work products.
 Quality Assurance: Perform quality assurance (QA) activities on every software project.
 Metrics: Use metrics to develop strategies for improving the software process and end
product quality.

Who does it?

 Responsibility: Everyone involved in the software engineering process is responsible for

quality.

Why is it important?

 Efficiency: Reducing rework results in lower costs and improved time-to-market.

 Quality Stress: Emphasizing quality in all activities minimizes rework.

What are the steps?

1. Define Quality: Understand software quality at different abstraction levels.

2. Identify SQA Activities: Filter errors out before they are passed on.
3. Work Product: Create a Software Quality Assurance Plan.
 o During analysis, design, and code generation: Formal technical review summary
reports.
o During testing: Test plans and procedures.
o Process improvement work products may also be generated.

How to ensure it’s done right?

 Defect Removal Efficiency: Improve efficiency to reduce rework.

SQA Encompasses:

1. Quality management approach

2. Effective software engineering technology (methods and tools)
3. Formal technical reviews throughout the software process
4. Multi-tiered testing strategy
5. Control of software documentation and changes
6. Procedure to ensure compliance with standards
7. Measurement and reporting mechanisms

Software Quality Definition:

 Conformance: Meets explicitly stated functional and performance requirements,

documents, and standards.
 Factors: Audit-ability, completeness, consistency, error tolerance, expandability,
hardware independence, software system independence, modularity, security, and
simplicity.

SQA Activities:

 Planned Approach: Ensures quality systematically.

 Reviews: Conducted at all stages (analysis, design, coding) to filter errors.
 Testing: Automate testing processes using various tools.
 SCM: Maintains integrity and traceability of software items, assessing and implementing
changes.

10.2 Producing Quality Software

Challenges in Quality Determination:

 Agreement on Metrics: Developers and customers must agree on quality metrics.

 Quality Assessment: Objectively, subjectively, and non-assessable components must be
managed.
o Objective: Characteristics identified in the requirements specification.
o Subjective: Compliance with customer’s expectations.
o Non-assessable: Behavior in unforeseen situations.
  Requirements Specification: Must describe measurable characteristics to minimize
disputes.

Quality Control in Development:

 Frequent Assessments: Needed throughout the development cycle.

 Well-Defined Requirements: Minimize disputes and disagreements.

10.3 Quality Control

Variation Control:

 Inspections, Reviews, and Tests: Ensure each work product meets its requirements.
 Feedback Loop: Measurement and feedback tune the process, minimizing defects.

Quality Control Activities:

 Automated, Manual, or Combined: Quality control can be implemented in various

ways.
 Defined Specifications: All work products should have measurable specifications.
 Feedback Minimizes Defects: Essential for reducing defects.

10.4 Quality Control Myths

Common Myths:

1. Quality Costs Money: Quality usually saves money by reducing rework and failures.
2. Software Failures Are Unavoidable: This myth justifies poor quality but should not be
a design parameter.

Standards and Procedures:

 IEEE Standards: Software quality assurance plans and detailed guides.

 US DOD Standards: Quality programs and development standards.
 ISO 9000-3: Covers configuration control and quality assurance broadly.

10.5 Resources for Quality Control

SQA and Configuration Control:

 Combined Responsibilities: Merging SQA and configuration control can eliminate

duplication.
 Tools for SQA: General support tools include documentation utilities, software design
tools, debugging aids, structured preprocessors, file comparators, structure analyzers,
standards auditors, simulators, execution analyzers, performance monitors, statistical
analysis packages, integrated CASE tools, test drivers, and test case generators.
Planning and Resources:

 SQA Plan: Identifies and describes all required quality assurance resources and their
application.
 Budgeting and Procurement: SQA resources are part of project development resources
from the start.

Quality Assurance in Software Development

Definition and Goals

Quality Assurance (QA): Quality assurance is the systematic process of auditing and reporting
on product quality to ensure it meets defined standards and requirements. The goal of QA is to
provide management with insights and confidence that the product quality is up to the mark. If
issues are identified, it is management's responsibility to address them and allocate necessary
resources for resolution.

Software Quality Assurance (SQA): In software development, QA focuses on ensuring that

software meets its functional and performance requirements and adheres to documented
standards. High-quality software conforms to explicit requirements, development standards, and
implicit characteristics like usability and maintainability.

Historical Context

1. Early Days:
o In the early 20th century, quality assurance in manufacturing started with Bell
Labs in 1916.
o Formal approaches to quality control emerged in the 1940s, emphasizing
measurement and process improvement.
2. Software Development:
o Initially, software quality was the programmer's responsibility.
o Formal QA standards for software emerged in the 1970s, particularly in military
software development, and expanded to commercial software.

Key Concepts

1. Software Quality Definition:

o Conformance to Requirements: Quality is measured based on how well the
software meets specified functional and performance requirements.
o Development Standards: Adherence to development standards ensures quality.
o Implicit Characteristics: Software must also meet implicit requirements such as
ease of use and maintainability.
2. SQA Responsibilities:
o SQA is a planned and systematic process to ensure software quality.
o Involves various stakeholders, including software engineers, project managers,
and the SQA group.
SQA Activities

1. Planning:
o Prepare an SQA plan outlining evaluations, audits, standards, procedures, and
feedback mechanisms.
2. Process Description:
o Review the software process description for compliance with organizational
policies and standards.
3. Compliance Verification:
o Review engineering activities to ensure adherence to defined processes.
4. Audits:
o Perform audits of work products to verify compliance and report findings.
5. Deviation Handling:
o Document and address deviations from standards and procedures.
6. Reporting:
o Record non-compliance issues and report to senior management.
7. Change Management:
o Coordinate change control and collect software metrics.

SQA Plan Components

1. Organization and Resources:

o Define organizational structure, personnel skills, and resources.
2. Standards and Guidelines:
o Specify applicable SQA standards, procedures, and guidelines.
3. Documentation:
o Detail required documentation and methods for evaluation.
4. Software Requirements:
o Evaluate software requirements, development processes, and reused software.
5. Storage and Handling:
o Ensure proper storage, handling, and delivery of project documents and software.
6. Reviews and Audits:
o Plan and conduct reviews and audits.
7. Configuration Management:
o Address software configuration management if not covered elsewhere.
8. Problem Reporting:
o Document and address problem reports and corrective actions.
9. Test Procedures:
o Evaluate and validate test procedures.
10. Tools and Techniques:
o Specify tools, techniques, and methodologies used.
11. Quality Control of Suppliers:
o Manage quality control for subcontractors and suppliers.
12. Additional Controls:
o Include any project-specific control procedures.
13. Reporting and Documentation:
 o Define reporting procedures, maintenance, storage, and retention of records.

Software Quality Metrics

1. Purpose:
o Metrics help measure and compare software quality objectively.
2. Examples:
o Reliability: Percentage of operational time.
o Recoverability: Time taken to recover after failure.
o User-Friendliness: Training time required for new users.
3. Measurement:
o Quality should be measured throughout development, not just at the end, to catch
issues early.

General Guidelines

1. Small Projects:
o SQA activities can be managed by the project manager.
2. Testing Independence:
o Testing is best conducted by a separate team, though small projects might not
justify this.
3. SQA Team Independence:
o SQA activities should ideally be performed by an independent team, though small
projects may need different arrangements.
4. Requirement Specification:
o Effective quality control relies on clear and detailed software requirements
specifications.

By following these principles and practices, software development teams can enhance the quality
and reliability of their products, ensuring they meet both explicit and implicit requirements
effectively.

Lecture #43: Managing Tasks in Microsoft Project 2000

11. Application Tools

11.1 Managing Tasks in Microsoft Project 2000

Project management involves complex activities like planning, resource allocation, risk
management, and estimation. Microsoft Project 2000 helps automate these tasks, offering
features for project planning, resource and cost allocation, and tracking.

 Tasks in Microsoft Project:

o Tasks are units of work that consume effort, time, and money.
o The software helps specify tasks and their durations, preparing a project schedule.
 o The schedule includes start and end dates and a Gantt chart, which visually
represents the tasks and resources over time.

11.2 Creating Tasks

Effective project management involves breaking down a project into manageable units.
Microsoft Project helps with this by allowing you to define tasks and their details.

 Example Scenario:
o XYZ Inc. plans to develop an ERP project in five phases: analysis, design,
development, testing, and implementation.
o In the analysis phase, tasks are defined and managed using Microsoft Project.
 Creating Tasks:
1. Access Task Information:
 Click the Project menu and select Task Information.
 Alternatively, use the shortcut Shift + F2.
2. Define Task Details:
 Enter the task name (e.g., Analysis).
 Set the duration (e.g., 5 days) and other relevant details.
 For estimated durations, use a question mark or select the Estimated
checkbox.
3. Subtasks and Summary Tasks:
 Create subtasks (e.g., Project scope determination) and indent them under
the main task (e.g., Analysis).
 A summary task aggregates related subtasks and reflects their start and
finish dates.

11.3 Types of Tasks

Microsoft Project allows you to create three types of tasks:

1. General Tasks:
o Regular tasks without special duration characteristics.
o Example: Analysis task.
o Created using the Task Information dialog box, specifying the task name and
duration.
2. Milestone Tasks:
o Mark significant accomplishments with no duration.
o Example: Analysis Complete.
o Create by selecting the Mark task as milestone checkbox in the Advanced tab of
the Task Information dialog box.
o Displayed as tasks with no duration in the Gantt chart.
3. Recurring Tasks:
o Tasks that repeat at regular intervals (daily, weekly, monthly, or yearly).
o Example: Weekly project meetings.
o Created using the Insert menu and Recurring Task command.
  Specify the recurrence pattern and end date.
 The task appears with a circular arrow symbol and is shown at intervals in
the Gantt chart.

Summary:

Microsoft Project 2000 offers tools to efficiently manage project tasks, including creating
general, milestone, and recurring tasks. It helps visualize project schedules and track progress
using Gantt charts and other features.

Adding Constraints to Tasks in Project Management

Constraints are limitations or conditions that impact a project’s schedule and quality. They can
affect various aspects, such as the project’s duration, resources, and performance goals. Here’s a
detailed overview of how to handle constraints in project management using Microsoft Project:

Common Constraints in Project Management

 Duration of a Project: The overall time allocated to complete the project.

 Resources of a Project: The personnel, equipment, or materials required.
 Performance Goals: The specific objectives or standards that need to be met.

Types of Constraints in Microsoft Project

Microsoft Project allows you to apply various constraints to tasks to manage scheduling more
effectively. These constraints help in controlling when tasks can start or finish.

1. As Soon As Possible (ASAP):

o Definition: Schedules the task as early as possible without specifying a date.
o Usage: Default setting when scheduling a new task from the project's start date.
2. As Late As Possible (ALAP):
o Definition: Schedules the task as late as possible without specifying a date.
o Usage: Applied when scheduling from the project's finish date.
3. Start No Later Than (SNLT):
o Definition: Specifies the latest possible start date for a task.
o Example: Training before the development phase; set the start date to February
13 if development starts on February 15.
4. Finish No Later Than (FNLT):
o Definition: Specifies the latest possible finish date for a task.
o Example: Ensure the project proposal task finishes by February 19 if the analysis
phase starts on February 20.
5. Start No Earlier Than (SNET):
o Definition: Specifies the earliest start date for a task.
o Example: Set a start date for creating test cases after the completion of
construction and unit testing phases.
6. Finish No Earlier Than (FNET):
 oDefinition: Specifies the earliest finish date for a task.
oExample: Extend the finish date of unit testing to ensure thorough quality checks.
7. Must Start On (MSO):
o Definition: The task must start on a specific date.
o Usage: Used in critical projects where task timing is crucial.
8. Must Finish On (MFO):
o Definition: The task must finish on a specific date.
o Usage: Applied to ensure critical tasks are completed by a set date.

Adding Constraints to Tasks

1. Open the Task Information dialog box.

2. Go to the Advanced tab.
3. Select the Constraint Type from the list.
4. Specify the appropriate date based on the chosen constraint.
5. Click OK to apply the constraint.

Example: To add a constraint to the "Develop test plans" task:

 Set a Finish No Later Than constraint with the date August 10.

Adding Deadlines to Tasks

Deadlines are strict finish dates for tasks. They act as target dates without affecting the overall
project schedule. Deadlines help in tracking task progress and ensuring timely completion.

Steps to Add a Deadline:

1. Open the Task Information dialog box.

2. Click the Advanced tab.
3. Enter the desired deadline date in the Deadline field.
4. Click OK to apply the deadline.

Example: Set July 15 as the deadline for the "Assign development staff" task.

Setting Dependencies Between Tasks

Dependencies define how tasks relate to each other. Four types of dependencies can be set:

1. Finish-to-Start (FS):
o Definition: The successor task starts after the predecessor task finishes.
o Example: The high-level design begins after the SRS document is completed.
2. Start-to-Start (SS):
o Definition: The successor task starts at the same time as the predecessor task.
o Example: Functional and integration testing start simultaneously.
3. Finish-to-Finish (FF):
 o Definition: The successor task finishes at the same time as the predecessor task.
o Example: Preparing a checklist cannot end until implementation testing is
complete.
4. Start-to-Finish (SF):
o Definition: The successor task cannot finish until the predecessor task starts.
o Example: Testing phase starts only after the coding phase begins.

Lag and Lead Time Between Tasks

 Lag Time: The delay between the predecessor and successor tasks. Set as a positive
value.
 Lead Time: The overlap between tasks. Set as a negative value.

Example of Setting Lag Time:

1. Create tasks "Develop code" and "Developer primary testing".

2. Link the tasks with a Start-to-Finish dependency.
3. Set a four-day lag time between them.

Steps to Link Tasks and Set Lag Time:

1. Create and select tasks.

2. Use the Edit menu to link tasks.
3. Set the relationship type (e.g., SF).
4. Specify the lag time in the Lag field.

These functionalities in Microsoft Project enable you to manage your project schedule
effectively by setting constraints, deadlines, dependencies, and timing adjustments.

4o mini

Splitting Tasks

 Definition: A split in a task represents an abrupt interruption in the planned schedule,

usually due to resource constraints.
 Example: At XYZ Inc., a software module testing task can be interrupted to train
developers if both tasks require the same server.
 Steps to Split a Task in Microsoft Project:
1. Create a summary task (e.g., "Testing") and a sub-task (e.g., "Unit testing").
2. Select the sub-task (e.g., "Unit testing").
3. Go to the Edit menu and select "Split Task."
4. Drag the cursor to define the split in the Gantt chart view.

Assigning Resources

 Types of Resources:
 o Work Resources: People and equipment that are not consumed by the project
(e.g., developers).
o Material Resources: Resources that are consumed by the project (e.g., hardware,
software).
 Steps to Assign Resources:
1. Create a task (e.g., "Develop prototype").
2. Go to the Tools menu, then Resources, and select "Assign Resources."
3. In the Assign Resources dialog box, select the resource (e.g., hardware) and
specify the units.

Assigning Costs

 Types of Costs:
o Standard Rate: Normal rate for a resource.
o Overtime Rate: Rate for resource use beyond standard hours.
 Steps to Assign Costs:
1. Go to the Resource Sheet view.
2. Select the resource (e.g., "Tester").
3. Open Resource Information from the Project menu.
4. Enter standard and overtime rates in the Cost tab.

Tracking a Project Plan

 Progress Lines:
o Always Display: Shows current progress status.
o Selected Dates: Shows progress on specific dates.
o Recurring Intervals: Displays progress lines at regular intervals (daily, weekly,
etc.).
o Steps to Set Progress Lines:
1. Go to the Tools menu, then Tracking, and select "Progress Lines."
2. Choose the appropriate display options (e.g., daily every third day).
 Project Baselines:
o Definition: Baselines represent the planned schedule and cost for comparison
against actual performance.
o Steps to Save a Baseline:
1. Go to the Tools menu, then Tracking, and select "Save Baseline."
2. Choose to save the baseline for the entire project or selected tasks.

These features help manage tasks and resources efficiently and track the progress of your project
accurately. If you need more details or have specific questions about these concepts, feel free to
ask!

4o mini

Recording and Updating Tasks

  Purpose: Track actual work completed versus planned work to determine remaining
work.
 Steps to Record and Update Tasks:
1. Select Task: Choose the task you want to update (e.g., "Unit testing").
2. Open Table Entry: Go to the View menu, click Table Entry, and then select
Work.
3. Update Fields: Enter actual work done in the Actual field. Microsoft Project
updates the Remaining field and recalculates the Work field and Variance.
4. Modify Remaining: Optionally adjust the Remaining field if needed. The Work
field and Variance will update accordingly.
5. Percent Complete: You can also update the percentage of work completed in the
General tab of the Task Information dialog box.

Rescheduling Tasks

 Purpose: Adjust the start or finish dates of tasks to reflect changes in the project timeline.
 Steps to Reschedule Tasks:
1. Select Task: Choose the task to reschedule (e.g., "Create user manuals").
2. Open Update Project: Go to the Tools menu, click Tracking, and then Update
Project.
3. Select Reschedule Option: Choose "Reschedule uncompleted work to start after"
and specify the new start date.
4. Confirm: Select whether to reschedule the selected task or the entire project, then
click OK.

Modifying the Duration of a Project Plan

 Purpose: Adjust the project’s start and finish dates to accommodate changes or delays.
 Steps to Modify Duration:
1. Open Project Information: Click the Project menu, then Project Information.
2. Adjust Finish Date: In the Project Information dialog box, select "Schedule
from" and choose "Project Finish Date."
3. Set New Finish Date: Select the new finish date from the calendar (e.g., June 15)
and click OK.

Displaying Project Information Using Reports

 Purpose: Create and view reports to analyze project status and details.
 Creating Standard Reports:
1. Open Report Menu: Go to the View menu and select Reports.
2. Choose Report Type: Select Custom to create a new report.
3. Define New Report: Click New in the Custom Report dialog box, choose the
Resource or Task option, and click OK.
4. Specify Report Details: Enter the report name, sort information, and click OK.
5. Preview Report: Click Preview to view the report. Ensure a printer is configured
to print if needed.
Modifying and Printing a Standard Report

 Purpose: Adjust the content or format of reports to better suit project needs.
 Steps to Modify Reports:
1. Access Report Dialog Box: Use the Task report dialog box to modify report
display settings.
2. Save and Print: Adjust as necessary, save changes, and print the report if needed.

These features in Microsoft Project help ensure that project tasks, schedules, and resources are
managed effectively, providing clear visibility into project performance and status. If you need
further clarification or additional details, let me know!

Modifying and Printing Reports

Modifying an Existing Report:

1. Open the Custom Reports Dialog Box:

o Click the "Edit" button to modify an existing standard task or resource report.
2. Access the Task Report Dialog Box:
o The relevant reports dialog box will appear.
3. Modify the Report:
o Definition Tab:
 Check the "Show summary tasks" checkbox to display only summary
tasks, excluding subtasks.
o Details Tab:
 Check the "Gridlines between details" checkbox to add gridlines between
details.
4. Save Changes:
o Click "OK" to close the Task Report dialog box.
5. Sort Report Fields:
o You can sort reports based on different fields displayed.

Printing a Standard Report:

1. Open the Define New Report Dialog Box:

o Click the "Print" button to open the Print dialog box.
2. Print the Report:
o From the Print dialog box, configure print settings and proceed to print the report.

Software Implementation

Implementation Prerequisites:

1. Finalize Licenses:
 o Confirm the number of software licenses required.
2. Error Logging Procedures:
o Establish procedures for logging and handling errors.
3. System Changeover Scheduling:
o Plan the schedule for transitioning to the new system.
4. Data Backup Procedures:
o Implement procedures for maintaining data backups.
5. Coordination Committee:
o Set up a committee to oversee implementation, including members from various
departments.

Key Implementation Plans:

1. Implementation Plan:
o Details methods of system transfer, hardware/software requirements, and
implementation schedule.
o Includes sections for Resource List, Software Components, and Data Migration.
2. Training Plan:
o Contains focus areas, training courses, schedules, and roles/responsibilities.
o Ensures both users and operators are trained effectively.
3. Acceptance Plan:
o Details acceptance testing procedures, including testing schedule, criteria,
resource list, and bug reporting.
4. System Support Plan:
o Outlines post-implementation support, including warranty details and support
personnel.

Implementation Activities:

1. User Acceptance Testing (UAT):

o Conduct final testing to ensure the software meets user requirements.
o Includes preparing a UAT plan, executing test cases, and fixing identified bugs.
2. Training:
o Provide training to users and operators on system functions and support tasks.
o Use documentation such as user manuals and guides.
3. Data Migration:
o Transfer data from old systems to new ones, using scripts/tools or subcontracting
if needed.
4. Installation and Configuration:
o Deploy and configure the system on user machines, possibly using automated
tools.
5. Product Sign-Off:
o Obtain formal acceptance from users, confirming that all issues are resolved and
contractual obligations are met.
6. Project Wind-Up:
 o Conclude the project by analyzing performance, gathering feedback, and ensuring
all deliverables are met.
o Include monitoring deliverables, progress, and financial completion.

Summary:

 Modification and Printing: Adjust report settings to show summary tasks, add gridlines,
and print as needed.
 Implementation: Involves planning, training, acceptance testing, data migration,
installation, and closure activities to ensure successful product deployment and user
satisfaction.

Project-End Activities

1. Data Collection
o Collect and organize data accumulated during the project.
o Analyze actual cost per task, cost overruns and underruns, unplanned tasks, and
planned but unnecessary tasks.
o Record software change requests and bug statistics.
o Evaluate the project team's performance based on task completion, quality, cost
adherence, schedule adherence, innovation, teamwork, communication, and self-
assessment.
2. Post Mortem
o Document valuable information and lessons learned from the project.
o Make recommendations for future project enhancements.
o Submit project-related items to the project library.
o Conduct feedback sessions among team members regarding interpersonal
communication and work processes.
o Prepare a project closedown report with:
 Project description
 Success assessment
 Schedule, budget, and technical details
 Implementation problems
 Data updates on cost estimation
3. Product Delivery
o Transfer packaged software, documentation, and contract items to the
maintenance team.
o Ensure smooth knowledge transfer from the development team to the maintenance
team.

Software Maintenance

1. Importance of Maintenance
o Continuous adjustments are necessary due to changing environments.
o Maintenance can be in-house or outsourced.
2. Types of Maintenance Activities
 o Corrective Maintenance (17%): Fixing bugs and defects.
o Adaptive Maintenance (18%): Modifying the code to adapt to new features or
environments.
o Perfective Maintenance (60%): Improving code maintainability and
functionality.
o Preventive Maintenance (5%): Protecting code against potential failures by
adhering to coding standards.
3. Maintenance Phases
o Initiation Phase:
 Knowledge acquisition from the development team.
 Baseline assessment and understanding operating procedures.
o Preparation Phase:
 Setting up administrative and support procedures.
 Finalizing and implementing procedures from the initiation phase.
o Execution Phase:
 Executing maintenance activities and maintaining communication with the
development team.
4. Maintenance Curve
o High Effort: Immediately after implementation due to numerous changes and
issues.
o Stable Effort: During the system’s maturity phase with fewer major changes.
o Increasing Effort: As the system becomes obsolete, requiring significant updates
and enhancements.
5. Maintenance Process
o Prerequisites: Complete and up-to-date documentation, available
hardware/software/network, and a constituted maintenance team.
o Corrective Maintenance Process: Involves reporting, analyzing, fixing, testing,
and releasing modifications.
o Adaptive Maintenance Process: Includes planning and implementing changes
due to external environment modifications.
o Perfective Maintenance Process: Enhancements for better performance and
additional functionalities.

These elements outline how project completion and maintenance processes are managed to
ensure the software continues to meet users' needs and remains functional over time.

Maintenance and Reengineering Overview

Maintenance Processes

1. Preventive Maintenance
o Objective: Make software more adaptable, correctable, and enhanceable.
o Steps:
 Risk Identification: Project coordinator identifies potential risks.
 Recommendations: Suggestions for maintenance actions are prepared for
management approval.
  Detail Plan: The project detail plan for the changes is prepared.
 Team Formation: A maintenance team is formed based on the work required.
 Implementation: Changes are made according to the request procedure.
 Deployment: Changes are deployed based on the deployment strategy.
2. General Maintenance Process
o Initiation: User requests changes, and the process involves impact analysis and
planning.
o Execution: Testing and releasing system changes based on a deployment strategy.
o Coordination: Managed through change management to ensure smooth operation.

Reengineering

1. Definition
o Objective: Modify and evolve software to meet changing business requirements.
o Importance: Prevents obsolescence and supports continuous adaptation.
2. Types of Reengineering
o Reverse Engineering:
 Purpose: Recover design from source code to understand and improve old
systems.
 Steps:
 Analyze and gather information about the existing system and code.
 Create draft documents and update based on user feedback.
 Reengineer requirements, design, and construction to enhance the
system.
 Tools: Rigi, Refine Language Tools, static analyzers, and test editors.
o Forward Engineering:
 Purpose: Build new programs from old system requirements and design
specifications.
 Steps:
 Recover and use old design information to improve and reconstitute the
system.
 Move from high-level abstraction to low-level implementation.

Best Practices for Maintenance

1. Testing and Environment:

o Ensure testing and production environments are the same.
o Implement version control using tools like VSS and PVCS.
2. Documentation:
o Keep documentation up-to-date.
3. Team Management:
o Rotate team members across different business areas to enhance efficiency.
o Identify backups for key personnel.
4. Balance and Training:
o Maintain a balance between new development and problem-solving.
o Provide proper training and use the latest technology.
5. Knowledge Sharing:
 o Conduct knowledge sharing sessions and ensure an online help facility is available.
6. Problem Tracking and Analysis:
o Use helpdesk tools for tracking problems.
o Perform periodic causal analysis and corrective actions.
7. Quality Reviews:
o Conduct periodic quality reviews and monitor quality goals of the team.

This overview provides a structured approach to managing maintenance and reengineering,

ensuring software systems remain effective and adaptable over time.

Preventive Maintenance Process

Objective: Enhance software to ensure easier correction, adaptation, and improvement.

1. Risk Identification:
o Project coordinator identifies potential risks.
2. Recommendations:
o Maintenance actions are proposed to management for approval.
3. Detail Planning:
o A detailed plan is prepared for implementing changes.
4. Team Formation:
o A team is assembled based on the scope of work.
5. Implementation:
o Changes are made following the request procedure.
6. Deployment:
o Changes are deployed according to the strategy.
7. Process Flow:
o Start: User requests a change.
o End: Changes are tested and released for operation.
o Coordination: Managed through change management.

Reengineering

Objective: Evolve and modify software to meet changing business requirements and maintain
competitiveness.

1. Reverse Engineering:
o Definition: Recover the design from source code to understand and improve old
systems.
o Purpose: Identify system components and interactions, and represent the system at a
higher abstraction level.
o Process:
 Gather information about source code, design documents, and developer
knowledge.
 Create and refine draft documents with user feedback.
 Perform requirement, design, and construction reengineering.
 Test the reengineered system through various testing methodologies.
 2. Forward Engineering:
o Definition: Build new programs from old design specifications to enhance and
reconstitute the system.
o Purpose: Improve performance and add new functions by moving from high-level
abstraction to low-level implementation.

Maintenance Best Practices

1. Testing and Environment:

o Ensure the testing environment mirrors the production environment.
o Implement strict version control (e.g., VSS, PVCS).
2. Documentation:
o Keep documentation current and relevant.
3. Team Management:
o Rotate team members across different business areas.
o Identify backups for key personnel.
4. Development Balance:
o Balance new development with problem-solving tasks.
5. Training and Technology:
o Provide adequate training and use the latest technology.
6. Knowledge Sharing:
o Conduct knowledge sharing sessions and maintain online help facilities.
7. Problem Tracking and Analysis:
o Use helpdesk tools for tracking and conducting periodic causal analysis.
8. Quality Assurance:
o Perform regular quality reviews and monitor the team’s quality goals.

This comprehensive approach ensures effective maintenance and continuous improvement of

software systems.