How To Develop A Telelogic Harmony/Esw Project

Transcription

1 White paper October 2008 The Telelogic Harmony/ESW process for realtime and embedded development. Bruce Powel Douglass, IBM

2 Page 2 Contents 3 Overview 4 Telelogic Harmony/ESW core principles 6 Harmony/ESW overview 9 The software microcycle 10 Conclusion

3 Page 3 Overview Closely linking people, best practices, processes and tools can optimize your development lifecycle. Improving your technology and your process together can be dramatically more effective at increasing productivity than improving technology alone. Why? Because process improvement enhances effectiveness while development tools increase efficiency. Together, they significantly improve productivity and quality. Tailored for the development of embedded and realtime applications, Telelogic Harmony/ ESW is an iterative, model-driven development process based upon the Unified Modeling Language (UML) 2.1. It provides strong guidance for the developer or manager of realtime and embedded systems and helps resolve many of the process and management issues surrounding object-oriented and object-based systems development. It also helps improve quality while reducing cost by iteratively creating and testing executable visual models, detecting defects early in the development lifecycle while maintaining synchronization with the code. The Telelogic Harmony library of best practices contains an integrated product development process that takes product development from requirements capture through systems engineering, iterative development and design, and into final test and validation.

4 Page 4 An overview of the process is shown in figure 1. Figure 1. Harmony/ESW process overview ( microcycle ) The microcycle is an incremental process in which the requirements elements are specified and selected, and then vertical slices of the system are constructed and validated. The system (referred to as the prototype, even though it is fully production-quality code) is constructed incrementally, with new vertical slices adding new system-level capability to the increasingly complete and capable system. The advantages of such an incremental approach can include higher quality deliverables, lower cost of quality and even reduced development time. Telelogic Harmony/ESW core principles Harmony/ESW is an agile process that has demonstrated its effectiveness in realtime and embedded projects. It consists of an integrated set of interrelated roles, work products, tasks and guidance that are the practical outcome of the application of a small set of core principles.

5 Page 5 Developing working software: your primary goal You should focus your effort on the tasks and activities that have the most effect on the production of high-quality, working software. This is not to say that supporting activities have no value, but they are secondary to the development of the software per se. Working software is your primary progress metric The most important single measure of project progress is the addition of executing functionality to the working software. Other measures, such as lines of code produced, don t always correlate with true project progress. Continuous feedback is crucial You need constant feedback about the quality and correctness of the software and you need it more than daily. This is the basis for Harmony/ESW application s nanocycle of continuous execution of the developing software and microcycle validation that typically occurs every four to six weeks. Defining your architecture with five key views Harmony/ESW specifies five primary architectural views that encompass the strategic design decisions of the system design: the subsystem and component view, the concurrency and resource view, the reliability and safety view, the distribution view, and the deployment view. The system architecture is the sum of one or more design pattern solutions in each of these views. Harmony/ESW provides strong guidance on how best to select and apply appropriate design patterns within these different architectural views. Plan, track and adapt Since plans are always made in (some degree of) ignorance, it is crucial to plan to re-plan and update your system plans as you learn more and as things change. This is the basis of the increment review ( party ) phase at the end of each microcycle.

6 Page 6 Ignoring risks = leading cause of failed projects Managing risk is crucial to project success. Harmony/ESW incorporates risk reduction into the mission statement for each microcycle and provides guidance on how to help effectively reduce risk. Continuous attention to quality is essential Quality is not something that can be added ex post facto, but is instead a way of performing your daily work. The Harmony/ESW nanocycle provides continual feedback as to the correctness and accuracy of the software, making it easier to concentrate on producing great software. Modeling is crucial Good modeling provides significant benefits in terms of understandability, analyzability, code generation and reusability. Harmony/ESW provides strong guidance on how to most effectively model realtime and embedded systems. Optimize the right things In Harmony/ESW, design is all about optimization. Harmony/ESW puts strong emphasis on when and how to achieve optimal designs. Harmony/ESW overview Development within Harmony/ESW proceeds, as already mentioned, in an iterative, incremental activity called the microcycle. The software team begins with this speci-fication of requirements and context. It then selects functionality organized around the software subsystem use cases to be developed.

7 Page 7 Analysis phase In the analysis phase of the microcycle, the use cases to be added to the prototype are identified and detailed, if necessary. Following this, a domain analysis (a.k.a., object analysis ) is done to identify the essential elements that must be included in any acceptable software solution to the problem. Following the analysis phase, the project enters the design phase. Design phase Design is all about optimization of a system against the set of design criteria for the product. The design criteria are the properties of the system that measure the goodness of the design properties such as worst case performance, throughput, bandwidth, reliability, safety, security, time to market, complexity, maintainability and so on. These properties are prioritized in order of their criticality. Design then proceeds by identifying design patterns that help optimize the most important design criteria at the expense of the least important criteria. It is during this stage that technological solutions are adopted to achieve these design goals. Code generation and synchronization Following design, the code is produced that realizes the design. In a high-quality solution such as Telelogic Rhapsody, almost all of the code is generated automatically from the UML design specification. With less capable tools, significant effort must be expended to create the code and synchronize it with the model. As an integral part of the development of this code, we include unit-level test mostly oriented around the important classes from the analysis model and, following successful unit test, peer review. Peer review of the model enables team members not only to validate the design, but also to disseminate information about parts of the design to the rest of the team.

