SOFTWARE VALUE ENGINEERING IN DEVELOPMENT PROCESS

SOFTWARE VALUE ENGINEERING IN DEVELOPMENT PROCESS Pawel Grzegrzolka University of Gdansk, Department of Business Informatics, Piaskowa 9, 81-864 Sopot, Poland, pawel.grzegrzolka@gmail.com Abstract. This paper studies the way of updating qualified software and solution to reduce development time early in the project life cycle, applying it to real projects in order to verify the feasibility. Software has inherited problems; software could not be verified by itself, software could not be developed by itself. Software out of set-product is never stands alone. It is strongly dependent on hardware, so developers should consider software from set-product level, not alone. To achieve more reliable software quality in the early development time it is quite essential to launch success products at the timely market. For that end, there is a need to provide methods to guarantee quality and reduce lead time at preliminary development time. A possibility of securing early quality, would mean that companies could produce more successful products, within schedule. This paper proposes Software Value Engineering (SVE) for that end. SVE focuses on early development stage, analysis and design. Through empirical case on SVE with real projects, paper includes its introduction into practice. Keyword. software development, size estimation, function point, Value Engineering, software quality 1 Introduction Quality and lead time are at the same time critical for the success of set products (mobile phones, television sets, Set Top Boxes, etc.) and most problematic in software development. To mitigate the problems software was developed in advance at research development cycle instead of at product development cycle. Unfortunately, the result proved to be insufficient. Software was still delayed in many cases. Recently software issues are related to the increase of complexity and function. Fundamental problem consists in lack of software s isolation, as it is always dependant on hardware, which makes it necessary to consider software in its entire setproduct. This paper introduces Software Value Engineering (SVE) as one of means to secure qualified software within a given schedule. SVE is an extended version of Value Engineering (VE) for software [4]. VE consists in a series of activities for cost reduction and utility increase. SVE adapts VE instruments, such as cross function activity, function analysis, cost reduction and quantitative management into software development. 2 Software Issues The increase of software cost at set-product has been quite remarkable (80% in cellular phone, 60% in DVDR and the numbers keep increasing). In the biennial report describing software project outcomes by the Standish Group called The Chaos Report for the year 2009, 44% of projects were delivered late (late, over budget and/or with less than the required features and functions), while 24% were failed (cancelled prior to completion or delivered and never used). The report also shows that software projects now have a 32% success rate [1]. Figure 1 shows data for 15 years between 1994 and 2009: Figure 1. Project outcomes: about 75% of all software projects are delivered late or fail outright [1] The Standish Group surveyed IT executive managers for their opinions about why projects succeed or fail. Three major factors that influence the project are user involvement, executive management support and clear statement of requirements. Also other success criteria were mentioned, but with these three elements in place the chances of success are much greater. Lack thereof dramatically increases the chance of failure. [1] - 77 -

Table 1. Project Success Factor [1] Project Success Factors % of Responses 1 User Invlovement 15,9% 2 Executive Management Support 13,9% 3 Clear Statement of Requirements 13,0% 4 Proper Planning 9,6% 5 Realistic Expectations 8,2% 6 Smaller Project Milestones 7,7% 7 Competent Staff 7,2% 8 Ownership 5,3% 9 Clear Vision & Objectives 2,9% 10 Hard-Working, Focused Staff 2,4% Other 13.9% Table 2. Project Impaired Factors [1] Project Impaired Factors % of Responses 1 Incomplete Requirements 13,1% 2 Lack of User Involvement 12,4% 3 Lack of Resources 10,6% 4 Unrealistic Expectations 9,9% 5 Lack of Executive Support 9,3% 6 Changing Requirements & 8,7% Specifications 7 Lack of Planning 8,1% 8 Didn t Need It Any Longer 7,5% 9 Lack of IT Management 6,2% 10 Technology Illiteracy 4,3% Other 9,9% Table 2 presents indicated reasons for the impairment and ultimate cancellation of projects. Incomplete requirements and lack of user involvement are at the top of the list. Capers Jones presents another view of project outcomes. Through several years, Jones observed that project success depends on the source code size (larger projects struggle more than smaller projects), which is presented in table 3. Table 3. Project outcomes by project size [2] Size in FP (approximate LOC) 10 FP (1,000 LOC) 100 FP (10,000 LOC) 1,000 FP (100,000 LOC) 10,000 FP (1,000,000 LOC) 100,000 FP (10,000,000 LOC) Early On Time Late Failed 11% 81% 6% 2% 6% 75% 12% 7% 1% 61% 18% 20% <1% 28% 24% 48% 0% 14% 21% 65% 3 Software Value Engineering Main activities of VE are function analysis, evaluation and ideas generation. VE calculates the value with function and cost perspective. Value = Function / Cost There are three ways to increase the value in function and cost view. Firstly, raise customer satisfaction (function) with the same cost. Secondly, provide the same customer satisfaction with low cost. Lastly, raise customer satisfaction, together with cost reduction. VE recommends focusing on the early stage of development - 78 -

