WORKPRODUCT SYNCRONIZATION USING THE SYNCHRO-X^TM LIFECYCLE MODEL AND OBJECT TECHNOLOGY

David G. Beshore, P.E.

The Boeing Company

Rocketdyne Division

Canoga Park, CA 91309

Abstract. Systems Engineering (SE) requires computer-based information capture, synthesis, and rework to complete on-time, quality SE documents – also known as SE workproducts. Product development lifecycle application is often challenged early, in the formative stages, when customer commitment and client resourcefulness are undefined. Goal-directed effort can only be performed if the SE work products and product development lifecycle model are coordinated - an example is shown in this paper by the new Synchro-X^TM lifecycle model along with implemention of object oriented techniques and workflow practices.

This new lifecycle model requires an understanding of Object Technology (OT) (Ambler 1998, Cantor 1998, Goldberg 1995, IBM 1997, Jacobson 1992, Meyer 1995, Taylor 1998) for the development, co-ordination and completion of work products during a program’s process execution and product development. Current systems engineering standards and capability maturity models (SE-CMM 1995) are used as the foundation for these lifecycle models and practices.

This paper examines:

1) the application of object technology to systems engineering,

2) the use of Synchro-X^TM lifecycle model which integrates process and product development,

3) how work can be synchronized at the practice, process and product class levels,

4) the need to focus on Process to minimize rework, and

5) how workflow technology can reduce the risk of product development.

WHAT IS THE ‘OBJECT’ IN SYSTEMS ENGINEERING?

Objects know and do things! Object-oriented systems engineering is the practice of representing, developing and maintaining packages, classes and objects that are uniquely attributable to systems engineering. When developed with a disciplined, structured framework environment, the OT entities in Systems Engineering are evidenced in the ‘workproducts’ – approvable documents. These SE objects should be reusable, loosely coupled, but highly cohesive data structures contained in SE templates, models, drawings, schematics, plans, reports, tables, databases. The workproducts’ timely development requires the use of software tools and information technology for the timely data collection and review.

In order for SE workproduct objects to be used in concert with product development, SE high-level process definitions and workflow methods need to be established. These process definitions and methods need the identification of both common and domain specific attributes (data) in several engineering disciplines – systems, software, electronics, aerospace, environmental, mechanical, chemical and nuclear systems. Large-scale systems integration (LSSI) requires the establishment of workproduct template sets through integrated master plans and schedules early in the program in order to establish priorities and minimize rework.

Products and workproduct levels must integrate with the program’s budget and schedule while satisfying customer needs and product development activities – planning, requirements development, analysis, synthesis, verification and validation of products (Figure 1).

FIGURE 1. PRODUCT DEVELOPMENT REQUIRES LEVELS OF ABSTRACTION

Synchronization points (reviews, walkthroughs and audits: Systems Design Review (SDR), Preliminary

Design Review (PDR), Critical Design Review (CDR), Functional and Physical Configuration Audits, and Acceptance Reviews) in product development co-ordinate different levels of activity. (Level 1: Program management, Level 2: Process management; Level 3: Process and Product Teams, and Level 4: Fabrication and Production Teams).

Objects in software engineering have been clearly defined in response to the complexity of software development. In software, an object represents a high-level data structure consisting of data and the methods to operate on that data. An object is an instance of a class that has the properties of polymorphism, inheritance, and encapsulation. These properties ensure the reusability and flexibility of the object for other applications.

SE workproducts also have object qualities. They:

1) have state, behaviour and identity through a product lifecycle,

2) tie together data and processes (encapsulation),

3) can be cloned from other SE classes

4) have templates (inheritance)

5) can be tailored to the special needs of the program (polymorphism)

In addition, workproducts:

1) can be evaluated through metrics

2) may be deliverable with hardware and software

3) ensure quality products

Through analogy with software OT and Structured Analysis and Design Techniques (SADT) (Table 1), an ‘object’ in systems engineering are instances of several things: people, processes, products (software and hardware components), and workproducts. The workproduct template is also reusable for other projects, with minor change.

TABLE 1. OBJECT ORIENTATION EXAMPLES IN SOFTWARE, SYSTEMS AND WORKPRODUCTS

OO Level	System	Software	Work-Products
Class	Process, Product, Practice	Class, Package	Workproduct Template
Object	Plan, Diagram, Report, Specification, Model	Object, Module	Workproduct
Operation	Functional Decomposition	OOAD, SADT	Workflow
Attribute	Requirements, Part Numbers, Dates, Costs	Data	WorkProduct Input /Output

