|
|
|
||||||||
The Use of the Best Industry Practices for
Defense and Commercial Software
Seminar Abstract
Don O’Neill
Independent Consultant
Opening
Accompany Don O’Neill on a two-day tour of the use of Best Industry Practices for defense and commercial software development. Don’s breadth of background and his unique insights on all aspects of software promise to change the way you look at software and its role, whether your view be the project, the enterprise, the industry, or the nation. Don will help you ”listen to the voice from the factory floor” as well as bring you views from the senate hearings on software competitiveness. His engaging personality and approachability assure that each participant will receive full satisfaction from the session.
Threats and Challenges
There are threats and challenges to information technology. These impact the trustworthiness of our defense systems and the global competitiveness of our commercial software operations. Well chosen directions and effective solutions are needed at every level to counter these threats. While the nation’s leaders often view software only as shrink wrapped commodity software for personal computers, the backbone software systems that comprise our national data systems and sustain government and commercial operations are large scale, complex custom software applications. The national and enterprise software capability to evolve and sustain critical software operations is threatened by software personnel shortages, a leadership shortfall in industry capability maturity models, research funding reductions, and concerns about the trustworthiness of software systems. The Perry Directive to adopt commercial practices to stretch defense budgets remains a compliance challenge. The Perry Directive to adopt commercial practices to stretch defense budgets remains a compliance challenge, and there are side effects too.
Directions and Solutions
What is software, and what is the state of the practice? What is needed is a blueprint for success that moves beyond commitment to specific changes and calls for raising the ability to improve to a core competence. The blueprint objectives are designed to achieve this goal by knowing what the customer needs most, aligning the best capability of the organization to provide it, understanding current practice, measuring its critical aspects, selecting the most promising changes, planning for lasting improvement. A set of models is used to guide an organization towards success in several dimensions including shared vision, software engineering process maturity, software project management, software development architecture, operations support, and domain specific architecture.
Process and Product
Improving productivity and quality, shortening schedules, reducing costs, and achieving higher customer satisfaction are best achieved indirectly by establishing an effective infrastructure of software process improvement. The sluggish improvement in software process maturity revealed in the Software Engineering Institute’s software process assessment history reflects the difficulty experienced by organizations striving to achieve higher maturity levels. While much is made of the need for senior management sponsorship, very real problems lie with the change agents and the target projects. Change agents often lack the readiness to roll out the the key process areas for the software process maturity level being sought. Target projects may lack the sustained focus needed to adopt the many management and engineering practices required. The result can be an organization anchored at the present level. The seminar provides a breakout strategy that overcomes these obstacles to software process improvement. First, this program provides a mechanism for assessing the readiness for rolling out a key process area. Second, it defines a Project Suite of key processes and a method for assessing the adoption status of each project for each. Third, it provides the means to oversee the organization software process activities. The use of software product lines to house the software value points critical to the nation’s data systems promise needed improvements in the evolution and maintenance of legacy software systems.
Risk and Metrics
Program managers are being asked to deliver systems with increasingly greater software content and on shorter schedules. Software engineers are being asked to produce defect free software products that fully conform to requirements and achieve a high degree of user satisfaction. Adopting a Software Risk Management Program is an action that every program manager can take to more effectively manage and field a successful software intensive system. These systems are in increasing demand but present higher levels of risk than comparable engineering projects in other fields. In any field, risk is the uncertainty of an event and the prospect of loss if it should occur. In software engineering, the complexity of large systems composed of hundreds or even thousands of interacting components increases the uncertainty of doing the right job, doing it within cost and schedule boundaries, and doing it in the right way for ease of operation and maintenance. Consequently, a powerful risk management mechanism is needed to identify risks early, to confront them and assign ownership, and to resolve or accept them. This risk management process provides a discipline for accepting the possibility that future events may cause adverse effects.
Success on a large scale software development projects depends on complex factors which have nonlinear outcomes. Measuring and understanding these factors are complex because their behavior is not linear. What is true on a small project does not predictably scale up on a large project. Some of the complex factors with nonlinear outcomes include: size, time, effort, changes, defects, and computer resources.
Management Track
It is essential that program managers and software engineers forge a shared vision and achieve a mutual understanding of the program goals to be met, the prescriptions needed to carry them out, and the common problems encountered in developing complex software systems.
The use of the best industry practices for managing commitments and performing with predictability are reviewed. These practices center around project planning and tracking and oversight.
This seminar helps to more realistically align the expectation of program managers with the needs of industry quality systems and with the capability, practice, and performance of the software engineering organization. Quality systems demand much while industry software practice struggles to reach maturity. When a program manager knows the customer needs and what the current capability and practice are on the project, the predictability of program performance is greatly improved. To the extent that customer needs and project capability are not understood, the risk in achieving cost, schedule, and customer satisfaction goals is increased. The complex factors associated with software and their nonlinear outcomes are explored.
Software Change Management Process Integration is set forth as a ten step program of process activities, intergroup coordination, tool usage, and measurement. The artifacts resulting from this Process Integration include policies, procedures, tools, measurements and metrics, and training. Ten Key Process Areas are applied in various steps. These operations are tightly coupled in certain business, management, and engineering processes and the personnel roles for intergroup interaction.
The realities associated with the critical shortages in software personnel skills, the impact on immigration policy, and the practice of outsourcing are explored comprehensively. Each participant will acquire a deeper understanding of these issues and the unique perspectives provided.
Engineering Track
Forging a shared vision among stakeholders depends on requirements determination and management practices. These industry practices and their intellectual foundations remain inadequate. Consequently large scale software development is inherently research in nature.
To be more precise, the state of the art in computer science and software engineering has led state of the practice in those areas where small scale experimentation applies, but the state of the art has trailed the state of the practice on large scale applications leaving the experimentation to industry. In particular, universities have tended to specialize their research on small scale problems where one factor at a time is altered to study its effects. On the other hand, industry has been faced with increasingly large scale complex real time software applications that stress the advancements of computer science and software engineering. Consequently software practice on the factory floor is left to employ a process of experimentation and discovery that is essentially research in nature even as software is becoming an increasingly critical element in the competitiveness of business enterprises in every sector. The research community is not generating results that are in tune with industry. As a result, industry practitioners resort to experimentation as the substitute for profound knowledge in building software systems.
The seminar explores the software product engineering practices that need to be adopted to produce trustworthy software systems in the absence of adequate information at each stage of the life cycle.
The seminar explores the software product engineering practices that need to be adopted to produce trustworthy software systems in the absence of adequate information at each stage of the life cycle. The interaction among function, form, and fit in the software product and the risks in execution traces,path lengths, user response times, and integration effects both horizontal and vertical are explored.
Quality
Software inspections provide an immediate and concrete step that every organization can take to improve its process maturity. They provide a powerful mechanism for improving software product quality by detecting and correcting defects early and preventing their reoccurrence. Software inspections accomplish this by conducting a close and strict examination of software plans, requirements, specifications, designs, code, and test procedures. They provide a vantage point not occupied by designers, programmers, and testers. This vantage point is the foundation for fact-based software management and the initiation of defect prevention practice. Organizations utilizing software inspections as the exit criteria for each activity in the software product engineering life cycle experience defect detection rates of 80-90% and defect leakage of 10-20%.The application of an industrial strength software inspections process reduces development costs, shortens delivery schedules, and promotes higher reliability of operational software products in the field. The seminar overviews the structured review process, standard of excellence product checklists, defined roles of individuals, and forms and reports used.
In 1992 the DOD Software Technology Strategy set the objective to reduce software problem rates by a factor of ten by the year 2000. The National Software Quality Experiment is being conducted to benchmark the state of software product quality and to measure progress towards the national objective.The experiment is a mechanism for obtaining core samples of software product quality from the nation’s software inspections labs. This national database provides the means to benchmark and measure progress towards the national software quality objective and contains data from 1992 through 1997. Thousands of participants from dozens of organizations are populating the experiment database with thousands of defects of all types along with pertinent information needed to pinpoint their root causes. These measurements taken in the lab and the derived metrics are organized along several dimensions including year, software process maturity level, organization type, product type, programming language, global region, and industry type. The seminar participant will obtain an understanding of what to expect from software inspections in terms of upper and lower limits for key metrics.
The Year 2000 Problem promises to impact information systems of all kinds. With no silver bullet available, the responsible manager must take a variety of actions to detect and correct this problem. A powerful mechanism for detecting and correcting the Year 2000 Problem is the practice of Software Inspections. By explicitly setting the standard of excellence for software products to operate correctly before, during, and after the Year 2000 and by conducting Software Inspections on those software products thought to be date sensitive, the responsible manager is taking an important and prudent step to meet the challenge. A Year 2000 Product Checklist is discussed.
The organization that is to lead the industry in the production of trustworthy software systems is the organization that is capable of predicting and controlling the critical defects, faults, and failures in the software systems it builds. Bridging the gap of prediction practice among defects, faults, and failures remains an unsolved problem. Defects are detected early using software inspections as exit criteria for activities in the software life cycle. Faults are detected later through exercise during integration and system test. Failures occur even later during system operation. Yet there is no accepted method for using defect data available early to predict faults and failures that occur later. Specifically:
- There is insufficient defect, fault, and failure data available from the nation’s factory floor.
- There is insufficient process, method, and tooling to combine defect data obtained through software inspections practice, software fault data obtained through software product test and use, and software failure data obtained through software system operation.
Maintenance
Expert software maintenance practice is essential to sustaining trustworthy software systems and global software competitiveness. The increasing dependency on software and the shortage of software skills combine to demand an increase in span of responsibility within the software maintenance operation. Span of responsibility determines the cost of software ownership. It is the size of the code base depended on by the enterprise divided by the number of people who support it. Span of responsibility can be increased by improving product traceability and semantic correspondence among life cycle artifacts.
Strategic software maintenance manages span of responsibility by distinguishing software products along the lines of value add and commodity. Value add components are retained in house while commodity software may be purchased off the shelf or outsourced either domestic or offshore. The leading indicators of globally competitive software maintenance and the measured results of defect type frequencies are used to suggest improvements in software maintenance tactics.
@Copyright Don O’Neill,1998 # Best Industry Practices