SPM pt. 2

Additional cards to review

Quality Planning

Identifying which quality standards are relevant to the project and how to satisfy those standards

Quality Control

Monitoring specific project results to ensure that they comply with the relevant quality standards, while identifying ways to improve overall quality

Quality Assurance Process

Concerned with defining or selecting the quality standards

Quality Standard

set of rules for ensuring quality

Product Standard

A specific criteria or benchmark to evaluate the quality of products or services, ensuring they meet established guidelines and requirements.

Process Standard

Define the porocesses that should be followed during software development

Unit Test

Used to test each individual component to ensure it is defect-free, performed before integration testing

Integration Testing

Ensures that the subsets of the overall system work together correctly, occurs between unit testing and system testing

System Testing

Tests the entire system as one entity. Ensures entire system working correctly

User Acceptance Testing

Testing performed by end users prior to accepting the delivered system. Ensures system fits the needs of the users of the system.

Quality Planning Template

1) Product overview 2) product plan 3) quality goals 4) process description 5) document and coding standards 6) risks and risk management

Review

common project management technique for monitoring and control of targeted project aspects or artefacts

Code Inspection

This form of inspection is conducted on a code artefact using a checklist based on the coding standard.

Acceptance Criteria & BDD Syntax

Given [condition], when [something happens], then [result]

Acceptance-Test Driven Development (ATDD) Cycle

1. Write acceptance criteria

2. Write acceptance tests

3. Implement code

4. Run acceptance tests

5. Refractor

Three Laws of Test-Driven Development

1. You are not allowed to write any production code unless it is to make a failing unit pass

2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures

3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test

Documentation process standards

How documents should be developed, validated and maintained

Document Standards

Concerned with document identification, structure, presentation, changes highlighting, representation and interchange

Capability Maturity Model Integration (CMMI)

Describes the key elements of an effective software development process and an approach for software companies to move from an ad-hoc, immature process to a mature developed process.

Organizations characterized being at level from 1-5 based on the processes they follow.

5 Levels of Capability Maturity Model Integration (CMMI)

1. Initial

2. Repeatable

3. Defined

4. Managed

5. Optimizing

McCall Quality Model

Based on Operation, Revision and Transition

Estimated Delivery Time Calculation

Sum of all story points / velocity

Velocity Calculation

Number of story points completed / time period over which they were completed

5 Steps to Product Backlog

1. Write the User Stories

2. Write Acceptance Criteria per User Story

3. Prioritize the User stories

4. Add Story points

5. Definition of Done

User Story Format

As a [user role] I want to [goal action] So that [reason/benefit]

3 C’s for User Stories

Card, Conversation, Confirmation

Epic

A large user story that will take more than one or two sprints to develop and test. They are split into smaller user stories so that a story can be completed within a sprint.

User Role

Collection of defining attributes that characterize a population of users and their intended interactions with the system.

“Must Have'“ MoSCoW

Requirements that have to be included in the delivered scope in order for it to be a success. If even one “MUST” requirement is not included, the project delivery should be considered a failure.

“Should Have'“ MoSCoW

Requirements are critical to the project and will generally all need to be delivered for a successful project.

“Could Have'“ MoSCoW

Requirements are often seen as nice-to-haves

“Won’t Have'“ MoSCoW

Requirements are either the least-critical, lowest-payback items, or not appropriate at this time.

Story Points

Rate the relative effort of work to completed user stories and other stories currently being estimated. They are drawn from abstract scales (no units).

Analysis Paralysis

Spending too much time attempting to develop detailed estimates or delaying making commitments until all of the information required to make decision has high level of certainty.

Cavalier Approach

Not worrying about managing uncertainty and risk at all and just starting the project with no planning at all, or assuming that whatever uncertainty and risk is inherent in the project will be discovered and somehow work itself out as the project succeeds.

T-shirt Sizes

Story point estimation tool using t-shirt sizes XS, S, M, XL, XXL.

Definition of Done

It is universally applicable and is a comprehensive checklist of necessary, value-added activities that assert a feature's quality, not its functionality.

DoD at various levels

Product backlog, sprint, release

Story Points

A relative measure of the size of a user story 

Project Management Plan (PMP) 2 parts

Project information, project governance

Stakeholder Analysis steps

1. Stakeholder Identification

2. Understanding Stakeholder Interests

3. Assessing Stakeholder Influence

4. Prioritizing Stakeholder Engagement

5. Managing Stakeholder Relationships

Stakeholder Identification

Identifying all individuals, groups, or organizations who may be affected by, or have an interest in the project, whether directly or indirectly.

Understanding Stakeholder Interests

Examining stakeholders' interests, objectives, expectations, and concerns regarding the project to ensure their needs are addressed.

Assessing Stakeholder Influence

Evaluate the level of influence or power each stakeholder holds over the project's outcomes, decision-making processes, or resources.

Prioritizing Stakeholder Engagement

