3.

2 INCOSE Object-Oriented Systems Engineering Method (OOSEM)

3.2.1. Overview
The Object-Oriented Systems Engineering Method (OOSEM) integrates a top-down, model-based approach that uses OMG SysML to support the specification, analysis, design, and verification of systems. OOSEM leverages object-oriented concepts in concert with more traditional top down systems engineering methods and other modeling techniques, to help architect more flexible and extensible systems that can accommodate evolving technology and changing requirements. OOSEM is also intended to ease integration with object-oriented software development, hardware development, and test. OOSEM evolved from work in the mid 1990s at the Software Productivity Consortium (now the Systems and Software Consortium) in collaboration with Lockheed Martin Corporation.7 The methodology was applied in part to a large distributed information system development at Lockheed Martin that included hardware, software, database, and manual procedure components. INCOSE Chesapeake Chapter established the OOSEM Working Group in November 2000 to help further evolve the methodology.8 OOSEM is summarized in various industry and INCOSE papers [35],[36],[37], and more recently, in the forthcoming book entitled Practical Guide to SysML: Systems Modeling Language by Fridenthal, Moore, and Steiner [38]. An introduction to the methodology is also available as a full day tutorial [39]. The OOSEM objectives are the following: Capture and analysis of requirements and design information to specify complex systems. Integration with object-oriented (OO) software, hardware, and other engineering methods. Support for system-level reuse and design evolution. As stated above, OOSEM is a hybrid approach that leverages object-oriented techniques and a systems engineering foundation. It also introduces some unique techniques as indicated in see Figure 3-6. The OOSEM supports a SE process as illustrated in Figure 3-7. The core tenets of OOSEM include recognized practices essential to systems engineering that include: 1) Integrated Product Development (IPD), essential to improve communications, and 2) a recursive Vee lifecycle process model that is applied to each multiple level of the system hierarchy. As shown in Figure 3-8, OOSEM includes the following development activities: Analyze Stakeholder Needs Define System Requirements Define Logical Architecture Synthesize Candidate Allocated Architectures Optimize and Evaluate Alternatives

 Validate and Verify System These activities are consistent with typical systems engineering Vee process that can be recursively and iteratively applied at each level of the system hierarchy. Fundamental tenets of systems engineering, such as disciplined management processes (i.e. risk management, configuration management, planning, measurement, etc.) and the use of multidisciplinary teams, must be applied to support each of these activities to be effective. OOSEM utilizes a model-based approach to represent the various artifacts generated by the development activities using OMG SysML as the predominant modeling language. As such, it enables the systems engineer to precisely capture, analyze, and specify the system and its components and ensure consistency among various system views. The modeling artifacts can also be refined and reused in other applications to support product line and evolutionary development approaches. A summary description of the activities and artifacts is provided on the following pages [37]. Analyze Stakeholder Needs This activity captures the as-is systems and enterprise, their limitations and potential improvement areas. The results of the as-is analysis is used to develop the to-be enterprise and associated mission requirements. An enterprise model depicts the enterprise, its constituent systems, including the systems to be developed or modified, and enterprise actors (entities external to the enterprise). The as-is enterprise is analyzed using causal analysis techniques to determine its limitations, and used as a basis for deriving the mission requirements and to-be enterprise model. The mission requirements are specified in terms of the mission / enterprise objectives, measures of effectiveness, and top-level use cases. The use cases and scenarios capture the enterprise functionality. Define System Requirements This activity is intended to specify the system requirements that support the mission requirements. The system is modeled as a black box that interacts with the external systems and users represented in the enterprise model. The system-level use cases and scenarios reflect the operational concept for how the system is used to support the enterprise. The scenarios are modeled using activity diagrams with swim lanes that represent the black box system, users, and external systems. The scenarios for each use case are used to derive the black box system functional, interface, data, and performance requirements. The requirements management

