Thursday, March 30, 2023

Software Engineering - Industrial Engineering in Software Engineering

Is the full capability of the #hardware exploited for value creation? An industrial engineer can evaluate periodically. Software engineering component of industrial engineering.

#IndustrialEngineering #Productivity #CostReduction #InformationSystems #SoftwareEngineering

https://nraoiekc.blogspot.com/2020/07/industrial-engineering-in-data-center.html

An industrial engineering approach to software development

D.N. Card, R.A. Berg

Abstract

Many different tools and techniques have been developed to increase software quality and productivity. However, periodic acquisition of improved methods and tools, by itself, does not ensure continual improvement. To be effective, new technology must be integrated into an underlying process. That process must be managed explicitly. This paper describes an industrial engineering approach that treats software development as a process distinct from its unique application to any specific project. Its essential elements include formal process definition, software measurement, process engineering, and quality control. Although already successfully embedded in many manufacturing processes, application of industrial engineering techniques to software remains a novelty. Nevertheless, this approach provides the software enterprise with a long-term plan for improving software quality and productivity.

Journal of Systems and Software

Volume 10, Issue 3, October 1989, Pages 159-168

https://www.sciencedirect.com/science/article/abs/pii/0164121289900290

SWE Industrial Engineering - Software Engineering Process Improvement Function

This guide was written to help organizations establish and sustain a process improvement group as the

focal point of a software engineering process improvement program.

The guide is concerned with the technology used in existing and improved processes and the human side of stimulating a higher quality process.

The term technology is used throughout this guide in the broadest sense. For example, this use of the term would include software inspection as a peer review technology for detecting errors in software development work products; computer-aided software engineering (CASE) as a technology providing automated support for performing activities and creating work products in the software development process; and change management as a technology for planning and implementing organizational change.

How do organizations move from their current state to one where there is continuous improvement? First, they must establish an organizational commitment to quality; next, they must create an entity in the organization that is the focal point, some group responsible for facilitating actions supporting that commitment; and finally, they must carefully plan each step to move from the current situation to the desired one. In the software industry, the organizational focal point is a software engineering process group, and the model for the step-by-step change is the process improvement cycle.

The Process Improvement Cycle

Software process improvement is a continuous cycle.

1. Set expectations based on capabilities of new technologies and benchmarking.

2. Assess the current practice inside the organization.

3. Analyze the variance between expectation and practice.

4. Develop and Propose changes that will reduce the variance and thereby improve the process.

5. Plan the integration of the improvements into the existing process and update the process definition. If a formal process definition does not exist, it should be documented now.

6. Implement the improvements.

7. Perform the process as it is now defined.

8. Start over.

The Process Group - Industrial Engineering Group

The software engineering process group is the focal point for process improvement. Composed of line practitioners who have varied skills, the group is at the center of the collaborative effort of everyone in the organization who is involved with software engineering process improvement. Group size is usually equal to 1-3% of the development staff.

Following are ongoing activities of the process group:

• Obtains and maintains the support of all levels of management.

• Facilitates software process assessments.

• Works with line managers whose projects are affected by changes in software engineering practice, providing a broad perspective of the improvement effort and helping them set expectations.

• Maintains collaborative working relationships with software engineers, especially to obtain, plan for, and install new practices and technologies.

• Arranges for any training or continuing education related to process improvements.

• Tracks, monitors, and reports on the status of particular improvement efforts.

• Facilitates the creation and maintenance of process definitions, in collaboration with managers and engineering staff.

• Maintains a process database.

• Provides process consultation to development projects and management.

The process group is not part of product development but is staffed by practitioners. As a result, it has expertise in software engineering.

An improved process also allows easier acquisition and adoption of new technology because that technology can be acquired in direct support of defined processes. The process definition necessary to a disciplined software process is also prerequisite to reasoned analysis about what software tools and methods best support the goals and the creation of products and systems within the organization.

Improvement Activity Plan Implementation Steps

1. Overview

•Goals and objectives

•Related policies

•Needs analysis

2. Technology description

3. Enabling technology

description

4. Sources for technology

and related services

5. Purchases

6. Tailoring

7. Education and training

8. Technology selection

procedure

9. Evaluation procedures