8 Page 8 System integration Once the high-quality (i.e., tested and verified) architectural units (e.g., subsystems) are produced, they are integrated (along with specific artifacts from other engineering disciplines) into a system prototype that is then validated against the requirements of the prototype. Using regression testing to help ensure that previously working features haven t been broken by the new development work, these requirements include not only the new ones added during the current microcycle but also those added in previous microcycles. Acceptance testing and customer release The system prototypes become increasingly complete as more of the remaining capabilities are added over time until the system meets the entire set of requirements necessary for product release. At this point, the engineered system is passed to final acceptance testing and released to the customer. A linear view of project progress The spiral can be unrolled to show how the project progresses in linear time. In this view, one can see how the phases occur over time and how, at the end of each spiral, an executing, validated prototype is released. Figure 2 shows how this might look for a typical project. Each prototype release includes some level of functionality and completeness (in terms of materials, composition, requirements, etc.). Normally, these prototypes are between four and twelve weeks, and they may vary a bit (as shown in the figure). However, the length of each spiral (known as a microcycle) is much shorter than the length of the entire development cycle. Figure 2. Unrolled microcycles

9 Page 9 The software microcycle From a software point of view, the spiral is detailed as shown in figure 3. In the analysis phase, the requirements for the next prototype are selected from those inherited from the systems engineering hand-off and then relegated to software by the IPT in the transition phase of the overall Telelogic Harmony process. Once the use cases clustering the relevant requirements are selected, an object or domain analysis is done to identify the objects, classes and types that are required in the solution. After all, it wouldn t be a microwave oven if it didn t have a microwave emitter, and it wouldn t be a flight management system without an understanding of flight plans, waypoints, vectors and their relationships. The purpose of object analysis is to identify these key concepts and their relations before design optimizations are inserted. The object analysis model is high-quality and executable, so it is demonstrably correct against the requirements. It is not, however, optimal and may not meet various quality goals for service requirements. This optimization is done in design. Figure 3. Software spiral ( microcycle ) in Harmony/ESW

10 Page 10 Design microcycle Design proceeds in three phases. As mentioned above, design is all about optimization. In architectural design, strategic design decisions are made that attempt to optimize the entire system at once. Mechanistic design focuses on optimizing a single collaboration that realizes one use case. Detailed design optimizes the individual objects that require it. Implementation microcycle The implementation phase produces the code mostly through tool-generation but possibly partly by hand. This code is then unit-level tested to help ensure a high level of quality of the system build. Following the code-unit test, the model, and possibly parts of the code, is peer reviewed to help identify defects not yet uncovered and to disseminate information about the design. Testing: the integration and validation microcycle The testing phase is broken into two parts integration and validation. In integration testing, the various software units (software subsystems and/or components) are linked, and the software is integrated with the hardware that is developed for this prototype. This is typically done at two levels. First, the integrated subsystem is constructed, and then the various integrated subsystems are brought together to create an integrated system prototype. Following this integration, the system is validated against the requirements for this prototype build. Conclusion Harmony/ESW is a robust, iterative, model-driven development process that optimizes the development lifecycle by closely linking people, best practices, processes and solutions. By providing strong guidance for the developer or manager of real-time and embedded systems, Harmony/ESW resolves many of the process and management issues surrounding objectoriented and object-based systems development. It also improves quality, while reducing cost, by iteratively creating and testing executable visual models, detecting defects early in the development lifecycle while maintaining synchronization with the code. Many projects, both small and large, have benefited from using Harmony/ESW.

11 Page 11 For more information To learn more, please visit: About the author Dr. Bruce Powel Douglass has over 25 years experience designing safety-critical realtime applications in a variety of hard realtime environments. He has designed and taught courses in object orientation, realtime and safety-critical systems development. He is an advisory board member for the Embedded Systems Conference, UML World Conference and Software Development magazine. He is a cochair for the Real-Time Analysis and Design Working Group in the Object Management Group (OMG) standards organization. Bruce has written 11 books on software development including his latest, Real-Time UML 3rd Edition: Advances in the UML for Real-Time Systems. He is a chief evangelist at IBM.

12 Copyright IBM Corporation 2008 IBM Corporation Software Group Route 100 Somers, NY U.S.A. Produced in the United States of America October 2008 All Rights Reserved IBM, the IBM logo, ibm.com, Rational, and Telelogic are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol ( or ), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at Copyright and trademark information at ibm.com/legal/copytrade.shtml Other company, product, or service names may be trademarks or service marks of others. References in this publication to IBM products and services do not imply that IBM intends to make them available in all countries in which IBM operates. The information contained in this documentation is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this documentation, it is provided as is without warranty of any kind, express or implied. In addition, this information is based on IBM s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this documentation or any other documentation. Nothing contained in this documentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM (or its suppliers or licensors), or altering the terms and conditions of the applicable license agreement governing the use of IBM software. RAW14053-USEN _0810_US