database is updated during this activity to trace each system requirement to the enterprise/mission level use case and mission requirements. Requirements variation is evaluated in terms of the probability that a requirement will change, which is included in the risks, and later analyzed to determine how to design the system to accommodate the potential change. A typical example may be a system interface that is likely to change or a performance requirement that is expected to increase. Define Logical Architecture This activity includes decomposing and partitioning the system into logical components that interact to satisfy the system requirements. The logical components capture the system functionality. Examples may include a user interface that is realized by a web browser, or an environmental monitor that is realized by a particular sensor. The logical architecture/design mitigates the impact of requirements changes on the system design, and helps to manage technology changes. OOSEM provides guidelines for decomposing the system into its logical components. The logical scenarios preserve system black box interactions with its environment. In addition, the logical component functionality and data are repartitioned based on partitioning criteria such as cohesion, coupling, design for change, reliability, performance, and other considerations. Synthesize Candidate Allocated Architectures The allocated architecture describes relationship among the physical components of the system including hardware, software, data and procedures. The system nodes define the distribution of resources. Each logical component is first mapped to a system node to address how the functionality is distributed. Partitioning criteria is applied to address distribution concerns such as performance, reliability, and security. The logical components are then allocated to hardware, software, data, and manual procedure components. The software, hardware, and data architecture are derived based on the component relationships. The requirements for each component are traced to the system requirements and maintained in the requirements management database. Optimize and Evaluate Alternatives This activity is invoked throughout all other OOSEM activities to optimize the candidate architectures and conduct trade studies to select the preferred architecture. Parametric models for modeling performance, reliability, availability, life-cycle cost, and other specialty engineering

concerns, are used to analyze and optimize the candidate architectures to the level needed to compare the alternatives. The criteria and weighting factors used to perform the trade studies are traceable to the system requirements and measures of effectiveness. This activity also includes the monitoring of technical performance measures and identifies potential risks. Validate and Verify System This activity is intended to verify that the system design satisfies its requirements and to validate that the requirements meet the stakeholder needs. It includes the development of verification plans, procedures, and methods (e.g., inspection, demonstration, analysis, test). System-level use cases, scenarios, and associated requirements are primary inputs to the development of the test cases and associated verification procedures. The verification system can be modeled using the same activities and artifacts described above for modeling the operational system. The requirements management database is updated during this activity to trace the system requirements and design information to the system verification methods, test cases, and results. The full description of each OOSEM activity and process flows are provided in the cited book by Friedenthal, Moore, and Steiner [38] and the referenced OOSEM tutorial [39].

3.2.2. Tool Support

A dedicated process framework tool for OOSEM does not exist; however, tool support for OOSEM can be provided by COTS-based OMG SysML tools and associated requirements management tools. Other tools required to support the full system lifecycle should be integrated with the SysML and requirements management tools, such as configuration management, performance modeling, and verification tools. A more complete set of OOSEM tool requirements is provided in the referenced OOSEM tutorial[39].

3.2.3. Offering/Availability
The OOSEM tutorial and training materials can be made available by contacting the INCOSE OOSEM Working Group to gain access through the INCOSE Connect collaboration space. Unlike other industry-provided MBSE methodologies, OOSEM is not a formal offering that can be purchased from any specific vendor, including professional services. Support services may be available by contacting representatives of the INCOSE OOSEM Working Group.

3.2 INCOSE sistemas orientados a objetos Mtodo de Ingeniera (OOSEM) 3.2.1. Informacin general El mtodo orientado a objetos Ingeniera de Sistemas (OOSEM) integra una de arriba hacia abajo, basado en el modelo enfoque que utiliza OMG SysML para apoyar la especificacin, anlisis, diseo y verificacin de sistemas. OOSEM aprovecha conceptos orientados a objetos en el concierto con ms de arriba hacia abajo tradicionales sistemas de mtodos de ingeniera y otras tcnicas de modelado, para ayudar a los arquitectos ms flexible y sistemas extensibles que pueden adaptarse a la evolucin de la tecnologa y las nuevas necesidades. OOSEM tambin pretende facilitar la integracin con desarrollo orientado a objetos de software, hardware desarrollo y prueba.

OOSEM evolucionado desde el trabajo a mediados de la dcada de 1990 en el Consorcio de Software de Productividad (en la actualidad Sistemas y Software Consortium), en colaboracin con Lockheed Martin Corporation.7 El metodologa se ha aplicado en parte a un gran desarrollo distribuido sistema de informacin en Lockheed Martin que incluye hardware, software, bases de datos y componentes de un manual de procedimientos. INCOSE Chesapeake Captulo estableci el Grupo de Trabajo OOSEM en noviembre de 2000 para ayudar a an ms la evolucin OOSEM methodology.8 se resume en la industria de diversos documentos y INCOSE [35], [36], [37] y, ms recientemente, en el prximo libro titulado Gua prctica para SysML: Sistemas de Lenguaje de Modelado por Fridenthal, Moore, y Steiner [38]. Una introduccin a la metodologa tambin est disponible como un tutorial de todo el da [39]. Los objetivos OOSEM son los siguientes: de captura y anlisis de requisitos y la informacin de diseo para especificar sistemas complejos. La integracin con orientacin a objetos (OO) de software, hardware, y otros mtodos de ingeniera. apoyo para su reutilizacin a nivel de sistema y la evolucin del diseo. Como se mencion anteriormente, OOSEM es un enfoque hbrido que aprovecha las tcnicas orientadas a objetos y un sistemas de ingeniera de fundaciones. Tambin introduce algunas tcnicas nicas, como se indica en la Figura 6.3. El OOSEM apoya un proceso de SE, como se ilustra en la Figura 7.3.

