If it's software, then it's engineering

CMMI PP + PMC vs. Planning in XP

2007-10-22T01:53:00.000-07:00

A first mention is that there are some types of software projects for which a traditional approach to project management is more valuable than a hybrid between XP and traditional. For example, projects that:
· Involve mission critical or safety critical systems, where formal methods must be employed for safety or insurance reasons
· Are large projects which may overwhelm informal communication mechanisms
· Have complex products which continue beyond the project scope to require frequent and significant alterations, where a recorded knowledge base, or documentation set, becomes a fundamental necessity to support the maintenance.

Now, if you take Agile/XP Methodologies to a certain level of formalism, it can map, or at least it can go along with what they call traditional approaches, like CMMI, but it won’t be pure SCRUM, for example.

Talking about SCRUM, it is based on some statements that should be true, if one really wants to benefit from this method:

- the teams are quite small (5 to 8 people)

- the customer is almost part of the development team (this means, excepting the fact that the customer has to be willing to spend his time with this team, a lot of logistics and legal difficulties – access for the customer in the local network of the supplier, NDAs signed, legal contracts, etc, etc; what do you do when you have several customers for the same product?)

- under no circumstances you will change the delivery date of the current sprint – meaning: you keep the committed date and, in the worst case, you cut off some of the features (and what is the benefit of this when your team creates only a small part of a system, part that has to be integrated with another 10 parts; and one of the other parts is just not working without the feature you won’t deliver this sprint; and the integration of the system + system tests take a couple of days; and all this for a system that will not work … but the commitment has been kept)

One thing to remember is that “SCRUM of SCRUMs” is for the moment just a philosophy. No company has implemented yet more than 2 levels of SCRUM. Or, when you have a company with hundreds or thousands of employees, in any kind of matrix organization, it is pretty difficult to resume the entire flow in only two hierarchical levels of SCRUM.

Anyway, in my opinion the problem is not in finding the way to make a correlation between the typical work products in CMMI and the items that XP methodologies are using. You probably won’t use the physical cards, but you can use an e-workspace that allows cards creation, collection and control. You might even get more benefit from something like this than from the pure cards. And this is just an example. (The estimations using story points seem to me ones of the most accurate. )

So, the only problem is in being able to satisfy the initial input requests of the extreme programming.

Once this happening, I don’t think that there are too many CMMI sub practices that you cannot implement when being agile or extreme, but, depending on the complexity of the organization and of the projects one might find out at a moment in time that the simplicity that agile practices suppose is not so simple anymore :)

Software Estimations - PERT and adapted PERT

2007-10-07T01:10:00.000-07:00

PERT comes from Program Evaluation and Review Technique and it's a common practice in the software estimations world, used in both bottom-up and top-down estimates.

The main principle is to give 3 estimates for each functionality/feature/module, etc. that has to be implemented:
1. the Best Case estimate : this is the most optimistic estimation; it would occur if and only if everything goes perfectly (no risks, no issues, no late dependencies, no lack of resources, etc)
2. the Most Likely Case : this is an estimated time based on another estimation technique ("Count, Compute and Judge", "Industry, Historical or Project Data Calibration", "Expert Estimation", etc)
3. the Worst Case estimate : this is the time needed if everything would go wrong (identified risks become issues, for example)

The original PERT formula for computing the Expected Case estimate is:

Expected Case = [Best Case + 4xMost Likely Case + Worst Case]/6