life cycle for lower cost and better customer satisfaction. Concept and plan in PLC, and Proposal and Plan in RLC are target stages for VE. Likewise, SVE also focuses on early stages in PLC and RLC. Some senior executives may believe that code and test are more important than analysis and design, but the industry reports show that defect removal in early stage can save 200 times cost in later one. (Fig. 2) Figure 2. Relative cost to repair software by lifecycle stage [3] SVE focuses on requirement analysis and design stage. SVE aims at providing clear goals, reasonable plan, robust architecture, quantitative managing project progress, and analysis modeling for code. All these provide for better quality and better productivity. The SVE process can be illustrated as follows (Fig. 3): Figure 3. Software Value Engineering process 3.1 Goals and Index on project One of the weak sides of software project is goal building. Maybe there are implicit goals, which tell some artifacts within schedule, however these are not enough. Project members need to have concrete goals. Moreover elicited goals should be shared between stakeholders at early stage, which is crucial for the success of products. Also, if all stakeholders have the same expectations concerning software, the project avoids serious risks in later stages. Building independent software goals is quite difficult since software cannot be regarded in isolation from circuit board, which is not stable at an early stage. However, in given circumstances, it is possible to establish goals related to quality, schedule or functions. Furthermore, the goals should be shared by all stakeholders. SVE starts a project with a 2~3 day s workshop. During the workshop, all related stakeholders are involved with setting the goals. The meaning of project goals of specific activities is that if these goals are achieved, the project will be recognized as successful. It is recommend to focus on three goals per project. One of projects where SVE has been applied is digital Set Top Box project. First goal is the reduction of product development period. The check point is whether all mandatory functions are implemented during research development time or not. Second goal is establishing the reuse environment. The way to achieve the goal is to build software platform. Platform would guarantee better quality and reuse. After setting up the goals the next step is to make an index which can monitor the goals. Size, defect, effort or schedule would be good candidates. To measure the first goal, there a list of all functions which should be developed during the project was created,. Next, the code of these functions should be estimated. Measuring explains whether the progress is on the right track or not. Every week the planned and actual progresses are compared. It is a good method for recognizing - 79 -

