We have 100 people working as an IT service company for mainly software development and maintenance projects. We want to have Requirements Management processes in place such that we can comply with CMMi level 2 and then gradually to level 3.
Could you provide some guidance on how we should proceed?
Entire books have been writeen on this subject so I won't try to replicate that information here. The short answer is: start by looking at what you ALREADY do today and perform a gap analysis between that and the CMMI practices for Requirements Management (REQM).
REQM is what is required for ML2. Requirements Development is part of ML3. For REQM, there are three key areas you need to focus on: developing a shared understanding of what the requirements mean, understanding how they impact the rest of the project (if they're new or changed), and gaining an appropriate level of committment from all key stakeholders.
Understanding what they mean includes ensuring they are even valid to begin with, that they come from the right source, the constraints, the issues, the risks, and that the amount of work to implement them is understood.
Understanding how they impact the project includes conducting a "traceability" exercise to determine the related changes that have to take place, reconciling the other project work with the new or changed requirement, and ensuring the team is working on the right things as the requirements change.
And finally, gaining committment on the requirement(s) is more than a "sign off." It means that all parties (customer, team, management, etc) are committed to all doing what it takes (as identified in the prior paragraph) to implement the new or changed requirement.
Focus on those three things (as opposed to the practices in the model) and you'll be fully compliant (and more importantly, successful). Good luck!
http://www.broadswordsolutions.com/
Saturday, February 9, 2008
I'm new to CMMI 1.2 and I don't understand the distinction between direct and indirect evidence.
I am in my first year of learning CMMI v1.2 and have participated as an ATM on a few appraisals; however, I still have trouble fully understanding the distinctions between direct and indirect evidence. I do not understand why the concept of ‘direct’ and ‘indirect’ flips in certain work/product instances. Why is this, and can you provide some assistance here?
First, welcome to the world of CMMI! It's a fascinating place where the more you learn about it, the more you'll understand how it can help improve software performance.
It sounds like you already know the basics: direct evidence is something that is the direct consequence of a process being performed. Note: these are the things that organizations who are trying to "game the system" create in order to "prove" they're performing at MLx. This, of course, is nonsense. It's FAR easier to just perform the process and accept what naturally falls out of it as the "right" evidence, but you just can't reason with some people!
The formula for achieving a "fully implemented" characterization on a practice is: Direct + (Indirect or Affirmation). So an indirect is not always required.
Indirect evidence is something that corroborates the direct evidence. If a task in a work plan and a meeting invitation on a calendar both refer to a code walkthrough, they are indirect evidence of the code review (e.g.; we planned for it and we invited people). Other indirect evidence may be meeting minutes, notes, and an agenda for the code review.
Using that example for VER SG2 the direct is the code review results and the indirect is any or all of the examples I gave.
When would this be flipped? Well, for VER SG1 we are "preparing" for peer reviews. Part of preparing is planning for them and inviting people, right? So the indirect for SG2 could be the direct for SG1! And an indirect for "prepare" - VER SG1) COULD be the code review results (they happened as planned, so we must have prepared for them).
There is a larger point here - one that will greatly reduce your overhead and increase efficiency. When planning and designing your process, think in terms of these "flipped" and "shared" work products. If you do, you'll end up with 50 instead of 400 artifacts - and your engineers will be pretty pleased about that!
Finally, remember that CMMI isn't about "evidence." We shouldn't create evidence to "pass" an appraisal. We should execute the process appropriately, and the evidence will take care of itself.
http://www.broadswordsolutions.com/
First, welcome to the world of CMMI! It's a fascinating place where the more you learn about it, the more you'll understand how it can help improve software performance.
It sounds like you already know the basics: direct evidence is something that is the direct consequence of a process being performed. Note: these are the things that organizations who are trying to "game the system" create in order to "prove" they're performing at MLx. This, of course, is nonsense. It's FAR easier to just perform the process and accept what naturally falls out of it as the "right" evidence, but you just can't reason with some people!
The formula for achieving a "fully implemented" characterization on a practice is: Direct + (Indirect or Affirmation). So an indirect is not always required.
Indirect evidence is something that corroborates the direct evidence. If a task in a work plan and a meeting invitation on a calendar both refer to a code walkthrough, they are indirect evidence of the code review (e.g.; we planned for it and we invited people). Other indirect evidence may be meeting minutes, notes, and an agenda for the code review.
Using that example for VER SG2 the direct is the code review results and the indirect is any or all of the examples I gave.
When would this be flipped? Well, for VER SG1 we are "preparing" for peer reviews. Part of preparing is planning for them and inviting people, right? So the indirect for SG2 could be the direct for SG1! And an indirect for "prepare" - VER SG1) COULD be the code review results (they happened as planned, so we must have prepared for them).
There is a larger point here - one that will greatly reduce your overhead and increase efficiency. When planning and designing your process, think in terms of these "flipped" and "shared" work products. If you do, you'll end up with 50 instead of 400 artifacts - and your engineers will be pretty pleased about that!
Finally, remember that CMMI isn't about "evidence." We shouldn't create evidence to "pass" an appraisal. We should execute the process appropriately, and the evidence will take care of itself.
http://www.broadswordsolutions.com/
Subscribe to:
Posts (Atom)