Lean software development: Discussion on questionnaire survey

Transcription

1 Lean software development: Discussion on questionnaire survey 1 Piyush Kumar Pareek, 2 A.N.Nandakumar Computer Science & Engineering, Jain University, Bengaluru, India Abstract : Lean development focuses on creating highvalue products by removing waste from the development cycle. Lean software development is a software development model adapted from lean manufacturing and agile development principles. The lean model focuses on customer feedback and waste reduction as well as a number of other useful principles that implement the basics of lean development in a software environment. Lean software development promotes an adaptable, incremental model that creates a quality product faster and more predictably than other development processes. This paper focuses on results of few questions when carried out on a sample population of 3 employees of different SME s in Bangalore on lean software development Keywords: Lean, waste reduction & agile I. INTRODUCTION Capability Maturity Model is a bench-mark for measuring the maturity of an organization s software process. It is a methodology used to develop and refine an organization s software development process. CMM can be used to assess an organization against a scale of five process maturity levels based on certain Key Process Areas (KPA). It describes the maturity of the company based upon the project the company is dealing with and the clients. Each level ranks the organization according to its standardization of processes in the subject area being assessed. A maturity model provides: A place to start The benefit of a community s prior experiences A common language and a shared vision A framework for prioritizing actions A way to define what improvement means for your organization In CMMI models with a staged representation, there are five maturity levels designated by the numbers 1 through 5 as shown below: Initial Managed Defined Quantitatively Managed Optimizing. There is an underlying problem, Bruce says. A software process optimized for fun is only good when the tasks are small and the motivation for quality is based on an individual s insight. A software process optimized for phased compliance, he goes on, is only valid for firm and stable requirements. It fails when there is uncertainty regarding the requirements. It also fails when the requirements are not stable. Thus both the natural intuitive approach and the managed response to it have proven to be poor models for controlling the software process. (Robert Glass 27:13-14) E-commerce brings new impacts on business management. E-commerce currently is the most important application on Internet, and is the inevitable result of developments of internet technologies. With the development of Information technology and system integration technology, internal communication and collaboration are greatly improved. Internet can provide 24 X 7 personalized services to customers and quality of services are enhanced (Lianru Liu 211: ) II. RESULTS & DISCUSSION 1. Are you familiar with the term Lean Software Development? When the question was asked to respondents of sample size percent of total respondents saying Yes which is 192 in frequency and 36. percent of the respondents saying No which is 18 of the total respondents. Here the cumulative percentage as shown in Table 1 is 64. percent is for Yes and 1. percent is for No. From the Figure 1 we can easily say that that many aware of the term Lean Software Development. Here Lean Software Development s objective is to eliminate waste, increase the feedback, delay commitment, faster delivery, building in the integrity, empowering the whole team, optimizing everything. When wastes are reduces then we will have increased feedback, hence leading to improved productivity. Thus this improves the overall performances which leads to better software being delivered in less time. Table 1: Familiarity with the term Lean Software Development Frequency Percent Valid Percent Cumulative Percent Yes No

2 Are you familiar with the term Lean Software Development? Series1 Yes No Axis Title Figure 1: Familiarity with the term Lean Software Development 2. Which of the following according to you are reasons behind extended durations of project? As per the Table 2 we can see that there are various reasons behind durations of the projects being extended. The duration of the project is being extended with Initial Scope being extended here the frequency is 76 and the percentage is 25.3 percent. Next is the Organizational which is 16 in frequency and valid percentage being 5.3 percent. The next one is the data issues which is 2 with the valid percentage of 6.7 percent. Then come resource constraints which is 2 with the valid percentage of 6.7 percent. Training issues frequency is 26 with valid percent 8.7 percent. Technical is 2 with 6.7 percent. Then with conflicts in priority of project the frequency is 4 and with valid percentage of 13.3 percent. Unrealistic Timeline with frequency is 21 and valid percentage is 7. percent. Vendor Functionality is 2 with valid percentage Table 2: Reasons behind extended durations of the project of 6.7 percent. Then comes Missed/ Delayed Communication with 41 as frequency and valid percentage of 13.7 percent. Now consider the cumulative percentage of each: First one is Initial Scope was Extended is 25.3 percent; Organizational is 3.7 percent; Data is 37.3 percent; Resource Constraints is 44. percent; Training is 52.7 percent; Technical is 59.3 percent; Conflicts in Priority of Project is 72.7 percent; Unrealistic Timeline is 79.7 percent; Vendor Functionality is 86.3 percent; Misses/ Delayed Communication is 1. percent. Here from the Figure 2 we can see that main reason behind the extended durations of the project is that Initial Scope was extended which is being highest of 25.3 percent. Here the initial scope means the scope of the project which was fixed earlier is extended with the increasing client s needs. Initial Scope was Extended Organizational Data Resource Constraints Training Technical Conflicts in Priority of Project Unrealistic Timeline Vendor Functionality Missed/ Delayed Communication