Usually, the estimators (like any other human being) are more on the optimism side and, more than this, they use to identify in the very beginning only few of the possible risks and dependencies. This why an adapted PERT formula has been put in place (and I recommend it's usage especially when the estimates come from engineers):

Expected Case = [Best Case + 3xMost Likely Case + 2xWorst Case]/6

References:
Steve McConnell - "Software Estimations - Demystifying the Black Art"

Project Mandatory Documentation: Project Stakeholder List

2007-08-13T05:52:00.000-07:00

Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing.
--Dick Brandon

Definition: A Stakeholder is a person (or a group of people) involved in a certain project's implementation: be him/her a decision maker, a technical contributor, a high-importance supplier, a manager, a quality engineer, a tester, an integrator, a customer, etc.

Having a list like this is crucial for time saving when needing an answer, an input, a resource assigned, etc.

The Project's Stakeholders List is not a difficult to mantain document, especially when some directory applications or something similar are available in the organization. When nothing like this is present, then, even Outlook can be very useful - for getting the internal stakeholder's data updated.

When no automated framework is used for the projects documentation, a simple excel file can store all the needed information.

An usual way to get the excel is to perform what they call a "Stakeholder Analysis". Mainly, this consists of executing a couple of steps:

Identify all the people that affect or are affected by your project (see the definition above)
For each stakeholder, list the roles he/she has in the project
For each stakeholder, list the responsibilities he/she has in the project
For each stakeholder, rate the impact he/she has on your project (this column may be left blank at the beginning of the project and updated when having all the date) - from 1 to 5, for example
When applicable, for a stakeholder, list the inputs/approaches he/she needs in order to support you more
Complete the list with the contact details for each of the stakeholder and with the names of his/her manager and his/her replacer
The most important thing with a list like this is to be sure that all the people listed there know about their roles and responsibilities, so, their acknowledgement is mandatory.

Finally you'll get to something like this:

Defects' Root Causes: PARETO Chart Technique

2007-08-13T04:25:00.000-07:00

Considering that for a pool of defects, the root cause classification was performed using one technique or another - an example for doing this can be found here , it is the time now for deciding the priority of the root causes removal.

The best way to do this is to consider a PARETO chart in order to represent the classes of root causes:

Based on a chart like this, you can verify if you correctly defined the taxonomy for the root causes and/or the investigation of the root causes is correctly performed, since the 80-20 principle should be satisfied: 80 percent of the problems in a process result from just 20 percent of the causes.

After a short look at the PARETO representation, it shouldn't be difficult to decide which are root causes you want to adress 1st. In this example, ~61% of the defects are caused by the people (lack of) skills and the process (lack of process or improper use of process, etc). So, deriving corrective actions for these two causes and implementing them correctly will halve the number of defects in the future.

Finding the appropriate corrective actions is not an easy task and its success depends a lot on the skills of the people involved in deriving and implementing them.

Effective software reviews

2007-05-20T22:27:00.001-07:00

Definition: “A review of a work product, which passes stated entrance criteria, led by a moderator who is not the author,…, that uses product specific checklists, uses scenarios and/or other effective reading techniques, initiates re-inspection based on stated criteria, passes or fails the work product based on exit criteria, and adds to the base of historical data. “ (Software Technology Transition)

How is the effectiveness of an inspection measured? Mainly, through the percentage of the defects in the work product that have been identified. If an inspection is rigorously performed (it can be described by the above definition), the efficiency is about 50%, but it can go higher than 90%. Another measure is the time spent for detecting a defect. The more mature the teams, the less will be this time.

It is important to find out what is the lowest cost of defect detection and removal. Depending of the type of architecture, design and programming language, modular/unit testing or inspection can be the most efficient and the cost is the lowest. (The efficiency of testing is also given by the time spent for detecting a defect – test implementation and test running). What ever would be the answer, for sure a combination of these two techniques for defects identification is more efficient. It’s subject of discussion if the review should be performed after the testing or before because it depends very much of the typicality of the artifacts.

As “cost of the defect removal” came in discussion, just think about what it takes you to solve a defect before merge, integration and release and what it takes to solve it between integration and release (new dev branch, new regression testing, new integration, new sanity tests) or after the release, when reported by customer, or even found by yourself (all the above + all the release activities; when between customer and development there is a validation team, include also the retesting that has to be done by this team in hours/man).

In order to increase the efficiency of peer reviews, it is very important to have as little “process overload” as possible, to make sure that the individuals involved in the inspection know how and what to look for, why collecting the data they are asked to record is important and what it will be used for.

Let’s see a few industry figures regarding how much of various artifacts can be inspected during one hour in an efficient manner:

Code: upto 150LOC

Requirements: 3 to 8 pages

High level design: 3 to 8 pages per hour

Low level design: 6 to 16 pages per hour or 100 to 200 psedo code lines per hour

Usually, for each of the facts above, the preparation time is also one hour.

These being said, what happens if there is no time left for inspecting everything? Well, in this case, some previous experiences or, better, a historical database is very useful: there are some pieces of code, requirements and design that encapsulate more defects than the others. So, when time is not enough, reviewing these parts and the functionalities critical to the end-users assures a pretty good efficiency.

Summarizing, in order to have an efficient system of peer reviews, the following are mandatory:

No management pressure for the author (the person that evaluates the author in terms of performance management shall not attend the peer review, unless he/she is the only person with the required technical skills; and, in this case, he/she must be confident that is able to review only the product and not the author)

Clear entrance criteria:

What is the state of the artifact that will be reviewed?

What are the rules it must obey?

What is the amount to be reviewed?

What is uplift factor (how much of the total amount have been modified?)

Clear roles assigned to the attendees

All the attendees are prepared for the review

Checklists (not longer than a page) for each type of artifacts

Additional session and re-inspection setting criteria

Clear understanding of the data to be collected and the reasons for collecting it

The tools used for supporting the peer reviews ease the “process overload”. For sure, some data still have to be collected and recorded, but this is the only way to build the historical database which will help in the future for better estimations and enhancement of the peer reviews.

I’ll finish this article with the “Seven Deadly Sins of Software Reviews”, as they were identified by Karl Wiegers, from Process Impact - http://www.processimpact.com/ :
1. Participants don’t understand the review process
2. Reviewers critique the producer, not the product
3. Reviews are not planned
4. Review meetings drift into problem solving
5. Reviewers are not prepared
6. The wrong people participate
7. Reviewers focus on style, not on substance

Sw Design Metrics: Cyclomatic Complexity

2007-05-09T05:16:00.000-07:00

The cyclomatic complexity metric is a measure of the quality of a software design and also an indicator of the level of testability and maintainability of a program.

Cyclomatic complexity measurement was introduced by McCabe in 1976 and it indicates the number of regions in a graph. In the software world, it is the number of linearly independent paths that comprise the program. To determine the paths, the program procedure is represented as a strongly connected graph with unique entry and exit points.

The formula for computing the cyclomatic complexity is: M=V(G)=e-n+2p, where:

V(G) = cyclomatic number of G,

e = number of edges,

n = number of nodes,

p = number of unconnected parts of the graph

If this calculus seems too complicated:

Start with 1 for a straight path through the routine.

Add 1 for each of the following keywords or their equivalent: if, while, repeat, for, and, or.

Add 1 for each case in a switch statement.

Example Let’s consider graph represented in the picture, which can be seen as a simple function with two if statements:

As we can see, the cyclomatic complexity is a summary index of binary decisions.

The cyclomatic complexity metric is additive: the complexity of several graphs considered as a group is equal to the sum of the individual graphs' complexities. It ignores the complexity of sequential statements and it doesn’t distinguish different kinds of control flow complexity such as loops versus IF-THEN-ELSE statements or cases versus nested IF-THEN-ELSE statements.

The cyclomatic complexity is applicable both in the OOP and Non-OOP. To have good testability and maintainability, McCabe recommends that no program module should exceed a cyclomatic complexity of 10. Of course, it can vary between some limits based on different factors (application type, programming language, etc).

The SEI provides the following basic risk assessment based on the value of code:

Cyclomatic Complexity	Risk Evaluation
1 to 10	a simple program, without very much risk
11 to 20	a more complex program, moderate risk
21 to 50	a complex, high risk program
> 50	an un-testable program (very high risk)

1 to 10	a simple program, without very much risk
11 to 20	a more complex program, moderate risk
21 to 50	a complex, high risk program
> 50	an un-testable program (very high risk)

1 to 10 a simple program, without very much risk
11 to 20 a more complex program, moderate risk
21 to 50 a complex, high risk program
> 50 an un-testable program (very high risk)

Measuring the cyclomatic complexity is important as it is correlated with the code coverage and the test effort.

In order to obtain this metric it is enough to run almost any static code analysis tool.

In the object oriented programming, a set of six metrics was proposed in 1994 by Chidamber and Kemerer, based on the cyclomatic complexity, which later became the commonly referred to CK metrics suite:

Weighted Methods per Class (WMC): the sum of the complexities of the methods (complexity is measured by cyclomatic complexity).

Depth of Inheritance Tree (DIT): the length of the maximum path of a class hierarchy from the node to the root of the inheritance tree.

Number of Children of a Class (NOC): the number of immediate successors (subclasses) of a class in the hierarchy.

Coupling Between Object Classes (CBO): the number of classes to which a given class is coupled (a class is coupled to another one if it invokes another one's member functions or instance variables ).

Response for a Class (RFC): the number of local methods plus the number of methods called by local methods.

Lack of Cohesion on Methods (LCOM): The cohesion of a class is indicated by how closely the local methods are related to the local instance variables in the class. LCOM is measured as the number of disjoint sets of local methods. Lack of cohesion increases complexity and opportunities for error during the development process.

Presentations: Winning or Losing an Unique Opportunity (1st Part)

2007-05-09T05:05:00.001-07:00

As incredible as it may seem, the presentation skills are just some skills, that, exactly like all the other skills, may be enhanced with some (hard) work.

Nowadays, the presentations skills become more and more important; almost as important as the technical ones, because there’s no use of having great innovative ideas if not being able to explain and “sell” them to the others. And within this “others” are important and decision making people, that are not necessarily having the required technical background in order to understand everything only by watching a scheme and listening to a couple of words.

There are lots of types of presentations, playing different roles and having different goals, from getting a door open to communicating with managers, colleagues or friends, but they all have something in common: they have a goal. In order to achieve this goal, whatever it may be, some fundamentals must be kept in mind, before, during and after the presentation:

Þ Go in prepared—very few openings are worst than “ I didn’t have time to prepare”

Þ Believe in yourself and your idea—if you don’t, how can you expect the others to “buy” it?

Þ Know your purpose and communicate it—not having a clear objective makes it difficult to: shape the presentation, know what to ask for, know that you’ve achieved your goal

Þ Have a focused central theme and core points—the most important slide in a presentation is the one with the summary

Þ Know your audience and tailor your presentation to them—people are there listening to you because they have some needs; if you don’t address their needs, the presentation is 90% failed

Þ For time pressed audiences, summarize early—or you may learn that you haven’t had the time for the most important of your ideas

Þ Help them get it with powerful reinforcement—use stories, examples, statistics

Þ Make sure visuals add and do not impede communication—don’t add charts or schemes that will make you say: “I know you cannot read this” (then why is it here? Isn’t this presentation intended for the audience?)

Þ Stage with care, ‘cause Murphy’s there—everything that might go wrong, will go wrong, so, prepare for these situations too

Þ Practice and get good feedback—rehearse and you’ll not have surprises like not knowing what comes after or your time is gone and you haven’t finished yet.

Þ Make your delivery personal and passionate—the data does not speak for itself, you speak for data

Þ Keep alert and flexible—stay tuned to the audience and situation, then adjust your presentation rather go in the wrong direction only because that’s the way you started

Þ Anticipate and manage questions well—not answering half of the questions you are asked takes your presentation to failure; people remember (and talk) more about the bad moments

Þ Keep your perspective, enjoy—fun is contagious, a stressed presenter will scare the audience

Þ Remember you’re selling—you’re selling yourself and your credibility, then your organization, your information and your proposition.

Reference: “How to prepare, stage and deliver winning presentations”, by Thomas Leech