Your SlideShare is downloading. ×

S5rud

136

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
136
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. FOCUS: lean software developmentA Business tomography, oncology, and ultrasound imaging. It enables more patient exams in less time and accommodates effi-Case for Feature- cient image creation, usage, archiving, and sharing for sound diagnoses. The syngo.via product has several thousandOriented requirements translating into millions of C++ and C# LOC. Like the rest of the medical device industry, Syngo faces business chal-Requirements lenges stemming from industry regu- lations, which require full compliance in product development (such as trace-Engineering ability and auditability of requirements changes) to ensure patient safety. In ad- dition, new market entrants, competi- tors from the BRIC countries (Brazil, Russia, India, and China), and IT com-Arnold Rudorfer, Siemens Healthcare Diagnostics panies moving into Siemens’ traditional market space are putting pressure onTobias Stenzel and Gerold Herold, Siemens Healthcare cost and cycle time. Moreover, medi- cal device functionality is increasingly being realized in software, as has hap- pened in other industries such as the automotive sector.1// Owing to the growing software content in medical To remain competitive amid thesedevices, an adequate requirements engineering approach challenges, Syngo must continually in- crease productivity. Regarding soft-is necessary to help meet the challenges of engineering ware development, we hope to lever-efficiency and cost effectiveness. Feature-Oriented age and adapt the principles of Toyota’sRequirements Engineering offers such a solution. // lean engineering approach3 to • create customer value, • reduce waste, and • optimize value streams, empow- erment of teams, and continuous improvement. Toward that end, Syngo developed Feature-Oriented Requirements En- gineering (FORE), a systematic ap-Syngo, a Siemens business unit, is syngo.via software is the central proach for organizing requirementsan imaging software and medical de- hub in many healthcare workflows according to marketable, customer-vice provider with several hundred de- (see Figure 1). With it, developers can oriented features. FORE ensures avelopers across multiple continents. Its build clinical applications for com- business perspective throughout theprojects are geographically distributed puted tomography, x-ray, magnetic product life cycle and is one of theto leverage engineering talent, speed, resonance, proton emission tomogra- enablers for product line engineer-and cost. phy, single-photon emission computed ing. Table 1 illustrates some ways that30 I E E E S o f t w a r e | p u b l is h e d b y t h e I E E E c o m p u t e r s o c ie t y 0 74 0 -74 5 9 / 12 / $ 3 1. 0 0 © 2 0 12 I E E E
  • 2. FORE is helping Syngo meet require-ments engineering challenges. Here,we describe FORE and the businesscase we developed for it.The FoRe approachA feature model is a hierarchical treedescribing the structure, dependen-cies, commonalities, and variability offeatures in a product or product line(such as platforms for a medical de-vice).4,5 A feature, in our nomencla-ture, is a marketable unit as an aggre-gation of requirements characterizinga system’s capability or performance(such as a reporting feature, movie fea- fIGUre 1. Integrated clinical workflows. Syngo.via software enables more patient exams inture, or volume-rendering-technique less time and accommodates efficient image creation, usage, archiving, and sharing for soundfeature). A feature is a mere container diagnoses.for one or more requirements. In otherwords, requirements specify features.The project phase dictates require- Feature Model Benefits abstraction level (instead of danglingments’ levels of detail (for example, Using feature models, we can struc- requirements) and graphical overviewconsidering market requirements ver- ture product requirements along the of the products’ functionality. Theysus software requirements). customer’s domain, achieving a higher also serve as a basis for proper product Requirements engineering challenges.taBle 1 Challenge Solutions introduced by Feature-Oriented Requirements Engineering Linkage of product • Tedious scoping sessions with customers, owing • Setting up a business-driven feature model from the customer’s requirements to to many specifications viewpoint business drivers • Many technology-driven requirements that have • Supporting agile methodologies by integrating the requirements no business rationale database and a backlog or a project management tool • Requirements creep or different entry points for • Central collection and evaluation of stakeholder requests requirements • Early transformation of stakeholder requests into requirements Relationship of • Nontransparent relations between the problem • Modeling relations between features and components to enable problem to solution and solution spaces impact analysis space • Complex product architecture, implementation, • Modeling product variability and product lines by clustering and testing requirements to features • No possibility to reuse requirements and specifications for different product lines Very large product • Testing without customer perspective (focusing • Testing self-contained features and use cases scope to test on components) • Continuous synchronization of up-to-date requirements with • Inefficient testing owing to a heterogeneous test cases requirements structure Reduce engineering • A complex tracing methodology with n:m • New techniques to model cross-cutting concerns that impact overhead relations (too many traces) various features • Simplifying tracing methods (structure-based tracing and 1:m relations) S E p t E m bE r /o c to bE r 2012 | IEEE S o f t wa r E 31
  • 3. FOCUS: lean software development Requirements engineering Project and test management Transformed info SW feature SW feature 1 2 4 Enhancement Backlog item Stakeholder request Sync Tested by Market req. Grooming and Market req. Test case Sync incorporation Mapped to into requirements SW req. SW req. Test case Sync 5 6 3 SW req. SW req. Test case Sync Architectural building block SW req. Architecture and designfIGUre 2. Integrating Feature-Oriented Requirements Engineering (FORE) into development. For an explanation of the steps,see the main article.line engineering and help manage vari- Architect) and a tool for backlog and product backlog for prioritizationability and commonality (for example, test management (Microsoft Team and release planning.defi ning rules about whether a feature Foundation Server). 5. As the assigned software develop-is mandatory or optional). Further- The following development use case ment Scrum teams further decom-more, developers can perfectly com- and steps summarize our approach (see pose and groom the backlog items,bine feature models with lean or agile Figure 2): they incorporate changes on the SWproject management methods (such requirement and design levels.as Scrum) by fi lling a product backlog 1. Product managers collect, analyze, 6. Both market and SW requirementswith user stories. and decide on stakeholder requests sync to the test management suite to from various sources, such as end enable tracing to test cases.Integrating Feature customers or internal stakeholders.Models into Development 2. If a requirements engineer ac- Introducing FORE and integrat-Feature models’ seamless integration cepts the stakeholder requests, he ing it in a Scrum-based developmentand application into product develop- or she transforms the requests into setup has provided multiple benefits.ment processes will be key to achiev- completely new software (SW) fea- The strict distinction of stakeholdering higher engineering efficiency. At tures or enhancements to existing requests and SW features and their en-Siemens Healthcare, we’ve integrated features. hancements avoids redundancies andFORE with the engineering disciplines 3. Together with architects, the require- inconsistencies in product require-of architecture and design, project ments engineer maps the SW features ments (such as a stakeholder requestmanagement, and test management. to architectural building blocks to that might address an existing feature We also introduced a tool chain determine complexity and effort. or enhancement). Besides representingsupporting FORE. It consists of a tool 4. Then, the product manager syn- the formal design input of the medicalfor requirements engineering, archi- chronizes the enhancements per device, the feature model serves as thetecture, and design (Sparx Enterprise feature in parallel as items in the primary input source for the product32 I E E E S o f t w a r E | w w w. c o m p u t E r . o r G / S o f t w a r E
  • 4. backlog and enables Scrum-basedproject management. Mapping archi- Type of investmenttectural building blocks to SW featuresprovides early information about com- Characteristicsplexity and input for subsequent effortestimations. Moreover, testers always Costsget up-to-date requirements that areready to be traced to test cases. In this Discounted cash flow: “As is” process vs. “to be” processregard, the feature model is the central net present value NPV)information hub and provides a col-laboration basis for various processes Benefitsand disciplines. Key benefits areas and levers Discounted cash flow: NPVThe Business CaseAlthough we already had experience Riskdoing business cases for software processimprovement, FORE’s business case was Determine critical factors: Determine error limitone of the most difficult to develop. sensitivity analysis for critical factorsThis difficulty was due to the nature ofrequirements engineering and the manyrelations the discipline has with adjoining fIGUre 3. Our business case approach involved four major steps: assessing the type ofengineering workflows. Figure 3 investment, costs, benefits, and risk.shows the business case approach’sfour major steps: assessing the type ofinvestment, costs, benefits, and risk. process (the future state—that is, manner for creating test cases. This is FORE). This way, we could accurately possible owing to a better overview forAssessing the Type of Investment record the as-is state’s operating costs. test cases. We spend less time on under-To investigate the investment’s char- Moreover, we could subsequently es- standing the requirements and their as-acteristics, we fi rst determined five timate preparation and rollout costs. sociated use cases. Additionally, there’squestions: This included the costs for needed pro- a much earlier consideration of non- cess changes (methodology and tool- functional requirements such as scal- • What’s the savings potential with ing), including staff training and orga- ability and performance. An explicit FORE? nizational change management. modeling attached with an integrated • What’s FORE’s return on invest- view lets us detect nonfunctional re- ment (ROI)? Assessing Benefits quirements issues early in the process. • By when will we recover the To determine the key benefits and levers, We can quickly detect any omission. investment? we ran a series of workshops with key • Which engineering areas contribute stakeholders from development (prod- Transparency. This area relates to most to the business case? uct managers, architects, test managers, the requirements content. A feature • Finally, what happens if important and project managers). We identified model, owing to its graphical nature, levers fail? (Levers are critical suc- four key benefits. The fi rst was more provides a quick overview from a cus- cess factors that will help us realize effective testing and easier bug fi xing. tomer’s perspective on how product FORE’s benefits.) The second was transparency and easy requirements are structured. Further- overview of product functionality. The more, we can trace each feature fromWe investigated the answers later, when third was reduced product complexity the business need to the customer re-assessing benefits and risk. through variability modeling, and the quirement. A business-driven feature fi nal benefit was easier tracing owing to model has the benefits of allowing usAssessing Costs fewer trace relationships. to more easily defi ne a product releaseNext, we determined an “as is” re- and to more quickly understand the re-quirements engineering process (the Effective testing and easier bug fixing. quirements content.current state) and defi ned the “to be” One of FORE’s levers is a simplified First, it’s easier to prepare and S E p t E m bE r /o c to bE r 2012 | IEEE S o f t w a r E 33
  • 5. FOCUS: lean software development variability modeling. Applying this in our project helped reduce redundancy in the product architecture. Simplified tracing. The feature mod- el’s tree structure mirrors the vertical traces from a business need to product requirements, design, and code. This Costs and benefits (Euro) Benefits implicit tracing mechanism is built Costs when we construct the feature model. Cumulative benefits So, we have fewer traces to manage and fewer opportunities to inject tracing er- rors when we must retrace. Therefore, rework also decreases. Benefits analysis. Equipped with the benefits data, we can calculate the net Roll out Operative present value (NPV) and the time of Preparation payback (see Figure 4 for an example). We used the time-savings-times-salary Time method to calculate benefits.7 The NPV in our case was approximately 15 to 20 percent of an annual RD budget. ThefIGUre 4. FORE benefits calculation. The net present value was approximately 15 to 20 time of payback was approximatelypercent of an annual RD budget. The time of payback was approximately two years, resulting two years, resulting in an ROI of ap-in an ROI of approximately 1:3. proximately 1:3. Another interesting result was the distribution of the resulting benefits development release as we select the across the product development dis- number of features that fit our resource ciplines: product defi nition, project and time constraints. Second, we can management, design, and testing (see 25% quickly bring product managers up Figure 5). We could conclude that test- Product definition to speed when looking at a graphical ing would be the biggest beneficiary of model (rather than having them parse applying FORE. Furthermore, to un- 45% through many text-only product re- derstand the total set of benefits, we Testing quirements descriptions). In the con- had to look holistically at all product 23% Product text of our product, we needed to deal development disciplines. It was also management with more than 5,000 requirements. best to continue reviewing and con- 7% The resulting feature model had more fi rming benefits with stakeholders from Design than 800 features. Industry practitio- all those disciplines. We’d need those ners report that using graphical mod- stakeholders as champions to roll out els in requirements engineering helps FORE and to continue reiterating in-fIGUre 5. The distribution of benefits reduce the time to understand and re- vestment benefits to development staff.across engineering disciplines. Testing is the view product requirements by 40 per-biggest beneficiary of applying FORE. cent. 6 In this case, the product struc- Assessing Risk ture’s transparency helps us determine Finally, we determined how levers where to zoom in—for example, when behave. Running a sensitivity analy-conduct scoping sessions to defi ne reviewing a clinical workflow. sis on the key levers with large ben-a product release. Given the logi- efits showed that the NPV was stillcal decomposition, early on, we can Reduced complexity. We can reduce positive. So, implementing FORE stilldefi ne the boundaries for a product product complexity through product made sense.34 I E E E S o f t w a r E | w w w. c o m p u t E r . o r G / S o f t w a r E
  • 6. F ORE ensures that product re- aBoUt tHe aUtHors quirements only get into prod- uct releases that create cus- aRnoLD RUDoRFeR is the program manager for system platformtomer value. This avoids unnecessary development at Siemens Healthcare Diagnostics. His research interests include requirements engineering, organizational change management,up-front specifications of product re- software technologies, and business strategy. Rudorfer has an MS inquirements that won’t be implemented. software engineering and business administration from the UniversityThus, engineering effort isn’t wasted. of Technology Graz, Austria. Contact him at arnold.rudorfer@siemens. The feature model as a central de- com.velopment artifact helped our devel-opment organization optimize valuestreams in architecture and testing. A ToBiaS STenZeL is a process manager for requirements engineeringkey lesson we learned from doing the and product management at Siemens Healthcare. His research interests requirements engineering- and product management-related topics.business case is that FORE helps sus- Stenzel has an MS in computer science from the University of Technol-tain focus in actual implementation. ogy Munich, Germany. Contact him at tobias.stenzel@siemens.com.Furthermore, we can develop a busi-ness case only if we have completelyspecified FORE. Changing a key pro-cess development step requires endur-ing support from all levels of the or- geRoLD HeRoLD is a program manager for change managementganization and the involvement of key projects and a process manager for project management at Siemens Healthcare. His research interests include globally distributed, largestakeholders. software development projects from technical and business perspec- We can take further steps to in- tives. Herold has an MS in computer science and an MS in electricalcrease FORE’s utility through auto- engineering, both from the University of Erlangen-Nürnberg, Germany.mation. For example, requirements Contact him at gerold.herold@siemens.com.quality checking via rules in a featuremodel would help ensure consistencyand data quality. This would alsohelp product managers and require-ments engineers catch requirementsdefects early. Furthermore, in product 2010; www.lexjansen.com/pharmasug/2010/risk management, product risks could ib/ib01.pdf. 3. T. Ohno and N. Bodek, Toyota Productionbe linked to requirements in a fea- System: Beyond Large-Scale Production,ture node. This would help save time Productivity Press, 1988.in fi nding product risk and the corre- 4. C. Kang and S. Cohen, Feature-Oriented Domain Analysis (FODA) Feasibility Study,sponding mitigation. tech. report CMU/SEI-90-TR-021, Software Eng. Inst., Carnegie Mellon Univ., 1990. 5. B. Berenbach et al., Software Systems Re-acknowledgments quirements Engineering, McGraw Hill, 2009. Fill Ad 6. B.A. Berenbach, “Comparison of UML andWe thank Siemens colleagues Christa Schwan- Text Based Requirements Engineering,” Proc.ninger, Peter Hofman, Klaus Moritzen, Thom- 19th Ann. ACM SIGPLAN Conf. Object-as Baer, and particularly our master’s student, Oriented Programming, Systems, LanguagesFelix Popp, for input, discussion, and reviews. and Applications Conf. (OOPSLA 04), ACM,We also extend our appreciation to the Syngo 2004, pp. 247–252.global head of RD, Michael Heinold, for 7. B. Mutschler, N. Zarvic, and M. Reichert, Aproviding senior management support to make Survey on Economic-Driven Evaluations ofsoftware development improvement happen. Information Technology, tech. report, Centre for Telematics and Information Technology, Univ. Twente, 2007.References 1. G. Reichart and M. Haneberg, Key Drivers for a Future System Architecture in Vehicles, tech. report 2004-21-0025, SAE Int’l, 2004. Selected CS articles and columns 2. C. Smoak, “Medical Device Diagnostic In- are also available for free at dustry 101,” Proc. PharmaSUG, Pharmaceuti- cal Industry SAS Users Group, paper 1B01, http://ComputingNow.computer.org. S E p t E m bE r /o c to bE r 2012 | IEEE S o f t w a r E 35

×