Description
Computer software, or just software, is any set of machine-readable instructions that directs a computer's processor to perform specific operations. The term is used to contrast with computer hardware, the physical objects (processor and related devices) that carry out the instructions. Hardware and software require each other; neither has any value without the other.
Case on Study on Software Economics - A Road Map to Future
ABSTRACT
World economies are depending on software for delivery excellence and higher economic outcomes. Software field remains very challenging still due to the people centric nature of software engineering processes and practices. There are various evolutions and revolutions in the software development processes with varying successes and failures. Although technology has advanced rapidly still the people intensive processes make the researchers, Project Managers and Quality consultants to keep an eye on economic aspects of software projects in general. This article covers key aspects of software economics and research findings.
Key words: Software economics, Requirements engineering, risk factors, metrics, Estimation models
1.0 Introduction: Software economics is an emerging concept with lot of emphasis on adding value to the existing software systems and to define a process for new software development projects. This covers complete life cycle activities of any project from use case preparation till implementation of software. A model to monitor every activity, delivery and results is the ultimate objective of this research work. By performing an end to end study and development of a framework with monitoring control mechanism would help the project managers to manage the projects well. This study is becoming very important due to the fact that failure rate of projects worldwide is increasing with no value addition. 2.0 Objective of the Study: 1. Carry out a comprehensive study on factors influencing productivity of software projects and draw a correlations between them 2. To make an in-depth probe and identify the blend of factors that can be used as a composite yardstick to determine baselines 3. Finalize the factors which have high degree of influence on productivity 4. Recommend methodologies and modified processes that can enhance productivity of IT projects 3.0 Scope of the Study: Productivity is becoming an emotional topic of discussion among software professionals and consultants today. There are various factors influences the productivity positively or negatively impacting economics. In an era of tight budget conditions and increased customer expectations, determining productivity measures are very essential for the outsourcing organizations to continue their services to 205
client organizations on various projects. Therefore the study aims at finding out factors influencing the performance of the software projects. This study covers software development, enhancement, maintenance and support projects across various service organizations like HCL, CTS, WIPRO, Cap Gemini, Accenture and few other small organizations. This research work studied the factors covering many SDLC processes and activities like requirements engineering, tools & techniques, software estimations, knowledge management, quality & system improvement programs, experience of resources, defect management, people aspects and risk management. Finally this research work identified informed suggestions, recommendations to improve overall performance and delivery capability of software projects. 4.0 Review of Literature Risk Management Program(1) According to Rita Mulcahy (2001), the Risk management process was a systematic and proactive approach to taking control of IT projects and to reduce uncertainties. Risk Management should be applied to both small and large projects. Risk Management involves minimizing the consequences of adverse events as well as maximizing the results of positive events. Therefore risks can be good or bad events. Risk Management is a process and following that process is important to achieve results. It allows us to take control of the project, rather than letting the project to take control on us. The steps of Risk Management process as per project management body of knowledge (PMBOK) are (2) 1. Risk Management Planning: Determine how Risk Management will be done, who will be involved and procedure to be adopted. 2. Risk Identification: Determine specific risks by project and by task. Getting the stakeholders involved in making a long, comprehensive list of risks. 3. Quantitative and Qualitative: Analyzing the risks obtained in the identification step and deciding which risk warrant a response in the next step. Probability and impact are determined qualitatively, a choice is made whether or not a quantitative evaluation is necessary and the project risk score and probability of meeting project objectives are determined. 4. Risk Response planning: Determining what can be done to reduce the overall risk of the project by decreasing the probability or impact of the shortlisted risks and increasing probability or impact of opportunities. 5. Risk monitoring and control: Execute the risk response plan as risk events occur throughout all the project phases. Key factors, Processes and Priorities(3) Caper Jones (2007) in his article said that the most common problem in the software industry for large systems is that of intense but artificial schedule pressure applied to the programmers by their managers, by senior executives in their companies or by the clients. Unfortunately, intense schedule pressure leads to carelessness, which in turn drives up the chances of making errors and introducing bugs. The overall impact of intense schedule pressure is not what is desired, but instead tends to lengthen schedules because the software does not work well enough to be released. If one know the size of a software application and set schedules that are much shorter than the productivity level of the organization, one will have a very small chance of achieving the schedules and a very large chance of running late and over budget because schedule pressure one apply will cause haste and carelessness and will drive up the bug or error probably to dangerous levels. So it is very important to measure the size of the work in terms of standard measure and apply the productivity value based on its own productivity value or the value given by the productivity specialists or consultants like SPR.com (Software productivity research council) or David consulting Inc. (davidconsulting.com). Requirements Engineering(2) Scope Management is a key knowledge area in the whole of project management aspects. Scope management includes all are the processes to ensure that project includes all the work required and only 206
,
the work required to complete the project successfully. Managing scope primarily deals with defining and controlling what is and is not included in the project. The processes are Collect requirements: The process of defining and documenting stake holder requirements to meet the project objectives. Define Scope:The process of developing a detailed description of the product and project. Create WBS: The process of subdividing deliverables and project tasks into smaller and more manageable components. Verify Scope: The process of acceptance of the completed deliverables. Control Scope: The process of monitoring the status of the project and product scope and managing changes to the scope baseline. Software Estimation Methodologies (4) There are many software size estimation methodologies / approaches are in practice and prominently used by the practitioners in the industry. Researchers have been working on for quite long on many estimation techniques. Estimation models in the early stages were typically based on regression analysis or mathematical models. During 1970s and 1980s models derived were from historical data of various software projects. Among many estimation models expert estimation, COCOMO, Function Point and derivatives of function point like Use Case Point, Object Points are most commonly used. While Lines of Code (LOC) is most commonly used size measure for 3GL programming and estimation of procedural languages, IFPUG FPA originally invented by Allen Alrecht at IBM has been adopted by most in the industry as alternative to LOC for sizing development and enhancement of business applications. FPA provides measure of functionality based on end user view of application software functionality. Some of the commonly used estimation techniques are as follows:
• • • • • • • •
Lines of Code (LOC): A formal method to measure size by counting number of lines of Code, Source Lines of Code (SLOC) has two variants- Physical SLOC and Logical SLOC. While two measures can vary significantly care must be taken to compare results from two different projects and clear guideline must be laid out for the organization. IFPUG FPA: Formal method to measure size of business applications. Introduces complexity factor for size defined as function of input, output, query, external input file and internal logical file. Mark II FPA: Proposed and developed by Mark Simons and useful for measuring size for functionality in real time systems where transactions have embedded data COSMIC Full Function Point (FFP): Proposed in 1999, compliant to ISO 14143. Applicable for estimating business applications that have data rich processing where complexity is determined by capability to handle large chunks of data and real time applications where functionality is expressed in terms of logics and algorithms. Quick Function Point (QFP): Derived out of FPA and uses expert judgment. Mostly useful for arriving at a ballpark estimate for budgetary and marketing purposes or where go or no go decision is required during project selection process. Object Points: Best suited for estimating customizations. Based on count of raw objects, complexity of each object and weighted points. Predictive Object Points: Tuned towards estimation of the object oriented software projects. Calculated based on weighted methods per class, count of top level classes, average number of children, and depth of inheritance. Estimation by Analogy: Cost of project is computed by comparing the project to a similar project in the same domain. The estimate is accurate if similar project data is available.
207
,
Software Estimation methodologies (Documentation)(5) Every manager and cost estimating specialists who deals with large applications needs to understand that a typical software system produces more than 100 words for every line of code. Cost and schedules for creating these words are greater than the cost of actually writing the source code. 1. Software is the most labour intensive of any U.S industry in terms of the amount of human effort required to create a project 2. Software being abstract has become a document intensive industry and tends to create a larger volume of text and graphics based than almost any other industry. 3. ISO 9000, CMMI quality standards and processes demands heavy documentation work to satisfy audit requirements 4. Learning to use software applications often requires more training and more tutorial info than any other consumer product 5. Major cost drives for software projects in rank order of total effort are 1. Bug fixing 2. Paper documentation (ex: requirements specifications, plans, reports, test cases, plans, user manuals, implementation plans and etc.) 3. Meeting and communications 4. Coding 5. Project management effort
When agile methods have had some successes but there are issues. The problems with the agile approach of replacing paper documentation with face-to-face meetings, for projects with thousands of users, agile methods are not suitable. For military projects documentation, traceability from requirements to end product are critical for reference. For long range projects for maintenance, lack of documentation may prove troublesome. Software Estimation Methodologies (Schedule Pressure) The most common problem in the software industry for large systems is that of intense but artificial schedule pressure applied to the programmers by their managers, by senior executives in their companies or by the clients. Unfortunately, intense schedule pressure leads to carelessness, which in turn drives up the chances of making errors and introducing bugs. The overall impact of intense schedule pressure is not what is desired, but instead tends to lengthen schedules because the software does not work well enough to be released. If one know the size of a software application and set schedules that are much shorter than the productivity level of the organization, one will have a very small chance of achieving the schedules and a very large chance of running late and over budget because schedule pressure one apply will cause haste and carelessness and will drive up the bug or error probably to dangerous levels. So it is very important to measure the size of the work in terms of standard measure and apply the productivity value based on its own productivity value or the value given by the productivity specialists or consultants like SPR.com (Software productivity research council) or David consulting Inc. (davidconsulting.com). Defect Free Programming (7) The following are the key aspects one should follow to achieve defect free software. 1) Believe Defect-Free Software is Possible 2) Think Defect-Free Software is Important 3) Commit to Delivering Defect-Free Software 4) Design Your Code for Simplicity and Reliability 5) Trace Every Line of Code When Written 6) Review Code by Programmer Peers 7) Build Automated QA into Your Code 8) Build and Test Daily 9) Use Automated Checking Wherever Possible 208
,
Quality Management Processes (6) Project Quality Management includes the processes and tasks of the performing organization that determine quality processes, objectives and responsibilities so that the project will be able to satisfy the needs for which the project was under taken. It implements through policies and procedures with continuous process improvement activities throughout the project life cycle. Plan Quality: The process of identifying quality requirements and standards for the project and product and documenting how the project will demonstrate compliance level Quality Assurance: The process of auditing the quality requirements and the results from quality control measurements to ensure appropriate quality standards and operational definitions are used Quality Control: The process of monitoring and recording results of executing the quality activities to assess performance and recommend necessary changes. 5.0 Research Design and Methodology The research design used for the study is descriptive cum exploratory design. The methodology of the study is based on primary data gathered through a well-framed and structured questionnaire to obtain the opinion of the respondents. Sampling technique used for the study was convenience sampling and the size of the sample was 456. 6.0 Hypothesis and Findings
Dimensions of Productivity Traits
Risk Mgmt. Program No Yes Metrics program No
N
M ean
Std. Deviation 11.112 9 .450 Std. Deviation 9 .237 6 .351
Std. Erro r M ean 3 .929
t
Sig. (2-tailed)
Delivery performance Dimensions of Productivity Traits
8 448
52 .87 65.530
-3.745 0 .446 Std. Erro r M ean 0 .990 0 .331 Std. Erro r M ean 0 .600 0 .399 Std. Erro r M ean 0 .703 0 .549 Std. Erro r -2.807 t 0 .005 -15.184 -16.090
0 .000 *
N
M ean
T
Sig Value (P)
87 369
51.715 68.513
Delivery performance
Yes
0 .000 *
Dimensions of Productivity Traits Delivery performance Dimensions of Productivity Traits Delivery performance Dimensions of Productivity
Productivity Imp Program No Yes Tools and techniques to detect faults No Yes Tools for testing phase
N 244 212
M ean 60.222 71.162
Std. Deviation 9 .374 5 .807 Std. Deviation 7 .542 10.149 Std. Deviation
t
Sig.
0 .000 *
N 115 341 N
M ean 63.434 65.939 M ean
t
Sig Value (P)
Sig Value (P)
209
,
Traits
M ean
Delivery performance
No Yes
340 116
64.888 66.538
10.545 5 .979
0 .571 0 .555 -2.071 .039
From the above table, it is evident that there is a significant difference between risk management aspects, project metrics, productivity improvement programs, usage of tools and techniques for detecting faults and for testing with regard to overall dimensions of productivity traits. Since the P value is less than 0.05, the null hypotheses listed below are rejected at 5% level of significance with regard to dimensions of Productivity traits. Few important Null Hypotheses are listed below: (a) There is no significant difference between Risk Management Program with regard to dimensions of Productivity traits. (b) There is no significant difference between software metrics programs with regard to dimensions of Productivity traits. (c) There is no significant difference between Productivity Improvement programs with regard to dimensions of Productivity traits. (d) There is no significant difference between Use of tools and techniques to detect the faults and errors to improve productivity with regard to dimensions of Productivity traits. (e) There is no significant difference between usages of tools for testing the project to perform the Testing better with regard to dimensions of Productivity traits. 7.0 Research Findings and Recommendations
74 72 70
Mean Delivery performance
68 66 64 62 60 58 56 14.29
28.57
42.86
57.14
71.43
85.71
Tools and techniques
Graph I: Tools and techniques The above graph is showing a direct impact on productivity in software projects when various tools are being used. During the SDLC process, using various tools and techniques for design, construction, test script generation and testing would help enhance the productivity without any extra effort. Automating all the current manual processes, batch job scheduling and monitoring are the few functions that project teams should look at to make changes.
210
,
70
Mean Delivery performance
60
50
40 .00 50.00 100.00
Risk Management Programs
Graph II: Risk management programs Risk management is one of the nine functions of project management standards which the project managers should spend more time. The key activities as part of risk management are identifying the risks, mitigating the risks, preparing risk responses, estimating cost of risks, handling residual risks and risk monitoing. This research work identified clearly that proper risk management would help contain the situation under control.
80
Mean Delivery performance
70
60
50
40 10.00 40.00 50.00 60.00 70.00 80.00 90.00 100.00
Defect Software Management
Graph III: Defect free software management The above graph on defect free software management proves that there is a direct co-relation between productivity and defect management. So during software development life cycle it is very essential to perform product reviews at all stages. Also efforts should be taken to control and remove the defects by altering the process or by adopting some tools and techniques to improve the productivity during project life cycle.
211
,
80
Mean Delivery performance
70
60
50 .00 33.33 66.67 100.00
System Improvement Programs
Graph IV: System improvement Programs Similarly the above graph proves that productivity and process improvement programs in projects have a direct influence in enhancing productivity. It is highly recommended to adopt productivity improvement programs across all projects and engagements to ensure that performance and productivity is improved continuously 8.0 Software Economics and Conclusion The key advantage of looking economic perspective of softwareengineering providesa balanced view of overall life cycle ofsoftware projects. There is a constant demand for an economical model to do software size, effort and cost estimations consistently. Such an economical model would help avoid underestimates, over estimates, outright buy-ins that still plagues the industry today. Project managers should look at various options like reuse of software components, applying LEAN principles in projects, use all possible tools throughout the lifecycle, use of right estimation models, maintaining a proper knowledge management system and team motivation are few immediate steps to ensure software economics are in control. REFERENCES (1) Rita Mulcahy PMP (2001), "Tricks of the Trade for Project Managers (Risk Management)", Published by RMC Publication Inc., page 21-22 (2) Project Management Body of Knowledge (PMBOK) (2008), fourth edition, PMI, Page No 103 - 128; (3) Capers Jones (2007), (Software Productivity Research LLC), "Estimating Software Costs" "Bringing Realism to Estimating", (Estimating programming or coding), Tata McGraw-Hill Publications, Page 459 (4)http://approachtoproject.com/component/k2/item/10-software-estimation-techniques.html (5) Capers Jones (2007), (Software Productivity Research LLC), "Estimating Software Costs" "Bringing Realism to Estimating", (Estimating user and project documentation), Tata McGraw-Hill Publications, Page 519 (6) Project Management Body of Knowledge (PMBOK) (2008), fourth edition, PMI, Page No 189 - 213 (7)Source:http://www.tenberry.com/nodefect/steps.htm (Tenberry Software, Inc.) (8) Walker Royce and Kurt bittner (2009), "The Economics of iterative software development - steering towards better business results", pages 23, 25
212
doc_845266376.docx
Computer software, or just software, is any set of machine-readable instructions that directs a computer's processor to perform specific operations. The term is used to contrast with computer hardware, the physical objects (processor and related devices) that carry out the instructions. Hardware and software require each other; neither has any value without the other.
Case on Study on Software Economics - A Road Map to Future
ABSTRACT
World economies are depending on software for delivery excellence and higher economic outcomes. Software field remains very challenging still due to the people centric nature of software engineering processes and practices. There are various evolutions and revolutions in the software development processes with varying successes and failures. Although technology has advanced rapidly still the people intensive processes make the researchers, Project Managers and Quality consultants to keep an eye on economic aspects of software projects in general. This article covers key aspects of software economics and research findings.
Key words: Software economics, Requirements engineering, risk factors, metrics, Estimation models
1.0 Introduction: Software economics is an emerging concept with lot of emphasis on adding value to the existing software systems and to define a process for new software development projects. This covers complete life cycle activities of any project from use case preparation till implementation of software. A model to monitor every activity, delivery and results is the ultimate objective of this research work. By performing an end to end study and development of a framework with monitoring control mechanism would help the project managers to manage the projects well. This study is becoming very important due to the fact that failure rate of projects worldwide is increasing with no value addition. 2.0 Objective of the Study: 1. Carry out a comprehensive study on factors influencing productivity of software projects and draw a correlations between them 2. To make an in-depth probe and identify the blend of factors that can be used as a composite yardstick to determine baselines 3. Finalize the factors which have high degree of influence on productivity 4. Recommend methodologies and modified processes that can enhance productivity of IT projects 3.0 Scope of the Study: Productivity is becoming an emotional topic of discussion among software professionals and consultants today. There are various factors influences the productivity positively or negatively impacting economics. In an era of tight budget conditions and increased customer expectations, determining productivity measures are very essential for the outsourcing organizations to continue their services to 205
client organizations on various projects. Therefore the study aims at finding out factors influencing the performance of the software projects. This study covers software development, enhancement, maintenance and support projects across various service organizations like HCL, CTS, WIPRO, Cap Gemini, Accenture and few other small organizations. This research work studied the factors covering many SDLC processes and activities like requirements engineering, tools & techniques, software estimations, knowledge management, quality & system improvement programs, experience of resources, defect management, people aspects and risk management. Finally this research work identified informed suggestions, recommendations to improve overall performance and delivery capability of software projects. 4.0 Review of Literature Risk Management Program(1) According to Rita Mulcahy (2001), the Risk management process was a systematic and proactive approach to taking control of IT projects and to reduce uncertainties. Risk Management should be applied to both small and large projects. Risk Management involves minimizing the consequences of adverse events as well as maximizing the results of positive events. Therefore risks can be good or bad events. Risk Management is a process and following that process is important to achieve results. It allows us to take control of the project, rather than letting the project to take control on us. The steps of Risk Management process as per project management body of knowledge (PMBOK) are (2) 1. Risk Management Planning: Determine how Risk Management will be done, who will be involved and procedure to be adopted. 2. Risk Identification: Determine specific risks by project and by task. Getting the stakeholders involved in making a long, comprehensive list of risks. 3. Quantitative and Qualitative: Analyzing the risks obtained in the identification step and deciding which risk warrant a response in the next step. Probability and impact are determined qualitatively, a choice is made whether or not a quantitative evaluation is necessary and the project risk score and probability of meeting project objectives are determined. 4. Risk Response planning: Determining what can be done to reduce the overall risk of the project by decreasing the probability or impact of the shortlisted risks and increasing probability or impact of opportunities. 5. Risk monitoring and control: Execute the risk response plan as risk events occur throughout all the project phases. Key factors, Processes and Priorities(3) Caper Jones (2007) in his article said that the most common problem in the software industry for large systems is that of intense but artificial schedule pressure applied to the programmers by their managers, by senior executives in their companies or by the clients. Unfortunately, intense schedule pressure leads to carelessness, which in turn drives up the chances of making errors and introducing bugs. The overall impact of intense schedule pressure is not what is desired, but instead tends to lengthen schedules because the software does not work well enough to be released. If one know the size of a software application and set schedules that are much shorter than the productivity level of the organization, one will have a very small chance of achieving the schedules and a very large chance of running late and over budget because schedule pressure one apply will cause haste and carelessness and will drive up the bug or error probably to dangerous levels. So it is very important to measure the size of the work in terms of standard measure and apply the productivity value based on its own productivity value or the value given by the productivity specialists or consultants like SPR.com (Software productivity research council) or David consulting Inc. (davidconsulting.com). Requirements Engineering(2) Scope Management is a key knowledge area in the whole of project management aspects. Scope management includes all are the processes to ensure that project includes all the work required and only 206
,
the work required to complete the project successfully. Managing scope primarily deals with defining and controlling what is and is not included in the project. The processes are Collect requirements: The process of defining and documenting stake holder requirements to meet the project objectives. Define Scope:The process of developing a detailed description of the product and project. Create WBS: The process of subdividing deliverables and project tasks into smaller and more manageable components. Verify Scope: The process of acceptance of the completed deliverables. Control Scope: The process of monitoring the status of the project and product scope and managing changes to the scope baseline. Software Estimation Methodologies (4) There are many software size estimation methodologies / approaches are in practice and prominently used by the practitioners in the industry. Researchers have been working on for quite long on many estimation techniques. Estimation models in the early stages were typically based on regression analysis or mathematical models. During 1970s and 1980s models derived were from historical data of various software projects. Among many estimation models expert estimation, COCOMO, Function Point and derivatives of function point like Use Case Point, Object Points are most commonly used. While Lines of Code (LOC) is most commonly used size measure for 3GL programming and estimation of procedural languages, IFPUG FPA originally invented by Allen Alrecht at IBM has been adopted by most in the industry as alternative to LOC for sizing development and enhancement of business applications. FPA provides measure of functionality based on end user view of application software functionality. Some of the commonly used estimation techniques are as follows:
• • • • • • • •
Lines of Code (LOC): A formal method to measure size by counting number of lines of Code, Source Lines of Code (SLOC) has two variants- Physical SLOC and Logical SLOC. While two measures can vary significantly care must be taken to compare results from two different projects and clear guideline must be laid out for the organization. IFPUG FPA: Formal method to measure size of business applications. Introduces complexity factor for size defined as function of input, output, query, external input file and internal logical file. Mark II FPA: Proposed and developed by Mark Simons and useful for measuring size for functionality in real time systems where transactions have embedded data COSMIC Full Function Point (FFP): Proposed in 1999, compliant to ISO 14143. Applicable for estimating business applications that have data rich processing where complexity is determined by capability to handle large chunks of data and real time applications where functionality is expressed in terms of logics and algorithms. Quick Function Point (QFP): Derived out of FPA and uses expert judgment. Mostly useful for arriving at a ballpark estimate for budgetary and marketing purposes or where go or no go decision is required during project selection process. Object Points: Best suited for estimating customizations. Based on count of raw objects, complexity of each object and weighted points. Predictive Object Points: Tuned towards estimation of the object oriented software projects. Calculated based on weighted methods per class, count of top level classes, average number of children, and depth of inheritance. Estimation by Analogy: Cost of project is computed by comparing the project to a similar project in the same domain. The estimate is accurate if similar project data is available.
207
,
Software Estimation methodologies (Documentation)(5) Every manager and cost estimating specialists who deals with large applications needs to understand that a typical software system produces more than 100 words for every line of code. Cost and schedules for creating these words are greater than the cost of actually writing the source code. 1. Software is the most labour intensive of any U.S industry in terms of the amount of human effort required to create a project 2. Software being abstract has become a document intensive industry and tends to create a larger volume of text and graphics based than almost any other industry. 3. ISO 9000, CMMI quality standards and processes demands heavy documentation work to satisfy audit requirements 4. Learning to use software applications often requires more training and more tutorial info than any other consumer product 5. Major cost drives for software projects in rank order of total effort are 1. Bug fixing 2. Paper documentation (ex: requirements specifications, plans, reports, test cases, plans, user manuals, implementation plans and etc.) 3. Meeting and communications 4. Coding 5. Project management effort
When agile methods have had some successes but there are issues. The problems with the agile approach of replacing paper documentation with face-to-face meetings, for projects with thousands of users, agile methods are not suitable. For military projects documentation, traceability from requirements to end product are critical for reference. For long range projects for maintenance, lack of documentation may prove troublesome. Software Estimation Methodologies (Schedule Pressure) The most common problem in the software industry for large systems is that of intense but artificial schedule pressure applied to the programmers by their managers, by senior executives in their companies or by the clients. Unfortunately, intense schedule pressure leads to carelessness, which in turn drives up the chances of making errors and introducing bugs. The overall impact of intense schedule pressure is not what is desired, but instead tends to lengthen schedules because the software does not work well enough to be released. If one know the size of a software application and set schedules that are much shorter than the productivity level of the organization, one will have a very small chance of achieving the schedules and a very large chance of running late and over budget because schedule pressure one apply will cause haste and carelessness and will drive up the bug or error probably to dangerous levels. So it is very important to measure the size of the work in terms of standard measure and apply the productivity value based on its own productivity value or the value given by the productivity specialists or consultants like SPR.com (Software productivity research council) or David consulting Inc. (davidconsulting.com). Defect Free Programming (7) The following are the key aspects one should follow to achieve defect free software. 1) Believe Defect-Free Software is Possible 2) Think Defect-Free Software is Important 3) Commit to Delivering Defect-Free Software 4) Design Your Code for Simplicity and Reliability 5) Trace Every Line of Code When Written 6) Review Code by Programmer Peers 7) Build Automated QA into Your Code 8) Build and Test Daily 9) Use Automated Checking Wherever Possible 208
,
Quality Management Processes (6) Project Quality Management includes the processes and tasks of the performing organization that determine quality processes, objectives and responsibilities so that the project will be able to satisfy the needs for which the project was under taken. It implements through policies and procedures with continuous process improvement activities throughout the project life cycle. Plan Quality: The process of identifying quality requirements and standards for the project and product and documenting how the project will demonstrate compliance level Quality Assurance: The process of auditing the quality requirements and the results from quality control measurements to ensure appropriate quality standards and operational definitions are used Quality Control: The process of monitoring and recording results of executing the quality activities to assess performance and recommend necessary changes. 5.0 Research Design and Methodology The research design used for the study is descriptive cum exploratory design. The methodology of the study is based on primary data gathered through a well-framed and structured questionnaire to obtain the opinion of the respondents. Sampling technique used for the study was convenience sampling and the size of the sample was 456. 6.0 Hypothesis and Findings
Dimensions of Productivity Traits
Risk Mgmt. Program No Yes Metrics program No
N
M ean
Std. Deviation 11.112 9 .450 Std. Deviation 9 .237 6 .351
Std. Erro r M ean 3 .929
t
Sig. (2-tailed)
Delivery performance Dimensions of Productivity Traits
8 448
52 .87 65.530
-3.745 0 .446 Std. Erro r M ean 0 .990 0 .331 Std. Erro r M ean 0 .600 0 .399 Std. Erro r M ean 0 .703 0 .549 Std. Erro r -2.807 t 0 .005 -15.184 -16.090
0 .000 *
N
M ean
T
Sig Value (P)
87 369
51.715 68.513
Delivery performance
Yes
0 .000 *
Dimensions of Productivity Traits Delivery performance Dimensions of Productivity Traits Delivery performance Dimensions of Productivity
Productivity Imp Program No Yes Tools and techniques to detect faults No Yes Tools for testing phase
N 244 212
M ean 60.222 71.162
Std. Deviation 9 .374 5 .807 Std. Deviation 7 .542 10.149 Std. Deviation
t
Sig.
0 .000 *
N 115 341 N
M ean 63.434 65.939 M ean
t
Sig Value (P)
Sig Value (P)
209
,
Traits
M ean
Delivery performance
No Yes
340 116
64.888 66.538
10.545 5 .979
0 .571 0 .555 -2.071 .039
From the above table, it is evident that there is a significant difference between risk management aspects, project metrics, productivity improvement programs, usage of tools and techniques for detecting faults and for testing with regard to overall dimensions of productivity traits. Since the P value is less than 0.05, the null hypotheses listed below are rejected at 5% level of significance with regard to dimensions of Productivity traits. Few important Null Hypotheses are listed below: (a) There is no significant difference between Risk Management Program with regard to dimensions of Productivity traits. (b) There is no significant difference between software metrics programs with regard to dimensions of Productivity traits. (c) There is no significant difference between Productivity Improvement programs with regard to dimensions of Productivity traits. (d) There is no significant difference between Use of tools and techniques to detect the faults and errors to improve productivity with regard to dimensions of Productivity traits. (e) There is no significant difference between usages of tools for testing the project to perform the Testing better with regard to dimensions of Productivity traits. 7.0 Research Findings and Recommendations
74 72 70
Mean Delivery performance
68 66 64 62 60 58 56 14.29
28.57
42.86
57.14
71.43
85.71
Tools and techniques
Graph I: Tools and techniques The above graph is showing a direct impact on productivity in software projects when various tools are being used. During the SDLC process, using various tools and techniques for design, construction, test script generation and testing would help enhance the productivity without any extra effort. Automating all the current manual processes, batch job scheduling and monitoring are the few functions that project teams should look at to make changes.
210
,
70
Mean Delivery performance
60
50
40 .00 50.00 100.00
Risk Management Programs
Graph II: Risk management programs Risk management is one of the nine functions of project management standards which the project managers should spend more time. The key activities as part of risk management are identifying the risks, mitigating the risks, preparing risk responses, estimating cost of risks, handling residual risks and risk monitoing. This research work identified clearly that proper risk management would help contain the situation under control.
80
Mean Delivery performance
70
60
50
40 10.00 40.00 50.00 60.00 70.00 80.00 90.00 100.00
Defect Software Management
Graph III: Defect free software management The above graph on defect free software management proves that there is a direct co-relation between productivity and defect management. So during software development life cycle it is very essential to perform product reviews at all stages. Also efforts should be taken to control and remove the defects by altering the process or by adopting some tools and techniques to improve the productivity during project life cycle.
211
,
80
Mean Delivery performance
70
60
50 .00 33.33 66.67 100.00
System Improvement Programs
Graph IV: System improvement Programs Similarly the above graph proves that productivity and process improvement programs in projects have a direct influence in enhancing productivity. It is highly recommended to adopt productivity improvement programs across all projects and engagements to ensure that performance and productivity is improved continuously 8.0 Software Economics and Conclusion The key advantage of looking economic perspective of softwareengineering providesa balanced view of overall life cycle ofsoftware projects. There is a constant demand for an economical model to do software size, effort and cost estimations consistently. Such an economical model would help avoid underestimates, over estimates, outright buy-ins that still plagues the industry today. Project managers should look at various options like reuse of software components, applying LEAN principles in projects, use all possible tools throughout the lifecycle, use of right estimation models, maintaining a proper knowledge management system and team motivation are few immediate steps to ensure software economics are in control. REFERENCES (1) Rita Mulcahy PMP (2001), "Tricks of the Trade for Project Managers (Risk Management)", Published by RMC Publication Inc., page 21-22 (2) Project Management Body of Knowledge (PMBOK) (2008), fourth edition, PMI, Page No 103 - 128; (3) Capers Jones (2007), (Software Productivity Research LLC), "Estimating Software Costs" "Bringing Realism to Estimating", (Estimating programming or coding), Tata McGraw-Hill Publications, Page 459 (4)http://approachtoproject.com/component/k2/item/10-software-estimation-techniques.html (5) Capers Jones (2007), (Software Productivity Research LLC), "Estimating Software Costs" "Bringing Realism to Estimating", (Estimating user and project documentation), Tata McGraw-Hill Publications, Page 519 (6) Project Management Body of Knowledge (PMBOK) (2008), fourth edition, PMI, Page No 189 - 213 (7)Source:http://www.tenberry.com/nodefect/steps.htm (Tenberry Software, Inc.) (8) Walker Royce and Kurt bittner (2009), "The Economics of iterative software development - steering towards better business results", pages 23, 25
212
doc_845266376.docx