Therefore, the systems engineering management effort for each project is to co-ordinate these workproducts in the proper sequence with the product development. Indeed, such tailoring would make systems engineering user-friendlier with program management. Also, the use of several process standards (ex. IEEE1220 1998 for systems engineering, ISO 12207 1995 for software engineering, and EIA632 1998 for enterprise engineering of systems) inherently require work products as evidence that the standard has been followed.

Domains can be represented in Packages, as shown in Figure 2. Packages can bundle objects, classes, and use cases that belong to Systems Engineering and Integrated Process and Product Development, for example. The information needed by each package of the other is shown. At least one class in each package needs such information.

Figure 2. Domain Packages

As examples, classes can be developed such as Systems Engineering Workproduct class (Figure 3) Systems Engineering Process class (Figure 4) and IPPD Practice class (Figure 5). Practice classes (like Quality Function Deployment and Robust Design) become required ideologies when adopted by the customer or the program.

Figure 3. System Engineering ‘WorkProduct’ Class

These practices must be considered, and must add value to the organizations’ current mix of processes and workproducts. If these do not add value to the organization or the product development, they should not be adopted.

Figure 4. Systems Engineering ‘Process’ Class

Figure 5. Integrated Product and Process Development ‘Practice’ Class

The interaction of classes of concern to systems engineering can be developed using class models, which describe the class collaboration. As shown in Figure 6, a process needs zero to many Practices and develops at least one Workproduct. A Practice is developed from one or more processes and adds value (quality) to the Product. A Product needs at least one process and at least one Workproduct, and zero to many Practices. In many organizations, the overlap between Process and Practice classes is huge, because of the confusion between the two class definitions.

Methodologists can introduce a new practice (a set of processes, such as Integrated Product and Process Development, Cost as an Independent Variable), which can help or hinder product development. By definition, a practice must add value to the product. It is assumed that process and workproducts add value to the product, but applied inappropriately could conceivably work against product development.

Practices integrate processes! Sets of processes that greatly add to product value are called ‘Best Practices’ and used by Program Managers to focus and direct product development. Capability Maturity Models (SE-CMM 1995) define practices that are specific and common to processes. CMMs help to categorize the practices found in process areas. However, CMMs do not define processes that organizations need to product workproducts and products.

Figure 6. SE Class Model of product, process, practice, workproduct

In short, at least 2 classes and maybe 3 are needed to support the product class. The issue with synchronization is one of timely execution of process, workproduct, and practices.

LEVEL 1: PRODUCT DEVELOPMENT USING SYCHRO-X^TM LIFECYCLE MODEL

– A Best Practice?

Lifecycle methods can also be viewed as ‘Best Practices’. Product development has been dependent on the basic ‘requirements-design-construct-test’ lifecycle in various forms for well over 50 years. Product lifecycles are needed to provide a model for the ‘people’ to follow direction for that development. Unfortunately, a variety of lifecycles have been used to show that products can never be completed as long as requirements change and design and code are constantly in a state of rework (iterative, spiral, evolutionary, fountain, and cluster models (Meyer 1995)). However, freezing requirements, using the classic waterfall lifecycle (Meyer 1995), no longer applies in today’s highly volatile, globally competitive environment. With either model paradigm, both people direction and product development are difficult and frustration is noticeable because neither model expresses the desired product end-state – a delivered product that satisfies customer requirements.

Successful product development needs a high degree of co-ordination of information and people with lifecycle models that reinforce the discipline of goods systems and software engineering practices. Synchronization of effort is not clear in iterative lifecycle methods, particularly those in which the current version of the build won’t fully satisfy customer expectations – i.e. a prototype. The classic waterfall model is too simplistic where rework is the norm and the pace of technological change is intense. Front-end concurrent engineering and just-in-time methodologies, introduced in the late ‘80s, present severe budget capital and people resource issues in the early stages of large-scale systems development.

The Synchro-X^TM lifecycle model was developed after first looking at the linkage existing between requirements and verification methods in systems engineering commonly depicted as the V- model (Figure 7), and adopted by German Federal Armed Forces (General Directive 250) (Zahran 1998). A new model, Synchro-X^TM (Figure 8), is being tested and evaluated on several programs to satisfy the shortcomings of previous models.

FIGURE 7. V-MODEL – BASIS FOR SYNCHRO-X^TM

Requirements development with the V-model requires knowledge of not only capturing requirements, but also determining early their verification method (inspection, analysis, demonstration, and test).

In the V-model, the development of requirements with the proper document template (such as with MIL-STD–490, Section 4, Quality) requires the completion of the requirements verification matrix -- before the actual initiation of verification effort! This feedfoward thinking (planning) of ‘completion’ requirements is a necessary part for the planning of budgets, personnel, and facilities.

TABLE 2. COMPARISON OF LIFECYCLE MODEL CHARACTERISTICS

(McConnell 1996)

