A Recommended Practice for Software Reliability - Written by Dr. Norman F. Schneidewind for Crosstalk Aug 2004, vol. 17, no.8, this article reports on advances and revisions to the "American Institute of Aeronautics and Astronautics Recommended Practice for Software Reliability" as they apply to software reliability engineering. The revision addresses reliability prediction through all phases of the software life cycle, since identifying errors early reduces the cost of error correction. Furthermore, there have been advances in modeling and predicting the reliability of networks and distributed systems that are included in the revision.
ABSRACT: The AN/BQQ-10(V) Acoustic Rapid Commercial off-the-shelf (COTS) Insertion (A-RCI) submarine sonar system has been repeatedly cited as one of the Department of Defense's premier examples of using COTS technology to provide significantly improved system performance at far lower costs than previously possible. The ability to rapidly and inexpensively upgrade a ship's sonar hardware suite to provide continually increasing sonar performance has helped to restore United States submarine superiority over all potential adversaries. As part of this revolution in RCI, the program has identified several lessons on using COTS hardware and software that can help other programs making the same leap into the COTS world.
Boeing SEI CMM Level 5: For the Right Reasons - CrossTalk (August 1997) - In July 1996, the Defense and Space Group (D&SG), Boeing Space Transportation Systems (STS), achieved a Level 5 rating using the Software Engineering Institute (SEI) Capability Maturity Model (CMM). This significant achievement illustrates how customer interest has shifted from the technology focus of the 1960s and 1970s to the cost and schedule focus of the 1980s, and finally to a process focus in the 1990s. Because the STS made process improvement a high priority, it demonstrated a high level of maturity in a formal assessment. This article was written by George Yamamura and Gary B. Wigle. - CrossTalk is a publication of the DoD Software Technology Support Center (STSC).
Crosstalk: Risk Management - This entire Crosstalk Journal is devoted to Risk Management. Articles Include:
Understanding Risk Management
Risk Management for Systems of Systems
Inherent Risks in Object-Oriented Development
Software Risk Management From a System Perspective
Managing Acquisition Risk by Applying Proven Best Practices
Microsoft's IT Organization Uses PSP/TSP to Achieve Engineering Excellence
Experiences With the TSP Technology Insertion
Personal Earned Value:Why Projects Using the Team Software Process Consistently Meet Schedule Commitments
A TSP Software Maintenance Life Cycle
Defining Software Process Improvement - CrossTalk (February 1996) - by Dr. David J. Szymanski and Capt. Thomas D. Neff. The authors propose a working definition of software process improvement pointing to its importance to several persons including those involved in software engineering process groups (SEPGs). The definition is based on denotations of process and software process advanced by the Institute of Electrical and Electronics Engineers (IEEE) and the Software Engineering Institute (SEI), and a definition of process improvement based on a value-added approach. The definition of software process improvement (SPI) is offered for consideration.- CrossTalk is a publication of the DoD Software Technology Support Center (STSC).
Effects of Process Maturity on Development Effort - Written by Bradford K. Clark, USC. ABSTRACT: f you are having difficulty in convincing your project manager, organization, or customer concerning the power and value of continuous process improvement, digest this article. The author's study, using a 112-project sample, concluded that a change in one level of process maturity using the CMM framework resulted in a reduction of development effort of 10-32 percent! The author provides references to a half dozen other studies concerning the benefits of process improvement.
Experience of Applying Statistical Control Techniques to the Function Test Phase of a Large Telecommunications System - Authors: Bertolino, A. Marchetti, E. Mirandola, R. Lombardi, G. Peciola, E. - This paper appears in: Software, IEE Proceedings, Aug 2002; Vol: 149, Issue: 4, On page(s): 93- 101, ISSN: 1462-5970. Abstract: The software test process of a large telecommunications system is presented. The feasibility of introducing statistical process control techniques to one crucial software test phase, namely the function test is explored
Inherent Risks in Object-Oriented Development - Writtne by Dr. Peter Hantos, The Aerospace Corp., this article discusses Bertrand Meyer's classic OO technology concepts are mapped into Barry Boehm's Top 10 methodology-neutral software risks to illustrate potential areas of exposure. Recent developments in OO technology, such as Java, Use Cases, or the Unified Modeling Language fit well into this framework and are included as examples. The systematic approach introduced will allow project managers to better understand the cost/benefit aspects of applying OO technology, and to align their project management strategies more successfully with the organization's business goals.
Managing Acquisition Risk by Applying Proven Best Practices - This Crosstalk Journal article is written by Mike Evans, American Systems Corp.; Corinne Segura, American Systems Corp., and Frank Doherty, U.S. Navy. - As a result of their analysis, the authors conclude that successful acquisition risk management is based on: (1) providing educated leadership and a supportive organizational culture, (2) adapting proven best practices in response to specific circumstances, and (3) emphasizing the program environment rather than process maturity.
Mission Critical and Time Sensitive Data Require Data Integration High Availability - This Forrester Report by Philip Russom and Colin Teubner looks at data integration best practices. The reports discusses how historically data integration processes were executed in a 24 hour or longer cycle, in support of business practices that may tolerate incomplete or late data. Now mission-critical applications and time-sensitive business processes depend on real-time data. This link downloads a PDF file.
Risk Management (Is Not) for Dummies - Written by Lt. Col. Steven R. Glazewski, Air Force Institute of Technology, for Crosstalk, vol.18, no.2, Feb 2005. Software program managers crave a silver bullet in the form of a comprehensive checklist of things to watch so the program does not suffer from bad surprises. Highlighted in this article are some prime examples from almost 15 years' experience acquiring software in Department of Defense programs, from identifying broad areas where software risks tend to hide to describing an eight-step risk management process. While there are no silver bullets to be found, there are a few golden nuggets if you make the focused effort to look!
Risk Management for Systems of Systems - Written by Dr. Edmund H. Conrow, Risk-Services.Com for Crosstalk, vol.18, no.2, Feb 2005. Integrating diverse sets of systems and hardware, all at different maturity levels, presents unusual challenges and risks. This author examines methods for better implementing risk management on such programs.
Software Quality at Top Speed - First published in Software Development, August 1996, this article is now availabel on-line at author Steve McConnell's website. This article discusses how Products with the lowest defect counts can also have the shortest schedules. A Project Manager does not have to sacrifice quality for speed.
Taking a Page from ITIL's Best Practices - A 44-volume set of guidelines published by the British government 12 years ago may forever change the way IT is managed. Today, American IT organizations are at a crossroads, facing challenges from offshore outsourcers and from internal financial pressures. In response, they’re stealing a page from their global competitors’ playbooks -- a process framework developed in the United Kingdom called ITIL, or IT Infrastructure Library. Written by David L. Margulius for Infoworld, September 24, 2004, issue 39.
Tantara's Software Process Improvement (SPI) and Software Quality Assurance (SQA) Hotlist - Tantara provides a collection of Software Process Improvement (SPI) and software quality resources. The site includes links to SPI resources, focus groups, SQA resources, SPINs, online newsletters and e-journals, magazines,associations, seminal documents, discussion groups, and governing agents for standards/models.
TSP Can Be the Building Blocks for CMMI (CrossTalk 2005) - Written by Alan S. Koch, ASK Process Inc., for CrossTalk vol. 18, no. 3, ABSTRACT: Your organization has a mandate to achieve Capability Maturity Model® Integration (CMMI®) Level 3. Why would you even consider adding the Team Software Process SM (TSPSM) to your plate when it is already overflowing? In this article, the author discusses how TSP— far from adding work to a CMMI initiative — can potentially reduce the time and effort that will be required to achieve your goals. Simultaneously, TSP will engage your engineers in disciplined processes, giving them an appreciation for good processes along with the desire to adopt improved processes in every area of the organization.
What the Agile Toolbox Contains - Written by Dr. Alistair Cockburn, Humans and Technology for Crosstalk, Nov 2004, Vol. 17, No. 11.
ABSRACT: The agile development community is noted for scorning Computer-Aided Software Engineering modeling and Gantt project scheduling tools (among others), but what has it replaced them with? Conducting a survey of agile teams for tools they say help produce better software quicker, this author found they used a cross-disciplinary set of mental, social, environmental, mechanical, and process tools, in addition to a carefully selected set of software-based tools. This list of tools can help your organization prepare for the tools — human resource, facilities, software, and non-software — that will be requested and used by the team starting to adopt the agile approach.
ABSRACT: The transition from defect detection and removal activities to defect prevention activities may not be as smooth as you would like. You may start asking, "Where do I start?" Or, you may have the feeling that you are not getting much benefit from your defect prevention activities. You may also find yourself faced with a need to explore, evaluate, and adopt new metrics. This article discusses some quantitative (non-statistical process control [SPC]) methods for looking at your data; I will show the results of applying SPC to the same information, and provide a few "what next" options. The intent of this article is to provide process improvement team members, program managers, and supervisors with ideas for defect prevention metrics to help them identify and analyze problem areas and to help them prioritize and plan their defect prevention activities. I have chosen to avoid discussing complex mathematical algorithms in favor of providing charts to aid the reader in participating in brainstorming activities to identify metrics they will find useful for their situation.
DACS Gold Practice Initiative