10. Schedule and responsibilities

A process that is not well understood and articulated cannot be managed or improved. Just as manufacturers must select activities and tools for a particular product line, software organizations must also define and implement appropriate processes for each major development effort. Software, by its nature, is very easy to change. Because software practitioners are well-educated professionals who readily take independent action, a well articulated and understood process is essential to the orderly and predictable operation of a software development organization.

A well-defined and articulated description is prerequisite to process improvement. As Card and Berg [Card89] state, "periodic acquisition of improved methods and tools, by itself, does not ensure continual improvement. To be effective, technology must be integrated into an underlying process. That integration must be managed explicitly." Increases in quality and productivity, along with the successful use of technology, depend directly on a well articulated and well-understood process.

Card and Berg [Card89]: An industrial engineering approach to software development

D.N. Card, R.A. Berg, Journal of Systems and Software, Volume 10, Issue 3, October 1989, Pages 159-168 https://www.sciencedirect.com/science/article/abs/pii/0164121289900290

Describing the Existing Process

Building a process definition for an organization begins with describing what exists. Eventually, the definition of what should exist is also created, and replaces the initial description.

Recommended reading for those beginning the task of describing or defining software process:

[Humphrey89], Ch. 13, "Defining the Software Process."

Any of a number of different methods may be used; one of the simplest, ETVX [Radice85], is described below. Another straightforward method with tool support is described in [Kellner89]. Whatever the method, describing the existing process should result in documentation of how software products are actually developed and maintained in a given organization.

4.1.1. Documenting the Process: One Approach

One very accessible approach to writing a process description is presented in [Radice85]. Radice considers a process to be made up of software activities, which must be defined. A defined activity is one which has:

(1) a list of entry criteria that should be satisfied before beginning the tasks, (2) a set of task descriptions that indicate what is to be accomplished, (3) a validation procedure to verify the quality of the work items produced by the tasks, and (4) a checklist of exit criteria that should be satisfied before the activity is viewed as complete. (p. 83)

Radice calls this the E (Entry Criteria) T (Tasks) V (Validations) X (Exit Criteria) process architecture. Using ETVX to describe each phase of software activity should result in a consistent description of software development processes. Gaps—missing activities or a missing E, T, V, or X for an activity—that appear in the process description indicate where immediate process improvement may be needed. For example, the exit criteria for module design may not have been defined or may not match the entry criteria for the next activity. On the most abstract level, process definition is simply the determination of what stages and activities will be used by a given software organization.

[Radice85] lists the following phases for a commercial product:

• Requirements and planning

• Product-level design

• Component-level design

• Module-level design

• Code

• Unit test

• Functional verification test

• Product verification test

• System verification test

• Package and release

• Early support program

• General availability

E, T, V, and X must be defined for each activity.

Types of Measurement

In general, there are two types of measures: product and process. Product measures describe the characteristics of each system component being produced or maintained. Typical product measures are size, cost, complexity, quality (number of defects), and resources consumed to develop or maintain the component. Process measures describe aspects of the process used to produce or maintain those components, and are attributable to the human processes that create the product. Typical process measures are defect rates, repair rates, and production rates. Broader measures such as labor turnover, learning curve, communications overhead, and degree of overall adherence to the defined process also relate to process. In fact, a single measure may apply to both process and product, depending upon its usage and one’s point of view. Both types of measures may be collected on individual components or across groups of components; when product measures are aggregated, they often provide information about the process.

Defect Prevention

Several process information files are needed to support the defect prevention process.

• The defect file contains a record of each defect and information such as originator, description, resolution, disposition, and effort to repair.

• The action item file contains the action items that arise out of a causal analysis of the defects. These items are suggestions for improving the process so that future defects would not be manifest in the software product.

The process group should capture the history of the improvement efforts. The group should collect, catalog, and maintain reports and other artifacts related to attempts to improve the process. In many organizations, these products are lost when personnel change, and the improvement lessons must be learned all over again. Records should include: an indication of what went well and what did not go well; a description of how problems were handled; and suggestions for improving performance on similar tasks in the future. Capturing and reviewing lessons learned can be a part of the development life

cycle. The challenge is to make this information available to those who need it, past the life of a project.

