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
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/
Software Engineering - Course Notes and Slides
https://www2.cs.siu.edu/~mengxia/Courses%20PPT/435/435ppt.htmhttps://www.mheducation.com/highered/product/software-engineering-practitioner-s-approach-pressman-maxim/M9780078022128.html
Preview - Pressman Book
https://books.google.co.in/books?id=bL7QZHtWvaUC&printsec=frontcover#v=onepage&q&f=false
Chapter 1 Introduction to Software Engineering
Playlist of 33 videos
https://www.youtube.com/watch?v=GMOogBp3AAE&list=PL9P1J9q3_9fNfUBVYhFeoieHRnJg_vXxx&index=1
__________________
__________________
SWE Body of Knowledge
https://sceweb.sce.uhcl.edu/helm/SWEBOK_IEEE/data/swebok_chapter_01.pdf
https://sceweb.sce.uhcl.edu/helm/SWEBOK_IEEE/data/swebok_chapter_02.pdf
Software Quality Engineering - https://www.sealights.io/software-quality/software-quality-engineering-a-beginners-handbook/
Ud. 30.3.2023
Pub. 29.7.2020
