How many times we have been asked this question, “How long you think it will take for you to write this code” or “how much does it cost to develop” and we go scrambling, searching for some figures and randomly guess and throw a number based on our gut feeling at the spur of the moment. It may be so that, at times, we may have to provide such figures representing a large team. Well, at the end, we will only be puzzled to ask ourselves "did I tell the right figure?"
Would it be nice if we had real parameters handy enough to provide estimate on metrics collected from previous projects such as project size, KLOC (Lines of Code in Kilobytes) /projects, team size, cost, defect density etc. But how do track projects in terms of above parameters?
In order to track these parameters, there are different processes followed in many teams/companies by adhering to some flavor of Software Development Life Cycle (SDLC) process. One the most successful processes industry-wide is Team Software Process (TSP), recommended by Carnegie Mellon University, which technically is the next higher model to Capability Maturity Model (CMM). In fact, TSP is implemented by few internal teams in Microsoft including my team (SMIT - Arsenal & Infoweb).
What are the benefits we can derive by implementing Team Software Process (TSP) across Development or Testing teams
IT or Engineering groups use the TSP to apply integrated team concepts to the development of software-intensive systems. A four-day launch process walks teams and their managers through
How does TSP actually work?
First of all, all the team members undergo Personal Software Process (PSP) training which will ensure that each individual is exposed to a set of standard practices laid out for each phase - Envisioning, Design, Stabilization, Deployment, Production - of the SDLC process. PSP offers role-based training that is focused for various roles; Developers, Testers, Program managers and Product mangers. Once the team completes PSP, they will be ready to embark upon TSP launch.
When a project is awarded, the team internally groups together and kicks-off a TSP launch. Assuming that business requirement and functional requirement are signed-off by management team, typically, a TSP launch spans for about 3-5 days, where the whole project is broken-down into several smaller modules. Each module is assigned a set of tasks such as design document, design inspection, coding, code-walk through, code inspection, unit testing, integrated testing and post-mortem depending on how many tasks the team collectively agrees to add for each task. Tasks will vary depending on the functional role; developer, tester, Program manager and so on. Now, time is allocated to each task (usually measured in hours), called task hours. Apart from this, there are other non-project related tasks like reading e-mails, attending mandatory company meetings, filling TSP worksheet etc., which are classified as non-task hours. After identifying the number of total task hours and non-task hours, they are rolled-up to derive the total estimated project time. Usually if the team is launching TSP for the first time, then task hours (number of hours associated to a task) are based on some gut feelings (more of an average coding time by the team). Otherwise it will be directly imported from previous historic data. Then these tasks are evenly distributed to team members. With the total project time, number of resources in the team, dependency of tasks on other tasks, the team comes out with a project plan and schedule (several milestones dates, including start, design complete, code complete, end date and so on). There are times when the management might have some release dates in which case, few alternative plans and schedules are created by adding more resources or reducing the number of tasks associated to a module to meet management goals.
Also, during the TSP launch, there are several key assumptions, decisions, risks, mitigation identified by the team, recorded by a time-keeper and documented for future references. These factors are submitted to the management team along with the project plan and schedule for approval.
After the launch, the TSP provides a defined process framework for managing, tracking and reporting team's progress on a weekly basis. Each individual is handed-over a worksheet that will contain a filtered view of individual’s tasks. When the individual sets off to work on a module, several tasks are opened in the worksheet, once each task is completed, it is closed. Whenever a task is closed, it is attributed towards progress of the project, in essence, called project earnings. Then all individual’s worksheet is consolidated and rolled-up at project level to report progress of projects, defect metrics, Lines of Code (LOC), forecasting and other metrics. In addition to this, there are also other tools to, capture errors, record time spent on each task, count LOC for methods or functions (LocMeth) etc.
By implemented TSP, an organization can build self-directed teams that plan and track their work, establish goals, and own their processes and plans. These can be pure software teams or integrated product teams of 3 to 20 engineers. TSP will help your organization establish a mature and disciplined engineering practice that produces secure, reliable and quality software. TSP is also being used as the basis for a new measurement framework for software acquirers and developers. When it comes to meeting cost, schedule and performance objectives, program managers need
The Integrated Software Acquisition Metrics (ISAM) project was initiated with the assumption the TSP can be the foundation that program managers need to answer questions like: Where are you in your program? How do you know for sure? ISAM is developing pilot studies to create an effective, common measurement framework for acquirers and developers based on TSP and PSP practices. Managers will be able to use data from TSP teams so that they can answer these questions with confidence.
For more details on PSP, TSP and CMM, you can visit these sites…