Beginning Continuous Improvement

The process of introducing an improvement includes selecting a candidate technology, tailoring the technology and the training for its use, and using the technology on a pilot basis. Feedback should be collected and the full implementation plan is developed in light of the pilot experience.

One key long-term activity is the installation, over and over again, of new procedures and technology that support process improvement. These installations should begin with a pilot (prototype) installation—a controlled experiment. Pilots are essential when an organization has no experience with a technology, or when the technology will be applied in a new domain or with inexperienced staff. This is true even if the technology seems to be mature, as with software inspections, or even if the organization has excellent in-house resources, such as a technical working group with some experience in cost estimation. If a technology is new to an organization, it cannot be considered mature in that context. Appendix D presents an extended discussion of this phenomenon. This chapter describes some considerations for executing a pilot effort.

Process Consultation

The process group spends a significant proportion of its time coaching others and problem solving, based on the examples of best practices developed in other organizations. This consulting and broad awareness of the quality of particular efforts is indispensable for the success of the overall process improvement program.

As the focal point for process improvements, the process group spends a significant proportion of its resources meeting with those whom it serves. The group’s consulting activities include:

• Helping to set realistic expectations for improvement activity results.

• Tailoring process priorities, definitions, standards, training, and other process

materials.

• Suggesting methods for improving a specific process if a working group has not

already done so.

• Analyzing process measurement data.

• Facilitating improvement planning meetings and activities.

• Demonstrating improvement technology. (For example, serving as a moderator

for inspections until a project can develop its own inspection moderators.)

• Referring groups with similar interests to each other so that they can help each

other.

Process group members must have or develop good consulting skills; they need the ability

to listen and clarify, and to collaborate in problem solving with those who seek their help. If

process group members have access to training or expert advice (especially in the form of

"shadow" consulting) in this area, they should take advantage of it.

Process Group Membership

Process group members should collectively have experience from throughout the software life cycle.

Members of the process group are advocates for improvement. They are software professionals assigned, generally full time, to help the organization increase the maturity of its

software process. Members should be carefully selected with the goal of balancing the experience and educational background of the group as a whole.

Selecting the Process Group Leader

The process group leader must be an acknowledged technical leader,

with these characteristics:

• Extensive experience in or knowledge of the software process.

• Experience advocating improved software development processes, methods,

and tools—that is, improved quality and productivity.

• Experience in management or project leadership.

• Knowledge of the software development environment

Robert L. Grady and Deborah L. Caswell, Software Metrics: Establishing a Company-Wide Program, Prentice-Hall, 1987.

• H. J. Harrington, The Improvement Process: How America’s Leading Companies Improve Quality, McGraw-Hill, 1987.

• Watts Humphrey, Managing the Software Process, Addison-Wesley, 1989.

• Rosabeth Moss Kanter, The Change Masters: Innovation for Productivity in the

American Corporation, Simon and Schuster, 1983.

• Marvin Weisbord, Productive Workplaces: Organizing and Managing for Dignity, Meaning, and Community, Jossey-Bass, 1987.

Process Management Approach - Card

The process management approach includes three essential activities: process definition,

process control, and process improvement. An undefined process cannot be controlled. An

uncontrolled process cannot be improved consistently. Because improvement means

change, attempting to improve an unstable process often leads to further instability. Figure

B-3 shows how these elements are connected by the common threads of performance data

and corrective action.

The process definition activity provides a prescription for performing work. Measuring the

initial process performance establishes a baseline against which subsequent performance

can be compared. The process control activity is concerned with identifying and correcting

special causes of poor quality, to keep the process performing as intended. That is, it seeks

to maintain key quality parameters within pre-defined control limits. The process improvement activity seeks to identify and rectify common causes of poor quality by making basic

changes in the underlying process.

Software Design Improvement

Until recently, hardware designers left many important product quality considerations to be handled by manufacturing engineers. Because software does not go through a corresponding manufacturing phase, the software engineer must deal with those producibility concerns directly [Card90]. That is, the software system must be designed to be easy to implement and maintain. This is in addition to satisfying the customer’s functional requirements.

Process Design Improvement

