Cleanroom software development

The 'cleanroom' software development process is a technical and organizational approach to developing software with certifiable reliability. Key ideas behind the process are well structured software specifications, randomized testing methods and the introduction of statistical controls; but the main point is to deny entry for defects during the development of software. This latter point suggests the use of the term 'cleanroom' in analogy to the defect prevention controls used in the manufacturing of high technology hardware. In the 'cleanroom', the entire software development process is embedded within a formal statistical design, in contrast to executing selected tests and appealing to the randomness of operational settings for drawing statistical inferences. Instead, random testing is introduced as a part of the statistical design itself so that when development and testing are completed, statistical inferences are made about the operation of the system

Software development: Stratosphere modeling

A more comprehensive model for stratospheric chemistry and transport theory was developed for the purpose of aiding predictions of changes in the stratospheric ozone content as a consequence of natural and anthropogenic processes. This new and more advanced stratospheric model is time dependent and the dependent variables are zonal means of the relevant meteorological quantities which are functions of latitude and height. The model was constructed by the best mathematical approach on a large IBM S360 in American National Standard FORTRAN. It will be both a scientific tool and an assessment device used to evaluate other models. The interactions of dynamics, photochemistry and radiation in the stratosphere can be governed by a set of fundamental dynamical equations

Teaching Software Development to Non-Software Engineering Students

This paper argues that although the object-oriented programming (OOP) paradigm is appropriate for students taking programming modules on Higher Education (HE) software engineering course, this paradigm is not as relevant for students from other courses who study programming modules. It is also asserts that adopting another paradigm when teaching programming to non-software engineering students need not prevent the encouragement of good software engineering practices The paper discusses the software development model, procedures, techniques and programming language that the author requires non-software engineering students to employ when developing their software. This discussion also includes consideration of implementation issues in an educational context. The paper concludes that his alternative approach has been successfully implemented, that it requires the student to adopt a rigorous approach to development and that it encourages best software engineering practices. The conclusions also note that delivering this alternative offers the opportunity to include good educational practice, such as role-play

Automated software development workstation

Engineering software development was automated using an expert system (rule-based) approach. The use of this technology offers benefits not available from current software development and maintenance methodologies. A workstation was built with a library or program data base with methods for browsing the designs stored; a system for graphical specification of designs including a capability for hierarchical refinement and definition in a graphical design system; and an automated code generation capability in FORTRAN. The workstation was then used in a demonstration with examples from an attitude control subsystem design for the space station. Documentation and recommendations are presented

Engineering software development with HyperCard

The successful and unsuccessful techniques used in the development of software using HyperCard are described. The viability of the HyperCard for engineering is evaluated and the future use of HyperCard by this particular group of developers is discussed

Enabling Multi-Stakeholder Cooperative Modelling in Automotive Software Development and Implications for Model Driven Software Development

One of the motivations for a model driven approach to software development is to increase the involvement for a range of stakeholders in the requirements phases. This inevitably leads to a greater diversity of roles being involved in the production of models, and one of the issues with such diversity is that of providing models which are both accessible and appropriate for the phenomena being modelled. Indeed, such accessibility issues are a clear focus of this workshop. However, a related issue when producing models across multiple parties,often at dierent sites, or even dierent organisations is the management of such model artefacts. In particular, different parties may wish to experiment with model choices. For example, this idea of prototypingprocesses by experimenting with variants of models is one which has been used for many years by business process modellers, in order to highlight the impact of change, and thus improve alignment of process and supporting software specications. The problem often occurs when such variants needed to be merged, for example, to be used within a shared repository. This papers reports upon experiences and ndings of this merging problem as evaluated at Bosch Automotive. At Bosch we have dierent sites where modellers will make changes to shared models, and these models will subsequently require merging into a common repository. Currently, this work has concentrated on one type of diagram, the class diagram. However, it seems clear that the issue of how best to merge models where collaborative multi-party working takes places is one which has a significant potential impact upon the entire model driven process, and, given the diversity of stakeholders, could be particularly problematic for the requirements phase. In fact, class diagrams can also be used for information or data models created in the system analysis step. Hence, we believe that the lessons learned from this work will be valuable in tackling the realities of a commercially viable model driven process