“Understanding Quality Practices in SME's”

(1)

“Understanding Quality Practices in SME’s”

1Kothapalli Venkata Rao, ²Balakrishna R

1 Research Scholar, Computer Science & Engineering, JAIN University, Bengaluru & Associate Professor in Department of Computer Science and Engineering, Kammavari Sangham Institute of Technology, Bengaluru

2Professor and Principal RajaRajeswari College of Engineering, Bengaluru Research Guide, Computer Science & Engineering, JAIN University, Bengaluru

Email: [email protected], [email protected]

Abstract : The nature of data framework advancement is a need for associations that depend on creating office programming applications. Data framework quality ought to be surveyed by means of a standard system. Different strategies have been exhibited for improving data framework programming improvement. In any case, existing methodologies are expensive and hard to actualize and in this way are infrequently utilized by small– medium associations in creating nations. Luckily, measurable methodologies, when connected appropriately, are less asset escalated than ordinary methodologies for enhancing the advancement of programming data frameworks, while being similarly powerful. Be that as it may, couple of examinations have specified the methodology associated with receiving these important factual methodologies for small– medium associations. This Paper aims to identify the quality practices being followed in SME’s in Bengaluru using a Questionnaire Survey

Keywords : Framework , Associations , Questionnaire and Factual Methodologies.

Introduction

Lean software development (LSD) is a translation of lean manufacturing and lean IT principles and practices to the software development domain. Adapted from the Toyota Production System, a pro-lean subculture is emerging from within the agile community. Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles.

In Implementing Lean Software Development, Mary and Tom Poppendieck show how the seven principles of lean manufacturing can be applied to optimize the whole IT value stream. These principles are:

1. Eliminate waste. Lean thinking advocates regard any activity that does not directly add value to the finished product as waste. The three biggest sources of waste in software development are the addition of unrequired features, project churn and crossing organizational boundaries (particularly between stakeholders and development teams). To reduce waste

2. Build in quality. Your process should not allow defects to occur in the first place, but when this isn’t possible you should work in such a way that you do a bit of work, validate it, fix any issues that you find, and then iterate. Inspecting after the fact, and queuing up defects to be fixed at some time in the future, isn’t as effective. Agile practices which build quality into your process include test driven development (TDD) and non- solo development practices such as pair programming and modeling with others.

3. Create knowledge. Planning is useful, but learning is essential. You want to promote strategies, such as iterative development, that help teams discover what stakeholders really want and act on that knowledge. It’s also important for a team to regularly reflect on what they’re doing and then act to improve their approach.

4. Defer commitment. It’s not necessary to start software development by defining a complete specification, and in fact that appears to be a questionable strategy at best. You can support the business effectively through flexible architectures that are change tolerant and by scheduling irreversible decisions to the last possible moment. Frequently, deferring commitment requires the ability to closely couple end-to-end business scenarios to capabilities developed in multiple applications by multiple projects.

5. Deliver quickly. It is possible to deliver high- quality systems quickly. By limiting the work of a team to its capacity, which is reflected by the team’s velocity (this is the number of “points” of functionality which a team delivers each iteration), you can establish a reliable and repeatable flow of work. An effective organization doesn’t demand teams do more than they are capable of, but instead asks them to self-organize and determine what they can accomplish. Constraining these teams to delivering potentially shippable solutions on a regular basis motivates them to stay focused on continuously adding value.

(2)

7. Optimize the whole. If you want to be effective at a solution you must look at the bigger picture. You need to understand the high-level business processes that individual projects support—processes that often cross multiple systems. You need to manage programs of interrelated systems so you can deliver a complete product to your stakeholders. Measurements should address how well you’re delivering business value, because that is the sole reason for your IT department.

Lean thinking is important for scaling agile in several ways:

1. Lean provides an explanation for why many of the agile practices work. For example, Agile Modeling’s practices of light weight, initial requirements envisioning followed by iteration modeling and just-in-time (JIT) model storming work because they reflect deferment of commitment regarding what needs to be built until it’s actually needed, and the practices help eliminate waste because you’re only modeling what needs to be built.

2. Lean offers insight into strategies for improving your software process. For example, by understanding the source of waste in IT you can begin to identify it and then eliminate it.

