Upstream and downstream influences on system architecture

Publish in

Engineering

143 views

Please download to get full document.

View again

of 54
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Description
This presentation is to review of chapter 10 in the book of system architecture. It contains the explanation of upstream and downstream influences on system architecture in complex system development. It intends to share the knowledge derived from the insightful book published in May 2015 from specialists working in MIT System Design Management Division
Transcript
  • 1. 4th July, 2016 / Jinwon Park (jwpark1@gmail.com) System Architecture Chapter 10. Upstream and Downstream Influences on System Architecture
  • 2. MV Blue Marlin: Float-On / Float-Off (FLO-FLO) ship * 270m x 42mx13.3m, 56000tons, 14.5kts(cruise) / 25000nm, 1999 - 4
  • 3. Eli’s Goliat Platform: The Largest Oil Rig in the World * Diameter abt. 107m, a staff of 120, 14 anchor lines and 22 wells including 11 producers, builder: HHI(2015), owner: Eni (Norway) 5
  • 4. Norway’s Dragon Oil Platform * A depth of 250m, owner: AS Norke Shell 6
  • 5. Contents 7
  • 6. Terms
  • 7. System 조직화된 전체(Organized Whole)라는 그리스어(Systema)에서 유래(1603~) * Merriam-Webster Dictionary, ISO/IEC 15288, MIL-STD-499B, etc. 목적 달성을 위해 상호작용하는 요소(사람, 제품, 프로세스)의 집합체 * Von Bertalanffy (1901-1972), Biologist, one of the pioneers of the ‘general systems theory’ “Whole compounded of several parts or members, system” 9
  • 8. Big picture of System: ‘구조’가 행태를 결정하고 형태가 ‘구조’를 변화시킨다. * 김동환, ‘시스템사고, 시스템으로 생각하기’, pp. 64-, 선학사, 2004 시스템은 하나 또는 그 이상의 명시적인 속성(Property)이나 기능(Function)을 가지고 있다. 각 구성요소(Component)는 전체의 행태(Behavior)나 속성(Property)에 영향을 미친다. 부분이나 구성요소들은 상호작용(Interactive)하며, 상호의존(Interdependent) 관계이다. 시스템은 자신의 명시적인 기능을 수행하기 위해 어떤 환경적 조건을 필요로 한다. * 이준형, ‘시스템의 이해’, 인하대학교 출판부, 2000) 10
  • 9. Architecture 건축물이나 다른 물리적 구조물을 “계획하고, 설계하며 공사하는 절차와 산출물”로 라틴어 ‘Architectura’, 그리스어 ‘Arkhitekton’에서 유래됨 * https://en.wikipedia.org/wiki/Architecture 건축물이나 다른 물리적 구조물을 설명하는 일반적인 용어 건축물과 다른 비건축 구조물을 설계하는 예술과 과학 건축물과 다른 물리적 구조물을 제작하는 방법과 설계 스타일 예술, 과학, 기술과 인문학에 대한 지식 건축물의 설계나 환경을 조성하는 것과 관련된 전문 서비스를 제공하는 건축가의 실무 매크로 수준에서 마이크로 수준으로 실행하는 아키텍터의 설계활동 A general term to describe buildings and other physical structures The art and science of designing buildings and (some) nonbuilding structures The style of design and method of construction of buildings and other physical structures Knowledge of art, science, technology and humanity The practice of the architect, where architecture means offering or rendering professional services in connection with the design and construction of buildings, or built environments The design activity of the architect, from the macro-level (urban design, landscape architecture) to the micro-level (construction details and furniture) 12
  • 10. 제약사항과 요구조건을 충족시키기 위해 필요한 시스템 요소들의 구조, 배치 또는 배열과 내 부적 관계 물리적 블럭내에 기능적 요소들의 배치 시스템 요소와 요소들간의 관계에 대한 개념적인 표현 요소들과 주변 환경간의 인터페이스 정의와 구조요소들에 대한 개념의 구현과 물리적/정보적 기능의 할당 일반공학적 측면에서의 ‘아키텍처(Architecture)’ 정의 The Structure, Arrangements or configuration of system elements and their internal relationships necessary to satisfy constraints and requirement (Alfred Frey, 1903-1998, American Architect) The Arrangement of the functional elements into physical blocks (Ulrich, Eppinger, Professor at UPenn, 1961-, American engineer and professor at MIT) An abstract description of the entities of a system and the relationship between those entities (Crawley et al.) The embodiment of concept, and the allocation of physical/informational function to elements of form to elements of form, and definition of interfaces among the elements and with the surrounding context. (Crawley) 아키텍처는 개념(Related by concept)을 구현하기 위해 기능(Function)을 형식(To form)에 할당하는 추상적 표현으로 이해할 수 있음 Concept vs. Architecture ✤ Concept은 작동원리, 형태의 추상성, 기능에서 형 태로의 매핑을 포함하는 프로젝트나 시스템의 비 젼, 아이디어 또는 심리적이미지(Mental image) ✤ Architecture는 기능에서 구조로의 할당, 인터페 이스와 구조의 정의에 대한 구체화된 결과물 * MIT ‘System Architecture’ ESD.34 Lecture 1/2, Ed Crawley January 11, 2007 Rev 2.0 13
  • 11. Front Elevation View Plan View Perspective View Building Codes Technical Standards View Front Elevation View Plan View Perspective View Building Codes Technical Standards View Physical view to an Architecture * Boeing, System Architecting - An Introduction, October 18, 2005 14
  • 12. Functional view to an Architecture * Boeing, System Architecting - An Introduction, October 18, 2005 15 1.0 Provide Space 2.0 Provide Nourishment 3.0 Provide Protection 4.0 Provide Comfort 5.0 Provide Communication & Entertainment Provide Human Habitat 1.1 Provide Access & Mobility 1.2 Provide Storage 1.3 Provide Living Space 1.2.1 Provide Vehicle Storage 1.2.2 Provide Object Storage 2.1 Provide Food and Drink 2.2 Provide Waste Disposal 3.1 Provide Physical Security 3.2 Provide Physical Protection 4.1 Provide Sleeping 4.2 Provide Climate 4.3 Provide Personal Cleaning 4.4 Provide Seating 5.1 Provide Video Entertainment 5.2 Provide Audio Entertainment 5.3 Provide Computing Entertainment 5.4 Provide Telephony
  • 13. Architect 건축 공사를 계획, 설계하고 감독하는 사람이라는 뜻으로 라틴어 ‘Architectus’, 그리스어 ‘Arkhi-tekton (Cheif-builder)’에서 유래됨 * https://en.wikipedia.org/wiki/Architect 건축외에도 Landscape architecture, naval architecture, software architecture에서도 사용됨 The Architect is not a generalist, but a specialist in sampling complexity, resolving ambiguity and focusing creativity * MIT ‘System Architecture’ ESD.34 Lecture 6, Ed Crawley January 11, 2007 Rev 2.0 Define the boundaries and function, create the concept, define the elements, interfaces and abstractions 16
  • 14. Architecting Architecting: word or not? http://www.cardinalsolutions.com/blog/2014/08/architecting_iot By Architect, derive architecture ? Being architect? 17
  • 15. Function and Form “Function is ‘what the system does’, Form is what the system is” Function은 Performance를 발생, 생성하거나 기여하는 활동, 운영과 변환을 포 함하며 Solution-neural language로 표현되어짐 (i.e., Function = Process + Operand) Form은 존재하거나 존재할 가능성이 있는 물리적/정보적 구현체로 요소들의 집합, 요소들간의 관계 즉 구조로 표현되어짐 (i.e., Form = Element + Structure, Form in the instrument of function) The physical/informational embodiment which exist, or has the potential to exist. The activities, operations and transformations that cause, create or contribute to performance (i.e. meeting goals) * MIT ‘System Architecture’ ESD.34 Lecture 1/2, Ed Crawley January 11, 2007 Rev 2.0 18
  • 16. System Architecture “A system architecture or systems architecture is the conceptual model that defines the structure, behavior, and more views of a system” 시스템아키텍처는 시스템의 구조와 거동, 그리고 관점을 정의하는 개념적인 모델 * Annu Jaakkola and Bernhard Thalheim. (2011) "Architecture-driven modelling methodologies." In: Proceedings of the 2011 conference on Information Modelling and Knowledge Bases XXII. Anneli Heimbürger et al. (eds). IOS Press. p. 98 아키텍처는 구조, 거동 및 배열의 영역을 다루어야 함 “Architectural design descriptions must cover the areas of structure, behavior, and layout” * Richard Stevens, et. al., “Systems engineering coping with complexity”, p. 92, Prentice Hall Europe 1998 System structure: 주요 구성품들이 어떻게 분해되고 조직 되었는지, 구성품들의 기능과 인터페이스 그리고 요구조 건과의 관계성 등을 기술 (e.g., diagrams, hierarchies) System behavior: 시스템의 목적과 관련된 Event에 대한 시스템의 동적반응을 나타냄(e.g., Functional block diagrams) System layout: 물리적인 배치, 패키징, 설계의 배치특성 등 (e.g., reports, drawings, etc.) 19
  • 17. Naval Architecture Naval architecture also known as naval engineering, is an engineering discipline dealing with the engineering design process, shipbuilding, maintenance, and operation of marine vessels and structures 조선공학은 공학설계, 선박건조, 선박과 해양구조물의 운영 및 유지를 다루는 공학분야(Engineering discipline) * https://en.wikipedia.org/wiki/Naval_architecture Naval Engineering can be said an activity of ‘Naval Architecting’? Why not? 20
  • 18. Boundaries, values, functions, forms Product/supporting systems, use context, boundaries, interfaces Principal internal functions, form decomposition, functions to forms, etc. Process sequence, operation modes, etc. Architecting Framework * MIT ‘System Architecture’ ESD.34 Lecture 6, Ed Crawley January 11, 2007 Rev 2.0 21
  • 19. The Role of the Architect
  • 20. 모호성 감소(Reduce ambiguity): Define the boundaries, goals, and functions of the system ✤ Interpreting corporate and functional strategies ✤ Interpreting competitive marketing analysis ✤ Listening to users, beneficiaries, customers, or their representatives ✤ Considering the competence of the enterprise and its extended supply chain ✤ Considering the operations and operational environment of the system ✤ Infusing technology where appropriate ✤ Interpreting regulatory and pre-regulatory influences ✤ Recommending standards, frameworks, and best practices ✤ Developing goals for the system based on the upstream influences 창의성 도입(Employ creativity): Create the concept ✤ Proposing and developing concept options ✤ Identifying key metrics and drivers ✤ Conducting highest-level trades and optimization ✤ Selecting a concept to carry forwards, and perhaps a backup ✤ Thinking holistically about the entire product life cycle ✤ Anticipating failure modes and plans for mitigation and recovery 복잡성 관리(Manage complexity): Choose a decomposition of the system ✤ Decomposing form and function ✤ Clarifying the allocation of functionality to elements of form ✤ Defining interfaces between subsystems and the surrounding context ✤ Configuring the subsystems ✤ Managing flexibility vs. optimality, Defining the degree of modularity ✤ Articulating vertical vs. horizontal strategies ✤ Balancing in-house vs. outsourcing design and manufacturing, Controlling product evolution 아키텍터의 역할(The role of the architect) * Edward Crawley et al., ‘System Architecture’, Chapter 9, PEARSON, 2016 23
  • 21. Objectives of Chapter 10. Upstream and Downstream Influences on System Architecture
  • 22. Which influences will meaning fully reduce ambiguity? Which influences will help us select among candidate architectures? To answer questions about the magnitude of the impact of each of the influences (e.g., will marketing affect whether the car is two-wheel or four-wheel drive?) What upstream influences impact architectural decisions? Figures/Tables, Design Structure Matrix, Decision Tree, Trade-off study, Cost, etc. * Edward Crawley et al., ‘System Architecture’, Chapter 10, PEARSON, 2016 25
  • 23. Brief view of Upstream/downstream influences
  • 24. * Edward Crawley et al., ‘System Architecture’, Chapter 10, PEARSON, 2016 Corporate Strategy Marketing Regulation Technology Infusion Upstream Influences Downstream Influences Implementation Operations Design for X Product Evolution SYSTEM ARCHITECTURE 27
  • 25. Upstream influences Upstream Influences Corporate Strategy Marketing Regulation Technology Infusion
  • 26. Corporate Strategy 아키텍처에 대한 가장 기본적인 상부영향은 조직의 전략(Strategy of Enterprise) 기업환경: 수익율 증대, 경쟁력 있는 주주가치 형성 등의 기업목표 정부환경: 기관이 임무를 달성하기 위해 요구되는 수단으로 정의 전략은 조직의 특정활동(Specific activities)을 정의하는 것임 조직의 임무, 활동범위, 장기/중장기 목표, 자원활용결심 및 계획된 이니셔티브 효과적인 기업전략은 이해관계자/팀과 함께 비젼과 방향성을 공유하는 가장 중요한 수단이며, 안전자산(Scarce resources) 투자에 대한 가이드로 작용함 기술기업에서 시스템아키텍처와 기업 전략간에는 상당한 상호영향이 존재함 IBM: 25년간 OS(운영체계)는 마이크로스프트(MS)로부터 아웃소싱하여 데스크탑PC 시장 형성 Airbus: 자사 A319~321 항공기에 공통조종실(Common glass cockpit) 설계 적용으로 훈련 및 유지 비용 절감을 통해 공통화(Commonality)에 따른 장점을 고객에게 제공함 * Edward Crawley et al., ‘System Architecture’, pp. 212-214, Chapter 10, PEARSON, 2016 29
  • 27. Upstream Influences Corporate Strategy Marketing Regulation Technology Infusion Shareholder annual report corporate strategy Executive corporate strategy Business unit strategy Functional strategies 기업의 장기목표, 실행프로그 램, 자원활동 우선순위 등. 실제 목표달성을 위해 어떤 활 동을 해야하는 지에 대한 구체 적 정보는 미제공 핵심사업영역 정의, 지속가 능한 경쟁력 개발을 위한 투 자수단 명시 등. 기업의 철학과 주주기대 정 의, 사업세분화, 사업추세 분 석 등 포함 예) BMW to exit F1 in 2009 사업부, 시장, 지역 또는 기술별로 구체화됨. 아키텍터는 환경, 우선순 위, 결심 및 투자프로세스 등을 이해하기 위해 BUS 에 친밀해야 함 예) BMW i sub-brand 마케팅, R&D, 제조/아 웃소싱 등. 각 기능부분 들이 기업목표 달성을 위해 어떻게 해야하는 지를 기술함. * Edward Crawley et al., ‘System Architecture’, pp. 212-214, Chapter 10, PEARSON, 2016 30
  • 28. Impactful relationships between aspects of strategy and architecture * Edward Crawley et al., ‘System Architecture’, pp. 214-215, Chapter 10, PEARSON, 2016 1. Mission and Scopes 아키텍처는 기업의 임무와 이해관계자 요구를 직접적으로 나타내야함. 기업전략에 정의된 영 역(Scope)을 반영하여야 하며, 특히 배제되어질 활동도 반영되어야 함 2. Enterprise Goals 아키텍처는 수익, 마진과 투자수익율을 위한 회계목표 달성에 기여하거나 충족해야하며, 회 사의 성장을 지원해야함. 기술적 지향점과 브랜드 전략에 대해서도 기술할수 있음. 아키텍터는 회사의 핵심역량에 기반한 제품생산을 계획하여야 하며 핵심역량 확장을 위한 지 원 또는 다른 회사와의 협력을 위한 계획을 수립해야 함. 3. Resource Allocation Decisions 아키텍처의 개발은 자원할당지침에 따라 수행되어야 하며, 아키텍터는 결심프로세스와 자원 할당 방어(Defend) 방안에 대해 이해하여야 함 4. Initiatives and Action Plans 아키텍처는 가능한 경우 회사의 이니셔티브와 기능전략간에 영향력을 행사하여야함. 아키텍처는 새로운 기능전략 수립의 중심 역할을 할수 있으며, 이니셔티브와 실행계획을 복 잡하게 만드는 제약사항을 다루어야 함. 31
  • 29. Marketing 아키텍터는 마켓팅과 제품개발조직간에 간극을 줄이는데 있어 핵심역할을 수행함 * Edward Crawley et al., ‘System Architecture’, pp. 215-216, Chapter 10, PEARSON, 2016 마켓팅의 일반적 정의 “Creating, communicating and delivering value to customers, and … managing customer relationships in ways that benefit the organization and its stakeholders” * Upstream function by the creation of value, and Downstream delivery => Inbound/outbound marketing Inbound/outbound marketing as seen by the architecture Inbound marketing 사용자의 요구(User needs) 를 발견하는 과정으로 마켓 팅영역에서는 Product development라고 불림. 아키텍터의 관심영역 Outbound marketing 고객의 요구(Consumer needs) 를 만족시키는 과정으로 일반적 으로 마켓팅이라 불리는 영역 Downstream 제품개발과 Upstream 요소간의 필수적인 상호작용 없는 마케팅은 오류 중 하나 성공적인 아키텍터는 시장전략과 아키텍처 개발간에 밀접한 관계를 가지도록 함 32
  • 30. Interaction between marketing and system architecture is critical, especially for inbound marketing * Edward Crawley et al., ‘System Architecture’, p. 217, Chapter 10, PEARSON, 2016 1. Stakeholders and Their needs 아키텍처는 이해관계자의 요구를 이해함으로써 형태를 갖춤. 2. Segmentation of Markets, Market sizing, Penetration 아키텍터는 실제 고객커뮤니티를 반영하는 시스템 요구조건을 개발하기 위해 시장세분화를 깊이있게 이해하여야 함. 제품에 대한 예측된 시장 규모는 이윤 예측에 크게 영향을 줌 시장진입 시점은 시장(Market)에서 아키텍처의 안정성(How stable)을 크게 변화시킬수 있음 3. Competitors and Competing Products 아키텍터는 성공적인 경쟁기반을 조성하기 위해 경쟁시스템에 대한 최고로 가용한 예측치 (Best possible estimate)를 만들어내야 함. 4. Outbound Marketing 아키텍터는 제품의 이윤을 정의하고, 아키텍터는 마케팅과 고객과의 소통계획 및 공급채널에 따른 제품정의 위한 계획 이해 33
  • 31. Regulation * Edward Crawley et al., ‘System Architecture’, pp. 218-219, Chapter 10, PEARSON, 2016 규제는 경쟁에 따른 이점(Competitive advantages)과 시장장벽으로 공히 작용할수 있음 규제의 명확한 영향은 아키텍처와 제품 설계에 있어서 그것의 실행임 2015년까지 미국내 자동차에 백업카메라의 의무적 설치, 의료장치에서의 재질(Material) 규제 규제는 국제규정은 물론 미국의 경우 연방/주정부/시 수준에서 요구됨 고객보호, 작업장내 인력안전 기준 수립, 환경보호, 산업정책 실행, 민감자료 유출 방지(ITAR) 등 Regulation Compliance (준수) Anticipated regulation Awareness (인식) Standards Alignment (추종) Liability Compliance with Enterprise procedure The level of engagement with the Architecture by regulation and pseudo-regul. 아키텍터는 현재 규제뿐만 아니라 향후 예상되는 규제를 예측하고 관리하여야 함. 적용시의 이익과 벌금간의 평가, 규제관련 기업전략을 이해하여 적용범위 판단, 규제에 따른 제품개발에 관련된 가이드라인 제공 등 34
  • 32. Technology Infusion * Edward Crawley et al., ‘System Architecture’, pp. 220-221, Chapter 10, PEARSON, 2016 아키텍터의 핵심역할 중 하나는 아키텍처에 새로운 기술을 적용할 것인지? 어떻게 제품에 적용할 것인지를 결정하는 것임 기술적용과 관련되어 아키텍터에 의해 제기되어야 하는 질문: Will the technology be ready for infusion? 예) Technology Readiness Level (TRL) Will this technology actually create additional value from the perspective of the customer and other stakeholders? ✤ Comparative analysis: New technology versus those without the technology Will this technology be effectively transferred into the product or system? 기업의 기술개발팀과 일하는 아키텍터의 역할은 효과적인 지식전달 원리를 개발하고 새로운 기술을 제품에 성공적으로 적용하도록 지원하는 것 35
  • 33. Downstream influences Downstream Influences Implementation Operations Design for X Product Evolution
  • 34. Implementation * Edward Crawley et al., ‘System Architecture’, pp. 223-224, Chapter 10, PEARSON, 2016 Coding, Manufacturing, and Supply Chain Management 아키텍터는 제품개발 실행과정(Implementation process)에 대해 이해 필요 Design for Implementation Work with implementers from early 아키텍터는 실행 가능토록 설계하여야 하며 개발초기부터 실행자와 함께 작업을 하여야 함 실행은 아웃소싱, 실행자금계획, 계획/착수, S/W 개발 및 시험, H/W 제작 및 품질관리, 공급망 관리, 시스템통합, 시스템 수준 시험, 인증 등을 포함함 아키텍터 관점에서 핵심실행결심은 “구매할 것인가? 자체 제작할것인가?”의 판단 자사에서 또는 외부공급자 능력내에서 제품을 구현할 것인가? 자사가 가진 핵심실행 능력내에서 가능한 일인가? 자사가 전체 시스템을 제작할 실행능력을 가지고 있는가? 또는 실행능력을 자체적으로 개발하기를 원하는가? 등 37
  • 35. * Edward Crawley et al., ‘System Architecture’, pp. 223-224, Chapter 10, PEARSON, 2016 만일 주요공급자가 참여하게 된다면 아키텍터는 아래 두가지 질문에 직면하게됨 공급자를 얼마나 빨리 개발과정 참여시킬 것인가? 아키텍처 분해에 있어 공급자의 영향을 어떻게 취급할 것인가? Key supplier 아키텍터는 초기에 실행팀에 포함되어야 하며, 제작/구매(make/buy) 결심에 참여 하여야 하며, 아키텍팅 과정에 있어 공급자의 참여 시점을 주의깊게 결정해야 함. 아키텍터의 최종 실행이슈는 공급망(Supply chain)의 변동성(dynamics)을 다루 어야함 실행시스템은 거대하며 많은 조정이 필요한 사항(종종 불완전한 정보와 함께)이 있음 아키텍터는 공급망 관리가 첫제품의 시장출시와 같은 많은 시점결심(Timing decision)에 영향 을 주기 때문에 관련사항을 이해하기 위해 준비되어져야 함 38 공급자를 실행 초기에 참여시킬 경우 아래의 장점과 단점을 동시에 가질수 있음 장점 : 더 많은 기술과 실행경험에 대한 접근 제공 단점 : 공급자가 아키텍처에 자사의 제품을 위한 영향을 초기부터 줄수 있음(hard boundary and influence on decomposition)
  • 36. Operations * Edward Crawley et al., ‘System Architecture’, p. 224, Chapter 10, PEARSON, 2016 아키텍터는 시스템이 직면하게 될 운영관련 폭 넓은 이슈를 이해하는 것이 중요함 예) Commissioning은 음식물 구입/요리/테이블 세팅, Primary value는 저녁식사 자체, Decommissioning은 설거지/테이블정리, 식기 정리 등을 의미함 39
  • 37. * Edward Crawley et al., ‘System Architecture’, pp. 225-226, Chapter 10, PEARSON, 2016 Operation framework Get Ready: 시스템 설치 Transporting, connecting, powering up, initializing, etc. Fueling, starting, loading, adjusting, etc. Get Set: 시스템 준비(Every time) Primary value, Secondary value, contingent, emergency, stand-alone, etc. Go: 작동 Unloading, regular inspection, etc. Get Unset: 작동완료(post-operation) Terminating, disconnection, depowring, storing, etc. Get Unready: 작동정지(long storage) Inspecting, calibrating, repairing, overhauling, updating, etc. Fix: 정비(regular or event-driven maintenance) ✤ Contingent: 주기능 손실, 인명/장비 피 해 없는 비정상운영 상태 ✤ Emergecy: Contingent외 비정상운영 상태 ✤ Stand-alone: 시스템 시험, 망분리 등 40
  • 38. Design for X * Edward Crawley et al., ‘System Architecture’, pp. 226-228, Chapter 10, PEARSON, 2016 A Series of Design Guidelines Safety, Quality, Reliability, Flexibility는 1880년대 이후 꾸준히 증가 1950년대 즈음 대두된 Modularity, Maintainability는 꾸준히 증가 추세 1960년대 이후 Testability, Scalability, Interoperability, Sustainability가 급격히 증가 추세 * 저널논문에 언급된 빈도수로 정리 41
  • 39. Product and System Evolution, and Product Families * Edward Crawley et al., ‘System Architecture’, pp. 228-231, Chapter 10, PEARSON, 2016 많은 복잡시스템이나 제품 개발시 아래의 재사용, 제품라인, 플랫포밍, 모듈화 등에 대한 고려 없어 취급됨 Reuse, Legacy, product extensions Product lines, preplanned product improvements Product platforms, modularity, commonality, standardization Reuse and Legacy Elements Product Lines Platforming and Architecture 42 지금까지 백지에서 출발하는 아키텍처 정의에 논하였지만 실제 백지에서부터 시 작하는 아키텍팅은 없으며 현실적으로 불가능한 사항임
  • 40. * Edward Crawley et al., ‘System Architecture’, p. 229, Chapter 10, PEARSON, 2016 Reuse and Legacy Elements (재사용 및 기존요소) 모든 시스템은 기존요소의 재사용(Reuse)을 고려함 재사용은 기존설계시 향후 재사용하도록 계획되어 설계되지는 않은 부분이나 신규설계시 이 를 모듈로 채용하는 개념임 예) 부속품, 컴퓨터 코드, 우주왕복선의 로켓모터 재사용 등 등 재사용은 다음과 같은 장단점이 있음 ✤ 비록 체계통합이나 개조비용은 일부 필요할 수 있으나 개발비용의 상당 부분이 이미 지불되었음 ✤ 개발도구/공구에 대한 비용이 이미 지불되었음 ✤ 성능 특성이 잘 알려져 있음 ✤ 단점: 기존요소를 재사용 할 경우 요소가 원래 가진 제한사항을 피할수 없음 (예. 네트워크 버스 재사용시 데이터 전송율 제한) 재사용은 원래 설계(Original design)에서 계획하지 않았던 장비나 모듈의 공유를 의미하 나, Platforming(after 2 slides)는 설계단계에서부터 의도적인 공유를 계획하는 것임 43
  • 41. * Edward Crawley et al., ‘System Architecture’, p. 229, Chapter 10, PEARSON, 2016 Product Lines (제품 라인) 제품라인(Product lines) 또는 제품군(Product families)은 제품 그룹과 관계됨 ✤ 제품군은 기본 구성품 또는 아키텍처를 필수적으로 공유하지는 않음 ✤ 유사한 제품명을 가질수 있으며 마켓팅 목적으로 외부형상을 계층화(stratify) 할수 있음. 재사용과 유사하게 제품군 확대 범위는 예측하기가 어려움 (예. 철로(안정), 모바일폰(불확실)) 아키텍터는 설계 과정 중 미래 모듈성(Modularity) 보장 위해 추가적인 인터페이스를 고려 하는 것과 같은 옵션을 고려해야 함 ✤ Best Practice는 High-clockspeed 쪽에 계획되지 않은 진화가 발생할 것이라는 가정하에 Slow와 Fast 변화요소간의 인터페이스를 정의하는 것임 Slow-clockspeed evolution High-clockspeed evolution 44
  • 42. * Edward Crawley et al., ‘System Architecture’, p. 229, Chapter 10, PEARSON, 2016 Platforming and Architecture 플랫포밍은 제품내 또는 제품간에 부품과 프로세스를 계획적으로 공유하는 것임 ✤ 아키텍터는 어떤 파트나 모듈이 사용되어질 모델을 예상하여 공통파트나 모듈 개발 노력 필요 ✤ 재사용과 달리 아키텍터는 적용되어질 제약사항을 선택할수 있으며 향후 적용시의 불확실성을 미리 다루어야 함 플랫포밍은 주요 장점중 하나는 제품간의 비용 공유(Cost sharing)임 * Volkswagens’ A Platform (VW Jetta, Audi TT, Seat Toledo), Joint Strike Fighter (F-35A/B/C) ✤ 개발비용(Development cost) 절감, 제조원가(Labor hours) 감소, 재고율(Safety stock level) 저하 등 http://www.f1technical.net/forum/viewtopic.php?t=12881 http://w
  • Related Search

    Previous Document

    kalpakjian 3

    Next Document

    Kartul Medis Cover

    Related Documents
    View more...
    We Need Your Support
    Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

    Thanks to everyone for your continued support.

    No, Thanks