Once the process has been defined and controlled, management can turn its attention to improving the underlying process. This can be done by simplifying the process and by inserting appropriate new technology. [Turner78] suggests five questions that should be asked about each process element:

1. Is this activity necessary or can it be eliminated?

2. Can this activity be combined with another or others?

3. Is this the proper sequence of activities?

4. Can this activity be improved?

5. Is the proper person doing this activity?

Initial process improvement efforts should be concentrated at leverage points: those activities that require the most effort and produce the most problems (see, for example, Pareto

analysis in [Grady87]). Improvement actions should be evaluated in situ by studying their

effect on actual process performance.

An Introduction to Technological Change

This topic addresses the fundamentals of implementing technological change in software organizations. The process group can greatly improve its odds for success if it understands and acquires some skills in managing the technological and organizational change attendant to process improvement.

It is an introduction to the basic knowledge that is prerequisite to effective and predictable technological change in the context of software engineering.

Technology Mapping

Mapping is a simple but powerful way to determine whether a technology is likely to succeed in an organization. The mapping process essentially involves: 1) examining the technology to be implemented for aspects of context that have been built into it and 2) comparing ("mapping") the results of this examination to the results of the organizational context analysis. If there is minimal overlap, the risk is high that implementing the technology will be complex and unpredictable and will require more resources, especially in pilot efforts. If there is a significant overlap, the chances of success are greater. The comparison should take into account the fact that some aspects of context may carry more weight than others. Context analysis is a useful step to take just prior to beginning a search for a technology. It

can help narrow the candidate field by noting major aspects of context, such as application domain, technical compatibility, and budget, which would seriously constrain possible matches. Once the list is pared down to a half dozen or so technologies, mapping is a major step in the final selection process.

Mapping is necessary because all software engineering technologies are based on a set of assumptions. Certain application domains or classes of application domains—for example, real-time embedded, MIS, scientific—may be assumed when a technology is developed. Certain types of users—for example, ordinary citizen, engineer, scientist, bank teller—may also be assumed. Certain technical requirements—machine type and size, operating system, network type—are usually stated. The easiest technologies to eliminate from a candidate list are those with the least overlap with the organization’s context; as the list shrinks, the mapping process requires more detective work and attention to subtleties such as software engineering terminology, life-cycle phase coverage and definition, and style of work in groups. Even a technology that is well targeted to a particular market niche cannot take all variations of an organization in that niche into account. The best test of a new technology is a series of pilot uses, thoroughly evaluated.

When an organization is dealing with newer and softer technologies, mapping becomes critical. If transfer mechanisms are people-based, they are heavily influenced by frame of reference and by the skills of the people who must translate between frames of reference in the

transfer process.

Boundary Spanners

Boundary spanners are people who are comfortable in multiple frames of reference; they

can work effectively as members of a business organization, with management and engineers, and on professional society committees. Examining the process of communicating in

different languages provides a useful analogy to the services boundary spanners perform.

Because the mapping process is similar to translation between languages, it is best done by

boundary sponsors who are the equivalent of multi-lingual. If these people have extensive

experience in translation, they will know when to proceed cautiously; they will understand

the need, for example, to define carefully terms that most people will assume are well understood.

Boundary spanners are common outside organizations in the technology advocate roles described in Figure D-3. These boundary spanners play an important role in getting new products from research into the marketplace, in articulating the new technology in universities and professional communities, in marketing the technology once it becomes a product, and in supporting new users.

In their role, boundary spanners typically serve on technical working groups or as members of the process group "porting" technology experience from one organizational group to another; they

connect the inside of the organization to the outside world. They track technology directly

[Carlyle88]; they may also track it by serving on outside working groups such as the IEEE

Computer Society standards committees. Having largely internalized context analysis

results for their own organization, they effectively scan for and select candidate

20 technologies. People who perform this role best have had experience in a number of

contexts; criteria for boundary spanners are much the same as for members of process

group

See search results of SEI software process improvement

Software Development Processes

https://opendsa-server.cs.vt.edu/ODSA/StandaloneModules/20221129151902/html/IntroProcess.html

Software Engineering

The Top 10 Blog Posts of 2022 - CMU Software Engineering Institute

https://insights.sei.cmu.edu/blog/the-top-10-blog-posts-of-2022/