19 research outputs found

    An examination of the Cosmos model for use in Department of Defense software development management

    Get PDF
    Currently, the proper management of DoD software development projects is lacking. This is due, in large pan, to the use of models of the software development process which neglect management aspects of the process. The Commonsense Management Model, "Cosmos", however, presents a complete view of this process by treating both its production and management facets. This model calls for a software development project manager to make three essential trade-offs. To make these essential trade-offs, a manager must consider the six principles of dealing with the dynamic complexity found in software development. Methods for dealing with these six principles can be found if the manager takes a three dimensional view of the software development process. Due to the conceptual nature of the Cosmos model, the model must first be grounded with "real world" examples before it can be effectively applied within DoD. To accomplish this, the Patriot software development management method is used to relate the concepts to specific examples for DoD use. By relating the concepts to examples, eight types of tools were found that could be used by future DoD software development projects to gain the benefit of a holistic view of the software development process presented by the Cosmos model. Specific recommendations are contained for inclusion in DoD policy with respect to software development management.http://archive.org/details/anexaminationofc1094531539NANAU.S. Army (USA) autho

    Building software factories in the aerospace industry

    Get PDF
    Thesis (M.S.)--Massachusetts Institute of Technology, Dept. of Aeronautics and Astronautics, 1997.Includes bibliographical references (p. 107-110).by Jose K. Menendez.M.S

    Implementing Software Safety in the NASA Environment

    Get PDF
    Until recently, NASA did not consider allowing computers total control of flight systems. Human operators, via hardware, have constituted the ultimate safety control. In an attempt to reduce costs, NASA has come to rely more and more heavily on computers and software to control space missions. (For example. software is now planned to control most of the operational functions of the International Space Station.) Thus the need for systematic software safety programs has become crucial for mission success. Concurrent engineering principles dictate that safety should be designed into software up front, not tested into the software after the fact. 'Cost of Quality' studies have statistics and metrics to prove the value of building quality and safety into the development cycle. Unfortunately, most software engineers are not familiar with designing for safety, and most safety engineers are not software experts. Software written to specifications which have not been safety analyzed is a major source of computer related accidents. Safer software is achieved step by step throughout the system and software life cycle. It is a process that includes requirements definition, hazard analyses, formal software inspections, safety analyses, testing, and maintenance. The greatest emphasis is placed on clearly and completely defining system and software requirements, including safety and reliability requirements. Unfortunately, development and review of requirements are the weakest link in the process. While some of the more academic methods, e.g. mathematical models, may help bring about safer software, this paper proposes the use of currently approved software methodologies, and sound software and assurance practices to show how, to a large degree, safety can be designed into software from the start. NASA's approach today is to first conduct a preliminary system hazard analysis (PHA) during the concept and planning phase of a project. This determines the overall hazard potential of the system to be built. Shortly thereafter, as the system requirements are being defined, the second iteration of hazard analyses takes place, the systems hazard analysis (SHA). During the systems requirements phase, decisions are made as to what functions of the system will be the responsibility of software. This is the most critical time to affect the safety of the software. From this point, software safety analyses as well as software engineering practices are the main focus for assuring safe software. While many of the steps proposed in this paper seem like just sound engineering practices, they are the best technical and most cost effective means to assure safe software within a safe system

    AdaNET research project

    Get PDF
    The components necessary for the success of the commercialization of an Ada Technology Transition Network are reported in detail. The organizational plan presents the planned structure for services development and technical transition of AdaNET services to potential user communities. The Business Plan is the operational plan for the AdaNET service as a commercial venture. The Technical Plan is the plan from which the AdaNET can be designed including detailed requirements analysis. Also contained is an analysis of user fees and charges, and a proposed user fee schedule

    Volume II Acquisition Research Creating Synergy for Informed Change, Thursday 19th Annual Acquisition Research Proceedings

    Get PDF
    ProceedingsApproved for public release; distribution is unlimited
    corecore