Unit 5

Software project management

Requirements and Quality Function Deployment
Quality function deployment (QFD), also commonly known as a way to
represent the "voice of the customer," is a process for capturing customer
requirements and translating them into requirements that can be used by
designers, producers, and suppliers.
The process of QFD can be found within methods of brainstorming, FAST, and
JAD. With QFD, sharing of information is achieved through the efforts of a
cross-functional team from various stakeholder groups such as marketing,
sales, service, distribution, product engineering, process engineering,
procurement, production, and of course, the end-user of the software system.
A second QFD characteristic found throughout the requirements elicitation
process has to do with capturing the requirements information in one place, in
a compact form.
● Create high-level requirements from customer input, considering different
Viewpoints.
● Assign a value, indicating a degree of importance rating, to each
requirement.
Some goals of QFD are parallel to the goals for requirements
elicitation:
Both endeavor to educate management on the importance of the
elicitation phase and the benefits of promoting communication during this
Phase.
Both strive to capture the "voice of the customer,"
Both promote group work to achieve the common goal of producing quality
requirements and sharing ownership in them.
Advantages of using QFD during requirements elicitation include:
● Cross-functional communication and teamwork result in a more usable
product.
● Prioritized requirements allow high-priority items to be undertaken early, and
enhances resource allocation throughout the development cycle.
● QFD documentation preserves knowledge and promotes reuse, ultimately
shortening development time.
● Customer-focused activities lead to increased satisfaction with the product.
Building the Software Quality Assurance Plan
Purpose
The purpose of the SQAP frames the part that software quality assurance plays
within overall project management. These pieces need to be in this section:
Definition of the software end use;
Definition of the criticality of the need for this software solution;
Block diagram of how it fits with other software systems;
Intended audience for the SQAP;
Justification of the project
Specific software deliverables covered;
Description of software life cycle development model used; and
List of specific COTS software to be used.
Reference Documents
● List of documents that form the basis of this SQAP;
● Reason for listed documents used;
● List of deviations from standards, policies, and procedures;
● List of software deliverables covered by the SQAP that require additional,
● more rigorous, or more relaxed practices or procedures; and
● Record of deviations that reflect the criticality presented in the last section
● and the references that justify those deviations.
3 Management
This section describes the product development organization and the
organization's tasks and responsibilities.
Organization
The organization chart showing all stakeholders and their relationship to
the development organization;
Reporting and approval paths within the organization;
Conflict-resolution process;
Issue tracking mechanism; and
Change control board responsibilities and organization.
Tasks
The items to be included in this paragraph are listed here:
The specific tasks to be performed in the SQA process, to include auditing,
reporting, and reviewing;
The specific actions to be executed on the specific deliverables;
The specific points within the software development life cycle where SQA
plays an active role; and
A workflow diagram of the SQA activities for this specific project.
Responsibilities
A table of roles and responsibilities of all members of the development team
must be shown.
Documentation Requirements
This list is the minimum set of documents that would be produced on a project
requiring a SQAP:
Project management plan;
Software requirements specification;
Software design specification;
Software test plan;
Software risk management plan;
Software configuration management plan; and
User-deliverable documentation.
Standards, Practices, Conventions, and Metrics

Software quality assurance is driven by many industry standards, best-of-

breed practices, local organization conventions, and individual project metrics.

This section enumerates all of these external and internal factors that will

have an impact on the ultimate quality of the software product.

Purpose

The SQA is the scorekeeper, not the quarterback. These items are included in the purpose:

Cross-references of all documents to the specific practices to be applied from each;

Cross-references of monitoring, review, and audit compliance for each; and

Cross-references of where each occurs in the development life cycle.

Content

These items need to be in the content section:

Product-specific quality measures;

Web page standards;

Documentation standards;

Logic structure standards;

Coding standards;

Naming conventions;

Commentary standards;

Testing standards and practices; and

All software quality assurance product and process metrics.

Reviews and Audits
Reviews and audits are the SQA activities that provide both a testing

mechanism to determine the progress of the project and a feedback loop for

the developers to check the quality of the product in progress.

Purpose

This section will have the following information:

Definitions of the technical and managerial reviews and audits to be conducted;