3. Lean principles provide a philosophical foundation for scaling agile approaches.

4. It provides techniques for identifying waste.

Value stream mapping, a technique common within the lean community whereby you model a process and then identify how much time is spent on value-added work versus wait time, helps calculate overall time efficiency of what you’re doing. Value stream maps are a straightforward way to illuminate your IT processes, providing insight into where significant problems exist. I’ve created value stream maps with several customers around the world where we analyzed their

existing processes which some of their more traditional staff believed worked well only to discover they had efficiency ratings of 20-30%. You can’t fix problems which you are blind to.

Motivation

As the popularity of Lean Six Sigma techniques expands into software and technology environments, the notion that these methods and tools can provide a quick fix, unrealistic results or a panacea (for all that is wrong) has been proliferated. Some of these notions are further compounded by the reality that many of these environments are at a low maturity level with regard to process stability, repeatability and even basic measurement. Software and technology processes are often the result of a start-up mentality or organization.

These dynamics complicate – and are even counterproductive to – a conventional Six Sigma deployment approach that a typical manufacturing or service organization might use successfully. This reality must be taken into consideration to develop an acceptable approach to successful implementation. By carefully studying the actions of early adopting organizations and characterizing each individual organization’s needs and culture, analysts can design and implement a deployment strategy that is more finely tuned and has a higher probability of success.

RESEARCH METHODOLOGY

 Geographic Location : Bengaluru

 Accepted Sample Size for the Survey : 317

 Rejected Sample : 57

 Type of Company : Software

 Category : Small & Medium Level Enterprises

 Investment : Less Than 10 Crores

 Tool Used : IBM SPSS

RESULTS OF QUESTIONNAIRE

Table 1 : Are the activities for software project tracking and oversight reviewed with senior management on a periodic basis

Frequency Percent Valid Percent Cumulative Percent

Valid Strongly Agree 40 12.6 12.7 12.7

Agree 148 46.7 46.8 59.5

Neither Agree nor Disagree 32 10.1 10.1 69.6

Disagree 96 30.3 30.4 100.0

Total 316 99.7 100.0

Missing System 1 .3

Total 317 100.0

(3)

Figure 1 : Normal Distribution Curve for Project Tracking

For the Research Question “Are the activities for software project tracking and oversight reviewed with senior management on a periodic basis”, 60 % of the respondents agreed , 10% of respondents had no opinion whereas 30 % of the respondents disagreed

Table 2: Are software configuration management activities planned for the project?

Frequency Percent Valid Percent Cumulative Percent Valid

Strongly Agree 48 15.1 15.2 15.2

Agree 172 54.3 54.4 69.6

Disagree 80 25.2 25.3 100.0

Total 316 99.7 100.0

Missing System 1 .3

Total 317 100.0

Figure 2 : Normal Distribution Curve for Configuration Management activities

For the Research Question, “Are software configuration management activities planned for the project? ” , Out of 317 Respondents , 70% of the respondents agreed , only 5 % of the respondents were neutral and 25% disagreed.

Table 3: Does the project follow a written organizational policy for implementing software configuration management activities?

Agree 124 39.1 39.2 79.7

Disagree 32 10.1 10.1 97.5

Total 316 99.7 100.0

Missing System 1 .3

Total 317 100.0

(4)

Figure 3 : Normal Distribution Curve for Organisation Policies

For the Research Question on , “Does the project follow a written organizational policy for implementing software configuration management activities? ” , 80%

of the respondents agreed that they follow a written organizational policy , whereas 7% respondents were neutral and 10% of the respondents disagreed for the same.

Table 4 : Are measurements used to determine the status of the activities for software tracking and oversight Frequency Percent Valid Percent Cumulative Percent

Agree 156 49.2 49.4 62.0

Disagree 96 30.3 30.4 100.0

Total 316 99.7 100.0

Missing System 1 .3

Total 317 100.0

Figure 4 : Normal Distribution Curve for Software Tracking and Oversight

For the Research question on , “Are measurements used to determine the status of the activities for software tracking and oversight ” , 62% of the respondents agreed that they are measuring status of activities for software tracking , 7.6% of respondents were neutral on this matter , whereas 30% of the respondents disagreed for the same.

