1001655

Introduction: Project measures should be identified and evaluated carefully, insufficient measures and analysis may lead to project incomplete. Many measures not good for the project as it increases complexity and makes analysis confusing. Definition of the measures depends upon type of organisation and project goals. If we do not measure, then there is no way to track our processes or program. Measurement enables us to assess the status of program and processes and determine whether it is in trouble or need any process improvement. Early detection of problems can be done with the help of good measurement program and as it also provides quantitative clarification of complex development issues. Metrics has the ability to identify and resolve critical risk issues before their occurrence. Measurement is important for strategic, program and technical level. Before defining measures, the first task is to established organization/projects goals, then identification of questions and finally identification of measure (Woodword, 2009). For successful software product development, six commonly used measures are identified which includes, Lines of Code, Defects, Schedule duration, Efforts and Function points. This document includes definition, descriptions, utilization and recommendation of each measures described above. Managers need to work on measures described below for successful product development project: Product Development Measures Function Points  Definition: The volume of software functionality contained in a application quantified by the unit of measure known as Function point (WOODWORD, Steven M, 2009). It expresses the amount of business functionality in an application program which is provided to the user.  Description: The International Function Point Users Group (IFPUG) provides framework and guidelines for consistent functional sizing of any software. Function point depends upon the functionality of the application using function point like military weapon system, financial applications. Function points are the weighted sum of different factors related to the user requirements. Five different factors related to the user requirements (ALBRECHT, A.J, 1979): - Inputs - Outputs - Logic - Inquiries - Interfaces  Utilization: We need to develop, enhanced and support the software functionality; function points are the key units to assess project size, managing risk and establishment of estimates. In order to count function points, we need to first tally functions which are inputs, outputs, logic, inquiries and interfaces;

1001655 then multiplied by values established. Product total then adjusted by degree of complexity, which are domain specific and depends upon number of factors. Inputs Outputs Inquiries Files Interfaces Unadjusted function point Simple 2X 4X 1 2X 4X 5X Average 5X 2 3X 3 2X 7X 1 9X Complex 4X 2 3X 7X 10X 3X 1 Total 18 10 0 7 3 = 38

Table: Function Point Computation

Functions points includes many drawbacks like, it is difficult to estimate function points during the early stages of System Development, complexity factor mentioned above in equation depends upon analyst judgement, which is subject to change according to personnel.  Recommendation: Function points is a standardised process by an internationally recognition organisation (IFPUG) and should be the core measure for software product development. Function points helps technical team in delivering software functionality which is most important factor while developing product that satisfies user needs and lastly helps business in building customer base. Effort Hours  Definition: Number of hours required to complete software activity and tasks associated with software development is known as Effort hours. It is important to know effort hours so that we can assign resources to determine project duration and estimation of labour and non-labour costs.  Description: Project effort hours should be tracked appropriately in order to satisfy project requirements. There are no international standards established for effort hours like Function points. Every organisation needs to check which should be included or excluded from the project like, vacation time, training, management.  Utilization: To monitor progress and report productivity, effort hours will be the measure. It can be estimated with the help of organisation historical data as well. Collection of this measure should be consistent to ensure accurate performance analysis. Process to estimate total effort required for product development (MOCHAL, 2006): 1. Determination of accurateness of estimates More accurate estimate requires more details with time, if rough order of magnitude estimate (-25% - +75%), shows completeness of the work more

1001655 quickly with minimum amount of detail at high level. With estimate within 10% requires more time with work at a low level. 2. Initial estimation There are many ways to create initial estimation with the help of work break down structure, expert opinion, analogy etc. Word break down structure is dynamic tool which can be revised according to the project requirement. It is a tool to define and group projects discrete work tasks and elements. It may be product, data, a service or combination. It starts with objective and then subdivided into managerial components in terms of size, duration and responsibility (HAUGAN, 2001). Work break down structure provides universal platform for the ordinary development of the overall preparation and control of a project. It divides work into definable augmentation from which assertion of work can be developed and technical, schedule, cost and labour hour coverage can be established (AMITESH, 2010).

