How can I identify quality objectives and associated metrics?

Question

Our project was on ENROLLMENT SYSTEM DEVELOPMENT. We are 4 members and we are adding new software to improve the system to give clash free timing to students.

Stakeholders are:

• My teammates
• The University

Here are the time constraints:

• Project Start Date: August 30, 2012.
• Projected Finish Date: October 21, 2013

But the problem is that now we're having trouble approaching these 3 questions:

• What Quality Objectives would be needed for the project?

• What metrics should we use to measure the quality of this project?

• What actions should we take to ensure Quality Assurance of this
  project?

The answer to these questions are not in my syllabus.

Answer 1

According to Wikipedia, you should quantify the main characteristics of your software, try to measure them, and to score each characteristic. After this scoring you would be able to find out how about the quality of your software. I suggest you to look through this house of quality graph, I think it is very useful.

In my experience a software quality can be measured in two main categories: the small (low priority) bugs and the critical (high priority) bugs. You cannot solve only one category and say that you solved the half of the bugs. This only can describe your project's situation. (Let's say, you have 50 low priority bugs, such as wrong interface offsets, typos, and 35 high priority bugs, such as crashes and application freezing. If you solve all the 35 critical bugs, you cannot say that you almost done the half of the bugs, only that your application is critical bug-free).

Another personal experience about bugs: the number of total bugs is pondering with 65-70% low priority bugs and 30-35% of critical bugs. After solving all of them, other bugs are generated, in my experience this number is the 33% of the previously solved bugs' number.

To make your software as good quality it can be, I suggest you to broke it in smaller parts, if you have about 1 year, I suggest you to broke it in 4 or 5 smaller releases. Each part should contain a specification part (15%), a development part (30%), bug fixing (40%) and final review with code freeze (15%). In the final review don't forget to discuss with your team the weak and strong points of the project, and try to avoid/improve in the next level the weak ones. Don't forget about the hard deadlines of these smaller parts.

Although, I suggest you to let about 1 month at the final of this 1 year project for the final fixes, to discuss with the customer in each final review, to confirm the already done parts of the project.

I also suggest you this chapter to read, I think is very useful.

Edit: I think your question is highly connected with risk measurement, here you can find a pretty good approach of risk management.

Answer 2

TL; DR

You have insufficient external inputs to properly address your questions within a project management context.

Are Quality Objectives Project Management?

There is probably some reasonable debate as to how much quality management really has to do with project management per se. To the extent that it's an external requirement imposed on the project, I would say that it bears on project planning and delivery, but while quality objectives may be inputs to a project, I don't think they are properly project management tasks in the normal sense.

Ordering Matters

Setting that aside, I think you're asking one mistaken question with two dependencies. You ask:

1. What Quality Objectives would be needed for the project?
2. What metrics should we use to measure the quality of this project?
3. What actions should we take to ensure Quality Assurance of this project?

The first question is not yours to decide. Objectives (also known as "requirements") are inputs to a project. For example, if you're making widgets, what are the machining tolerances? If you're writing software, what bug-free features are essential to ship the product? Those are questions that must be answered by stakeholders, not project managers, although a PM can certainly facilitate the requirements-gathering process.

The second and third questions are entirely dependent on the first. Until you know what your objectives are, how can you possibly measure them or evaluate the effectiveness of each objective's quality controls?

Further Reading

While it's a little thin, a reasonable place to start is the Requirements Analysis page on Wikipedia. It identifies a few ways to gather project requirements, and how goals can be set based on those requirements.

Specific details will, of course, be highly dependent on your particular circumstances. The best advice I can offer is to read widely and adapt processes as needed until a practice fits your project.

Answer 3

That seems to be a long project and I think a couple of internal milestones can help you with your quality related questions. I don't know anything about your context or way of working, so I'm going to share my general view: if people start talking about quality in the middle of the project, they are usually experiencing fear which comes from the uncertainty they are experiencing. If you can reduce the uncertainty, you can move forward instead of talking about quality.

One good way to do it is by introducing iterations and frequent internal milestones. This means that you figure out what you would like to do in the short term - maximum 3 weeks -, do it and made it public so that the users can start giving you feedback. At a university it must be easy to find a larger group of people who would join these early adapters and give you feedback. If they like your product then your quality is good enough. If they don't like it, it isn't and you have to change things in the next iteration.

Listen to them and see what do they value and use that as a quality indicator in your project. There was a project where we were focusing on the number of issues we had and all of our improvements was about this number. After a couple of months, we told our customer how drastically we reduced this number. She wasn't happy, because she didn't care about this number. She wanted faster answer times. I learned that the numbers I read in books or used before were irrelevant. I needed the number that the customer checked and valued.

Answer 4

What Quality Objectives would be needed for the project?

What metrics should we use to measure the quality of this project?

What actions should we take to ensure Quality Assurance of this project?

Your question is very general; I agree with @CodeGnome and @Mollybaba that there are insufficient details to answer the question in a manner that is satisfactory in either an academic or real world situation.

I would suggest that you begin with a review of the wikipedia Quality Management page.

I'm going to infer from the details that you do provide that you're developing software. In that case you'll probably want to check Software Quality Management and Software quality assurance.

I would choose some quality objectives that would enable me to ensure that I meet the customer's non-functional requirements - to ensure that my project meets and exceeds their needs. That involves discussion with the stakeholders to determine how they measure quality in the current system and what level of improvement they desire. Whatever they mean by "clash free timing", you'll want to set a threshold for "clash free timing", and a tolerance for clash free timing. (Any PMI resource will provide enough backgt

When you define "clash free timing", find a way to measure that; that's your first quality metric. I'd supplement that with standard quality measurements like "bugs/kilo-lines of code", or "average time to fix bug" or "total technical debt". The Software Engineering Institute provides some resources if I remember correctly.

Once you've done that, design processes. I can't speak to "clash free timing", but there are fairly standard ways of improving software quality. You could adopt extreme programming, or structured code reviews. You need to continuously measure the metric, detect when the production quality begins to veer towards your control limits and plan actions to take.

In my experience people tend to forget that you can improve software quality by training the developers in software quality and software security development.