“Lean software development: Discussion on questionnaire survey”
1Piyush Kumar Pareek, 2A.N.Nandakumar
Computer Science & Engineering, Jain University, Bengaluru, India Abstract : Lean development focuses on creating high-
value 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 300 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
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 2007:103-104) 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 2011:122-125)
II. RESULTS & DISCUSSION
1. Are you familiar with the term Lean Software Development?
When the question was asked to respondents of sample size 300. 64.0 percent of total respondents saying „Yes‟
which is 192 in frequency and 36.0 percent of the respondents saying „No‟ which is 108 of the total respondents. Here the cumulative percentage as shown in Table 1 is 64.0 percent is for „Yes‟ and 100.0 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 Cumulative
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 Issues which is 16 in frequency and valid percentage being 5.3 percent. The next one is the data issues which is 20 with the valid percentage of 6.7 percent. Then come resource constraints which is 20 with the valid percentage of 6.7 percent. Training issues frequency is 26 with valid percent 8.7 percent. Technical Issues is 20 with 6.7 percent. Then with conflicts in priority of project the frequency is 40 and with valid percentage of 13.3 percent. Unrealistic Timeline with frequency is 21 and valid percentage is 7.0 percent.
Vendor Functionality Issues is 20 with valid percentage
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 Issues is 30.7 percent; Data Issues is 37.3 percent; Resource Constraints is 44.0 percent; Training Issues is 52.7 percent; Technical Issues is 59.3 percent;
Conflicts in Priority of Project is 72.7 percent;
Unrealistic Timeline is 79.7 percent; Vendor Functionality Issues is 86.3 percent; Misses/ Delayed Communication is 100.0 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.
Table 2: Reasons behind extended durations of the project
Frequency Percent Valid Percent Cumulative Percent
Initial Scope was Extended 76 25.3 25.3 25.3
Organizational Issues 16 5.3 5.3 30.7
Data Issues 20 6.7 6.7 37.3
Resource Constraints 20 6.7 6.7 44.0
Training Issues 26 8.7 8.7 52.7
Technical Issues 20 6.7 6.7 59.3
Conflicts in Priority of Project 40 13.3 13.3 72.7
Unrealistic Timeline 21 7.0 7.0 79.7
Vendor Functionality Issues 20 6.7 6.7 86.3
Missed/ Delayed Communication 41 13.7 13.7 100.0
Total 300 100.0 100.0
0 50 100 150 200
Yes No
Series1 192 108
192
108
Respondents
Axis Title
Are you familiar with the term Lean Software Development ?
Figure 2: Reasons behind extended durations of the project 3. 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 „Strongly Disagree‟ is 33 with 11.0 percent;
„Disagree‟ is 67 with 22.3 percent; „Neither Agree Nor Disagree‟ is 34 is 11.3 percent; „Agree‟ is 133 is 44.3 percent; „Strongly Agree‟ is 33 with percentage of 11.0 percent.
The cumulative percentage is as follows „Strongly Disagree‟ is 11.0 percent; „Disagree‟ is 33.3 percent;
„Neither Agree nor Disagree‟ is 44.7 percent; „Agree‟ is 89.0 percent and „Strongly Agree‟ is 100.0 percent.
From Figure 3, the bar graph analyses that many respondents as many as 133 respondents out of 300 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.
Frequency Percent Valid Percent Cumulative Percent
Strongly Disagree 33 11.0 11.0 11.0
Disagree 67 22.3 22.3 33.3
Neither Agree nor Disagree 34 11.3 11.3 44.7
Agree 133 44.3 44.3 89.0
Strongly Agree 33 11.0 11.0 100.0
Total 300 100.0 100.0
100 2030 4050 6070 80
Initial Project
Scope was Extend
ed
Organi zationa l Issues
Data Issues
Resour ce Constr
aints
Trainin g Issues
Techni cal Issues
Conflic ts in Priority
of Project
Unreali stic Timelin
e
Vendor Functi onality
Issues
Missed / Delaye
d Comm unicati
Series1 76 16 20 20 26 20 40 21 20 on41
76
16 20 20 26 20
40
21 20
41
Respondents
Various options
Which of following according to you are reasons behind
extended durations of project ?
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 300 respondents „Strongly Disagreed‟ which is 11.0 percent; 32 of them
„Disagreed‟ which is 10.7 percent; 33 of them „Neither Agree nor Disagree‟ which is 11.0 percent; 101 of them
„Agree‟ which is 33.7 percent; 101 of them „Strongly Agree‟ which is 33.7 percent.
As per the Table 4, the cumulative percentage are as follows: „Strongly Disagree‟ is 11.0 percent; „Disagree‟
is 21.7 percent; „Neither Agree nor Disagree‟ is 32.7 percent; „Agree‟ is 66.3 percent; „Strongly Agree‟ is 100.0 percent.
As per the Figure 4, we can come to conclusion that many respondents agree that many respondents as many as 33.7 percent either „Disagree‟ or „Strongly Disagree‟
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.
Table 4: Technical complexity that was not analyzed properly during Design Phase
Frequency Percent Valid Percent Cumulative Percent
Strongly Disagree 33 11.0 11.0 11.0
Disagree 32 10.7 10.7 21.7
Neither Agree nor Disagree 33 11.0 11.0 32.7
Agree 101 33.7 33.7 66.3
Strongly Agree 101 33.7 33.7 100.0
Total 300 100.0 100.0
200 4060 80 100120 140
Strongly Disagree
Disagree Neither Agree nor
Disagree
Agree Strongly Agree
Series1 33 67 34 133 33
33
67
34
133
33
Respondents
Options
Prioritizing a requirement without having
complete information about it
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 300 respondents. 50 of them „Disagree‟ with 16.7 percent.
200 of them „Agree‟ with 66.7 percent. 50 of them
„Strongly Agree‟ with 16.7 percent.
The cumulative percent of „Disagree‟ is 16.7 percent;
„Agree‟ is 83.3 percent and „Strongly Agree‟ is 100.0 percent.
From the Figure 5 almost 200 out of 300 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 Frequency Percent Valid Percent Cumulative Percent
Disagree 50 16.7 16.7 16.7
Agree 200 66.7 66.7 83.3
Strongly Agree 50 16.7 16.7 100.0
Total 300 100.0 100.0
200 4060 10080 120
Strongly Disagree
Disagree Neither Agree
nor Disagree
Agree Strongly Agree
Series1 33 32 33 101 101
33 32 33
101 101
Respondents
Options
Technical complexity that was not analyzed properly during Designing Phase
0 50 100 150 200
Disagree Agree Strongly Agree
Series1 50 200 50
50
200
50
Wait time between the tasks that are identified to
complete different modules
REFERENCES:
[1] Robert Glass. 2007. „Is Software Engineering‟ in IEEE SOFTWARE 0740-7459/07103-104.
[2] Lianru Liu, Qian Wang. 2011. „A SaaS-based Web Call Center System for Network Marketing‟
in IEEE 978-1-4577-0208-2/11 122-125
[3] Lianru Liu.2010. „An Implementation of the online-payment Platform based on SaaS ‟ in IEEE 978-1-4244-6359-6/10 658-662
[4] Lee C S, Jeong C .2009. „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.2007. „Use of Extreme Programming Methodologies in IT Application Design Processes: An Empirical Analysis ‟in PICMET 2007 Proceedings, 5-9 August, Portland, Oregon - USA PICMET IEEE 2468-2475.
[6] Samuel A. Ajila. 2006. „The Impact of Firm Size on Knowledge Reuse and Exploration during Software Product Development: an Empirical Study ‟in IEEE 0-7803-9788-6/06 160-165 [7] Tina makitola. Harivirolainen. 2011. „Critical
Incidents in a Growth Path of a Small Software Company‟ in IEEE 978-1-890843-23-6 1-9