Rules and procedures for the reviews and audits to be accomplished;

Minimum attendees at reviews and audits in order to proceed;

Cross-reference of all reviews and audits to the project life cycle;

Minimum recording standards for all reviews;

Disposition process for issues uncovered during reviews and audits;

Use of issue tracking system; and Use of change control.

SQA Required Reviews
These are the reviews required for completing the SQA project activities:
Project management plan preview;
Software requirements specification review;
Software design specification review,Software test plan review;
Software risk management plan review;
Software configuration management plan review;
User-deliverable documentation review;
Functional audit as part of delivery milestone;
Physical audit for code and documentation internal consistency;
In-process audits for design to code consistently;
Managerial reviews to assess process and procedure compliance; and
Postmortem review for lessons learned at project end.
Risk Management

Any project requiring a SQAP also has a risk management plan. The cross-

reference to the SQAP is in those specific risks that are mitigated through the

use of the SQAP. These items would be included:

Cross-reference to specific risk mitigation plans aided by SQAP;

Statement of how SQAP reduced specific classes of risk for this project;

SQA review cycle, with special emphasis on risk mitigation;

Cross-reference of periodic risk reviews, with specific SQAP reviews,

assessments, and audits; and

Problem Reporting and Corrective Action

Cross-reference the roles and responsibilities previously listed to their

relationship to problem reporting and resolution.

Describe the process for issue tracking.

Describe the process for problem reporting.

Describe the life cycle of issue to problem to resolved problem.

Cross-reference how these processes interact with the configuration

management process.
Tools, Techniques, and Methodologies

These are the activities to complete the definition of all tools, techniques, and

methodologies used within the SQAP:

List all tools that are used for SQA on this project.

List who is responsible for managing the tools.

Describe the process for securing tool licenses.

Define all SQA-specific techniques used.

Provide ROI information on the use of the techniques.

Define all SQA-specific methodologies used.

Supplier Control
All COTS application software included in the final product;

All COTS application development tools used to build the final product;

All COTS database products used on the project;

A specific quality assurance plan for each piece of COTS software used on

the project;

All personnel requirements for nonemployee team members;

A plan for ensuring the work product quality of contractors on the project

team.
Software Configuration Management
Software configuration management (SCM) is the organization of the

components of a software system so that they fit together in a working order,

never out of synch with each other. Those who have studied the best way to

manage the configuration of software parts have more elegant responses.

SCM principles

The four basic requirements for an SCM system

Planning and organizing for SCM

SCM tools

Benefits of SCM

Path to SCM implementation

SCM Principles

SCM can be viewed as a pyramid, as shown in Figure 31-3. Let's explore each

of the six layers, starting at the bottom and working to the top. Then we'll look

at two other faces of the pyramidthe training plan and the transition plan.
SCM Plans and Policies

Development of an SCM policy for an organization and the subsequent plans

for each product developed is crucial to successful SCM implementation.

Putting SCM into an organization is a project like any other, requiring

resources of time and money.

SCM Processes

The specific processes of SCM are documented for all users to recognize. Not

all SCM processes need to be used within an organization or on a product. Yet,

it is important to have available, in "plain sight," those processes that are used

specifically in your organization.

Metrics

The measures used to show conformance to policy and product plans are

important details. These measures show where the organization is along the

path to reaping the benefits of SCM.

Tools for SCM

The tools used to implement SCM are the next-to-last item on the pyramid.

For too many managers, this is often the first instead of the fifth stem in

SCM many organizations and projects simply buy a tool, plop it in place, and

expect magic.
SCM Configuration Items

The configuration items (CI) are those "things" that represent internal and

external project deliverables. They are the final result of all the work done to

implement SCM in your organization.

The Four Basic Requirements for an SCM System

Identification, control, audit, and status accounting are the four basic

requirements for a software configuration management system. These

requirements must be satisfied regardless of the amount of automation within

the SCM process

Planning and Organizing for SCM
Multiple releases Enhancements to the base product should result in

additional releases of the product containing the latest changes.

Product family As products are built that offer the same capabilities across

a heterogeneous set of hardware platforms, both the common and the

platform-specific software bases must be managed.