Characteristics	Water-fall	Spiral	Evolu-tionary	Synchro-X (Beshore)
1. Works with poorly understood requirements	Poor	Excellent	Excellent	Fair
2. Works with poorly understood architecture	Poor	Excellent	Poor	Fair
3. Produces highly reliable system	Excellent	Excellent	Fair	Excellent
4. Produces system with large growth envelope	Excellent	Excellent	Excellent	Excellent
5. Manages risks	Poor	Excellent	Fair	Excellent
6. Can be constrained to a predefined schedule	Fair	Fair	Poor	Excellent
7. Has low overhead	Poor	Fair	Fair	Excellent
8. Allows for midcourse corrections	Poor	Fair	Excellent	Good
9. Provide customer with progress visibility	Poor	Excellent	Excellent	Excellent
10. Provides management with progress visibility	Fair	Excellent	Fair	Excellent
11. Requires little manager or developer sophistication	Fair	Poor	Poor	Excellent

A comparison of the current of lifecycle methods (waterfall, spiral, and evolutionary) with Synchro-X^TM is shown in Table 2.

The Synchro-X^TM model, scores good-to-excellent for all the characteristics in Table 2, especially for items 8-11. In addition, the Synchro-X^TM model is easily remembered, like the waterfall and V-models.

As shown in the Synchro-X^TM model, communication (review) paths are defined in two dimensions –feedforward / feedback (horizontal dashed lines) and concurrent paths (vertical dashed lines) among the four major work vectors (goal driven work effort).

In comparison with the V-model, feedforward communication (planning) and feedback (review) mechanisms are expanded in the model with two more vectored efforts – the design and build activities in Figure 8.

The concurrent activity of specification and design is then focused on the contractor/customer commitment to make, buy, or reuse software and systems engineering objects (primary effort is design and customer acceptance of the design). Note in Figure 8, time moves from left-to-right in this model (not in circles or do-loops as in iterative lifecycle models).

Effort is co-ordinated through timed feedforward / feedback / concurrent path synchronization points (change control decisions, revised plans, reviews, reports, drawings and workproducts at system, subsystem and component levels) of process execution (as evidence by completed work products) and product development.

In the Synchro-X^TM model, converging and concurrent efforts of ‘specify’ and ‘design’ drive toward commitments to make, buy or reuse all of the systems, subsystems and components at the lowest level of specification. After commitments (to make, buy or reuse hardware and software) are made in final design and specification reviews, focused on co-ordinated activities of build and test (when primary emphasis is on product test and delivery). The completion of the effort is indicated by proven functionality and performance at the system level, confirming all requirements are verified (review analysis and customer audits), and manufacturing and producibility goals have been completed in accordance with as-built design (review analysis and design verification).

Co-ordination (feedforward, feedback, and concurrent communications) is required at system, subsystem and component levels between all stakeholders – customers, requirements managers, designers, software engineers, manufacturers/suppliers, and test and analysis teams. Successive levels of commitment and cost detail are developed through requirements, traceability and design reviews, design compliance and configuration reviews, test readiness and quality verification reports, and verification and validation audits. The model clearly shows which teams (specification and design, build and test) need the closest and most accurate communication in order to produce quality, time-to-market products.

FIGURE 8. SYNCHRO-X^TM LIFECYCLE MODEL

Additional vectors could be shown for supplementary processes (such as analysis and planning). However, all vectors pass through the effort is same make/buy/reuse co-ordination point at the center of the model, to ensure proper management decision-making and controls.

LEVEL 2: ENSURING PROCESS EFFECTIVENESS WITH PROCESS METRICS

A major component of product development is ‘rework’, especially if adequate process definition (~5-10% of program budget) does not occur early in the program (see Figure 9).

FIGURE 9. COST of REWORK WITHOUT PROCESS TIMING

As shown in the bottom panel of Figure 9, process work too late in the lifecycle can force so much rework that product delivery can stop or be critically delayed. To determine if sufficient process definition has occurred, metrics on workproducts must focus on appropriate levels of quality (completeness) and timeliness. Also, workproduct development must be in synchronization with product development schedules.

While product metrics focus on the customer satisfaction of the hardware, process metrics focus on how fast the product can be developed while ensuring quality (satisfying requirements). Process metrics also focuses on eliminating defects in the product due to incomplete or undocumented work products that could have dependencies on other work products (requirements specifications, trade-studies that drive solutions, and fabrication and test verification records that indicate requirements compliance).

As shown in Table 3, it is possible to have a good process but bad product, and good product but bad process, among the other combinations. All situations point to poorly developed processes that do not match the product development lifecycle.

TABLE 3 (Donaldson 1997).

PROCESS and PRODUCT MEASUREMENT INDICATORS