project risk and status. Quantitative index is quite useful, but difficult to obtain. In order to gain quantitative index, a team should assign about 5~10% of all efforts to gather data. The data collection is essential activity to acquire high quality of software. The software management with quantitative data helps to diminish failure rate remarkably. Additionally, if there is a new requirement or a change, the team can quickly make necessary decisions. Later. defect data comes out, so it possible to lead a project more precisely in the direction of the desired output. This paper proposes effective size estimation methods which guide the preparation of a high quality software. 3.2 Building Development Strategy It is impossible to create a good-quality reusable software equipped with excellent performance and lots of functions with low cost in a short time. Software has various quality attributes, such as performance, reliability, security, reusability, usability, maintainability, extendibility, etc. When the time for development was drastically reduced, the programmers could not help giving up the quality. Recently, this point is overlooked, and so the number of defective software on the market is increasing. The already mentioned Chaos report informed that Unrealistic Expectation among stakeholders is the major failure factor in software project. Generally, senior executives may demand all good quality attributes on software, which is unrealistic. Therefore, when starting a project, stakeholders need to compromise and mutually share realistic expectation. If this is not the case, later it will become a major problem because of different views and expectations. In order to set up a good strategy for the software development, it is necessary to do benchmarking. In the first place, our relative capability against competitors should be assessed. Next, we should identify differential points against competitors. For example, a competitor can have an excellent user interface and reliable system. A company should know its market position. What will be the company s strong point? In order to raise the software quality, this approach proposes the application of an Architecture curve. Architecture curve shows the most important quality attributes on the system, and identifies the attributes which should be built or improved. It can be seen the characteristics of As-Is and To-Be software at the chart. In the case of reusing legacy systems, As-Is curve shows current software architecture. To-Be curve shows the desired architecture through this development. The gap between As-Is and To-Be curves illustrate the major tasks to improve. Gaps are the starting point of development strategies, as in the following example: Figure 4. Architecture Curve (Gap Analysis) Figure 4 is the architecture curve in one of the company s project. With this architecture curve, stakeholders could have the same expectation of the platform early in the lifecycle. There are five key quality attributes: memory usage, supported standards, prepare expected function changes, platform usability, and configurability. It is suggested that the team should focus on these elements in the future development. In general, project lead, architect, developer, tester, and marketing manager are important stakeholders in deciding on the architecture curve. Quality attributes are elicited from quality scenarios, which describe quality conditions. Each scenario has a priority by stakeholders voting. Utility tree is the set of scenarios. Next step, rate As-Is architecture quality using four levels, for instance: - Perfect. It doesn't need to be modified; - Quiet well, but not perfect; - Not bad, but not well; - Bad, it should be improved. - 80 -

3.3 Architecture Evaluation and Proposal Once target quality attributes and development strategies are selected, management should focus on solutions. The evaluation team makes it possible for software architect and developers to discuss architectural approaches and alternative versions relating to issues from the architecture curve. Each architecture alternative offered by software architects and developers is evaluated and analyzed from a trade-off point of view. Based on the trade-off analysis with each quality attribute s priority from architecture curve, software architect and developers decide on which alternative to apply. 3.4 Function Analysis In the examined company, software platform was brought into all divisions. The purpose of software platform is to reduce the development time and to increase the productivity through reuse. There are five mandatory conditions for the platform: separation design between common and variant, layered architecture, predefined interface, abstraction mechanism and documentation. With layered interface and abstraction mechanism applications and middleware can be reused without modification. In general, software platform is built on a product-group. It means that it is possible to easily apply well-built platform features to various derived products. In most cases, software is developed basing on a multimedia processor made by the outsourcing company. With such processor, hardware engineers build a circuit board. Next, software functions are implemented and programmers at divisions implement application and middleware mainly. The basic functions related to multimedia are already made by the outsourcing company and they are rarely changed. They are also maintained by the outsourcing company. Therefore, porting and applications modifying are main tasks of programmers at divisions. It means that it is easy to identify which components are modified or added in case of occurrence of new requirements, so the analysis scope can be reduced. Obviously, programmers should observe if the areas have defects or not. Main areas are application and interface. Doing function analysis on a platform should be an effective way of estimating the size. Defining basic functions is important for size estimation and makes it possible to manage software effectively. A popular size estimation method is function point, which is standard on software pricing in many companies. Function Point defines the basic functions as Elementary Process, which is the smallest unit of activity meaningful to the users. For example, login is a function identified by users, so it constitutes an elementary process, while to get authentic data from a database does not as it is not identifiable to user; it is just a sub internal logic for Login processing. In software programmers terms, it is obligatory to define elementary process that constitutes a smallest meaningful unit to developers. For example, Write some data into EEPROM constitutes an elementary process while save the data into buffers temporarily to write EEPROM does not as it is not meaningful or identifiable to the developer; it is just sub unit for Write-function. Identification elementary processes at a platform (layer interface, configuration, custom function, and application function) enables application s execution. If there are new requirements, programmers implement them with interface. Secondly, configuration function is similar to layer interface, but it has different usage. Configuration supports environment setting according to various users preference. Thirdly, custom function supports geographic environment setting according to countries. Fourthly, application is usually captured in the shape of sub/menu. Lastly, other functions are delivered and maintained by an outsourcing company or built as common yet variant part. Typical software architecture structure at platform: Application Application Interface Layer Middleware Device Abstraction Layer Device Driver OS Abstraction Layer OS / Kernel Hardware Access Control Figure 5. General layered architecture In building derived products, modification areas are roughly decided at the platform. These areas are marked with bold line. By calculating average LOC (mean or median) for the bold line layer, it is possible to estimate the size on new requirements more effectively. - 81 -