Source: Work breakdown structure, Amitesh, 2010

A Workplan Example
Work Plan Information Name of task Start date Completion date Person assigned Deliverable(s) Completion status Priority Resources needed Estimated time Actual time Example Perform economic feasibility Jan 10, 2008 Jan 20, 2008 Project sponsor: Rahul Jain Cost-benefit analysis Open High Spreadsheet 16 hours 14.5 hours

Source: (ALAN DENNIS, Barbara Haley Wixom, and Roberta Roth, 2006)

1001655

3. Addition of specialist resource hour Part time and specialist resources need to be included while estimating effort hours. This includes freelancer, training, administrative, procurement and legal associates. 4. Rework (Optional) Uncertainties are everywhere and even in real projects as well. Rework is optional during estimation of effort hours; however, never underestimate rework as many projects sometimes ended up with rework. 5. Add Project Management Time It included effort required to successfully manage project. Addition of 15% in effort hours required for project management. For example : If project estimate 10,000 hours (5-6 people) then add 1500 hours for full-time project manager. 6. Contingency hours Uncertainty and risks associated with the estimate comes under contingency hours. For work which is not well defined, we need to add 50% or 75% to reflect contingency. Contingency can be reduced to 5% for the people who worked in product development project before. 7. Total effort Calculation of total effort can be done by adding all the detailed work components. 8. Review and adjustment After addition of total efforts, sometime estimation become too high or low, if effort hours seems improper, its require to review and do the necessary adjustment in order to fix the effort hours problem. 9. Documentation of assumptions All assumptions should be documented while estimating effort hours, sometimes its important to document.  Recommendation: Accuracy in accounting time critical in order to evaluate accuracy of estimates. Establishment of specific guideline needed in organisation. Scope of activities to be included should be agreed upon early in the project life cycle. Project manager required to create work break down structure in order to get detailed estimation of cost and control along with scheduled development. Cost  Definition: Funds requires delivering and developing the software solution comes under Cost.  Description: In order to estimate cost, we need to multiply effort hours with hourly rate. Many additional costs involved such as hardware/software installation, maintenance and support. Documentation of costs which should be included or excluded in the project is required and it is also an important measure for product development.  Utilization: Cost analysis depends upon the appropriateness of costs estimated, collected and tracked. Constructive Cost Model (COCOMO) is a software cost estimation model by Barry Boehm. COCOMO model used

1001655 basic regression formula and some perimeters (derived from previous project). COCOMO II allows us to estimate the cost, effort and schedule when planning for new software product development. This model is mostly used for analysis and forecasting. This model comes in three forms: simple, intermediate and detailed. In order to use this model, first we need to decide type of system we building (Key Software Metrics, 1999): Organic: Refer to separate in-house DP system Embedded: Refers to real time systems Semi-detached: The system between organic and embedded For example:
Effort Applied = ab(KLOC)bb Development Time = cb(Effort Applied) db [months] People required = Effort Applied / Development Time [count] KLoC- estimated number of thousands of delivered lines of code for the project ai, bi are

Software project Organic Semi-detached Embedded

ai bi 3.2 1.05 3.0 1.12 2.8 1.20

 Recommendation: Which costs should be included and which should be excluded need to specify in advance during consideration. Purchasing costs of hardware/software, maintenance and customization need to be agreed upon early in the project. Project Duration Days  Definition: Project duration days is the measure which is used to calculate calendar days from the beginning of requirements through implementation. It is the period of time when efforts of project manager and team members applied to accomplish project successfully (Project Management Duration,2011).  Description: There is no industry standards defined for project duration, we need to decide what start/end dates to track progress, with the establishment of criteria.  Utilization: Project duration directly connected to the amount of effort needs to be performed during the project to achieve primary and secondary goals. Projects with smaller calendar days sometimes cost higher with high defects rate. It is primarily due to the ineffective communication and coordination between teams and people. Project duration is required measure while evaluating project progress. Simple process for estimating project duration: 1. Estimate the productive hours per day

