The development lifecycle must focus on the pertinent requirements of the automotive industry. Rather than spreading the effort across the entire spectrum, the Recommended Practice must concentrate on just the key elements of the software development lifecycle as it relates to the software buyer and software supplier relationship. Several important ideas influenced the J2516 committees direction : Instead of dealing with all of the various software design processes and their volumes of supporting materials, the Recommended Practice should narrow the scope to those aspects of the software development lifecycle which will provide the best value for the OEM-supplier relationship. Instead of dealing with all of the feature content and desirable aspects of software design tools, the Recommended Practice should limit the scope to the OEM-supplier relationship. Instead of dealing with all of the possible combinations of a software design requirements documentation package, the Recommended Practice should limit the scope to identify the key and minimal set of documents necessary to improve the quality of the design transfer. The scope of this Recommended Practice embraces the following key items : Concentration on the interface between the OEM (software buyer) and the software supplier. The buyer <---> supplier relationship is recognized as pivotal. This committee's expertise is better spent on defining the relationship between the OEM and the supplier as it applies to the procurement of software by the OEM and increasing the quality of the software that the supplier produces. --Support and description of both the OEM's and the supplier's point of view. The OEM, as a software buyer or consumer, has its own perspective and its own objectives. The supplier, who is the software producer, plays a different role. They share the common goal of creating a high-quality automotive electronic software product but they differ in their approach and methods. --Recommendation of the minimum set of best practices for the overall business and technical process. --Reuse of existing material. Re-inventing the various software development lifecycle work that has been created over the last 10 to 15 years is not necessary. A large amount of valuable material has been published, and some suggested references to these materials are included. --Definition of the essential elements of a good requirements document (from the supplier's point of view) --Definition of the essential components of a high-quality software product delivery (from the OEM's point of view). The general business scope of this effort includes : increasing software quality --minimizing errors made by all involved engineers --decreasing the cost of software development through use of the common development steps --raising the experience level of the embedded software community at a faster rate. In addition, this Recommended Practice does NOT : --identify the "best" software design tool nor make vendor-specific tool recommendations --concentrate on identifying or selecting the "best" software development process --form opinions or discuss potential deficiencies in software design process of any OEM, software buyer or software supplier. This Recommended Practice establishes definitions and recommendations for a generalized software development lifecycle. See Figures 2 and 3. The classic waterfall model is shown in Figure 2. The main flows of formation are shown using continuous lines. Possible alternative paths are shown with dashed lines; these represent the reality of the software development process in relation to possible re-work.
SAE Staff Representatives: