Productivity Improvement In Sw Industry

Amit Kumar Nayak

Productivity Improvement
Initiatives in
Software Industry
Author: Amit Kumar Nayak

1
Productivity Improvement Initiatives in Software Industry

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Amit Kumar Nayak

Probable Actions

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

Amit Kumar Nayak

Probable Actions

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

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

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

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

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

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

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 In Sw Industry

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Productivity Improvement In Sw Industry

Similaire à Productivity Improvement In Sw Industry (20)

Plus de Amit Kumar Nayak

Plus de Amit Kumar Nayak (6)

Productivity Improvement In Sw Industry