Los principios fundamentales de OOSEM incluyen prcticas esenciales para la ingeniera de sistemas que incluyen: 1) Desarrollo de Productos Integrada (IPD), esencial para mejorar las comunicaciones, y 2) una recursiva "V" del ciclo de vida del modelo de proceso que se aplica a cada nivel del sistema de mltiples jerarqua. Como se muestra en la Figura 3-8, OOSEM incluye las actividades de desarrollo siguientes: analizar las necesidades de los interesados Definir Requisitos del sistema definir la arquitectura lgica candidato Sintetizar Arquitecturas asignados optimizar y evaluar las alternativas validacin y verificacin de sistema Estas actividades son consistentes con la ingeniera de sistemas tpicos de "V" proceso que puede ser recursiva e iterativa aplicadas en cada nivel de la jerarqua del sistema.Principios fundamentales de la ingeniera de sistemas, tales como los procesos de gestin de disciplina (es decir, gestin de riesgos, gestin de configuracin, planificacin, medicin, etc) y el uso de equipos multidisciplinarios, debe ser aplicada para apoyar cada una de estas actividades para ser efectivo. OOSEM utiliza un enfoque basado en modelos para representar los diversos artefactos generados por la actividades de desarrollo con OMG SysML como el lenguaje de modelado predominante. Como tal, permite al ingeniero de sistemas para capturar con precisin, analizar y especificar el sistema y sus componentes y garantizar la coherencia entre las distintas vistas del sistema.Los artefactos de modelado tambin puede ser refinado y reutilizado en otras aplicaciones para apoyar la lnea de productos y el desarrollo evolutivo enfoques. Una breve descripcin de las actividades y los artefactos se proporciona en las pginas siguientes [37]. Analizar las necesidades de los interesados Esta actividad se captura el "tal cual" los sistemas y de la empresa, sus limitaciones y el potencial reas de mejora. Los resultados de la "tal cual" el anlisis se utiliza para desarrollar la empresa a ser y los requisitos asociados de la misin. Un modelo de empresa representa a la empresa, su constituyente sistemas, incluidos los sistemas a ser desarrollados o modificados, y los actores empresariales (entidades fuera de la empresa). El tal cual la empresa se analiza mediante tcnicas de anlisis causal de

determinar sus limitaciones, y se utiliza como base para derivar los requisitos de la misin y de serempresa modelo. Los requisitos de la misin se especifican en trminos de la misin / empresa objetivos, medidas de eficacia y de alto nivel casos de uso. Los casos de uso y escenarios capturar la funcionalidad empresarial. Definir los requisitos del sistema Esta actividad est destinada a especificar los requisitos del sistema que apoyan la misin requisitos. El sistema se modela como un cuadro negro que interacta con los sistemas externos y los usuarios representados en el modelo de empresa. Los casos de uso a nivel de sistema y los escenarios reflejan la concepto operacional para el funcionamiento del sistema se utiliza para apoyar la empresa. Los escenarios son modelado usando diagramas de actividad con los carriles de natacin que representan el sistema de recuadro negro, los usuarios, y sistemas externos. Los escenarios para cada caso de uso se utilizan para derivar el sistema de cuadro negro interfaz funcional, los datos y requisitos de rendimiento. Los requisitos de gestin base de datos se actualiza durante esta actividad para el seguimiento de cada requisito del sistema para la empresa / misin de alto nivel de casos de uso y requisitos de la misin. Variacin de los requisitos se evala en trminos de la probabilidad de que un requisito va a cambiar, que se incluye en los riesgos, y posteriormente se analizan para determinar cmo disear el sistema de adaptarse a los posibles cambios. Un ejemplo tpico puede ser una interfaz de sistema que es probable que cambio o un requisito de desempeo que se espera que aumente. Definir la arquitectura lgica Esta actividad incluye la descomposicin y la particin del sistema en componentes lgicos que interactan para satisfacer los requisitos del sistema. Los componentes lgicos de captura del sistema funcionalidad. Los ejemplos pueden incluir una interfaz de usuario que se realiza mediante un navegador web, o un seguimiento ambiental que se realiza mediante un sensor en particular. La arquitectura lgica / diseo mitiga el impacto de los cambios de requisitos en el diseo del sistema y ayuda a manejar los cambios tecnolgicos. OOSEM proporciona directrices para la descomposicin del sistema en sus componentes lgicos. La lgica escenarios de preservar las interacciones del sistema recuadro negro con su