Requirements change The first law of systems engineering is that no

matter where we are in the system life cycle, the system/software will change,

and the desire to change it will persist throughout the life cycle.

Schedule change As requirements change, so must the schedule. Mapping

the feature sets for release to the schedule allows project managers to more

accurately estimate the effort required for generating that next release.
Software changes No product developer has the luxury to write code once

and forget about it.

Staff changes In the best of organizations, people get promoted, take

other jobs, and leave.

System/user documentation change No product developer has the

luxury to produce in a technology or tool vacuum.

SCM Staffing
Identification

1. Ability to see partitions

Ability to see relationships

Some technical ability

System engineering orientation

Programming

Control

1. Ability to evaluate benefits versus cost

System viewpoint (balance of technical/managerial, user/buyer/seller)

An appreciation of what is involved in engineering a software change

Auditing

1. Extreme attention to detail

Ability to see congruence

Ability to perceive what is missing

Extensive experience with technical aspects of system engineering or

software engineering
Status Accounting

1. Ability to take notes and record data

Ability to organize data

Some technical familiarity

System engineering orientation

Programming
SCM Tools
Multiuser support Tools are to be used concurrently by several users.

They have to store all acquired information in a central, shared repository,

and the SCM tool has to allow controlled parallel work on the different

project documents.

Intuitive GUI Because the tools will be used throughout the project and

not only by developers, an intuitive, easy-to-use graphical user interface is

considered very important.

Conformity to the organization's development environment The

organization must define up front the hardware and software development

platforms used.

Scalability The tool should work equally well for smaller projects as for

larger ones.

Flexibility in integrating other software development tools The tool

must allow the integration of all the other development tools to provide a

highly homogeneous environment.

Ease of setup The SCM tool should allow an easy installation and setup,

and should be able to run nearly "out of the box."

Modifiable models Though a working set of models should be predefined,

each of these should be modifiable and extensible.

Process management Process management comprises efficient support

of object life cycles and object promotion, together with a flexible and

extensible approach to life cycle models.

Extensive support for the development phase During development

when checkout and update of objects is frequent, the tool should aid a

developer in determining the set of objects that need an update or

renewed check-in
Management of non development objects SCM tools must manage all

artifacts of the project, not just code.

Permission management Everyone should not have access to make

changes to different pieces of the software

Benefits of SCM Process and Tools
Some Problems with Software

Software development has traditionally suffered from producing end products

with a definite lack of inherent quality. The symptoms of this quality lack are

listed here:

Software development projects are often delivered late and over budget.

Often the delivered product does not meet customer requirements and is

never used.

Software products simply do not work right.

● Lack of Visibility
● Lack of Control
● Lack of Traceability
● Lack of Monitoring
● Uncontrolled Change
Legal Issues in Software
Product Development Techniques

The six legal practice areas that impact product development techniques are

shown in Table 32-4.

Project Management Skills
Alternative Dispute Resolution

Arbitration, negotiation, and mediation are forms of alternative dispute

resolution (ADR) recognized by the American Arbitration Association

People Management Skills
Patents

Patents protect any new or useful product, process, article of manufacture,

composition of matter, or improvement.

Copyrights

Copyrights protect original works of authorship such as writings, software,

photos, music, artwork architecture, and sound recordings. Protection is

automatic once the original work is fixed in a tangible medium of expression.

Trade Secrets

Trade secrets are confidential business information that gives the company

competitive advantage. It has value because it is not generally known and

reasonable precautions must be in place to safeguard the trade secrets.

Trademarks

Trademarks are used to identify goods and distinguish them from goods made

or sold by others. It may be a word, name, symbol, design, slogan or color,

sound, or other device.

Trade Dress

Trade dress is the product's total visual image. This is all factors making up the

total image presented to customers extending to a distinctive look and feel.

Training

These are the three steps needed to address SQA training within the SQAP:

List all baseline SQA training required for project team members.

List all SQA refresher training required.

List training requirements for audit, review, and facilitator positions.

Records Collection, Maintenance, and Retention
Location of the server file system maintaining all the project records;

Backup schedule of the project information;

Recovery instructions for the project information repository; and

Retention periods for project-generated quality records.