LEVEL 3: WORKFLOW REENGINEERING WITH PROCESSES AND WORKPRODUCTS

Automated business process reengineering tools enable the development of new or more efficient work paths to be coordinated via computers. The synchronization of workproducts could thus be efficiently routed to appropriate systems engineering,

IPT leaders, and program managers for timely completion. A simple example of the workproducts’ workflow is shown in Figure 10. As shown in Figure 10, workproducts are associated with process areas (PA) in the SE-CMM model (SE-CMM 1995).

The workflow of each workproduct is based on it’s data structure templates (outline and parameters) as depicted in a conceptual workflow model (Beshore 1998). Workproduct templates insure that data between workproducts is loosely coupled (not duplicated and independent of other workproducts) so each can be completed without excessive workproduct co-ordination.

Web-enabled workflow modelling software use metrics inputs from key personnel to provide the necessary data to determine status of workproduct development. Requirements and changes can be tracked (Beshore 1998) both in number and revisions as indicator of product development change.

LEVEL 4: PRODUCT DEVELOPMENT

Synchronization in levels 1 through 3 of Figure 1 lowers risk of product development at Level 4 – Product Assembly, Delivery and Support. The process starts with early selection of workproducts from the process, whose foundation is in repeatable, well-defined processes and adopted ‘Best Practices’. Next, these workproducts need to be coordinated with

FIGURE 10. SIMPLE WORKPRODUCT WORKFLOW

workproducts of other processes through reviews and

planning during the product lifecycle (such as depicted in the Synchro-X^TM model).

Make/buy/reuse decisions with customer inputs and consultation insure that timely decisions are made ‘not too early’ and ‘not too late’ in the product lifecycle. Computer-aided software tools in requirements management, design, manufacturing, and testing also ensure that appropriate levels of commitment are satisfied before each synchronization point. This point will ensure that product development is in the correct stage of maturity with it’s associated work products (specifications, drawings, diagrams, interface definition, etc.)

CONCLUSIONS

In large-scale systems integration, rework and maintenance contribute to over 90% of the cost (Donaldson 1997, Jones 1994) of the system – so a theoretical benefit-to-cost of up to 10:1 is achievable, near term. Many of the requirements are not developed until prototypes and experimental testing are completed, so over-specification and over-design too early in the lifecycle adds even more risk of product development. Simplification of lifecycle models along with workproduct co-ordination is paramount.

Without initial structure in the form of defined SE templates and workproducts, much rework based on unsynchronized activity occurs throughout product development. The Synchro-X^TM model and object technology assists the program and customer organizations through workproduct and product development by maintaining proper levels of developer and customer co-ordination with emphasis on horizontal - feedback (review), feedforward (planning), and vertical (concurrent) communications.

REFERENCES

Ambler, Scott, The Object Primer, The Application Developer’s Guide to Object Orientation, Cambridge University Press, 1998.

Beshore, David G., William Vietinghoff, and Jonathan Kiser; Improving Requirements Processes Through Modeling and Data To Achieve Level 5 Capability Maturity, Proceedings of the Eighth Annual International Symposium of the International Council on Systems Engineering, July 26-30, 1998.

Cantor, Murray R., Object-Oriented Project Management with UML, John Wiley, 1998.

Donaldson, Scott E. and Stanley G. Siegel, Cultivating Successful Software Development: A Practioners View, Prentice Hall, 1997.

EIA632, Processes for Engineering a System, Version 1.0, Draft, Electronic Industries Association, 28 April 1998.

Goldberg, Adel; and Kenneth Rubin, Succeeding with Objects – Decision Frameworks for Project Management, Addison-Wesley, 1995.

IBM Object-Oriented Technology Center, Developing Object Oriented Software – An Experience-Based Approach, Prentice Hall PTR, 1997.

IEEE 1220, IEEE Standard for Application and Management of the Systems Engineering Process, Final, 1998.

ISO/IEC 12207, Information Technology—Software Life-Cycle Processes, 1 August 1995

Jacobson, Ivar, Object Oriented Software Engineering – A Use Case Driven Approach, Addison-Wesley, 1992.

Jones, Capers; Assessment and Control of Software Risks, PTR Prentice Hall, 1994.

Meyer, Betrand, Object Success, Prentice Hall, 1995.

McConnell, Steve; Rapid Development, Microsoft Press, 1996.

Mil-Std 490A, Military Standard-Specification Practices, DOD, Washington, D.C., 4 June 1985.

SE-CMM^TM, Systems Engineering-CMM^tm, Software Engineering Institute, Carnegie-Mellon, Version 1.1, 1995.

Taylor, David A., Object Technology, A Manager’s Guide, Addison-Wesley, 1998.

Zahran, Sami; Software Process Improvement, Addison-Wesley, 1998.