3.5 Size Estimation Organizations try to achieve numerous objectives for their software project. Here are some of the goals they strive for: - Schedule: Shortest possible for the desired functionality at the desired quality level - Cost: Minimum cost to deliver the desired functionality in the desired time - Functionality: Maximum feature richness for the time and money available. However, some observations show that the more important feature is the ability of the executives to assess cost, schedule, and functionality in advance in other words, predictability. Predictability is essential for the success of the project. Software measurement and analysis are key activities for bringing CMMI/SPICE level 4 from level 3. The purpose of software measurement and analysis activity is to secure a kind of software predictability. To achieve better quality, project manager should make a reasonable project plan. To prepare a reasonable plan, programmers should catch the code size developed. The rule of thumb of project leader is not bad, however when there are some changes or turn-overs, it is difficult to judge objectively. Moreover, in order to assign reasonable resources, project manager needs to know a more precise code size. This helps to produce more qualified outputs. For precise size estimation, it is necessary to separate function code and data code. Function code is related to algorithm and business logic, which require 100% effort of programmers. However, data code is related to hardware setting values, which are a little cared for by programmers. Data code consists in several to thousands lines. Typical data codes are included into macro variable, structure variable, typedef, etc. Data code needs around 2% efforts compared with function code, which can be of several types. Therefore the separation between function code and data code is quite important. Code types, as shown by fig. 6, are another concern, as according to the types, effort is different. Figure 6. Code classification Comments and blank are not included into LOC. The most popular method for size estimation is LOC and Function Point. 3.6 Size Estimation based on Function Point In the case of no legacy platform or new feature added, function point can be used for size/effort estimation. Function point provides more systematic size analysis than any other method early in the development. Function point is an independent technology with its own development language and environment. As such, it can be applied in various kinds of software projects. Output can be compared with industrial average in terms of schedule, effort, and productivity. Function point uses three transaction functions and two data functions. From the point of view of the users, usually systems provide three types of external actions; input/execution, output/report and inquiry. To support the external actions, systems processes data calculations internally (internal logical file (ILF) and external interface file (EIF). By analyzing three external transaction functions and two data functions on requirements, it is possible to calculate the complexity of the system. The code size of the future system is therefore known. According to software characters, the degree of difficulty may be different. Function point provides 14 general system characteristics (Table 4). With GSC, the size estimation value is adjusted within +/- 35%. Table 4. General System Characteristic 1. Data Communication 2. Distributed Data Processing 3. Performance 4. Heavily Used Configuration 5. Transaction Rate 6. Online Data Entry 7. End-User Efficiency 8. Online Update 9. Complex Processing - 82 -

10. Reusability 11. Installation Ease 12. Operational Ease 13. Multiple Sites 14. Facilitate Change Each factor value is scaled from 1 to 5. Function points are applied to one of STB projects, that is firmware software for audio functions. Through the function analysis, project manager knows that new functions were made up of seven elementary processes. With function point analysis, the project has 57 FP. FP value can be converted into LOC using Cocomo II. 57 FP is equal to 17,920 LOC. It means that the LOC estimated is 17,920. Later the actual LOC is 15,832. The hitting ratio between plan and actual is 88%. The productivity of 1FP is 273 LOC. It is just unstable indexes by calculated just one instance. However, historical data is stored continuously according to the division. It could provide more precise and stable estimation. 3.7 Size Estimation based on Platform If a legacy software platform exists, it is possible to make an estimation based platform. The merit of this model is easy estimation of many derived products. For more precise estimation, it has two steps; model analysis estimation, linear regression estimation. First of all, it should be divided into common and variant components through the step of function analysis and elementary process out of platform should be identified. Next, the targets should be defined, to be later added or modified for requirements. For example:. Layer Interface Code Size Information (95% confidence interval) - Function Code: Mean 17 LOC (Min-14, Max-20) - Add or Modify layer Interface expected: 169 - Code estimated: 2873 LOC = 17 * 169 Configuration Code Size Information (95% confidence interval) - Function Code: Mean 17 LOC (Min-12, Max-22) - Add or Modify Configuration expected: 13 - Code estimated: 221 LOC = 17 * 13 DMS Code Size Information (95% confidence interval) - Function Code: Mean 14 LOC (Min-12, Max-17) - Add or Modify Configuration expected: 112 - Code estimated: 1568 LOC = 14 X 112 - Actual code = 1629 LOC - Hitting Ratio = 96% Using the actual data, linear regression calibrates the error of platform based estimation. It enables more practical estimation. Also, it could provide effort estimation based on size. Formula is as follows: Y = projected added and modified size E = estimated proxy size β o and β1 are calculated using estimated proxy size and actual added and modified size 3.8 Analysis/Design Modeling Model based code is an effective way to secure qualified software and to reduce development time in the early stage. In general, software architects or senior programmers can draw model for coding. Junior programmers can write coding. Introducing the division between design and code helps quite effectively to maintain balance between senior and junior programmer. It can also enhance code quality, because code - 83 -

guideline would be delivered and checked in advance and prepared by experienced people. If later any defects occurred, the modeling documentations would help to clear them effectively. There are two types of modeling: static modeling and dynamic modeling. Static modeling provides static information - key functions, classes (or files), package (or directory), dependence between classes, active or passive information, and so forth. On the other hand, dynamic modeling provides static information according to executive sequence of thread. By using dynamic modeling, the team can examine complex business logic in advance. Teams do not need to make all models against all functions. It is recommended to write model on quite complex modules, which is required preliminary examination. 3.9 Earned Value Tracking Earned value is a method used for tracking the actual progress of completed work against the overall project plan. As each task is completed, its Planned Value is added to the cumulative EV for the project. Partially completed tasks do not contribute to the EV total. The Planned Value of a task is equal to its planned time expressed as a percentage of the total planned time for the project. For example, a 5 hour task in a 50 hour project would have a PV of 10. It makes it possible to track Earned Value using size data or function point. During planning, the total PV for project tasks can be computed for each time period. Likewise, adding up the EV for completed tasks at any time period in a project determines the percentage of completed work to-data for the project. At any point in the project, the actual EV earned can be compared to the cumulative planned EV to determine if the project is on schedule, behind schedule or ahead of schedule. Table 7. Earned Value tracking with Function Point 4 Conclusion The output of software in research life cycle would be a barometer for successful product launching. SVE provides an effective way of acquiring better quality and productivity early in the development. It also supports the reduction of development time. SVE is the activity based on analysis and design phase. The key activities for analysis are building goals, writing architecture curve, and reasonable planning. SVE secures a guarantee of better quality and avoidance of risks together with reduction of the development time. The key activities for design are architecture evaluation and modeling. References [1] J. Dominguez, The Curious Case of the CHAOS Report, The Standish Group Report, 2009 http://www.projectsmart.co.uk/docs/chaos-report.pdf [2] T. Caspers Jones, Estimating Software Costs, Mc Graw-Hill International Limited, 1998 [3] R. B. Stewart, Software Engineering, IEEE Computer Society Press, 1997 [4] R. B. Stewart, Fundamentals of Value Methodology, Xlibris Corporation, 2007 [5] S. McConnel, Software estimation demystifying the black, Microsoft Press, 2006 [6] IFPUG, Function point counting practice manual release 4.3, 2010 [7] What Humphrey, TSP Workshop handouts, SEI/CMU, 2001 [8] M.Lopez, An Evaluation Theory Perspective of the Architecture Tradeoff Analysis Method, SEI, 2001 [9] J. Baik, Cocomo II Model Definition Manual, USC, 2000 [10] M. Pormeroy-Huff, The Personal Software Process Body of Knowledge version 1.0, SEI, 2006 [11] P.Clements, R. Kazman, Mark Klein, Evaluating Software Architectures Methods and Case Studies, SEI/CMU, 2002 [12] M. R. Barbacci, Quality Attribute Workshops(QAWs), Third Edition, SEI/CMU, 2003-84 -