Quality Management on Software Projects
By Dave Nielsen
This is the first in a series of articles about managing the Quality related activities in a software project, written from the project manager’s perspective. The first step the project manager will take should be to plan the Quality activities that are required for the application, web site, or system to meet its goals and objectives. You may need to document the goals, objectives, roles, responsibilities, and other details in a formal Quality Management Plan depending on the size and complexity of your project. If your project is not large or complex enough to require a formal plan, scheduling the work and assigning it to a resource in your WBS may be sufficient.
There are 3 different phases or types of testing required during the build phase of the project:
Read the Complete Article
- strongDeveloper testing – this is testing that will be done by the developers on the team and will include unit testing, function testing, thread testing, integration testing, and system testing.
Quality Management Strategy
By The Office of Government Commerce – OGC, UK
Read the Complete Article
- Quality Management recognise a number of management principles that can be used by senior management as a framework to guide their organisations towards improved performance. The principles cover: customer focus, leadership, involvement of people, process approach, system approach to management, continual improvement, factual approach to decision making, and mutually beneficial supplier relationships.
- Quality Management provides suitable guidance to build upon Quality Assurance standards to achieve business benefits for all stakeholder groups and focuses on continual performance improvement to sustain customer satisfaction. The core concepts are:
- continuous process improvement – driven by senior management, focused on critical process areas with explicit improvement goals
- customer focus – recognising both internal and external ‘customers’ and their needs and providing value to the user of the product
- defect prevention and non-compliance – seeking to prevent non-conformance issues arising with products and services early in the development cycle and being proactively engaged in prevention
- universal responsibility – recognising that quality is not only the responsibility of quality assurance teams or reviewers, but should be totally pervasive in all aspects of the business, with everyone seeking ways to improve the quality of their own products and services.
CMM and the PMBOK
By Dave Nielsen
CMM or CMMI may be the most prominent quality standards for software. CMM/CMMI goes beyond the scope of standards such as ISO to define the criteria for good software processes, which is what makes the standard so attractive to organizations with IT shops. CMM/CMMI is intended to govern processes of the entire IT organization, and the complete lifecycle of software applications so must include the processes used to govern the development of the software. CMM/CMMI’s influence on processes that govern software development means that it also influences the way that software development projects are managed. PMI’s PMBOK (Project Management Body of Knowledge) is recognized around the world as the bible of project management best practices. These apply to the management of projects in any industry including the IT industry so the best practices of the PMBOK will be influenced by the CMM/CMMI standard in any organization that wishes to apply the two standards. Read the Complete Article
Project Quality Metrics – The Other Side of the Grass
By Ram Narayanan Sastry
“What cannot be measured cannot be improved.”
This saying forms the basic reason why we have quality metrics defined and measured. There are two major purposes which these metrics serve. The first purpose is to know the current condition of the software and identify if things need to be improved. The second purpose is that it forms the basis to showcase the improvements done over a period of time. In this respect, software quality metrics are an essential part of any Quality Management System and allow projects to quantitatively measure the project’s quality.
But like any other metrics or statistics, the quality metrics also tend not to give the full picture in certain scenarios. Let’s take an example of Code Review Yield. A high Code Review Yield is supposedly an indicator of a good review mechanism. But this could also be an indicator of poor coding standards within a team. Read the Complete Article
The Two Types of Quality Reviews
By Kerry Wills
Most delivery methodologies recommend conducting reviews of key deliverables at specific points in time on the project. Conducting these reviews is an effective way to ensure the quality of project deliverables. There are two types of deliverable reviews that should be added to the project plan and resourced.
Read the Complete Article
Managing Project Quality (#31 in the Hut Introduction to Project Management)
By JISC infoNet
We have previously mentioned Time, Cost and Quality as key factors in project management. Assessing performance in terms of time and cost is relatively easy but quality is harder to define and measure. A high quality project may be one whose outputs:
- Meet the specification
- Meet stakeholder requirements
Or alternatively one whose outputs:
- Are fit for purpose
- Satisfy the stakeholders
These don’t all mean the same thing. The chances of the initial specification being correct or indeed of the stakeholders being able to adequately articulate their real needs are slight. We warned earlier of the dangers of hitting the targets but missing the point. Managing quality is about keeping an eye on the bigger picture and aiming for outputs that are in line with the second definition.
Elements of managing quality within a project include:
- A formal project management framework
- Adoption of recognised standards where they exist
- User Acceptance procedures
- Impartial evaluation
Many projects have some form of external quality assurance role built into the project structure. Read the Complete Article
Difference between Quality Assurance and Quality Control (#5 in the series Quality Management in Project Management)
By Joseph Phillips
Quality Assurance (QA) and Quality Control (QC) activities happen throughout the project. Remember QA is a management process that is prevention-driven, while QC is a project manager process that is inspection-driven. Now all of this is really good on paper and theory, but in the real world it comes down to the one person that matters most in any project: the customer.
Throughout the project the customer must participate in scope verification. Scope verification is the same process of QC: inspection. However, the difference is that QC is done before the customer, and scope verification is done with the customer. QC wants to keep mistakes out of the customers’ hands, while scope verification allows the customer to say things like, “Yep, looks good.” Or “I don’t know what I’m looking at, but I believe you.” Or, “You’re standing too close and your breath smells like onions.”
Project deliverables need to be inspected throughout the project – not just at the project’s end. Read the Complete Article
Quality Control in Project Management (#4 in the series Quality Management in Project Management)
By Joseph Phillips
Alright, so all this planning is good, and it’s even better when it all works, but how does a project manager know that project is meeting the quality expectations? You could wait until the very end of the project and see what the customer says, but that’s a risky as blow drying your hair in the shower. What you need, what you must have, is quality control (QC).
QC is inspection-driven. QC requires the project manager and the project team to inspect the work that’s been done to determine if the work results are in alignment with the stated and implied objectives of the project scope. And if they’re not? Fix the problem!
QC is all about keeping mistakes out of the customers’ hands. You and the project team must work diligently to ensure that all of the work is accurate, on-scope, and meets the objectives that customer has defined. Read the Complete Article
Spotlight on Software Quality Improvement: Three Strategies for Success
By ExecutiveBrief Staff
Trying to navigate the labyrinth of available quality improvement methodologies? Chart the right course for your organization by uncovering the bottom-line value offered by three proven strategies!
Standards in software development are essential to efforts toward improving communication between customer and contractor, reducing software costs throughout the entire life cycle, and improving overall software quality. Organizations have a number of viable choices to consider when it comes to applying software quality process improvement methodologies. Three useful options—the V-Model, ISO9000, and Six Sigma—provide different approaches to helping ensure quality in the software development process.
The V-Model, originally developed for German government defense projects in the early 1990s, is a software development process that is mapped out as a flowchart that takes the form of the letter “V.” According to Geoff Hewson, president of British Columbia-based Software Productivity Center, the V-Model is the best way to look at quality in software development. Read the Complete Article
Project Configuration Management
By Siraj Qureshi
In the project envisioning and planning phase, we gather requirements and analyze them. We then Create a problem statement and make a Vision/Scope statement. Once the vision/scope statement is approved by the client, we identify all the deliverables in the project along with their timelines. We also take the client’s approval for each and every deliverable. During the course of the project, we usually have issues of wrong code or old documentation being delivered to the client: sometimes the programmer loses his code due to project pressure or because of a virus infected development machine. Additionally, you might have the client asking for some old/scrapped functionality back; in case you don’t keep track of old code or old documents, the you usually have to do a lot of rework. In order to overcome this problem, we need to have a Project Configuration plan in place for the project. Read the Complete Article