Frederick Brooks in his 1975 book The Mythical Man-month contends that adding more people to a behind-schedule project doesn't actually speed it up. On the contrary, ramping up resources adds up to the communication complexity (an overhead in fact) within the development group. This is because inducting new people involves a certain amount of time and resources to orient before they can be deployed for production. Weaning away time and resources from the project towards trainings / orientation results in further delay.
Monday, January 29, 2007
Saturday, January 27, 2007
Function Points
Function points are a measure of the size of computer applications and the projects that build them. The size is measured from a functional, or user, point of view. It is independent of the computer language, development methodology, technology or capability of the project team used to develop the application.
In the late seventies, IBM felt the need to develop a language independent approach to estimating software development effort. It tasked one of its employees, Allan Albrecht, with developing this approach. The result was the function point technique.
In the early eighties, the function point technique was refined and a counting manual was produced by IBM's GUIDE organization. The International Function Point Users Group (IFPUG) was founded in the late eighties. This organization produced its own Counting Practices Manual. In 1994, IFPUG produced Release 4.0 of its Counting Practices Manual. While the GUIDE publication and each release of the IFPUG publications contained refinements to the technique originally presented by Albrecht, they always claimed to be consistent with his original thinking. In truth, it is still very close considering the nearly two decades that have elapsed since Albrecht's original publication!
During the eighties and nineties, several people have suggested function point counting techniques intended to substantially extend or completely replace the work done by Albrecht. Some of these will be briefly discussed in this FAQ. However, unless otherwise specified, information in this FAQ is intended to be consistent with IFPUG Release 4.0.
The fact that Albrecht originally used it to predict effort is simply a consequence of the fact that size is usually the primary driver of development effort. The function points measured size.
It is important to stress what function points do NOT measure. Function points are not a perfect measure of effort to develop an application or of its business value, although the size in function points is typically an important factor in measuring each. This is often illustrated with an analogy to the building trades. A three thousand square foot house is usually less expensive to build one that is six thousand square feet. However, many attributes like marble bathrooms and tile floors might actually make the smaller house more expensive. Other factors, like location and number of bedrooms, might also make the smaller house more valuable as a residence.
Read more about Function Points here:
http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm
In the late seventies, IBM felt the need to develop a language independent approach to estimating software development effort. It tasked one of its employees, Allan Albrecht, with developing this approach. The result was the function point technique.
In the early eighties, the function point technique was refined and a counting manual was produced by IBM's GUIDE organization. The International Function Point Users Group (IFPUG) was founded in the late eighties. This organization produced its own Counting Practices Manual. In 1994, IFPUG produced Release 4.0 of its Counting Practices Manual. While the GUIDE publication and each release of the IFPUG publications contained refinements to the technique originally presented by Albrecht, they always claimed to be consistent with his original thinking. In truth, it is still very close considering the nearly two decades that have elapsed since Albrecht's original publication!
During the eighties and nineties, several people have suggested function point counting techniques intended to substantially extend or completely replace the work done by Albrecht. Some of these will be briefly discussed in this FAQ. However, unless otherwise specified, information in this FAQ is intended to be consistent with IFPUG Release 4.0.
The fact that Albrecht originally used it to predict effort is simply a consequence of the fact that size is usually the primary driver of development effort. The function points measured size.
It is important to stress what function points do NOT measure. Function points are not a perfect measure of effort to develop an application or of its business value, although the size in function points is typically an important factor in measuring each. This is often illustrated with an analogy to the building trades. A three thousand square foot house is usually less expensive to build one that is six thousand square feet. However, many attributes like marble bathrooms and tile floors might actually make the smaller house more expensive. Other factors, like location and number of bedrooms, might also make the smaller house more valuable as a residence.
Read more about Function Points here:
http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm
PCMM
People Capability Maturity Model® Framework
The People Capability Maturity Model ® (People CMM ® ) is a tool that helps you successfully address the critical people issues in your organization. The People CMM employs the process maturity framework of the highly successful Capability Maturity Model ® for Software (SW- CMM ® ) [Paulk 95] as a foundation for a model of best practices for managing and develop- ing an organization™s workforce. The Software CMM has been used by software organizations around the world for guiding dramatic improvements in their ability to improve productivity and quality, reduce costs and time to market, and increase customer satisfaction. Based on the best current practices in fields such as human resources, knowledge management, and organizational development, the People CMM guides organizations in improving their processes for managing and developing their workforce. The People CMM helps organizations characterize the maturity of their workforce practices, establish a program of continuous workforce development, set priorities for improvement actions, integrate workforce development with process improvement, and establish a culture of excellence. Since its release in 1995, thousands of copies of the People CMM have been distributed, and it is used world wide by organizations, small and large, such as IBM, Boeing, BAESystems, Tata Consultancy Services, Ericsson, Lockheed Martin and QAI (India) Ltd.
The People CMM consists of five maturity levels that establish successive foundations for continuously improving individual competencies, developing effective teams, motivating improved performance, and shaping the workforce the organization needs to accomplish its future business plans. Each maturity level is a well-defined evolutionary plateau that institutionalizes new capabilities for developing the organization™s workforce. By following the maturity framework, an organization can avoid introducing workforce practices that its employees are unprepared to implement effectively.
Courtesy: SEI CMU
Cost of Quality
Cost of Quality (COQ) includes all costs incurred in the pursuit of quality or in performing quality related activities. Cost of quality studies are conducted to know the current COQ and to find out the opportunities for reducing the costs of quality and to provide a basis for comparison.
Types of COQ
Quality costs may be divided into:
1. Preventive Cost
2. Appraisal Cost
3. Failure Cost
QA Vs. QC
Software Quality Assurance (SQA) is defined as a planned andsystematic approach to the evaluation of the quality of andadherence to software product standards, processes, and procedures. SQA includes the process of assuring thatstandards and procedures are established and are followed throughout the software acquisition lifecycle. Compliance with agreed-upon standards and procedures is evaluated through process monitoring, product evaluation, and audits. Software development and control processes should include quality assurance approval points, where an SQA evaluation of the product may be done in relation to the applicable standards.
Quality assurance consists of the auditing and reporting functions of management. The aim of quality assurance is to provide management with the data necessary to be informed about product quality is meeting its goals.
How is it different from Quality Control?
Quality control is the process of variation control. Quality control is the series of inspections , reviews and tests generated throughout the development lifecycle to guarantee that each work product meets the requirements placed upon it.
Quality control activities may be fully automated, manual or combination of automated tools and human interaction.
Quality assurance consists of the auditing and reporting functions of management. The aim of quality assurance is to provide management with the data necessary to be informed about product quality is meeting its goals.
How is it different from Quality Control?
Quality control is the process of variation control. Quality control is the series of inspections , reviews and tests generated throughout the development lifecycle to guarantee that each work product meets the requirements placed upon it.
Quality control activities may be fully automated, manual or combination of automated tools and human interaction.
Subscribe to:
Posts (Atom)