1001655 We need to determine, how many productive hours of work each person working per day. On an average 6.0 to 6.5 productive hours per day after excluding socializing, breaks, bathroom breaks etc. Factor in multitasking productivity loss for part time resources Further reduction in productivity caused when one person working on multiple projects or combination of projects. Person shared on two or more unrelated efforts and its time consuming process to stop one task and start another. Example: if one person working on two projects for 20 hours each week, then this led to reduction in productivity by 10%. Determination of resources to each activity More resources led to faster completion of task, two resources will complete task faster than assigning two people. Factor in available workdays Non-project time which includes holidays, training and vacations need to be scheduled and accounted in advance. Non full time resources Half or 50% of resources will consume twice time to do any individual activity. Calculate delays and lag-times Delays caused by vendors in delivering resources should be taken into consideration. These are the activities which caused small effort hours but long durations. Identification of resource constraints Identification of activities that can be done sequentially and parallel need to be defined while building an initial work plan. All parallel activities can be done in parallel if we have enough resources. If there is lack of resources then we need to switch resources from parallel to sequential, this result in extending project duration. Documentation of assumptions Documentation of all the assumptions alone with estimation is required.

2.

3.

4.

5.

6.

7.

8.

 Recommendation: Project duration should be tracked, by predefined definitions, When the clock starts and when the clock end. Lines of Code  Definitions: Lines of code or Kilo lines of code refers codes which need to be executed. A line of code is easy to measure and impossible to interpret, mostly used to measure complexity or productivity. Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs (Bill Gates).  Description: LOC should be executable line of code not physical. Things like comments and black spaces should not be counted in LOC. Lines of code are the traditional way to measure size of application.  Utilization: Line counts are different for different programming languages. Line of C++ code is not same as code of VB. Implementing lines count in VB6 is more complex than VB.Net, as well as, while measuring programmer performance, lines count is not the perfect metric. It is useful to measure productivity but programming style can have impact on the values.

1001655 There are many ways to count lines of code, LOC seems like simple concept but its not, there are numerous ways to count LOC. Below mentioned are the ways to count LOC(Project Metrics,2011): Metric Physical lines Physical lines of code Logical Lines Logical lines of code Statements Supported as Lines Not supported LLines LLOC Description This metric counts the physical lines but excludes VB form codes and descriptions It counts lines but excludes empty lines and codes. It also known as SLOC (Source lines of code) It covers one or more physical lines. This contains actual source code excluding empty lines or comment lines. This is statement count, VB programs contains one statement per lines.

STMT

 Recommendation: It is easy to get LOC in languages such as COBOL, but it is very difficult when coding in PowerBuilder or VB plus at the end of project completion, it is difficult to get LOC. Therefore, concerns should be made when using LOC for product development. Defects  Definition: Defects are the problems or error that produces unsatisfactory results. Defects need to be consider while defining measures for product development as they  Description: Defects are referred by different names like Bugs, problem or supplemental features. Defects cane be anywhere, not only in software, it could be in design, documentation or requirement analysis. Origin (source), category and severity level (impact).  Utilization: Defects are useful in estimating quality of the software program and allows us to take required needed corrective actions during product development phase. This information is useful is forecasting maintenance staff levels, because, applications which are more prone to defect requires more support staff. It is recommended to use defect metrics on an ongoing basis to keep track on how product quality is shaping up. Root cause analysis provided useful information to improve requirements. Defect Analysis template (BORYSOWICH,12):

DEFECT CAUSAL ANALYSIS ACTION ITEMS

Project Name:

Meeting Date: Group Name: Meeting Date:

Identifier:

Project Name:

1001655

Action Item Number

Source Defect Number

Date Assigned

Action

Assigned To

