工程
工程过程域包括了分享过程规则的开发和维护活动。工程过程域使用了一般的工程术语来书写，所以任何包含于产品开发过程中的技术规则都能使用它们用于过程改进。
工程过程域也将与不同的过程规则相关的过程整合到一个单独的产品开发过程，用于支持一个面向产品的过程改进策略。这样的策略重点在于必要的商业目标而非特定的技术规则。过程方法有效的避免了组织的“烟囱”思维倾向。
工程过程域适用于开发领域（如：软件产品、硬件产品、服务或过程）中任何产品或服务的开发。
IPPD的技术基础建立在一个完备的系统之上，系统具有贯穿于产品生命期各阶段的工程方法。工程过程域提供这一技术基础。IPPD的实现通过扩大到重点放在并行开发和产品生命期各阶段的工程过程域上的特殊实践来进一步的确定。
CMMI的工程过程域包括：
l 需求开发
l 需求管理
l 技术方案
l 产品集成
l 验证
l 确认
图4.5给出了这6个过程域之间相互关系的鸟瞰图。
需求开发过程域识别客户需求并将这些需求转换为产品需求。通过对这些产品需求的分析来产生一个高级概念解决方案。之后将这些需求分派以建立一组初始的产品组件需求。其他帮助定义产品的需求来自并分派给了产品组件。产品和产品组件需求清楚的描述了产品的行为、设计特性、必要性验证，并且进一步的座位开发者理解和使用的依据。
需求开发过程域为技术方案过程域提供了需求，技术方案过程域则将需求转化为产品架构、产品组件设计和产品组件（如编码和制作）。需求也是产品集成过程域的提供者，在该过程域中合并了产品组件并且验证界面以确保组件符合需求开发过程域中的界面需求。
需求管理过程域用于维护需求。它描述了那些获取和控制需求变化以及确保其他相关的计划和数据保持更新的活动。它确保了需求从客户到产品再到产品组件的可追溯性。
需求管理确保确保需求的变化在项目计划、活动和工作产出中得到反映。这一变化周期可能会影响其他所有的工程过程域，然而，需求管理是一个动态的而且经常是递归的时间序列。需求管理过程域是一个可控的和有规律的工程设计过程的基础。
技术方案过程域为产品集成或供应商协议管理过程域用到的产品组件开发技术数据包。在选择基于确定标准的最优设计的目的下对各种方案进行检查。这些标准在产品、产品类型依赖、操作环境、操作需求、支持需求和费用或发布进度之间可能有相当大的差异。选择最终方案的任务用到了在因果分析和解决方案过程域中的特定实践。
技术方案过程域对用于在设计和最终构建之前执行设计验证和同级评审的确认过程域有依赖。
确认过程域确保选择的工作产品符合规定的需求。确认过程域选择工作产品和用于确认工作产品和规定的需求的确认方法。确认一般是一个递增的过程，从产品组件确认开始并且经常结束于对完全的产品装配的确认。
确认也存在于同级评审。同级评审是一种用于提前消除过失和对工作产品和开发和维护的产品组件提供有价值的看法的证明方法。
验证过程域递增的验证产品和客户需求。验证可能在操作环境或模拟的操作环境中进行。在验证需求上与客户的协作是这一过程域的重要元素。
验证过程域的范围包括产品、产品组件、选择的中间工作产品和过程的验证。这些验证的元素可能经常要求重新确认和重新验证。在验证中发现的问题通常在需求开发或技术方案过程域中得到解决。
产品集成过程域包含了与产生最可能的集成序列、集成产品组件和向客户发布产品有关的特定实践。
产品集成用到了对产品集成过程实现的确认和验证。确认实践确认接口和先于产品集成的产品组件的接口需求。这在集成过程中是必须的。在操作环境中的产品集成过程中也用到了验证过程域的特定实践。
工程过程域中的递归和迭代
大部分过程标准同意过程的提供存在两种方式。即：递归和迭代。
递归发生在一个过程在系统结构中应用于系统元素的后继级别的时候。一项应用的成果用于系统结构下一个级别的输入。例如，确认过程设计用于整个装配的产品、主要的产品组件，甚至还有组件的组件。你在产品中应用确认过程的深度整体上依赖于最终产品的大小和复杂度。
迭代发生在过程在同一个系统级别上重复的时候。新的信息通过反馈给相关过程的一个过程的实现来创建。这一新信息代表性的提出了在完成过程之前必须解决的问题。过程的再应用能够解决这些问题。迭代能在应用下一个过程之前确保质量。
工程过程（如需求开发和确认）在一个产品上反复实现以确保这些工程过程在交付给客户之前能充分的执行。工程过程进一步的应用于产品组件。例如，一些通过与确认和验证过程域相关的过程提出的问题可以通过与需求开发和产品集成过程域相关的过程来解决。这些过程的递归和迭代使项目能在交付给客户之前确保产品中所有组件的质量。
Engineering process areas cover the development and maintenance activities that are shared across engineering disciplines. The Engineering process areas were written using general engineering terminology so that any technical discipline involved in the product development process (e.g., software engineering or mechanical engineering) can use them for process improvement.
The Engineering process areas also integrate the processes associated with different engineering disciplines into a single product development process, supporting a product-oriented process improvement strategy. Such a strategy targets essential business objectives rather than specific technical disciplines. This approach to processes effectively avoids the tendency toward an organizational “stovepipe” mentality.
The Engineering process areas apply to the development of any product or service in the development domain (e.g., software products, hardware products, services, or processes).
The technical foundation for IPPD is grounded in a robust systems engineering approach that encompasses development in the context of the phases of the product’s life. The Engineering process areas provide this technical foundation. The implementation of IPPD is further addressed through amplifications to specific practices in the Engineering process areas that emphasize concurrent development and focus on all phases of the product’s life.
The Engineering process areas of CMMI are as follows:
· Requirements Development
· Requirements Management
· Technical Solution
· Product Integration
· Verification
· Validation
Figure 4.5 provides a bird’s-eye view of the interactions among the six Engineering process areas.
Figure 4.5: Engineering Process Areas
The Requirements Development process area identifies customer needs and translates these needs into product requirements. The set of product requirements is analyzed to produce a high-level conceptual solution. This set of requirements is then allocated to establish an initial set of product component requirements. Other requirements that help define the product are derived and allocated to product components. This set of product and product component requirements clearly describes the product’s performance, design features, verification requirements, and so forth, in terms the developer understands and uses.
The Requirements Development process area supplies requirements to the Technical Solution process area, where the requirements are converted into the product architecture, the product component design, and the product component itself (e.g., coding and fabrication). Requirements are also supplied to the Product Integration process area, where product components are combined and interfaces are verified to ensure that they meet the interface requirements supplied by Requirements Development.
The Requirements Management process area maintains the requirements. It describes activities for obtaining and controlling requirement changes and ensuring that other relevant plans and data are kept current. It provides traceability of requirements from customer to product to product component.
Requirements Management ensures that changes to requirements are reflected in project plans, activities, and work products. This cycle of changes may affect all the other Engineering process areas; thus, requirements management is a dynamic and often recursive sequence of events. The Requirements Management process area is fundamental to a controlled and disciplined engineering design process.
The Technical Solution process area develops technical data packages for product components that will be used by the Product Integration or Supplier Agreement Management process area. Alternative solutions are examined with the intent of selecting the optimum design based on established criteria. These criteria may be significantly different across products, depending on product type, operational environment, performance requirements, support requirements, and cost or delivery schedules. The task of selecting the final solution makes use of the specific practices in the Decision Analysis and Resolution process area.
The Technical Solution process area relies on the specific practices in the Verification process area to perform design verification and peer reviews during design and prior to final build.
The Verification process area ensures that selected work products meet the specified requirements. The Verification process area selects work products and verification methods that will be used to verify work products against specified requirements. Verification is generally an incremental process, starting with product component verification and usually concluding with verification of fully assembled products.
Verification also addresses peer reviews. Peer reviews are a proven method for removing defects early and provide valuable insight into the work products and product components being developed and maintained.
The Validation process area incrementally validates products against the customer’s needs. Validation may be performed in the operational environment or in a simulated operational environment. Coordination with the customer on the validation requirements is an important element of this process area.
The scope of the Validation process area includes validation of products, product components, selected intermediate work products, and processes. These validated elements may often require reverification and revalidation. Issues discovered during validation are usually resolved in the Requirements Development or Technical Solution process area.
The Product Integration process area contains the specific practices associated with generating the best possible integration sequence, integrating product components, and delivering the product to the customer.
Product Integration uses the specific practices of both Verification and Validation in implementing the product integration process. Verification practices verify the interfaces and interface requirements of product components prior to product integration. This is an essential event in the integration process. During product integration in the operational environment, the specific practices of the Validation process area are used.
Most process standards agree that there are two ways that processes can be applied. These two ways are called recursion and iteration.
Recursion occurs when a process is applied to successive levels of system elements within a system structure. The outcomes of one application are used as inputs to the next level in the system structure. For example, the verification process is designed to apply to the entire assembled product, the major product components, and even components of components. How far into the product you apply the verification process depends entirely on the size and complexity of the end product.
Iteration occurs when processes are repeated at the same system level. New information is created by the implementation of one process that feeds back into a related process. This new information typically raises questions that must be resolved before completing the processes. For example, iteration will most likely occur between requirements development and technical solution. Reapplication of the processes can resolve the questions that are raised. Iteration can ensure quality prior to applying the next process.
Engineering processes (e.g., requirements development or verification) are implemented repeatedly on a product to ensure that these engineering processes have been adequately addressed before delivery to the customer. Further, engineering processes are applied to components of the product. For example, some questions that are raised by processes associated with the Verification and Validation process areas may be resolved by processes associated with the Requirements Development or Product Integration process area. Recursion and iteration of these processes enable the project to ensure quality in all components of the product before it is delivered to the customer.
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
