We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byDominic Ramsey
Modified over 2 years ago
Introduction to Product Family Engineering
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 2 Product Family Engineering Overview Project Engineering vs. Product Engineering Requirements Variability: The Beginning of Product Families Architecting: Project Adaptations Product Families: Team Behavior State of the Discipline
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 3 Product Family Engineering Project Engineering vs. Product Engineering Project Engineering –Devoted to satisfying an end customer –Typically oriented toward one customers needs –Team will do anything for the good of the customer as long as its within the current budget and scope. Product Engineering –Devoted to satisfying a market need expressed by multiple end customers –Team considers alternative strategies to satisfy as many customers as possible, yet stay within budget and scope
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 4 Project Engineering vs. Product Engineering Salvage Engineering –Does your engineering development activity work in a Salvage Yard? –Do you manage projects by piecing together previous projects? –Do you claim to have a Product, but arent quite sure what the product can do, because every instance is different? Salvage engineering is a key characteristic of a project oriented business
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 5 Project Engineering vs. Product Engineering Salvage Engineering Salvaging –Copy and paste –Tendency to reinvent –Focus on unique customer needs with little or no unified product vision Sharing –Projects share common product definition - link to product intellectual property –Focus on product definition across diverse customers needs, while also enabling custom tailoring
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 6 Product Family Engineering Requirements Variability The Beginning of Product Families –Do you manage documents? –Or do you manage requirements/ intellectual property? PFE: Projects share content, not documents
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 7 Product Family Engineering Requirements Variability Variation - Understanding product differences and similarities Capture Project Differences –Project attribute - multi-enumerated value = Common Reqt Project A Project B Project C, etc N/A = Not Applicable to any project - retired or future
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 8 Product Family Engineering Requirements Variability Understand the differences - why? –Feature attribute - multi-enumerated value Different integration needs Different security needs Different capability needs Different performance needs –Capture why the requirement/ IP is different
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 9 Product Family Engineering Requirements Variability Understand timing - now, later, obsolete? –Currency attribute Current Obsolete Future Enhancement –Retire outdated/ no longer supported definition –Capture thoughts on future product upgrades –Understand what is being offered today
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 10 Product Family Engineering Requirements Variability
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 11 Requirements Variability Publishing Project Documentation - the by-product –Custom tailored for specific customer needs –Use filters to create reports Project = My Project or Common Feature = my set of selected features Currency = Current Upgrade reports –What opportunities exist for ECPs and upgrades? Report new features not currently selected Find Obsolete definition still lingering in deployed products Discover Future Enhancements for opportunity
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 12 Requirements Variability The Next Project Feature Exploration –New projects filter on and explore product features - which features address your unique customer needs? –Apply Project attribute to those feature that are shared –Copy requirement object when customer needs call for differences –Capture new difference in feature set
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 13 Product Family Engineering Architecting: Project Adaptations Requirements commonality –Share common problem definition Architecture commonality –Share common solution definition Individual projects have unique design and architecture –Select reusable components –But structure of solution may differ
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 14 Product Family Engineering Architecting Components have standard interfaces –Similar components must adhere to the same interface standard Integration of components is unique to project –Similar solution may be achieved with similar components in a different structure Product Family Architecting –Most effective when interface standards applied between all views of the architecture
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 15 Product Family Engineering Architecting: Allocation Logical Software Electrical Mechanical Civil/ Structural Allocation across architectural views
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 16 System Architectural Representation Elements of complete picture of a system architecture Function Task Objective Purpose Activity Role Mission Capability Principal Primary Application
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 17 System Architecture and Design Interface Definition
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 18 Product Family Engineering Requirements Variability with Architecting: Allocation Inheritance
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 19 Product Family Engineering Product Family: Team Behavior Never Delete IP Objects –May be shared by other projects –Use attributes to tailor out Apply all current projects to object, except yours –Add new IP at discretion, adding just your Project attribute Write IP with reuse in mind –Dont reference project name –Dont reference specific components of design –Dont make long lists in sentence form –Do bulletize, use tables, etc.
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 20 Product Family Engineering Product Family: Team Behavior Dont modify baselined objects –Current projects are already sharing that particular variation If possible, coordinate with all projects for enhancement Otherwise, –Copy current IP object –Apply changes to new object –Flag new object for your project –Flag old object for all other projects –Flag old object as obsolete
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 21 Product Family Engineering Product Family: Team Behavior Managing for reuse, not a salvage operation –Need a Product Family Manager - not a Project Manager Champion for product definition Keeper of the roadmap Enforcer of discipline Advocate for Product - better definition for all vs expedient definition for one
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 22 Product Family Engineering State of the Discipline Version Management –Sharing IP causes unique problems of version management When do you baseline shared data? How do you track changes within a project vs changes that may apply across several projects? Document Management Mentality vs. Architectural Models & Information Management –Management focus on paper products –Tool usage still document based
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 23 Product Family Engineering State of the Discipline Architecting –Limited tools Not addressing multi-dimensional views of architecture Not addressing interface standardization between views Not addressing relationship of requirements to architecture Not addressing component commonality vs. architectural adaptation
11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 24 Summary Product Family Engineering –Engineering products for an extended family of products –Products derived from a common basis –Custom tailoring for unique customer needs –Sharing Product IP - no Salvaging –Understanding variability & architecture
1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Software Re-use IS301 – Software.
An Introduction to Object Modeling An Introduction to Object Modeling The approach of using object modeling during systems analysis and design is called.
Operational Concepts and the Case for Use Cases Unifying UML with Systems Engineering Raymond W Jorgensen Rockwell Collins, Inc.
1 Computer Systems & Architecture Lesson 3 5. Designing the Architecture.
Software Process Modeling with UML and SPEM Chris Armstrong Armstrong Process Group
Systems Analysis and Design 8 th Edition Chapter 7 Development Strategies.
Architectural Design IS301 – Software Engineering Lecture # 14 – M. E. Kabay, PhD, CISSP Dept of Computer Information Systems Norwich University.
Nica Valentin–Danut SEM 2012 Service system fundamentals: Work system, value chain, and life cycle.
Chapter - 5 Understanding Requirements Unit II. Introduction Definition : “The broad spectrum of tasks and techniques that lead to an understanding of.
ISBN Prentice-Hall, 2006 Chapter 1 What is Software Engineering? Copyright 2006 Pearson/Prentice Hall. All rights reserved.
Chapter 17 Component-based software engineering Lecture 1 1Chapter 17 Software reuse.
IBM Rational Requirements Management Tools Achieving better control over your requirements.
ACHIEVING COMPLEX SYSTEMS UNDERSTANDING THROUGH THE USE OF MBSE-CENTRIC ANALYTICS Christopher Oster Lockheed Martin Advanced Technology Labs Company Logo.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 1 Chapter 29 Configuration Management.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 1 Chapter 14 Design with Reuse.
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 10 Object-Oriented Analysis and Modeling Using the UML.
Lecture 6 Conceptual Design Brainstorming Card sort Semantic networks Personas Scenarios, flowcharts and cognitive walkthroughs Both of these are excellent.
1 LECTURE 9 Amare Michael Desta Decision Support & Executive Information Systems:
J0 1 Marco Ronchetti - Basi di Dati Web e Distribuite – Laurea Specialistica in Informatica – Università di Trento.
IT203 Unit 2: Gather Information and Define Requirements Gathering Information Copyright © 2012 Pearson Education, Inc. Publishing as Prentice HallChapter2.1.
Page 1 R Copyright © 1997 by Rational Software Corporation Analysis and Design with UML.
1 Test documentation and Test case design Iana Mourza QA Lead/Release Lead VMware, Inc
1 Week 2 The Object-Oriented Approach to Requirements.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Systems Engineering 1Version 1.0 – October 18, 2005 Systems Architecting An introduction.
Data Architecture at CIA Dave Roberts Chief Technical Officer Application Services, CIO CIA
© 2005 by Prentice Hall Chapter 6 Determining System Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph.
1419 West Main Street Richmond, Virginia ©2010 CapTech Ventures The Business End of Data Modeling Bob Lambert.
© 2016 SlidePlayer.com Inc. All rights reserved.