Due Date

 Recommendation: Finding defects before product reaches customer is good thing for the business. As it increases customer loyalty and helps business in making strong customer base. Descriptions of Roles and Responsibilities (WHITSON, 2003):
Role
Project Sponsor

Responsibilities

Participant(s)

    

Steering Committee

  

Final decision-maker and tie-breaker Provide project oversight and direction Review/approve project elements Manage department resources Approves major funding and resource allocation strategies, and significant changes to funding/resource allocation Resolves conflicts and issues Provides direction to the Project Manager Review project deliverables

xxxxxx

xxxxxxx

Project Manager

        

Manages project in accordance to the project plan Serves as liaison to the Steering Committee Receive guidance from Steering Committee Supervises consultants Supervise vendor(s) Provide overall project direction Direct/lead team members toward project objectives Handle problem resolution Manages the project budget

xxxxxxx

1001655
Role
Project Participants

Responsibilities

Participant(s)

         

Understand the user needs and business processes of their area Act as consumer advocate in representing their area Communicate project goals, status and progress throughout the project to personnel in their area Review and approve project deliverables Creates or helps create work products Coordinates participation of work groups, individuals and stakeholders Provide knowledge and recommendations Helps identify and remove project barriers Assure quality of products that will meet the project goals and objectives Identify risks and issues and help in resolutions Lend expertise and guidance as needed

To be identified by Steering Committee

Subject Matter Experts

To be identified by Steering Committee

Effective coordination of activities is required in product development. There is need to develop communication plan, which includes communication methodology. Communication methodology utilizes three direction of effective communication: - Top down: All contributors of in this product development project intellect executive support. Executives need to verbalize straight to all levels of organisation. - Bottom Up: It is important to communicate in a way in which solutions were created. - Middle-Out: Full support at all levels where changes will have to be implemented. Communication outreach Follow are the list of communication events needs to create in this project: - Monthly Status Report: Project manager need to provide monthly status report to the Steering committee. Report should include: y Summary to task completed in previous month y Summary to task scheduled for next month y Summary of issues status and resolutions - Monthly Steering committee meeting: This meeting should be help in once every month and all members of Steering committee mandatory to participate in this meeting. Project manager required to send status report to each member of committee prior to meeting time.

1001655 Monthly project Team Status meeting: Should be held every month and every member of project team required to participate. Project manager need to send status report to all team member prior to meeting. Website Use: Project manager need to post information about project on the projects website.

10

Summary: Above mentioned are the key measures which is require for software product development. Project managers needs to careful analyse these measures. Managers are required to work on measures described above while coordinating with other product development activities.

References:
ALAN DENNIS, Barbara Haley Wixom, and Roberta Roth. 2006. Project Management. [online]. AMITESH. 2010. Work Breakdown Structure. [online]. BORYSOWICH, Craig. 12. toolbox.com. [online]. [Accessed 10 May 2011]. Available from World Wide Web: "http://it.toolbox.com/blogs/enterprisesolutions/defect-causal-analysis-action-item-template-17591" HAUGAN, Gregory T. 2001. Effective Work Breakdown Structures. Management Concepts, p.17. Key Software Metrics. 1999. [online]. [Accessed 10 May 2011]. Available from World Wide Web: "http://www.eecs.qmul.ac.uk/~norman/papers/qa_metrics_article/section_5_key_metr ics.html" MOCHAL, Tom. 2006. Use this process to estimate effort hours. [online]. [Accessed 10 May 2011]. Available from World Wide Web: "http://www.techrepublic.com/article/use-this-process-to-estimate-efforthours/6142489" Project Management Duration. [online]. [Accessed 10 May 2011]. Available from World Wide Web: "http://www.taskmanagementguide.com/planning-tasks/projectmanagement-duration.php" Project Metrics. [online]. [Accessed 10 May 2011]. Available from World Wide Web: "http://www.aivosto.com/project/help/pm-loc.html " WHITSON, Debbie. 2003. Project Plan. [online]. WIKIANSWERS. 2011. COCOMO Model II Formula. [online].