entorno. Adems, la lgica funcionalidad de los componentes y los datos se reparticionan basada en criterios tales como la particin la cohesin, el acoplamiento, el diseo para el cambio, fiabilidad, rendimiento, y otras consideraciones. Sintetizar arquitecturas candidatas asignados La arquitectura asignados describe la relacin entre los componentes fsicos del sistema incluyendo hardware, software, datos y procedimientos. Los nodos del sistema definir la distribucin de los recursos. Cada componente lgico es primero asignada a un nodo del sistema para hacer frente a cmo el funcionalidad se distribuye. Criterios de particin se aplica para tratar las preocupaciones de distribucin, como rendimiento, fiabilidad y seguridad. Los componentes lgicos se asignan a los equipos, software, datos y componentes de un manual de procedimientos. El software, el hardware y los datos arquitectura se obtienen sobre la base de las relaciones de los componentes.Los requisitos para cada componente se remonta a los requisitos del sistema y mantenerse en los requisitos gestin de base de datos. Optimizar y evaluar las alternativas Esta actividad se invoca en todas las actividades OOSEM otros para optimizar el candidato arquitecturas y realizar estudios de comercio para seleccionar la arquitectura preferida. Paramtrico de los modelos para el desempeo de modelado, fiabilidad, disponibilidad, la especialidad del ciclo de vida de costos, y otras de ingeniera preocupaciones, se utilizan para analizar y optimizar las arquitecturas candidato al nivel necesario para comparar las alternativas. Los criterios y factores de ponderacin utilizados para realizar los estudios de comercio son atribuibles a los requisitos del sistema y las medidas de eficacia. Esta actividad tambin incluye el seguimiento de las medidas de desempeo tcnico e identifica los posibles riesgos. Sistema de validacin y verificacin de Esta actividad est destinada a verificar que el diseo del sistema satisface sus requerimientos y validar que los requisitos de satisfacer las necesidades de los interesados. Incluye el desarrollo de la verificacin planes, procedimientos y mtodos (por ejemplo, inspeccin, demostracin, anlisis, pruebas). A nivel de sistema casos de uso, escenarios y requisitos asociados son insumos primarios para el desarrollo de la

casos de prueba y verificacin de los procedimientos asociados. El sistema de verificacin puede ser modelado utilizando las mismas actividades y los artefactos descritos anteriormente para el modelado del sistema operativo. La requisitos de gestin de bases de datos se actualiza durante esta actividad para rastrear el sistema requisitos y la informacin de diseo de los mtodos de sistema de verificacin, casos de prueba y los resultados. La descripcin completa de cada actividad OOSEM y flujos de procesos se proporcionan en el libro citado por Friedenthal, Moore, y Steiner [38] y el tutorial OOSEM referencia [39]. 3.2.2. Herramienta de apoyo Una herramienta de proceso del marco especfico para OOSEM no existe, sin embargo, herramienta de apoyo para OOSEM puede ser proporcionada por COTS OMG SysML y herramientas de gestin asociados a las necesidades herramientas. Otras herramientas necesarias para apoyar el ciclo de vida completo del sistema debe ser integrado con el SysML y herramientas de gestin de requisitos, tales como la gestin de la configuracin, el rendimiento modelado y herramientas de verificacin. Un conjunto ms completo de los requisitos de herramientas OOSEM se proporciona en el tutorial OOSEM referencia [39]. 3.2.3. Ofreciendo / Disponibilidad El tutorial OOSEM y materiales de capacitacin se pueden hacer ponindose en contacto con el INCOSE OOSEM Grupo de Trabajo para obtener acceso a travs del espacio de colaboracin INCOSE Connect. A diferencia de otros en la industria proporciona metodologas MBSE, OOSEM no es una oferta formal que se puede comprar a cualquier proveedor especfico, incluidos los servicios profesionales.Servicios de apoyo pueden ser ponindose en contacto con los representantes del Grupo de INCOSE OOSEM de Trabajo.