Table 5: Are training activities planned?

Agree 172 54.3 54.4 79.7

Disagree 32 10.1 10.1 94.9

Strongly Disagree 16 5.0 5.1 100.0

Total 316 99.7 100.0

Missing System 1 .3

Total 317 100.0

(5)

Figure 5 : Normal Distribution Curve for Planning Training activities

For the Research Question on , “Are training activities planned? ” , 79.7% of the respondents agreed to the fact that their training activities are very well planned , whereas 5% of the respondents were neutral on the same , 15% of the respondents disagreed for the same.

Table 6 : Does the project follow a written organizational policy for both tracking and controlling its software development activities?

Agree 104 32.8 32.9 45.6

Disagree 118 37.2 37.3 100.0

Total 316 99.7 100.0

Missing System 1 .3

Total 317 100.0

Figure 6 : Normal Distribution Curve for Tracking and Controlling

For the Research Question on , “Does the project follow a written organizational policy for both tracking and controlling its software development activities?” , 45.6%

of the respondents agreed to the fact that they follow policy for both tracking and controlling its software development activities , 17% of the respondents were neutral on the same , 37.2% of the respondents disagreed on the same.

Table 7: Are measurements used to determine the quality of the training program?

Agree 180 56.8 57.0 69.6

Disagree 64 20.2 20.3 97.5

Strongly Disagree 8 2.5 2.5 100.0

Total 316 99.7 100.0

Missing System 1 .3

Total 317 100.0

(6)

Figure 7: Normal Distribution Curve for Quality of Training Program

For the Research question on , “Are measurements used to determine the quality of the training program? ” , 69.6% of the respondents agreed that quality of training is measured , whereas 7.6% of respondents were neutral , 20.2% respondents disagreed , and 2.5% respondents strongly disagreed on the same .

Conclusion

A huge issue of the worldwide business is the expenses of programming issues or mistakes which influences programming designers as well as their clients and the end clients of the product. Frameworks fall flat as a result of deficient execution, security, unwavering quality, ease of use, or accuracy, generally known as quality attributes. Quality is one of the principle resources which empower a firm to upgrade its worldwide aggressive position. Programming measurements and quality models help increment the execution by estimating programming quality. Diverse programming quality models are proposed by various analysts. Various surely understood quality models are utilized to assemble quality programming.

References

[1] Agile Alliance. Manifesto for Agile Software Development. [Online] Retrieved 16th March

2009. Available at:

http://www.agilemanifesto.org .

[2] Agile Modeling Home Page. Effictive Practices for Modeling and Documentation. [Online]

Retrieved 17th March 2009. Available at:

www.agilemodeling.com .

[3] K. Beck, and C. Andres, Extreme Programming Explained: Embrace Change (2nd Edition), AddisonWesley, Boston, 2004.

[4] Computer Programming. [Online] Retrieved 5th

April 2009. Available at:

http://en.wikipedia.org/wiki/Programming [5] Crystal Clear (software development). [Online]

Retrieved 22nd March 2009. Available at:

http://en.wikipedia.org/wiki/Crystal_Clear_(soft ware_development)

[6] M. Cristal, D. Wildt and R. Prikladnicki, Usage of SCRUM Practices within a Global Company.

Global Software Engineering, 2008. ICGSE 2008. IEEE International Conference on, 2008, 222-226.

[7] J. Erickson, K. Lyytinen and K. Siau, Agile Modeling, Agile Software Development, and Extreme Programming: The State of Research. In Journal of Database Management, 16(4), 2005, 88-100.

[8] Extreme Programming. What is Extreme Programming? [Online] Retrieved 18th March

2009. Available at:

www.extremeprogramming.org

[9] Feature Driven Development. [Online] Retrieved 18th March 2009. Available at:

http://en.wikipedia.org/wiki/Feature_Driven_Dev elopment

[10] J. Ferreira, J. Noble, and R. Biddle., Up-Front Interaction Design in Agile Development. In Agile Processes in Software Engineering and Extreme Programming, Springer , Berlin / Heidelberg , 2007, 9- 16

