Productivity Improvement In Sw Industry


Published on

Lean implementation

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Productivity Improvement In Sw Industry

  1. 1. Amit Kumar Nayak Productivity Improvement Initiatives in Software Industry Author: Amit Kumar Nayak 1 Productivity Improvement Initiatives in Software Industry
  2. 2. Amit Kumar Nayak Contents 1.0 Introduction.......................................................................................................3 2.0 Challenges for Software Productivity Measurement........................................4 2.1 Why measure software productivity?................................................................4 2.2 Who should measure software productivity data?............................................5 2.3 What should be measured?..............................................................................6 2.4 How to improve software productivity?.............................................................9 3.0 Lean for software Industry..............................................................................10 Overproduction...........................................................................................................................................11 Pull is more effective than push..............................................................................................................15 4.0 Case Study:....................................................................................................17 4.1Productivity Improvement Measures: A case study........................................17 Figure- 2: Fishbone Analysis................................................................................18 ..............................................................................................................................20 Figure- 4: Fishbone – N1: New colleagues Productivity enhancement...............20 Figure- 5: Fishbone – T1: Testing optimisation...................................................21 ..............................................................................................................................22 5.0 Conclusion......................................................................................................23 6.0 Glossary..........................................................................................................24 List of Figures and Tables Figure – 1: PDCA(R) Cycle -------------------------------------------------12 Figure- 2: Fishbone Analysis ----------------------------------------------- 17 Figure- 3: Fishbone – P1: Process Optimisation ----------------------- 18 Figure- 4: Fishbone – N1: New colleagues Productivity -------------- 19 Figure- 5: Fishbone – T1: Testing optimisation ------------------------ 20 Figure- 6: Productivity trend ----------------------------------------------- 21 Table –1: Eliminating waste – Technique -------------------------- 10 Table-2: Baselines, Targets, Benefit measurement. ------------ 21 Abstract: 2 Productivity Improvement Initiatives in Software Industry
  3. 3. Amit Kumar Nayak Software development and maintenance became major corporate concerns in the last couple of years. Management remains troubled by a set of chronic problems associated with software applications: long schedules, major cost overruns, low quality and poor Customer satisfaction. These problems have occurred so widely that it is fair to characterize them as a quot;corporate epidemic.quot; Management throughout industry is realizing that possessing the ability to measure within their software environment is critical to their success and survival. Understanding current levels of productivity and quality is invaluable as an organization embarks on a process improvement initiative or considers their outsourcing alternatives. Identifying pockets of excellence within the organization, understanding why they exist, and then propagating these practices across the remainder of the organization can turn a good company into a world-class company. The goal of software measurement is to provide software managers and professionals with a set of useful, tangible data points for sizing, estimating, managing, and controlling software projects with rigor and precision. By capturing and tracking project metrics for effort, duration, staffing, cost, deliverable size, and defects at several levels of granularity an organization is able to improve its estimation capabilities, develop benchmarks on software performance, identify the effectiveness of their technology investments, and capture organizational best practices. Then, in assessing the measured data, management can compare actual and projected software project performance in terms of delivered quality and productivity to various benchmarks, including industry averages, quot;Best-in-Classquot; organizations, and internal standards. Assessment is also a vehicle to evaluate the strengths and weaknesses of the software environment and correlate them with quality and productivity performance. Process improvement recommendations can be modeled to evaluate the costs and benefits of implementation. This abstract highlights the Productivity Improvement measures that are taken in service sector, especially Software industry. Many of these initiatives have already started and implemented for many service provider such as Robert Bosch, Wipro, Philips, SITA etc. The report will address the facts in following order: Why do we require the productivity Improvement?  How do we measure the benefits (in quantitative terms)?  Some Examples of the best practices in software industry.  Lean In software industry.  Case Study.  Conclusion.  1.0 Introduction What affects software productivity and how do we improve it? This report examines the current state of the art in software productivity measurement. In turn, it describes a framework for understanding software productivity, some fundamentals of measurement, surveys empirical studies of software productivity, and identifies challenges involved in measuring software productivity. A radical alternative to current approaches is suggested: to construct, evaluate, deploy, and evolve a knowledge-based `software productivity modeling and simulation system' using tools and techniques (LEAN) from the domain of software process engineering. 3 Productivity Improvement Initiatives in Software Industry
  4. 4. Amit Kumar Nayak 2.0 Challenges for Software Productivity Measurement Before we proceed to understand the variables that affect software productivity, we should understand what lies beneath in productivity measurement.Let us try to analize some of the core things inside the Productivity measurement. (a) Why measure software productivity? (b) Who (or what) should measure and collect software productivity data? (c) What should be measured? (d) How to measure software productivity? (e) How to improve software productivity? The purpose of asking these five questions is to appreciate the complexity of the answers as well as to see the different answers lead to different software production measurement strategies. Unfortunately, as we have begun to see in the preceding section, the answers made in practice can lead to undesirable compromises in the analytical methods employed, or in the reliability of the results claimed. 2.1 Why measure software productivity? Now a day’s numbers of reasons for measuring software productivity have been reported. In simplest terms, the idea is to identify (and measure) how to reduce software development costs, improve software quality, and improve the rate at which software is developed. In practical terms, this includes alternatives such as: • Increase the volume of work successfully accomplished by current staff effort, • Accomplish the same volume of work with a smaller staff, • Develop products of greater complexity or market value with the same staff workload, • Giving the customer a better predictability for the upcoming or advanced version of the existing product. • Avoid hiring additional staff to increase workload, • Rationalize higher levels of capital-to-staff investment, • Reduce error densities in delivered products, and decreasing the amount of time and effort needed to rectify software errors, • Streamline or downsize software production operations, • Identify possible product defects in early development stage, • Identify resource utilization patterns to discover production bottlenecks and underutilized resources, • Identify high-output or responsive personnel to receive rewards, and identify low-output personnel for additional training or reassignment. Clearly, there are many reasons for measuring software productivity. However, once again it may not be desirable to try to accomplish most or all of these objectives through a single productivity measurement program. For example, different people involved in a large software project may value certain of these alternatives more than others. Similarly, each alternative implies certain kinds of data to be collected. This diversity may lead to conflicts over why and how to measure software productivity which, in turn, may lead to a situation where the measured results are inaccurate, misleading, or regarded with suspicion. Thus, a productivity measurement program 4 Productivity Improvement Initiatives in Software Industry
  5. 5. Amit Kumar Nayak must be carefully design to avoid creating conflicts, mistrust, or other conditions for mis- measurement within the software projects to be studied. Involving the software developers and project managers in the design of the measurement instrument, data collection, and feedback program can help minimize the potential organizational problems as well as gain their support. 2.2 Who should measure software productivity data? The choice of who (or what) should collect and report software production data is determined in part by the reasons for measuring productivity noted above. The choices include: • Programmer self report, • Project or team manager, • Outside analysts or observers, • Automated performance monitors. Programmer or manager self-reported data are the least costly to collect, although they may be of limited accuracy. However, if productivity measures are to be used for personnel evaluation, then one should not expect high reliability or validity in self-reported data. Similarly, if productivity measures are employed as the basis of allocating resources or rewards, then the data reporters will have an incentive to improve their reported production values. This is a form of the Hawthorne Effect, whereby people seek to accommodate their (software production) behavior to generate data values they think the data evaluators want to see. Instead, we want to engender a software production measurement capability that can feed back useful information to project managers and developers in a form that enhances their knowledge and experience over time. Outside observers can often collect such information, but at a higher cost than self report. Similarly, automated production performance monitors may be of use, but this is still an emerging area of technology requiring more insight for what should be measured and how. The use of automated performance monitoring systems is associated with perceived increase in productivity, more accurate assessment of worker performance, and higher levels of organizational control. However, where such mechanisms have been employed, workers indicate that managers overemphasize such quantitative measures, and underemphasize quality of work in evaluating worker performance. Workers also reported increased stress, lower levels of job satisfaction, and a decrease in the quality of relationships with peers and managers. Ultimately, one would then expect that these negative factors would decrease productivity and increase staff turnover. But some drawbacks in the use of automated performance monitors. Collecting high- quality production data and providing ongoing constructive feedback to personnel in the course of a project is thus a longer-term goal. Overall, if data quality or accuracy is not at issue, self-reported production data is sufficient. If causal behavior or organizational circumstances do not need to be taken in account, then automated performance monitors can be used. Similarly, if the desire is to show measured improvement in software productivity, whether or not production improves, self-reported or automated data collection procedures will suffice. On the other hand, if the intent of the productivity measurement program is to ascertain what affects software production, and what alternative work arrangements might further improve productivity, then reliable and accurate data must be collected. Such data might best be collected by analysts or observers who have no vested interest in particular measured outcomes, nor who will collect data to be used for personnel evaluation. In turn, the collected data should be analyzed and results fed back to project developers and managers in a form they can act upon. Again, this might be best facilitated through the involvement of representative developers and managers in the design of the data collection effort. 5 Productivity Improvement Initiatives in Software Industry
  6. 6. Amit Kumar Nayak 2.3 What should be measured? The choices over what to measure are many and complex. However, it is clear that focusing on program product attributes such as lines or code, source statements, or function points will not lead to significant insights on the contributing or confounding effects of software production process or production setting characteristics of software productivity, nor vice versa. The studies in earlier sections clearly indicate that different product, process, and production setting characteristics individually and collectively affect software productivity. However, based on this survey, there are some inconsistencies in determining which characteristics affect what increase or decrease in software productivity. As such, an integrated productivity measurement or improvement strategy must account for characteristics of the products, processes, and settings to delineate the potential interrelationships. This is necessary since we cannot predict beforehand which constituent variables will reveal the greatest significance or variance in different projects or computing environments. Similarly, we should expect that software product, process, and setting characteristics will need to be measured using a combination of nominal, ordinal, and interval and ratio measures. As such, consider in turn, the following constituents of software products, production processes, and production settings. Software Products: Software projects produce a variety of outcomes other than source code. Each product is valuable to the individual developers, project managers, project organization, or the client. Therefore, we should not limit production measurement attention to only one product, especially if comparable effort is committed to producing other closely related products. The point here is that since software projects produce many products along the way, our interest should be focused on ascertaining the distribution of time, skill, teamwork, and value committed to developing each product. Accordingly, we can see the following kinds of products resulting from a software development project. • Delivered (new versus modified) source statements for successive software life cycle development stages, including those automatically transformed or expanded by software tools, such as application generators. • Software development analyses (knowledge about how a particular system was produced): requirements analysis, specifications, architectural and detailed designs, and test plans, • Application-domain knowledge: knowledge generated and made explicit about the problem domain (e.g., how to electronically switch a large volume of telephone message traffic under computer control), • Documents and artifacts: internal and external reports, system diagrams, and terminal displays produced for development schedule milestones, development analyses, user manuals, and system maintenance guides, and • Improved software development skills, new occupational or career opportunities for project personnel, and new ways of cooperating in order to develop other software products. Software Production Process: Software is often produced through a multi-stage process commonly understood in terms of the system life cycle: from its inception through delivery, sustained operation, and retirement. But if requirements are frequently renegotiated, if senior software engineers quit after the preliminary architectural design, or if there are no modern software requirements, specification, or design 6 Productivity Improvement Initiatives in Software Industry
  7. 7. Amit Kumar Nayak aids employed, then we might expect that the coding phase may show comparatively low productivity, and that test and integration show comparatively high cost. Since each production process activity can produce valuable products, why is it conventional to measure the outcome of one of the smallest effort activities in this process of developing large software systems, coding. A number of studies indicate that coding usually consumes 10-20% of the total software development effort. On the other hand, software testing and integration consume the largest share, usually representing 50% of the development effort. Early development activities consume 10-15% each. Clearly, delivered software source code is a valuable product. However, it seems clear that code production depends on the outcomes and products of the activities that precede it. In general, software projects do not progress in a simple sequential order from requirements analysis through specification, design, coding, testing, integration, and delivery. However, this does not mean that such activities are not performed with great care and management attention. Quite the contrary, although the project may be organized and managed to produce requirements, specification, design, and other documents according to planned schedule, the actual course of development work is difficult to accurately predict. Development task breakdowns and rework are common to many projects. Experience suggests that software specifications get revised during later design stages, requirements change midway through design, software testing reveals inadequacies in certain specifications, and so forth. Each of these events leads to redoing previously accomplished development work. As such, the life cycle development process is better understood not as a simple linear process, but rather as one with many possible paths that can lead either forward or backward in the development cycle depending on the circumstantial events that arise, and the project conditions that precede or follow from the occurrence of these events. If we want to better estimate, measure, and understand the variables that affect software production throughout its life cycle, we need to delineate the activities that constitute the production process. We can then seek to isolate which tasks within the activities can dramatically impact overall productivity. The activities of the software life cycle process to be examined include: • System requirements analysis: frequency and distribution of changes in operational system requirements throughout the duration of the project, • Software requirements specifications (possibly including rapid prototypes): number and interrelationship of computational objects, attributes, relations and operations central to the critical components of the system (e.g., those in the kernel), • Software architecture design: complexity of software architecture as measured by the number, interconnections, and functional cohesion of software modules, together with comparable measures of project team organization. Also, as measured by the frequency and distribution of changes in the configuration of both the software architecture and the team work structure. • Detailed software unit design: time spent to design a module given the number of project staff participating, and the amount of existing (or reused) system components incorporated into the system being developed, • Software unit coding (or application generation): time to code designed modules, and density of discovered inconsistencies (bugs) found between a module's detailed design and its source code, • Unit testing, integration, and system testing: ratio of time and effort allocated to (versus actually spent on) testing, effort spent to repair detected errors, density of known 7 Productivity Improvement Initiatives in Software Industry
  8. 8. Amit Kumar Nayak error types, and the amount of automated mechanisms employed to generate and evaluate test case results, Similar variables for consideration can also be articulated for other system development and evolution activities including quality assurance and configuration management, preliminary customer (beta-site) testing, customer documentation production, delivery turnover, sustained operation and system evolution. In addition, we must also appreciate that software production can be organized into different modes of manufacture and organization of work, including: • Ad hoc problem solving and articulation work. • Project-oriented job shop, which are typical for software development projects. • Batched job shops, for producing a family or small volume of related software products • Pipeline, where software production is organized in concurrent multi-stage development, and staff is specialized in particular development crafts such as `software requirement analysts', `software architects', or `coders'. • Flexible software manufacturing systems, which represent one view of a `software factory of the future’. • Transfer-line (or assembly line), where raw or unfinished information resources are brought to semi-skilled software craftspeople who perform highly routinized and limited fabrication or assembly tasks. Accordingly, the characteristics that distinguish these potential modes of software production from one another are their values along a set of dimensions that include (1) developer skill requirements, (2) ease of productivity measurement and instrumentation, (3) capitalization, (4) flexibility of procedures to accommodate development anomalies, and (5) ability to adopt and assimilate software innovations. Software Production Setting: Does the setting where software is produced make a difference on productivity? Do we expect that SOFTWARE production at, say; organization X is different than at the organization Y. Do we expect that SOFTWARE production in various development organization departments of the same corporation is different? The answer to all is Y-E-S. Software production settings differ in a number of ways including: • Programming language in use (Assembly, FORTRAN, COBOL, C, C++, Ada, Common Lisp, Smalltalk, etc.) • Computing applications (telecommunications switch, command and control, AI research application, database management, structural analysis, signal processing, refinery process control, etc.) • Computers (SUN-4 workstations, DEC-VAX, Amdahl 580, Cray Y-MP, Symbolics 3670, PC-clone, etc.) and operating systems (UNIX variants, VAX-VMS, IBM-VM, Zetalisp, MS- DOS, etc.) • Differences between host (development) and target (end-user) computing environment and setting, as well as between computing server and client systems • Software development tools (compilers, editors, application generators, report generators, expert systems, etc.) and practices in use (hacking, structured techniques, 8 Productivity Improvement Initiatives in Software Industry
  9. 9. Amit Kumar Nayak modular design, formal specification, configuration management and QA, MIL- STD-2167A guidelines, etc.) • Personnel skill base (number of software staff with no college degree, degree in non- technical field, BS CS/EE, MS CS/EE, Ph.D. CS/EE, etc.) and experience in application area. • Dependence on outside organizational units (system vendors, Marketing, Business Analysis and Planning, laboratory directors, change control committees, clients, etc.) • Extent of client participation, their experience with similar application systems, and their expectation for sustained system support • Frequency and history of mid-project innovations in production computing environment (how often does a new release of the operating system, processor memory upgrade, new computing peripherals introduced, etc. occur during prior development projects) • Frequency and history of troublesome anomalies and mistakes that arise during prior system development projects (e.g., schedule overshoot, budget overrun, unexpected high staff turnover, unreliable new release software, etc.) 2.4 How to improve software productivity? To address this question, number of strategies had been made. But the thing which makes a difference from others is “BEST PRACTICES” and “LEAN” which is a constant and has a definite impact on the quality and productivity. As mentioned earlier, testing is the most important part of the software product life cycle and also takes the maximum time. So I’ll address some of the best practices in software Testing industry. Some known strategies are: • Get the best from people, • Make development steps more efficient, • Eliminate unnecessary development/testing steps, • Eliminate rework, • Build simpler products, and reuse components. These strategies draw attention to the development activities or processes that add value to an emerging software system. Many of these strategies are regularly practiced in various software companies to achieve software productivity improvements. 1. Prepare a long-term goal to address the important issues that can increase the bottom line of the organization. A distinct roadmap should be there after consulting with different interfaces. It should be kept in mind that the roadmap should align with the goal and objective of the organization (like customer satisfaction, low cost, high quality etc.) 2. Testing environment improvement (Technique, HW & SW): An appropriate set of tools (like silk, load runner etc.) will be identified including the related testing techniques and experimented on to get the best result from this. 3. Documentation Management System improvement: A new set of test data, test documentation tool and related management system will be defined and experimented on the baseline projects. The more automation will enter to this the better will be the expected result. 9 Productivity Improvement Initiatives in Software Industry
  10. 10. Amit Kumar Nayak 4. Test execution improvement: A set of test cases will be identified as quot;re- executable test casesquot;, similarly many related test cases should put together to reduce the number of test cases and to increase the test coverage. All this comes from the past experience and in depth knowledge of the product and process, called “LEARNING CURVE” experience. 5. Metric improvement: The current quality model will be reviewed in the frame of SEI CMMI or ISO/IEC etc standards. This process should be reviewed in a regular interval to see its value-add in qualitative as well as quantitative terms. So that if further improvement is required, measure can be taken. After implementing these are the some definite outcomes: Cycle time reduction of tests execution and test data record 1. management. End customer gets the product in a more frequently than earlier. 2. Better predictability of the product release date to the customer. 3. Productivity improvement especially in regression test due to frequent 4. testing in less time (w.r.t earlier testing cycle time) with less no of test cases and more coverage. Hence gives a better confidence to the end customer. Product quality improvement both in defect delivered with product and 5. early life defects (objects missing, wrong packaging) Service quality improvement in term of efforts and time for problem 6. fixing-resolution Paper reduction 7. Improvement of test process control. 8. Improvement of customer satisfaction. 9. 10. Improvement of skills. 3.0 Lean for software Industry On the path toward global competitiveness and industry dominance, software services today need to continue refining and improving operational efficiencies. A hybrid mix of quot;leanquot; initiatives and best practices helps reduce inventory, tighten supply cycles, and ultimately, reduce the cost of making goods. The benefits and basic principals of lean are widely known. However, many organizations struggle to gain a foothold. Or, perhaps more commonly, lean initiatives stall and sometimes are eliminated due to a lack of understanding of what it takes to make and sustain the lean transformation. But if we go back to 1960 when the team at Toyota emerged from the shop floor with a new manufacturing system, it wasn’t just for one company in a particular market and culture. What they had created was a new paradigm in manufacturing or service delivery—a new way of 10 Productivity Improvement Initiatives in Software Industry
  11. 11. Amit Kumar Nayak seeing, understanding, and interpreting what is happening in a production process that could propel them beyond the traditional way of thinking. In Lean, the goal is to eliminate anything not essential to the process. The goal of Lean Manufacturing is to eliminate the wastes – overproduction, unnecessary motion, inventory, waiting, transportation, defects, underutilized people and extra unnecessary processing. Cutting these wastes becomes an over-riding philosophy in Lean operations. In practice, this means a cultural shift towards reducing the wastes using 14 principles put across through LEAN. Now days many software companies are coming forward and trying to implement the lean in their process to improve their operational profit. We will discuss its implementation and outcome in software industry. Eliminating the waste (Technique, HW & SW): The sum total of incremental improvement efforts can be very powerful over time. However, huge breakthroughs are usually available by effectively aligning processes at a macro level and eliminating large elements of waste by looking at the overall flow of products, information, and material. There are enormous benefits by stepping back from the processes that we may have been very close to for many years. Take time to vision new process relationships that can drive significant cycle time reduction, dramatically eliminate non-value added work, while creating improved flexibility. Use concrete tools and processes, such as value stream mapping and product synchronization, to ensure optimum and sustained results and the main goal should be eliminating the waste and adding value add to the customer. One question comes to the mind, is their any waste in software industry? The answer will be YES. Below listed are examples of wastes in software industry. Waste Software Example Overproduction Features that nobody ever uses. Waiting Time QA waiting for a feature to be written so they can test it. Transportation Waste Time waiting for files to copy. Software written that doesn't contribute to the final Processing Waste product. A feature for which development has started, but Inventory Waste nobody is currently working on it. Doing a “refactoring” manually when the development Wasted Motion environment can do it automatically. Waste from Product Defects Bugs. Table –1: Eliminating waste - Technique We will do the Right in First Time (Incorporate Feedback?) quot;Do It Right the First Timequot; does not mean to quot;Freeze the Specs.quot; On the contrary, product (and software project) specifications change constantly. Lean discipline demands instantaneous 11 Productivity Improvement Initiatives in Software Industry
  12. 12. Amit Kumar Nayak adaptation to changing market conditions, which is best affected with a flexible architecture that readily accommodates changes, monitoring techniques that detect errors before they occur, and tests that are designed before development begins. The quot;Do It Right the First Timequot; rule has been widely used to justify the decision to develop a detailed system design before code is written. The problem with this approach lies in the assumption that customer requirements are static and can be defined by a predetermined system. Because requirements do change and happens frequently-throughout the life of most systems, they cannot be adequately fulfilled by a rigid design. If we acknowledge the axiom that customers may not know what they want at the beginning of development and that their needs might change midstream, we must incorporate a method of obtaining customer feedback during development. Instead, most software development practices include a complex quot;change control processquot; that discourages developers from responding to user feedback. Far from ensuring a quality result, these change-resistant processes actually get in the way of quot;Doing It Right.quot; Lean development employs two key techniques that make change easy. Just as Lean Production builds tests into the manufacturing process to detect when the process is broken, similarly Lean development must “build tests” at various stages of the development process. As development proceeds and changes are made, the unit and regression tests are run. If the tests don't pass, programming may be stopped until the problem is found and corrected. A comprehensive testing capability is the best way to accommodate change throughout the development process. The second technique that facilitates change is “refactoring” (Improving the design with out changing functionality), or improving the design of existing software in a controlled and rapid manner. With refactoring, initial designs can focus on the basic issue at hand rather than speculate about other features that may be needed in the future. Later in the process, refactoring techniques can incorporate these additional features, as they are required, making it easy to accommodate the future if and when it becomes the present. Empower those who add values A basic principle of Lean Production is to drive decisions down to the lowest possible level, delegating decision-making tools and authority to the people quot;on the floor.quot; Often when software development environments under-perform, the instinctive reaction is to impose more rigid processes, specifying in greater detail how people should do their jobs. Lean Production principles suggest exactly the opposite approach. When there are problems in manufacturing, a team of outside experts is not sent in to document in more detail how the process should be run. Instead, people on the manufacturing floor are given tools to evaluate and improve their own areas. They work in collaborative teams with the charter to improve their own processes and the links to nearby processes for which they are suppliers or customers. Their supervisors are trained in methods of forming and encouraging work teams to solve their own problems. To help people improve their own skills, some teams track via a job skill chart. It shows people's names on one axis, and skills on another. When someone has mastered a skill, a mark is put in the intersection. Some teams provide bonuses to people as they are certified in new skills, to recognize their effort and their increased value to the organization. Software development involves the handoff of information at least once (from user to programmer) and often more than once (from user to designer to programmer). One school of thought holds that it's best to transfer all such information in writing, but in fact, a great amount of tacit knowledge is lost by handing off information on paper. A second school of thought believes that it’s far more effective to have small collaborating teams work across the boundaries of an information handoff, minimizing paperwork and maximizing communication. 12 Productivity Improvement Initiatives in Software Industry
  13. 13. Amit Kumar Nayak It is extremely important to have solid metrics on the current state condition and to quantitatively target the improvement level for each individual. However, in order to continue to stretch performance to a higher level, you must always quantify the level of performance that would guarantee industry-leadership and near-perfect process capability. This process of entitlement visioning stretches the limits of potential success and enables out-of-the-box thinking when implementing designs. It also enables consensus on how far improvement efforts should continue. You have to look at three time frames of performance: current, next level, and entitlement vision. Create a culture of Continuous improvement. (Kaizen) Lean development gives priority to people and collaborating teams over paperwork and processes. It focuses on methods of forming and encouraging teams to address and resolve their own problems, recognizing that the people doing the work must determine the details. In many software development projects today, excellence means the ability to adapt to fast- moving, rapidly changing environments. Process-intensive approaches such as the higher levels of Software Engineering Institute's (SEI) Capability Maturity Model (CMM) may lack the flexibility to respond rapidly to changes and more over these process-documentation programs indicate excellence only when the documented process excels in the context of its use. So these accreditations have their own advantages and disadvantages. Iterative development can effectively employ the Plan-Do-Check-Act method. During the first iteration, the handoff from design to programming or programming to testing may be a bit rough. It's OK if the first iteration provides a learning experience for the project team, because the subsequent iterations will allow the team to improve its process. DO CHECK PLAN ACT RE- BASELIN Figure – 1: PDCA(R) Cycle In a sense, an iterative project environment becomes an operational environment, because processes are repeated and Deming's techniques of process improvement can be applied from one iteration to the next. A simple Plan-Do-Check-Act-Re Baseline principle can be followed. • Plan: Choose a problem. Analyse it to find a probable cause. • Do: Run an experiment to investigate the probable cause. • Check: Analyse the data from the experiment to validate the cause. • Act: Refine and standardize based on the results. 13 Productivity Improvement Initiatives in Software Industry
  14. 14. Amit Kumar Nayak • Re-Baseline: Reset the targets and set new targets. Product/Solution improvement is also enhanced in the iterative process, particularly if refactoring is used. In fact, refactoring provides a tremendous vehicle to apply the principle of continuous improvement to software development. However, we need an improvement model that can span more than a single project. We must improve future project performance by learning from existing ones. Here again, Lean Production can point the way. Teams may use job rotation as well: explicitly making sure that people get to do different jobs over time, so they maintain their skill in a variety of areas. It's easiest to balance work when people are able to be flexible about what they do. Teams are given control over their process. They may work with management and experts to help revise and improve their process, but they have the responsibility for it. Wherever possible a team will install foolproof mechanisms (Poka-Yoke) that make a part automatically move to the right position, or easily reject wrong parts. I see an analog of this in the way software teams apply tools such as configuration management systems, automated builds, and refactoring support. Another improvement tool has become known under the name SMED: Single Minute Exchange of Dies. In car manufacturing, changing from making one part to another can be a lot of work. The traditional solution has been, quot;make a long run of parts after a die change,quot; but this creates a lot of inventory. SMED encourages a team to be able to make a changeover quickly, so inventory is not necessary. The last tool I'll mention is the ability of teams to quot;stop the line.quot; Whenever a problem occurs, anybody is empowered to stop the line. When the line stops, people investigate. They do a root cause analysis by asking quot;why?quot; five times. Software teams can adopt this tool as well: make it a rule that anybody can ask for help or for the team's attention at any time, and don't settle for fixing immediate causes when you address a problem. Now days many organizations are facing a major issue regarding the timely delivery of the software with minimal defect and maximum customer satisfaction, but they don’t know how to address the situation. I think lean can address this. Implementing a “Service Roadmap” where a definite predictability is introduced in every part of the product life cycle (PLC). Here everybody starting from the end user to marketing team testing team and development team is aware of the product availability to perform their respective job. An entire backward integration needs to be done after a thorough analysis of the PLC. Unlike earlier customer doesn’t know when will he get the next product (new or upgraded version) and hence a dissatisfaction regarding the service. Similarly due to unavailability of the clear time frame and predictability the developer and tester were taking their own time to perform their job hence customer dissatisfaction and schedule deviation. Similarly the tester whose jobs largely depend on the developer’s work will not sit idle (is an example of inventory build up process or a waste) due to unavailability of the build or software. Do everything with the customer in mind Often, the goals of lean practices are to cut costs and improve internal operations. However, it is essential to broaden this scope when undergoing a true lean transformation. A firm should keep their customer at the forefront of the planning and implementation process. A key to success is including the customer in every single metric you choose. If you are not sure what needs your customers have, just ask. Will shortened cycle times improve customer satisfaction? Would vendor managed inventory help your customer improve service and cut costs? How will reducing the number of suppliers and components benefit your ultimate customer? LEAN tells quality as quot;conformance to requirements.quot; The most common cause of failed projects is missing, incomplete or incorrect requirements. The software development world has responded to this risk by amplifying the practice of gathering detailed user requirements and getting user 14 Productivity Improvement Initiatives in Software Industry
  15. 15. Amit Kumar Nayak sign-off prior to proceeding with system design. However, this approach to defining user requirements is deeply flawed. As discussed above in the “Do it right the first time” principle the process should have the provision for the customer to make changes. The Software compliance and User (Customer) acceptance testing must be done with reference to the customer requirements. Pull is more effective than push Lean Software development means rapid, Just-in-Time delivery of value. In manufacturing, the key to achieving rapid delivery is to manufacture in small batches pulled by a customer order. Similarly in software development, the key to rapid delivery is to divide the problem into small batches (increments) pulled by a customer test. The single most effective mechanism for implementing lean production is adopting Just-in-Time, Pull from demand flow. Similarly, the single most effective mechanism for implementing lean development is delivering increments of real business value in short time-boxes. Maximizing flow In lean software development, the idea is to maximize the flow of information and delivered value. In lean production, Maximizing flow does not mean automation. Instead it means limiting what has to be transferred, and transferring that as few times as possible over the shortest distance with the widest communication bandwidth. Similarly in software development the idea is to eliminate as many documents and handoffs as possible. In the lean software development emphasis is to pair a skilled development team with a skilled customer team and to give them the responsibility and authority to develop the system in small, rapid increments, driven by the customer priority and feed back. Project managers have been trained to focus on managing scope, just as in manufacturing production managers concentrated on maximizing machine productivity. However, Lean software development is fundamentally driven by time and feedback. In the same way that localized productivity optimization weakens the overall manufacturing process, so focusing on managing scope impairs project development. Holding the scope to exactly what was envisioned at the beginning of a project offers little value to the user whose world is changing. In fact, it imparts anxiety and paralyses decision-making, ensuring only that the final system will be outdated by the time it's delivered. Managing to a scope that's no longer valid wastes time and space, necessitating inefficient issue lists, extensive trade- off negotiations and multiple system fixes. However, as long as limiting a project to its original scope is a key project management goal; local optimization will flourish—at the expense of the project's overall quality. The lean production is a good metaphor for software development, if it is applied in keeping with the underlying spirit of lean thinking. The proposed lean software development process principles are: • Eliminate waste; • Satisfy stakeholders; • Empowerment; • Deploying Comprehensive testing; • Deliver as fast as possible; • Refactoring; • Learn by Experimentation; • Measure Business impact; • Optimize across organization; 15 Productivity Improvement Initiatives in Software Industry
  16. 16. Amit Kumar Nayak Lean thinking dictates that scope will take care of itself if the domain is well understood and there is a well-crafted, high-level agreement on the system's function in the domain. Scope will take care of itself if the project is driven in time buckets that aren't allowed to slip. Scope will take care of itself if both parties focus on rapid development and problem solving, and adopt waste-free methods of achieving these goals. When applied to software development in the right context and spirit, these concepts provide a much broader scope and framework for improving software development process. The simple tenets of Lean Production and Lean thinking have brought dramatic improvements in a myriad of industries. If applied to software development process as “Lean Software development and testing”, these practices can make highest quality, lowest cost, shortest lead- time software development possible. 16 Productivity Improvement Initiatives in Software Industry
  17. 17. Amit Kumar Nayak 4.0 Case Study: 4.1Productivity Improvement Measures: A case study Problem Definition: Increasing the development (software) Productivity by 10% in year to year basis for every individual activity involved in the process. The improvements should be measurable quantitatively. Project Summary: Objective: Application Software development towards reduction of Nitrogen Oxide (NO & NO2) in the emissions to conform to EURO5 norms for heavy duty vehicles. Development Environment: Embedded software development Team size: 45 people Major Challenges: The general trend in measuring the software size is, “Source Lines of Code” (SLOC) a frequently used one. But it is different for embedded development environment. In embedded development, the software will be said to be better if the task is accomplished in less number of SLOC. This is because of Processor Memory and Run time constraints. There may be some requirements, which call for deletion of some existing code and addition of new code. Finally, the delta change may be very less but the time required may be very high for impact analysis. When development related to hardware such as EEPROM (Electrically Erasable Programmable Read Only Memory), peripherals, MCU (Microcontroller unit), it is very difficult to estimate the effort. Once the development is done for few weeks, suddenly there may be some requirement change or little problem in compatibility which finally tends to change few lines of code. There it is a difficult task to measure the effort and size of the software Standardization for Size Measurement: In application development, most of the function can be realized in terms some standard components such and P-Controller, PI-Controller, Timers, Switches, Curves, Maps etc. For each component a weightage is assigned, which is called “Testable Tags” (TT). For example, P-Controller has 4 units of TTs, PI-Controller has 6 units of TTs, Timer has 1 unit of TT, and Curves has 4TTs. This way, size of software functionality can be derived in terms of TTs. Baseline Productivity (Bench marking): Based on past history of the data, Productivity is baseline as below: Productivity = No. of TT units software development per Person Day effort. = 2.26 TT / day. Brainstorming to identify areas of Improvement: Brainstorming sessions conducted within team to locate areas where productivity improvement can be possible. Fishbone analysis is done using the 5-Why Rule. This 17 Productivity Improvement Initiatives in Software Industry
  18. 18. Amit Kumar Nayak helps in getting the probable reasons / areas for productivity improvement. There after, 80:20 Pareto analyses is applied to first attack the few 20% reasons which may give maximum productivity benefit. These proposals are not only directed towards Productivity Improvement alone. They also help to reduce number of delivered defects, there by resulting in Quality Improvement. Fishbone Analysis P1: Process N1: New Colleague Optimization Productivity not optimum P1_1_1 P1_1_2 P1_1_2_1 P1_1 P1_2_1 N1_1_1 N1_1_2 P1_2 N1_1 P1_3_1 N1_2_1 P1_3 N1_2 Productivity Improvement hurdles T1_2_1 T1_1_1 T1_1_1_1 T1_2 T1_3_1 T1_1 T1_3 T1: Testing Figure- 2: Fishbone Analysis Each bone of the fish is tells about a probable problem. When we keep asking why, we get to the root of the problem. There are 3 major bones: 1. P1: Process Optimisation, to make the process Lean 2. N1: New Colleague Productivity not optimum 3. T1: Testing 18 Productivity Improvement Initiatives in Software Industry
  19. 19. Amit Kumar Nayak The following pictures depict more about each bone: Probable Actions Root causes Proposed Why ? P1: Process Optimization P1_1: Rework effort in Reviews is more, should be reduced. Why ? Prepare Project specific P1_1_1: Checklist are Old and checklists which can aid the Not up to date team to minimize defects and re-work effort. P1_1_2: Checklist are not used in spirit Encourage use of checklist atleast for any task greater than Why ? 2 weak. P1_1_2_1: Checklist are generic and does not much value P1_2: Redundant data updation at Multiple locations. Identify the areas of redundancy Why ? and eliminate the same. P1_2_1: Tool set is not coherent P1_3: Customer Requirements not managed properly Introduce use of Clear Quest Requirement Management tool. Why ? P1_3_1: Lack of Proper Requirement Management tool Figure- 3: Fishbone – P1: Process Optimisation 19 Productivity Improvement Initiatives in Software Industry
  20. 20. Amit Kumar Nayak Probable Actions Root causes Proposed N1: New Why? Colleagues Productivity Enhancement N1_1: Learning Curve is slow Why? N1_1_1: Lack of software Development & Process awareness Provide project specific OJT N1_1_2: Organization OJT does (On Job Training). focus on Project specific needs Focus project specific domain and toolset in OJT. N1_2: Lack of Domain Knowledge Why? N1_2_1: Tool set is not coherent Figure- 4: Fishbone – N1: New colleagues Productivity enhancement 20 Productivity Improvement Initiatives in Software Industry
  21. 21. Amit Kumar Nayak Probable Actions Root causes Proposed T1: Testing Why? Optimization (Testing effort more) T1_1: Testing environment is altogether different compared other s/ w companies. Why ? Provide project specific OJT. For new colleagues assign T1_1_1: Toolset is different and testing work and make them Black box testing proficient in testing. Why ? T1_1_1_1: Customer need is testing on actual target T1_2: Testing is not automated Identify areas where Tools can be developed/ used to reduce testing effort and Initiate Why ? necessary steps. P1_2_1: No specific tools developed or available which are Introduce TAXI suitable to environment T1_3_1: Re-use is minimum Make test plan preparation Why ? mandatory for Platform teams P1_3_1: Platform team do not and Customer teams to re- prepared test plans always. use the same wherever possible. Figure- 5: Fishbone – T1: Testing optimisation The actions items are identified for the 20% reasons and they are implemented. These are:  Introducing Project specific OJT (On job training) for new colleagues  Developing customized checklists specific to project and development environment. Encourage team to use these checklists as part of their regular work.  Develop or adopt Tools within the project to increase the efficiency and to measure quantitatively.  Re-use of test/code specifications. 21 Productivity Improvement Initiatives in Software Industry
  22. 22. Amit Kumar Nayak Baselines, targets and benefit measurements: Area of Improvement Baseline Target Actual Benefit Productivity Improvement 2.26 TTs / PD 2.48 (10%) 2.59 (14%) Quality Improvement (*) 0.037 defect / 0.044 (20%) 0.437 (18%) person hour (*): Quality Improvement is in terms of detection of defects internals before product is delivered to customer. Table-2: Baselines, Targets, Benefit measurement. After implementing the above action items, benefits were measured and results are illustrated in the table above. Although the set targets are achieved, we don’t stop in looking for improvements. We re- baseline the targets continuously after a set time of 1 year. This way the process cycle of PLAN – DO – CHECK – ACT – RE-BASELINE is maintained. The benefits measured are plotted in the graph below. The average of samples is 2.598 TTs/PD, against the baseline of 2.26TTs/PD, which is 14% increase over the baseline. Productivity trend 3 Productivity (TT/Day) 2.5 2 Actual Productivity 1.5 Baseline 1 0.5 0 1 2 3 4 5 6 No of Delivery Figure- 6: Productivity trend Challenges faced during implementation:  Inertia of team to change  Not enough Motivation They are tackled by constantly making the team to remind the Organization objective. One such thing, making them understand how these things could be helpful in getting CMMI-L5 certification. Although there is some improvement in removing their inertia, there is still lot of scope for improvement. 22 Productivity Improvement Initiatives in Software Industry
  23. 23. Amit Kumar Nayak 5.0 Conclusion The software industry is becoming increasingly interested in removing defects after they are created. A focus on defect removal sounds like a good idea. What if the defects are not created in the first place? What would that be worth??? Is it realistic to suggest that software can be built without defects?? The above issues can be addressed and productivity can be measured by improving software process with the objectives of improving software quality, productivity, and Deliverability. Various paradigms for improvement and for process capability modeling are in use or in trial. These approaches into two basic categorist op-down, such as the Software Engineering Institute’s Capability Maturity Model (CMM), and bottom-up, such as Prof. Victor Basili’s Quality Improvement Paradigm (QIP).At the same time, a number of software quality- related national and international standards like Lean are being promulgated and some are seeing wide spread adoption. These factors raise two issues that must be discussed within the software engineering Community. These are the relative merits and deficiencies of the various software process l improvement paradigms and their relative applicability to various organizational cultures, and relevance of the various software quality standards and process standards to actual improvements in quality or productivity. Businesses are focused on producing innovative product and services. In order to retain market share and to be able to remain in business, they must produce their products or services minimizing time-to-market and with a level of quality appropriate for their marketplace. The largest segment of the world IT economy is that populated by small and medium size companies. These do not have deep pockets that can support significant R&D or large process improvement projects. Changes in these organizations need to be evolutionary, not revolutionary. They need to precisely fit their business objectives. Meanwhile, engineers and managers must focus on getting product out-the-door. 23 Productivity Improvement Initiatives in Software Industry
  24. 24. Amit Kumar Nayak 6.0 Glossary Acceptance testing Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. Accuracy A quantitative measure of the magnitude of error. Adaptability The ease with which software satisfies differing system constraints and user needs. Code: The transforming of logic and data from design specifications (design descriptions) into a programming language. Compactness The degree to which a system or component makes efficient use of its data storage space- occupies a small volume Compatibility The ability of two or more systems or components to perform their required functions while sharing the same hardware or software environment CMM Capability Maturity Model. Complexity 1. (Apparent) the degree to which a system or component has a design or implementation that is difficult to understand and verify 2. (Inherent) the degree of complication of a system or system component, determined by such factors as the number and intricacy of interfaces, the number and intricacy of conditional branches, the degree of nesting, and the types of data structures . Concept phase: The initial phase of a software development project, in which the user needs are described and evaluated through documentation (for example, statement of needs, advance planning report, project initiation memo, feasibility studies, system definition, documentation, regulations, procedures, or policies relevant to the project. Cost estimation The process of estimating the quot;costsquot; associated with software development projects, to include the effort, time, and labor required. Cost of maintenance The overall cost of maintaining a computer system to include the costs associated with personnel, training, maintenance control, hardware and software maintenance, and requirements growth. Cost of operation The overall cost of operating a computer system to include the costs associated with personnel, training, and system operations. Design phase 24 Productivity Improvement Initiatives in Software Industry
  25. 25. Amit Kumar Nayak The period of time in the software life cycle during which the designs for architecture, software components, interfaces, and data are created, documented, and verified to satisfy requirements. Detailed design The process of refining and expanding the preliminary design of a system or component to the extent that the design is sufficiently complete to be implemented. Effectiveness The degree to which a system's features and capabilities meet the user's needs. Efficiency The degree to which a system or component performs its designated functions with minimum consumption of resources (CPU, Memory, I/O, Peripherals, Networks. EEPROM Electrically Erasable Programmable Read Only Memory Error handling The function of a computer system or component that identifies and responds to user or system errors to maintain normal or at the very least degraded operations. Error proneness The degree to which a system may allow the user to intentionally or unintentionally introduce errors into or misuse the system. Error tolerance The ability of a system or component to continue normal operation despite the presence of erroneous inputs. Fail safe (Poka-Yoke) Pertaining to a system or component that automatically places itself in a safe operating mode in the event of a failure. Fault An incorrect step, process, or data definition in a computer program. Functional testing Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions. Synonym: black-box testing Integration testing Testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them. Interface testing Testing conducted to evaluate whether systems or components pass data and control correctly to one another 25 Productivity Improvement Initiatives in Software Industry
  26. 26. Amit Kumar Nayak Operations and maintenance phase The period of time in the software life cycle during which a software product is employed in its operational environment, monitored for satisfactory performance, and modified as necessary to correct problems or to respond to changing requirements Person Day (PD) It is a unit of effort equivalent to 1 person working for 1 hour. Performance testing Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Portability The ease with which a system or component can be transferred from one hardware or software environment to another Productivity The quality or state of being productive Quality measure A software feature or characteristic used to assess the quality of a system or component. Reengineering Rebuilding a software system or component to suit some new purpose; for example to work on a different platform, to switch to another language, to make it more maintainable. Regression testing Selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified requirements. Reliability The ability of a system or component to perform its required functions under stated conditions for a specified period of time. Reusability The degree to which a software module or other work product can be used in more than one computing program or software system. Reverse engineering The process of analyzing a system's code, documentation, and behavior to identify its current components and their dependencies to extract and create system abstractions and design information. The subject system is not altered; however, additional knowledge about the system is produced. SLOC: Source Lines of Code Software life cycle The period of time that begins when a software product is conceived and ends when the software is no longer available for use. The life cycle typically 26 Productivity Improvement Initiatives in Software Industry
  27. 27. Amit Kumar Nayak includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement phase. These phases may overlap or be performed iteratively, depending on the software development approach used. SMED Single Minute Exchange of Dies Test phase The period of time in the software life cycle during which the components of a software product are evaluated and integrated, and the software product is evaluated to determine whether or not requirements have been satisfied. Test tools Computer programs used in the testing of a system, a component of the system, or its documentation. Examples include monitor, test case generator, and timing analyser. Test An activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component. TT: Testable Tags Usability The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component. 27 Productivity Improvement Initiatives in Software Industry