Software developers/designers functions

Today s automobiles incorporate an increasing number of functions that are realized by software. Developers design, implement and integrate the software-based functions using, amongst others, model-driven development. 

Is a written functional specification or design document a mandatory prerequisite for software development ... 

Application related configuration and parameters are to be specified which, together with application specific programming and when integrated, provides the full functionality required by the FDS. Software development tools with the potential to change software should not be installed on the production system. The Software Design shonld include the following ... 

Prototyping FDA (1995) An approach to accelerate the software development process by facilitating the identification of required functionality during analysis and design phases. A limitation of this technique is the identification of system and software problems and hazards. [Adapted.]... 

FIGURE 8.1 The V-Model covers the entire process for software development from the business requirements to the implementation of the software in its intended operational environment. The process starts with a statement of work that defines the effort reqnired for the design, engineering, development, production, and test, and prototyping of a software system. The software documentation process covers user requirements, functional, and technical aspects of the software development. After development, different test phases are performed to verify installation, operation, and performance of the software. A business acceptance from the customer finally leads to implementation of the software. 

Although the motivations for SAR research in academia and industry may differ, the techniques are largely the same. This is because the usual route for software development in the field is from academia to industry, with (increasingly) a commercial software vendor as a middleman. Over the years, CAMD methods have become much more sophisticated. At the same time, and largely because of commercial software, they can be much more easily and routinely applied. As a result, many published industrial applications have b me less orient towards the empirical prediction of activity, and more directed towards the study of receptor function and mechanism of action. This trend is certain to continue, since knowing the shape of a receptor or the mechanism of action of a particular compound makes it much easier to design new ones. 

The primary inputs (Figure 2.13) to the Functional Spedflcation are the records established in the RAD phase, structural design for bespoke software development and standard system documentation. The Fimctional Specification should clearly demonstrate that all requirements stated in the URS have been accommodated. Where there is a nonconformance with the URS, it should be documented and formally approved by the project sponsor. 

Functional Design Specification. The supplier should be able to demonstrate that an FDS is produced in response to the pharmaceutical organisation s URS. Typically, the FDS will be a standard document for the core product application, with deviations from the standard offering documented in an addendum or separate project-based document. Deviations usually warrant some degree of tailored software development and should, therefore, be of prime consideration during the validation exercise. Table 7.4 provides the typical content of the FDS. 

An iterative, user-centred approach has advantages in many areas of product development but perhaps none more so than in user interface design. Manufacturers should actively plan to work and re-work a user interface many times in the course of a project. Of course the earlier this process begins, the more opportunities there are to tweak the design without compromising project timescales. In the context of a time-bound software development project it may not be realistic to evaluate every screen and function in a system so it makes sense to prioritise those which are used frequently and/or are critical for safety. Even after go-live it is invaluable to solicit feedback from users once they have had the time to use the system in anger and address areas of concern. 

The CLARISSE System and Software Development Environment (CLARISSE SSDE) are available for the specification, design, coding, and validation of l C systems. It runs on a UNIX based workstation (typically a Sun SPARC station under OS Solaris). ITie CLARISSE SSDE provides the followings functions ... 

ABSTRACT The draft document of the NATO allied ordnance publication (AOP) 52 gives guidance on software safety design and assessment of ammunition-related computing systems. The content of the draft is reviewed and compared with the lEC 61508 standard for functional safety of electrical/electronic/programmable electronic (E/E/PE) systems. We discuss the overall development model, the safety-lifecycle model and proposed techniques and measures. We also investigate whether the functional safety concept of lEC 61508 is incorporated in the document. 

Safety standards acknowledge the economic need to employ previously developed systems, functions and components [12] [13] [14] [15]. In civil aerospace for example, systems may be reused across different aircraft types, without the need for additional assessment, provided that evidence of similar design, installation, application and operation can be produced [15]. Otherwise, the safety assessment process should be performed to examine the impact of the reusable systems on the aircraft functions. Also in civil aerospace, particularly for airborne software, the American Federal Aviation Administration (FAA) created an Advisory Circular (AC), offering means to satisfy the requirements of the aerospace software guidance DO-178B regarding the use of reusable software components [16]. 

SHOLIS (Chapman, 2000) is a software-based system that advises ship s crew on the safety of helicopter operations under various scenarios. The software was developed in accordance with DEF STAN 00-55 (Issue 2). A software hazard analysis was performed and on this basis certain parts of the software were designated as safety-critical. Safety critical software was formally specified using Z, developed in Spark Ada, and a partial correctness performed of the code against the specification. Information Flow analysis was used to demonstrate functional separation of critical and non-critical software. Freedom from run-time exceptions was demonstrated for all code. Static analysis of I/O usage, memory and timing was used to show separation of non-functional properties. Finally, proof that the system s top-level safety properties were maintained by the software was carried out. 

---