3 Which of following according to you are reasons behind extended durations of project? Initial Project Scope was Extend ed Organi zationa l Data Resour ce Constr aints Trainin g Techni cal Conflic ts in Priority of Project Unreali stic Timelin e Vendor Functi onality Missed / Delaye d Comm unicati on Series Various options Do you prioritize the requirement without having complete information about it? As per the Table 3 we can see that prioritizing a requirement without having complete information the respondents replied with responses with certain frequencies is 33 with 11. percent; is 67 with 22.3 percent; Neither Nor is 34 is 11.3 percent; is 133 is 44.3 percent; is 33 with percentage of 11. percent. The cumulative percentage is as follows is 11. percent; is 33.3 percent; Neither nor is 44.7 percent; is 89. percent and is 1. percent. Figure 2: Reasons behind extended durations of the project From Figure 3, the bar graph analyses that many respondents as many as 133 respondents out of 3 respondents which is 44.3 percent of the total respondents said that they agree to the prioritizing the requirements without having complete information about the following requirements. Prioritizing of the requirements is usually done by the business analysts. The business analysts collects the requirements that is Requirement Elicitation which is necessary step before the analysis and the design step. During this stage the requirements that are being collected are prioritized and based on the priority the designing is done. But many respondents feel that even for prioritizing it is not necessary to have complete information about each requirement. Table 3: Prioritizing a requirement without having complete information about it Neither nor

4 Prioritizing a requirement without having complete information about it Neither nor Series Options Figure 3: Prioritizing a requirement without having complete information about it. 4. What are the technical complexity that was not analyzed properly during Design Phase? As per the Table 4, The technical complexity that was not analyzed during the design phase as many as 33 respondents out of 3 respondents d which is 11. percent; 32 of them d which is 1.7 percent; 33 of them Neither nor which is 11. percent; 11 of them which is 33.7 percent; 11 of them which is 33.7 percent. As per the Table 4, the cumulative percentage are as follows: is 11. percent; is 21.7 percent; Neither nor is 32.7 percent; is 66.3 percent; is 1. percent. Table 4: Technical complexity that was not analyzed properly during Design Phase As per the Figure 4, we can come to conclusion that many respondents agree that many respondents as many as 33.7 percent either or which means that many of them don t agree that technical complexity was not analyzed during Design Phase. Here in the Design Phase, the system is designed in such a way that requirements identified are satisfied during the phase before Design Phase that is Requirements Analysis Phase where the requirements identified are transformed into a System Design Document which describes the design of the system and that can be used as an input to system development in the next phase Neither nor

5 Technical complexity that was not analyzed properly during Designing Phase Neither nor Series Options Figure 4: Technical complexity that was not analyzed properly during Design Phase 5. Is the wait time identified between the tasks that are to complete different modules? As per the Table 5 for the sample size of 3 respondents. of them with 16.7 percent. 2 of them with 66.7 percent. of them with 16.7 percent. The cumulative percent of is 16.7 percent; is 83.3 percent and is 1. percent. From the Figure 5 almost 2 out of 3 respondents that is 66.7 percent agree that the wait time between the tasks are identified so that work can be completed. When the work of one module is completed then there is a waiting time to identified so that what has to be completed in the next phase. In between the phase there are various tasks to be accomplished so that final product or final result that is after integration of different modules there should not be any difficulty. Thus this is the reason why wait time is very essential and should be identified between the modules. Table 5: The wait time between the tasks that are identified to complete different modules Wait time between the tasks that are identified to complete different modules Series1 2 Figure 5: The wait time between the tasks that are identified to complete different modules 114

6 REFERENCES: [1] Robert Glass. 27. Is Software Engineering in IEEE SOFTWARE / [2] Lianru Liu, Qian Wang A SaaS-based Web Call Center System for Network Marketing in IEEE / [3] Lianru Liu.21. An Implementation of the online-payment Platform based on SaaS in IEEE / [4] Lee C S, Jeong C.29. Evaluating the Effectiveness of Information Service for SMEs on Information Orientation and Firm Performance in Proceedings of the 42nd Hawaii International Conference on System Sciences1-9. [5] Adrian Moore, Wm. T. Flannery.27. Use of Extreme Programming Methodologies in IT Application Design Processes: An Empirical Analysis in PICMET 27 Proceedings, 5-9 August, Portland, Oregon - USA PICMET IEEE [6] Samuel A. Ajila. 26. The Impact of Firm Size on Knowledge Reuse and Exploration during Software Product Development: an Empirical Study in IEEE / [7] Tina makitola. Harivirolainen Critical Incidents in a Growth Path of a Small Software Company in IEEE