New Grounds or New Holes ?
New years bring new perspectives, but looking ahead is useless without a sound footing. These plain figures may shed some light on the matter.
What: Requirements and Models
Projects should start with some agreement about expectations and commitments. Maturity on that regard can be estimated with:
- Number of projects started on agreed (actual meeting between stakeholders and providers) requirements, relative to all started developments.
- Number of agreed requirements as sanctioned by models, relative to all requirements.
- Number of agreed requirements that included quality plans, relative to all agreed requirements.
- Number of root artifacts linked to requirements items relative to all root artifacts.
- Number of requirements items linked to root artifacts relative to all requirements items.
The critical point here is the traceability between rough requirements as initially expressed, and structured and non ambiguous ones agreed upon after analysis.
Who: Stakeholders, Users, Developers
If their maturity is tobe assessed and improved, engineering projects should clearly distinguish between roles, even when they are played by the same persons or in tight collaboration. Here some clues to find out what happens:
- Planned meetings with differentiated positions relative to all planned meetings.
- Decision making meetings relative to all planned meetings.
- Non functional agreed requirements relative to all agreed requirements.
- Changes in agreed requirements linked to decision makers relative to all changes in agreed requirements.
The focus here should be on the definition of domains and use cases on one hand, traceability on the other hand.
When: Planning
As almost every human endeavour, projects’ success is governed by time and resources, in that case the delivery of system functionalities on time and on budget. On that regard, process maturity assessment should start with:
- Number of projects not deployed relative to projects started on agreed requirements
- Time spent in decision-making meetings relative to total project time.
- Actual resources relative to estimations after agreed requirements.
- Elapsed time between applications ready to be deployed and actually operational relative to projects duration.
The critical factors here are the traceability of model contents and the mapping of development flows into work units.
How: Tools
Engineering processes are meant to be supported by tools but that’s not necessarily for the best. A rough diagnostic can be based upon:
- Number of tools installed relative to the number of functions supported by those tools.
- Number of tools installed during the last year relative to the number of tools installed.
- Number of exchanges operated between tools relative to the number of tools installed.
Further assessment should be set within the MDA/MDE perspective according model transformation policies.
Nice Chistmas wish list! Some figures seem hard to compute (How: Tools)… In fact: in this post you point out how far from traceability projects so often are!