Software Metrics-III: An unorthodox metric
Posted: June 9, 2010 Filed under: Software Metrics | Tags: Agile, Methodology, Software, Waterfall Leave a comment »The feedback received on the project’s artifacts was related not only to the defects in the work products but a major part was non-defect comments (see diagram below). We were able to demonstrate to the customer through an analysis that all review comments were not defects. A detailed classification was also provided to substantiate the data. This enabled the customer’s project manager to go back to his team and guide them in controlling the non-defect review comments. This resulted in reduction of re-work by the team and enhanced the customer’s perception about the quality of the deliverables.
Key Steps:
- Consolidate all review comments in a single document (a tool like MS Excel can also be used).
- Categorize each review comment by the phase, artifact and type.
- Prepare a visual representation (example pie chart) of review comments and include as part of the weekly status
Outcome: Help the customer analyze the project feedback by categorizing and visually representing the review comments for a better perspective. This will help both the team and the customer by reducing re-work and enhancing perceptions about deliverables.
Agile or Waterfall?
Posted: July 7, 2009 Filed under: Tips and Tricks | Tags: Agile, Methodology, Software, Waterfall Leave a comment »There is a very insightful passage that Roger Pressman1 quotes from a paper by Nogueira and colleagues that needs to be quoted in full:
The edge of chaos is defined “a natural state between order and chaos, a grand compromise between structure and surprise”. The edge of chaos can be visualized as an unstable, partially structured state… It is unstable because it is constantly attracted to chaos or to absolute order.We have the tendency to think that order is the ideal state of nature. This could be a mistake. Research…. supports the theory that operation away from equilibrium generates creativity, self- organized processes, and increasing returns. Absolute order means the absence of variability, which could be an advantage under unpredictable environments. Change occurs when there is some structure so that the change can be organized, but not so rigid that it cannot occur. Too much chaos, on the other hand, can make coordination and coherence impossible. Lack of structure does not always mean disorder.
In a SharePoint based project, for example, I found that the management of user requirements can best be done by managing them in an agile based manner, even though the overall project was done in waterfall model. The diagram below (from the Ambysoft site) proved to be very useful.
- Use Case
- Description
- Priority (High/ Medium/Low)
- Development Complexity (High/ Medium/Low)
- OOTB/RUC/Configuration/ Customization
- Iteration in which the feature will be built
OOTB: out of the box feature available in SharePoint to be used without any changes
RUC: Reusable component already available
Configuration: an OOTB feature but needs significant amount of effort in configuring it
Customization: Feature that needs custom code to be written, for example, in C#
By keeping the above parameters visible to the customer and end users, I found that it was very easy to negotiate as each iteration of the system was built. Each time this re- stacking was done, a number of features that were initially high priority go down the stack as users became aware of the implementation complexity and its impact on timelines and cost. This negotiation is required because there are always the constraints of time and funds. This excel sheet based “requirements stack” is pretty much all one needs for projects based on platforms like MOSS 2007.
(1) Roger S. Pressman, Software Engineering: A Practioner’s Approach, 6th Edition (2005), page 77