Prioritize stakeholders based on their importance, level of influence, or degree of impact on the project's success.

Managing Stakeholder Relationships

Proactively manage relationships with stakeholders by anticipating their reactions, addressing potential conflicts, and fostering open communication and collaboration.

5 Levels of Stakeholder Engagement

• Unaware

• Resistant

• Neutral

• Supportive

• Champion/Leading

Information included in stakeholder analysis

• Names and Organisations of Key Stakeholders

• Their Role on the Project

• Unique Facts about Each Stakeholder

• Level of Interest in the Project

• Influence on the Project

• Suggestions and Strategies for Managing Relationships with each Stakeholder

Autocracy Team

The boss hands out orders, team members carry them out

Anarchy Team

There is no boss, but nobody knows what to do

Democratic Team

make all decisions collaboratively

Collaborative Teams

Effective teams tend to have a fairly flat structure where team members may have different responsibilities.

Members make decisions within their area of expertise, so all teammates participate in decision-making to some extent

Distributed Teams

Team distributed across geographic locations, relying on communication technology.

Teamicide factors

• Defensive management

• Bureaucracy

• Physical separation

• Fragmentation of time

• Quality-reduced product

• Phony deadlines

• Clique control

Communication Plan

Assist in managing and coordinating key communication messages

Defines what will be communicated, channels, when info is distributed, owner, resources, needs of stakeholder, confidential information, flow of communication, constraints, templates or escalations

Risk Management Process

Plan, identify, analyse, respond (planning), monitor

SWOT Analysis Strengths

characteristics of the business or project that give it an advantage over others

SWOT Weaknesses

characteristics that place the business or project at a disadvantage relative to others

SWOT Opportunities

elements in the environment that the business or project could exploit to its advantage

SWOT Threats

elements in the environment that could cause trouble for the business or project

Risk Analysis

Identify each identified risk’s probability and impact

Risk Assessment

Prioritize risks so that an effective risk strategy can be formulated

Risk Analysis Qualitative Steps

1. Estimate risk probability (P)

2. Estimate risk impact (I)

3. Compute risk exposure (P*I Score)

4. Identify root cause

Waterfall steps

requirements, analysis, design, implementation, maintenance, retirement

Incremental steps

project requirements, analysis, design, development, testing, deployment, release # (repeat)

Successful Project

project is completed on-time and on-budget, with all features and functions as initially specified

Challenged project

completed and operational but over-budget, over the time estimate or offers fewer features and functions than planned

Failed project

project is cancelled at some point during the development cycle

Top 4 factors contributing to software project success

1. Executive sponsorship

2. Emotional maturity

3. User involvement

4. Optimisation

Project characteristics

• Introduce CHANGE to the organisation

• TEMPORARY, it has a defined beginning and end

• CROSS-FUNCTIONAL, cuts across organisational boundaries

• Deals with the UNKNOWN

• UNIQUE

• They all vary in SIZE 

Questions Project Schedule Answers

1. How long will the system take to develop

2. How much will it cost

Project Schedule Contents

• Duration & dependencies for each task

• People and physical resources required for each task

• Milestones and deliverables

• Project timeline

Developing Project Schedule Steps

1. Breakdown task into small chunks

2. Identify interdependencies between broke-down tasks and develop a task network

3. Estimate effort and the time allocation for each task

4. Allocate resources for tasks and validate effort

5. Develop project schedule

Dependencies caused by

• Task needing a work product of another task

• Task need resources used by another task

Types of task dependencies

• Finish-to-start: Task A must finish before Task B can start

• Start-to-start: Task A must start before Task B can start

• Finish-to-finish: Task A must finish before Task B can finish

• Start-to-finish: Task A must start before Task B can finish

Task Network

graphical representation of the task flow of a project, useful for depicting inter-task dependencies and determining critical path

person-months

The time in months for a single person working full time to complete the task.

Number of personnel calculation

Effort / Time duration (if effort of person-months and time are known)

Component in PERT Chart

• Earliest start time (ES)

• Latest start time (LS)

• Earliest finish time (EF)

• Latest finish time (LF)

• Slack time

Crashing the project scheudle

• Shortening the total duration of the project by shortening the critical path. By removing the dependencies between activities in the critical path; or

• Shortening the duration of activities in the critical path

Schedule variance calculation

• SV = EV – PV

• Expressed in currency units (e.g., dollars). A positive value indicates ahead of schedule; negative means behind.

Schedule Performance Index Calculation

• SPI = EV / PV

• A ratio (i.e., a fraction). An SPI > 1 indicates better-than-planned schedule performance; SPI < 1 means worse.

Cost Variance Calculation

• CV = EV – AC

• Expressed in currency units (e.g., dollars). A positive value indicates under budget; negative means over budget

Cost Performance Index Calculation

• CPI = EV/AC

• < 0 project performing poorly, >0 project performing well