Software Project Management Metrics - Coursework Example

ID # Software Project Management Metrics In the past few years, software project management has emerged as a very helpful practice. The majority of software development firms uses software project management in different ways to develop their products. In this scenario, a process is followed to develop a product and software project management principles are applied in this process. It is an admitted fact that the quality of a product heavily relies on the quality of a process. In the past few years, the majority of software development firms has started realizing this fact and they have started to put considerable effort to improve the capabilities of their software processes. In this scenario, the majority of software development firms follows well-known industry standards such as ISO/IEC 15504 and CMMI. Additionally, in an attempt to improve the quality of developed products as well as their firm’s development potential and efficiency, a large number of approaches have been suggested in previous researches. Without a doubt, process assessment allows software development firms to understand their process capability and productivity, and taking into consideration the results of this assessment that firm can look forward to an improvement in its development processes by determining and understanding the strengths, weaknesses and risks associated with its processes and how to prevent them. Though, Software Engineering Institute’s CMMI (capability maturity model integration) is specifically designed to measure the capability of processes of software development firms. In this scenario, a software development firm with high level maturity level is believed to have more mature software development process as compared to software development firms those having a lower maturity level. Hence, these firms can develop software products more constantly. In their research article, (Hwang) define software process capability “as the potential of a software development firm to develop software products consistently and predictably.” In the same way, a capability level refers to a wide collection of process characteristics and measures that work in cooperation to bring a significant improvement in the capability of a software development firm to carry out a software development process. In addition, CMMI is based on five levels and each level is intended to offer a major improvement of capability in the performance of a process (Hwang; VanHilst, Garg and Lo; Pressman). The basic purpose of this research is to present a detailed analysis of software project management metrics. This paper discusses various aspects associated with software project management metrics. What is a Metric? A software metric can be defined as any measurement or calculation utilized to measure some experimental element of efficiency and performance of a software development process. Additionally, normally software development firms collect software metric openly through inspection, for instance delay in delivery (usually measured in number of days), or number of defects detected in the software product. In addition, some firms derive their software metrics from steadfastly observable measures, for instance or a cost performance index (CPI) or bugs detected per each thousand lines of code (KLOC). However, software metric is acknowledged as an indicator or a key performance indicator (KPI) when it is used to monitor system with the purpose of determining project or programme progress (Lee). Basically, software metrics are based on quantitative measures or data associated with various aspects of software development. The research has shown that these software metrics provide an excellent support for software project management processes. In this scenario, they are concerned with the four functions of management in the following ways: Planning Function: During this process, metrics can be used for training planning, cost estimating resource planning, budgeting and scheduling (Center of Software Engineering; Kharytonov). Organizing Function: Metrics can be used to measure schedule and the size of the project hence they can strongly influence a projects organization (Center of Software Engineering; Kharytonov). Controlling Function: Metrics can be used to determine status and keep track of software development tasks in order to determine their compliance with plans (Center of Software Engineering; Kharytonov). Improving: One of the most important uses of metrics is for process improvement. The majority of software development firms uses them as a tool for improving their software development process and identifying where they should put improvement efforts. They get an idea of where they should concentrate and determine the effects of process improvement efforts (Center of Software Engineering; Kharytonov). Metrics Management In the past few years, the trend of studying and apply metrics has reached to a high level. In fact, it has given birth to a complete subfield of study known as metrics management. Basically, there are three main categories of project metrics (Lee): Pure project management measurements (for instance cost and accuracy estimation). Project success indicators (for instance measuring customers and stakeholder satisfaction). Business success indicators (for instance measuring return on investment). Figure 1most common tactical measures people want to be updated about, Image Source: (Lee) In addition, it is critical for the project management team to keep in mind time factor when they are going to report metrics to management. Without a doubt, actual failure or actual success will not be noticeable until long after a project is officially acknowledged as completed. For instance, it is possible that a recently launched software product can become a huge disappointment six months after it is installed for completing business tasks, when it is ultimately used by its intended usage targets (Lee). Metrics for Software Project Management In their paper (Bouwers, Visser and Deursen) discuss various concepts associated with software metrics. The authors take into consideration a question “is software metrics helpful tools or a waste of time? According to their point of view, software metrics are very helpful tools that facilitate software development firms all the way through the software development lifecycle to attain defined goals however in order to take this benefit a software development firm must be capable of using them in the approved manner, for the reason that they also have the power to de-motivate project teams and lead software development in the wrong way (Bouwers, Visser and Deursen). Software Metrics Management: A Source of Guidance There is a well-known phrase “you get what you measure”, which certainly applies to software project teams. Regardless of the way a metric is defined, once the software development firm starts using it to assess a team, the value of this metric starts to grow toward the preferred value. Hence, in order to attain an objective, a software development firm needs to constantly measure elements and tasks need to be completed in order to attain the desired objectives as well as plot these measurements in a place where these measurements are able to be seen by the project team. In an ideal scenario, these desired objectives are plotted at the side of the present measurement to point to the difference between the current progress and desired objectives. For instance, there is a project wherein the runtime efficiency of a specific use case is very critical. In this scenario, a software development team can develop a test which demonstrates the measurement of execution time of the use case on a daily basis. Hence, by providing this every day data point alongside the preferred result as well as ensuring that the project associates take notice of this calculation, it turns out to be obvious to project team members whether the desired objectives are being achieved or whether the current project progress is directing the team beyond the desired objectives (Bouwers, Visser and Deursen). Though, this entire situation seems straightforward, however there can be serious challenges if this process is not followed and executed in the approved manner in a number of subtle manners. (Bouwers, Visser and Deursen) discuss a case to clarify this situation. In this case, customers are not satisfied for the reason that they point out a wide variety of problems in a product that need to be solved in an appropriate manner. However, in order to deal with this issue project team starts tracking the normal resolution time for issues in a delivery. In this scenario, they follow the logic that resolution time with the lowest average time will increase customer satisfaction. Unluckily, it is not the truth. First all of, an attempt to resolve issues quickly can lead to unnecessary side effects such as, an immediate resolution can cause longer fix times afterward as a result of incurred technical reasons. Second, an attempt to resolve such issues in a short period and notice will not help the customers in view of the fact that if these resolutions are demonstrated simply once a year. As a final point, customers will be more satisfied and happy when the developed product does not require any fix in any way (Bouwers, Visser and Deursen). To be precise, a software development firm cannot ensure the delivery of a completely perfect product in the first place. In this scenario, the use of software project management metrics allows a software development firm to stay focused toward a desired objective. In addition, this objective can be defined either a sophisticated business intention (“for instance the expenses required to maintain this system should be less than $200,000 per year”) or it can be defined precisely (“such as the system shall load all the pages within 5 seconds”). On the other hand, the use of software project management metrics can also prevent a software development firm from attaining the desired objective, relying on the challenges met by the firm during development. It is suggested that a software development team should not use a metric in its present condition; however it should be used by placing it inside a framework that supports a significant assessment. In the same way, the there should be an obvious relationship between the metric and the desired objective needs to be attained from the system implementation for the reason that it allows a software development firm to make use of the metric to plan particular tasks and actions that they will need to perform in order to attain the desired objective. Thus, a software development firm must ensure that the planned tasks and actions are targeted in the direction of attaining the fundamental goal in place of simply improving the value of the metric (Bouwers, Visser and Deursen). Moreover, some researchers suggest that software development firms should make use of a variety of software project metrics in order to get fruitful results. Since, making use of simply single software metric to determine the progress and capabilities for instance whether a software development team is on the right track toward achieving defined objective minimizes the scope of that objective to a single dimension (such as the metric that is presently being measured). It is an admitted fact that a goal is always multi-dimensional. In this scenario, software project knowledge and experience continuous tradeoffs between providing preferred nonfunctional and functional requirements like that performance, security, maintainability and scalability. Hence, there is the need for using a mixture of a variety of metrics in order to make sure that desired objective, along with specific tradeoffs, is met. For instance, it is easier for the software development team to examine small code base, however if this code base encompasses extremely complicated terminologies and code, then it will be difficult for the team to make changes. Additionally, besides offering a more objective and effective vision of a defined objective, the use of multiple metrics can also help a software development team identify the basic reason of a problem. In view of the fact that the use of a single metric normally brings out only a single sign, on the other hand a mixture of metrics can assist in diagnosing the real problem within a project. Though, the use of a single metric oversimplifies the define objective, on the other hand making use of a mixture of metrics makes it difficult (or even impossible in some cases) to attain the desired objective. In fact, it is a complicated and challenge job to identify the appropriate mixture and balance among a wide variety of software metrics, also it is terrible for confidence when a software development team comes to know that whenever they make any change it causes the decline of in any case one metric. Moreover, sometimes the use of metrics degrades the dedication of software development team. For instance, when a software development team sees that the value of a metric is a long way from their established objective, then they start realizing, “they will never reach their destination, in any case,” and as a result pay no attention to the metrics altogether (Bouwers, Visser and Deursen). Recommendations Without a doubt, software project management metrics are very helpful tools for both software development firm and project team. However, to make best use of these metrics and get maximum benefit from the complete potential of metrics, software development firms and project managers should keep the following suggestions in mind (Bouwers, Visser and Deursen): It is an admitted fact that software project metrics are very helpful tool for attaining established objectives however following these metrics should not be an objective of the firm as well as a team. In addition, try to add meaning to each metric by putting it in a framework and effectively describing the connection between the established objective and metric, as well as do not make the metric an objective in itself (Bouwers, Visser and Deursen). It is a best practice to adopt a mixture of metrics to determine and track a variety of dimensions of desired objective; however the firm should avoid de-motivating a team by making use of too many metrics (Bouwers, Visser and Deursen). If a software development firm is already making use of metrics for the measurement of their daily tasks, it should seek to establish a close relationship between specific goals and adopted metrics. In addition, if a software development firm does not have any metrics in work at the present, however it wants to perceive their effects, it is suggested to start it from a basic level. For instance, the firm should define a short-term goal (these practices should be made simple for new team members so that they could easily understand them); identify and put into practice a small set of metrics (for instance it can be implemented to determine the complexity and length of methods); establish a desired measurement (for instance more than 80% of the code should be easy to understand); and install an automated software tool that can determine the working of the metric. Moreover, these goals and trend of the metric should be communicated to other team members along with experience the influence of metrics (Bouwers, Visser and Deursen). In view of the fact that effective management of the software development process requires the capability to recognize procedures that distinguish the fundamental aspects of project and process to have power over them as well as support nonstop improvement of the project and process. In this scenario, software project management metrics need to be effectively connected with a project and organizational goals to determine if a software development firm is attaining what it is intended to achieve (Sirias; Kaner; Atkinson, Hagemeister and Oman; Rombach). A software development firm needs to combine it day by day working tasks (as much as possible) with software project metrics with the purpose of avoiding having time assigned just to gather data (Sirias; Kaner; Atkinson, Hagemeister and Oman; Rombach). The software development firm should establish a validating and verification mechanism which could ensure that the selected metrics address different areas. In this scenario, the firm will be able to understand whether a project is completed with or without success (Sirias; Kaner; Atkinson, Hagemeister and Oman; Rombach). Without a doubt, metrics are just like words, they will not make any sense until they are presented in the form of a set of words that makes a sentence, accordingly to the extent that possible the software development firm should avoid over evaluating data gathered for one particular metric (Sirias; Kaner; Atkinson, Hagemeister and Oman; Rombach). The software development firm will not get any benefit of metrics if it cannot be used them to define or base action plans (Sirias; Kaner; Atkinson, Hagemeister and Oman; Rombach).. In order to take maximum benefit of metrics a firm should decide for target values for each metric they use for instance performance, once with the purpose of taking remedial measures, the project team must have knowledge of the predictable least amount and top figure value ranges (Sirias; Kaner; Atkinson, Hagemeister and Oman; Rombach). Conclusion This paper has presented a detailed analysis of software project management metrics. Software metrics are quantitative measures to determine the capability of a firm. They can also provide the basis for improvements. Without a doubt, these metrics can be used as a very useful tool for determining the progress of a certain project or process. In fact, these metrics help software development firms to improve their performance by taking certain actions. The research has shown that these software project management metrics offer simply the historical aspects. However, their effective use for decision making completely relies on meaningful knowledge of the series of actions that support a particular change in a software development process or team capabilities. Up till now, there have emerged a wide variety of software metrics which are being effectively used by software development firms to measure and improve their capabilities. However, both the success and failure of these metrics depend on the skills of people using them so in order to make better use of these metrics a firm should hire experienced people and train their staff members. Works Cited Atkinson, Gerald, et al. "Directing Software Development Projects with Product Metrics." METRICS 98 Proceedings of the 5th International Symposium on Software Metrics. IEEE Computer Society Washington, DC, USA, 1998. 193. Bouwers, Eric, Joost Visser and Arie Van Deursen. "Getting What You Measure." Queue - Networks, Volume 10 Issue 5 (2012): 50. Center of Software Engineering. CSCI 577b: Software Engineering II -- Spring 2001. 2001. 07 April 2013 . Hwang, Sun Myung. "Quality Metrics for Software Process Certification based on K-model." 2010 IEEE 24th International Conference on Advanced Information Networking and Applications Workshops. IEEE, 2010. pp.827-830. Kaner, Cem. "Software Engineering Metrics: What Do They Measure and How Do We Know?" 10th International Software Metrics Symposium. 2004. pp.1-9. Kharytonov, Serhiy. How to Use Metrics to Improve Project Management. 01 February 2010. 10 April 2013 . Lee, Crystal. Metrics in Project Management. 2013. 10 April 2013 . Pressman, Roger S. Software Engineering: A Practicioners Approach, 5th Edition. London: McGraw Hill, 2001. Rombach, H. Dieter. "Specification of software process measurement." ISPW 90 Proceedings of the 5th international software process workshop on Experience with software process models. IEEE Computer Society Press Los Alamitos, CA, USA, 1990. 127-129. Sirias, Carlos. Project Metrics for Software Development. 14 July 2009. 10 April 2013 . VanHilst, Michael, Pankaj K. Garg and Christopher Lo. "Repository mining and Six Sigma for process improvement." MSR 05 Proceedings of the 2005 international workshop on Mining software repositories. ACM, 2005. 1-4. Read More