Temario 7 Ing. Soft

Al proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones se le llama. ingeniería de requerimientos (IR). ingeniería del software (IS). ingeniería de sistemas (IS).

para representar los requerimientos abstractos de alto nivel; son enunciados, en un lenguaje natural junto con diagramas, acerca de qué servicios esperan los usuarios del sistema, y de las restricciones con las cuales éste debe operar. requerimientos del usuario. requerimientos del sistema. requerimientos de dominio.

para caracterizar la descripción detallada de lo que el sistema debe hacer, son descripciones más detalladas de las funciones, los servicios y las restricciones operacionales del sistema de software. El documento de requerimientos del sistema (llamado en ocasiones especificación funcional) tiene que definir con exactitud lo que se implementará. Puede formar parte del contrato entre el comprador del sistema y los desarrolladores del software. requerimientos del sistema. requerimientos del usuario. requerimientos de dominio.

Son enunciados acerca de servicios que el sistema debe proveer, de cómo debería reaccionar el sistema a entradas particulares y de cómo debería comportarse el sistema en situaciones específicas. En algunos casos, estos requerimientos también explican lo que no debe hacer el sistema. Requerimientos funcionales. Requerimientos no funcionales. Requerimientos de dominio.

Son limitaciones sobre servicios o funciones que ofrece el sistema. Incluyen restricciones tanto de temporización y del proceso de desarrollo, como impuestas por los estándares. se suelen aplicar al sistema como un todo, más que a características o a servicios individuales del sistema. Requerimientos funcionales. Requerimientos no funcionales. Requerimientos de dominio.

no sólo detallan los servicios o las características que se requieren del mismo, sino también especifican la funcionalidad necesaria para asegurar que estos servicios y características se entreguen de manera adecuada. requerimientos del sistema. requerimientos del usuario. requerimientos de dominio.

refieren lo que el sistema debe hacer. Tales requerimientos dependen del tipo de software que se esté desarrollando, de los usuarios esperados del software y del enfoque general que adopta la organización cuando se escriben los requerimientos. Requerimientos funcionales. Requerimientos no funcionales. Requerimientos de dominio.

se describen por lo general de forma abstracta que entiendan los usuarios del sistema. Sin embargo, estos requerimientos más específicos del sistema detallan las funciones del sistema, sus entradas y salidas, sus excepciones, etcétera. Requerimientos funcionales. Requerimientos no funcionales. Requerimientos de dominio.

se derivan del dominio de aplicación del sistema, más que a partir de las necesidades específicas de los usuarios del sistema. Pueden ser requerimientos funcionales nuevos por derecho propio, restricciones a los requerimientos funcionales existentes o formas en que deben realizarse cálculos particulares. Requerimientos funcionales. Requerimientos no funcionales. Requerimientos de dominio.

la especificación de estos requerimientos de sistema debe ser completa y consistente. Totalidad significa que deben definirse todos los servicios requeridos por el usuario. Consistencia quiere decir que los requerimientos tienen que evitar definiciones contradictorias. Requerimientos funcionales. Requerimientos no funcionales. Requerimientos de dominio.

son requerimientos que no se relacionan directamente con los servicios específicos que el sistema entrega a sus usuarios. Pueden relacionarse con propiedades emergentes del sistema, como fiabilidad, tiempo de respuesta y uso de almacenamiento. Requerimientos funcionales. Requerimientos no funcionales. Requerimientos de dominio.

estos requerimientos, como el rendimiento, la seguridad o la disponibilidad, especifican o restringen por lo general características del sistema como un todo. Requerimientos funcionales. Requerimientos no funcionales. Requerimientos de dominio.

afectan más la arquitectura global de un sistema que los componentes individuales. Por ejemplo, para garantizar que se cumplan los requerimientos de rendimiento, quizá se deba organizar el sistema para minimizar las comunicaciones entre componentes. Requerimientos funcionales. Requerimientos no funcionales. Requerimientos de dominio.

un requerimiento de seguridad, podría generar algunos requerimientos funcionales relacionados que definan nuevos servicios del sistema que se requieran. Además, también podría generar requerimientos que restrinjan los requerimientos ya existentes. Requerimientos funcionales. Requerimiento no funcional individual. Requerimientos de dominio.

surgen a través de necesidades del usuario, debido a restricciones presupuestales, políticas de la organización, necesidad de interoperabilidad con otro software o sistemas de hardware, o factores externos como regulaciones de seguridad o legislación sobre privacidad. Requerimientos funcionales. Requerimientos no funcionales. Requerimientos de dominio.

Estos requerimientos especifican o restringen el comportamiento del software. Los ejemplos incluyen requerimientos de rendimiento sobre qué tan rápido se debe ejecutar el sistema y cuánta memoria requiere, requerimientos de fiabilidad que establecen la tasa aceptable de fallas, requerimientos de seguridad y requerimientos de usabilidad. Requerimientos del producto. Requerimientos de la organización. Requerimientos externos.

Son requerimientos de sistemas amplios, derivados de políticas y procedimientos en la organización del cliente y del desarrollador. Los ejemplos incluyen requerimientos del proceso operacional que definen cómo se usará el sistema, requerimientos del proceso de desarrollo que especifican el lenguaje de programación, estándares del entorno o el proceso de desarrollo a utilizar, y requerimientos ambientales que definen el entorno de operación del sistema. Requerimientos del producto. Requerimientos de la organización. Requerimientos externos.

Este término cubre todos los requerimientos derivados de factores externos al sistema y su proceso de desarrollo. En ellos se incluyen requerimientos regulatorios que establecen lo que debe hacer el sistema para ser aprobado en su uso por un regulador, como sería un banco central; requerimientos legislativos que tienen que seguirse para garantizar que el sistema opere conforme a la ley, y requerimientos éticos que garanticen que el sistema será aceptable para sus usuarios y el público en general. Requerimientos del producto. Requerimientos de la organización. Requerimientos externos.

las métricas que se utilizan para especificar propiedades no funcionales del sistema. rapidez, tamaño, facilidad de uso, fiabilidad, robustez y portabilidad. menús, base de datos, software de aplicación. autenticación, respaldo.

métrica relacionada a Transacciones/segundo procesadas, Tiempo de respuesta usuario/evento y Tiempo de regeneración de pantalla. Rapidez. Tamaño. Facilidad de uso. Robustez.

métrica relacionada a Mbytes y Número de chips ROM. Rapidez. Tamaño. Facilidad de uso. Robustez.

métrica relacionada a Tiempo de capacitación y Número de cuadros de ayuda. Rapidez. Tamaño. Facilidad de uso. Robustez.

métrica relacionada a Tiempo de reinicio después de falla, Porcentaje de eventos que causan falla, Probabilidad de corrupción de datos en falla. Rapidez. Fiabilidad. Facilidad de uso. Robustez.

métrica relacionada a Porcentaje de enunciados dependientes de objetivo y Número de sistemas objetivo. Rapidez. Fiabilidad. Portabilidad. Robustez.

Estas organizaciones grandes, definieron estándares para los documentos de requerimientos. Comúnmente son muy genéricos, pero útiles como base para desarrollar estándares organizativos más detallados. el Departamento de Defensa estadounidense y el Institute of Electrical and Electronic Engineers (IEEE). Internet Engineering Task Force (IETF) y el Institute of Electrical and Electronic Engineers (IEEE). el Departamento de Defensa estadounidense y el Internet Engineering Task Force (IETF).

es un comunicado oficial de lo que deben implementar los desarrolladores del sistema. Incluye tanto los requerimientos del usuario para un sistema, como una especificación detallada de los requerimientos del sistema. En ocasiones, los requerimientos del usuario y del sistema se integran en una sola descripción. El documento de requerimientos de software (especificación de requerimientos de software o SRS). El catálogo. La introducción.

tiene un conjunto variado de usuarios, desde el administrador ejecutivo de la organización que paga por el sistema, hasta los ingenieros responsables del desarrollo del software. El documento de requerimientos de software (especificación de requerimientos de software o SRS). El catálogo. La introducción.

Usuarios de un documento de requerimientos. Especifican los requerimientos y los leen para comprobar que cubren sus necesidades. Estos usuarios especifican los cambios a los requerimientos. Clientes del sistema. Administradores. Ingenieros del sistema.

Usuarios de un documento de requerimientos. Usan el documento de requerimientos para planear una cotización para el sistema y el proceso de desarrollo del sistema. Clientes del sistema. Administradores. Ingenieros del sistema.

Usuarios de un documento de requerimientos. Usan los requerimientos para entender qué sistema debe desarrollarse. Clientes del sistema. Administradores. Ingenieros del sistema.

Usuarios de un documento de requerimientos. Usan los requerimientos para desarrollar pruebas de validación para el sistema. Clientes del sistema. Ingenieros de prueba del sistema. Ingenieros del sistema.

Usuarios de un documento de requerimientos. Usan los requerimientos para comprender el sistema y las relaciones entre sus componentes. Ingenieros de mantenimiento del sistema. Ingenieros de prueba del sistema. Ingenieros del sistema.

parte del documento de requerimientos que Debe definir el número esperado de lectores del documento, así como describir su historia de versiones, incluidas las causas para la creación de una nueva versión y un resumen de los cambios realizados en cada versión. Prefacio. Introducción. Glosario.

parte del documento de requerimientos que Describe la necesidad para el sistema. Debe detallar brevemente las funciones del sistema y explicar cómo funcionará con otros sistemas. También tiene que indicar cómo se ajusta el sistema en los objetivos empresariales o estratégicos globales de la organización que comisiona el software. Prefacio. Introducción. Glosario.

parte del documento de requerimientos que Define los términos técnicos usados en el documento. No debe hacer conjeturas sobre la experiencia o la habilidad del lector. Apéndices. Introducción. Glosario.

parte del documento de requerimientos que Aquí se representan los servicios que ofrecen al usuario. También, en esta sección se describen los requerimientos no funcionales del sistema. Esta descripción puede usar lenguaje natural, diagramas u otras observaciones que sean comprensibles para los clientes. Deben especificarse los estándares de producto y proceso que tienen que seguirse. Modelos del sistema. Definición de requerimientos del usuario. Especificación de requerimientos del sistema.

parte del documento de requerimientos que Este capítulo presenta un panorama de alto nivel de la arquitectura anticipada del sistema, que muestra la distribución de funciones a través de los módulos del sistema. Hay que destacar los componentes arquitectónicos que sean de reutilización. Modelos del sistema. Evolución del sistema. Arquitectura del sistema.

parte del documento de requerimientos que Debe representar los requerimientos funcionales y no funcionales con más detalle. Si es preciso, también pueden detallarse más los requerimientos no funcionales. Pueden definirse las interfaces a otros sistemas. Especificación de requerimientos del sistema. Evolución del sistema. Arquitectura del sistema.

parte del documento de requerimientos que Pueden incluir modelos gráficos del sistema que muestren las relaciones entre componentes del sistema, el sistema y su entorno. Ejemplos de posibles modelos son los modelos de objeto, modelos de flujo de datos o modelos de datos semánticos. Especificación de requerimientos del sistema. Modelos del sistema. Arquitectura del sistema.

parte del documento de requerimientos que Describe los supuestos fundamentales sobre los que se basa el sistema, y cualquier cambio anticipado debido a evolución de hardware, cambio en las necesidades del usuario, etc. Esta sección es útil para los diseñadores del sistema, pues los ayuda a evitar decisiones de diseño que restringirían probablemente futuros cambios al sistema. Especificación de requerimientos del sistema. Modelos del sistema. Evolución del sistema.

parte del documento de requerimientos que Brindan información específica y detallada que se relaciona con la aplicación a desarrollar; por ejemplo, descripciones de hardware y bases de datos. Los requerimientos de hardware definen las configuraciones, mínima y óptima, del sistema. Los requerimientos de base de datos delimitan la organización lógica de los datos usados por el sistema y las relaciones entre datos. Especificación de requerimientos del sistema. Modelos del sistema. Apéndices.

parte del documento de requerimientos que Pueden incluirse en el documento varios de ellos. Así como un índice alfabético normal, uno de diagramas, un índice de funciones, etcétera. Índice. Modelos del sistema. Apéndices.

es el proceso de escribir, en un documento de requerimientos, los requerimientos del usuario y del sistema. De manera ideal, los requerimientos del usuario y del sistema deben ser claros, sin ambigüedades, fáciles de entender, completos y consistentes. La especificación de requerimientos. Modelos del sistema. Evolución del sistema.

deben describir los requerimientos funcionales y no funcionales, de forma que sean comprensibles para los usuarios del sistema que no cuentan con un conocimiento técnico detallado. requerimientos del sistema. requerimientos del usuario del sistema. requerimientos de dominio.

si usted escribe los _______________, no tiene que usar jerga de software, anotaciones estructuradas o formales. Debe escribirlos en lenguaje natural, con tablas y formas sencillas, así como diagramas intuitivos. requerimientos del sistema. requerimientos del usuario del sistema. requerimientos del usuario.

son versiones extendidas de los requerimientos del usuario que los ingenieros de software usan como punto de partida para el diseño del sistema. Añaden detalles y explican cómo el sistema debe brindar los requerimientos del usuario. requerimientos del sistema. requerimientos del usuario del sistema. requerimientos del usuario.

deben describir de manera simple el comportamiento externo del sistema y sus restricciones operacionales. No tienen que ocuparse de cómo se diseña o implementa el sistema. Sin embargo, al nivel de detalle requerido para especificar por completo un sistema de software complejo, es prácticamente imposible excluir toda la información de diseño. requerimientos del sistema. requerimientos del usuario del sistema. requerimientos del usuario.

Es una forma de escribir una especificación de requerimientos del sistema. Los requerimientos se escriben al usar enunciados numerados en lenguaje natural. Cada enunciado debe expresar un requerimiento. Enunciados en lenguaje natural. Lenguaje natural estructurado. Lenguajes de descripción de diseño.

Es una forma de escribir una especificación de requerimientos del sistema. Los requerimientos se escriben en lenguaje natural en una forma o plantilla estándar. Cada campo ofrece información de un aspecto del requerimiento. Enunciados en lenguaje natural. Lenguaje natural estructurado. Lenguajes de descripción de diseño.

Es una forma de escribir una especificación de requerimientos del sistema. Este enfoque usa un lenguaje como un lenguaje de programación, pero con características más abstractas para especificar los requerimientos al definir un modelo operacional del sistema. Aunque en la actualidad este enfoque se usa raras veces, aún tiene utilidad para especificaciones de interfaz. Enunciados en lenguaje natural. Lenguaje natural estructurado. Lenguajes de descripción de diseño.

Es una forma de escribir una especificación de requerimientos del sistema. Los modelos gráficos, complementados con anotaciones de texto, sirven para definir los requerimientos funcionales del sistema; los casos de uso del UML y los diagramas de secuencia se emplean de forma común. Enunciados en lenguaje natural. Anotaciones gráficas. Lenguajes de descripción de diseño.

Es una forma de escribir una especificación de requerimientos del sistema. Dichas anotaciones se basan en conceptos matemáticos como máquinas o conjuntos de estado finito. Aunque tales especificaciones sin ambigüedades pueden reducir la imprecisión en un documento de requerimientos, la mayoría de los clientes no comprenden una especificación formal. No pueden comprobar que representa lo que quieren y por ello tienen reticencia para aceptarlo como un contrato de sistema. Enunciados en lenguaje natural. Anotaciones gráficas. Especificaciones matemáticas.

se usa para escribir los requerimientos de software. Es expresivo, intuitivo y universal. También es potencialmente vago, ambiguo y su significado depende de los antecedentes del lector. el lenguaje natural. Anotaciones gráficas. Especificaciones matemáticas.

Especificación en lenguaje natural. 1. Elabore un formato estándar y asegúrese de que todas las definiciones de requerimientos se adhieran a dicho formato. Al estandarizar el formato es menos probable cometer omisiones y más sencillo comprobar los requerimientos. 2. Utilice el lenguaje de manera clara para distinguir entre requerimientos obligatorios y deseables. Los primeros son requerimientos que el sistema debe soportar y, por lo general, se escriben en futuro “debe ser”. En tanto que los requerimientos deseables no son necesarios y se escriben en tiempo pospretérito o como condicional “debería ser”. 3. Use texto resaltado (negrilla, cursiva o color) para seleccionar partes clave del requerimiento. 4. No deduzca que los lectores entienden el lenguaje técnico de la ingeniería de software. Es fácil que se malinterpreten palabras como “arquitectura” y “módulo”. Por lo tanto, debe evitar el uso de jerga, abreviaturas y acrónimos. 5. Siempre que sea posible, asocie una razón con cada requerimiento de usuario. La razón debe explicar por qué se incluyó el requerimiento. Es particularmente útil cuando los requerimientos cambian, pues ayuda a decidir cuáles cambios serían indeseables.

es una manera de escribir requerimientos del sistema, donde está limitada la libertad del escritor de requerimientos y todos éstos se anotan en una forma estándar. El lenguaje estructurado. Lenguaje natural. Lenguaje formal.

Las anotaciones en este lenguaje emplean plantillas para especificar requerimientos del sistema. La especificación utiliza constructos de lenguaje de programación para mostrar alternativas e iteración, y destaca elementos clave con el uso de sombreado o de fuentes distintas. El lenguaje estructurado. Lenguaje natural. Lenguaje formal.

incluyen cuatro actividades de alto nivel. Éstas se enfocan en valorar si el sistema es útil para la empresa (estudio de factibilidad), descubrir requerimientos (adquisición y análisis), convertir dichos requerimientos en alguna forma estándar (especificación) y comprobar que los requerimientos definan realmente el sistema que quiere el cliente (validación). Procesos de ingeniería de requerimientos. Procesos de ingeniería de software. Procesos de validación de requerimientos.

es un breve estudio enfocado que debe realizarse con oportunidad en el proceso de IR. Debe responder tres preguntas clave: a) ¿El sistema contribuye con los objetivos globales de la organización? b) ¿El sistema puede implementarse dentro de la fecha y el presupuesto usando la tecnología actual? c) ¿El sistema puede integrarse con otros sistemas que se utilicen?. Estudio de factibilidad. Estudio de compatibilidad. Estudio de comprobación de resultados.

En esta actividad, los ingenieros de software trabajan con clientes y usuarios finales del sistema para descubrir el dominio de aplicación, qué servicios debe proporcionar el sistema, el desempeño requerido de éste, las restricciones de hardware, etcétera. adquisición y análisis de requerimientos. estudio de factibilidad. validación de requerimientos.

actividad del proceso de adquisición y análisis de requerimientos. Éste es el proceso de interactuar con los participantes del sistema para descubrir sus requerimientos. También los requerimientos de dominio de los participantes y la documentación se descubren durante esta actividad. Descubrimiento de requerimientos. Clasificación y organización de requerimientos. Priorización y negociación de requerimientos. Especificación de requerimientos.

actividad del proceso de adquisición y análisis de requerimientos. Esta actividad toma la compilación no estructurada de requerimientos, agrupa requerimientos relacionados y los organiza en grupos coherentes. La forma más común de agrupar requerimientos es usar un modelo de la arquitectura del sistema, para identificar subsistemas y asociar los requerimientos con cada subsistema. Descubrimiento de requerimientos. Clasificación y organización de requerimientos. Priorización y negociación de requerimientos. Especificación de requerimientos.

actividad del proceso de adquisición y análisis de requerimientos. Esta actividad se preocupa por priorizar los requerimientos, así como por encontrar y resolver conflictos de requerimientos mediante la negociación. Por lo general, los participantes tienen que reunirse para resolver las diferencias y estar de acuerdo con el compromiso de los requerimientos. Descubrimiento de requerimientos. Clasificación y organización de requerimientos. Priorización y negociación de requerimientos. Especificación de requerimientos.

actividad del proceso de adquisición y análisis de requerimientos. Los requerimientos se documentan e ingresan en la siguiente ronda de la espiral. Pueden producirse documentos de requerimientos formales o informales. Descubrimiento de requerimientos. Clasificación y organización de requerimientos. Priorización y negociación de requerimientos. Especificación de requerimientos.

es una forma de recopilar y organizar un conjunto de requerimientos de un grupo de participantes que cuentan con algo en común. incluye una serie de requerimientos del sistema. pueden provenir de usuarios finales, administradores, etcétera. Ayudan a identificar a los individuos que brindan información sobre sus requerimientos y a estructurar los requerimientos para análisis. punto de vista. opinión. argumento.

es llamado a veces adquisición de requerimientos, es el proceso de recopilar información sobre el sistema requerido y los sistemas existentes, así como de separar, a partir de esta información, los requerimientos del usuario y del sistema. Descubrimiento de requerimientos. Clasificación y organización de requerimientos. Priorización y negociación de requerimientos. Especificación de requerimientos.

el equipo de ingeniería de requerimientos formula preguntas a los participantes sobre el sistema que actualmente usan y el sistema que se va a desarrollar. Los requerimientos se derivan de las respuestas a dichas preguntas. entrevistas. cuestionarios. encuestas.

Tipo de entrevista donde los participantes responden a un conjunto de preguntas preestablecidas. Entrevistas cerradas. Entrevistas abiertas. Entrevistas híbridas.

Tipo de entrevista, en las cuales no hay agenda predefinida. El equipo de ingeniería de requerimientos explora un rango de conflictos con los participantes del sistema y, como resultado, desarrolla una mejor comprensión de sus necesidades. Entrevistas cerradas. Entrevistas abiertas. Entrevistas híbridas.

son particularmente útiles para detallar un bosquejo de descripción de requerimientos. Se trata de ejemplos sobre descripciones de sesiones de interacción. abarca comúnmente una interacción o un número pequeño de interacciones posibles. Se desarrollan diferentes formas y se ofrecen varios tipos de información con diversos niveles de detalle acerca del sistema. entrevistas. escenarios. casos de uso.

son una técnica de descubrimiento de requerimientos que se introdujo por primera vez en el método Objectory (Jacobson et al., 1993). Ahora se ha convertido en una característica fundamental del modelado de lenguaje unificado. entrevistas. escenarios. casos de uso.

En su forma más sencilla, un _________ identifica a los actores implicados en una interacción, y nombra el tipo de interacción. Entonces, esto se complementa con información adicional que describe la interacción con el sistema. La información adicional puede ser una descripción textual, o bien, uno o más modelos gráficos como una secuencia UML o un gráfico de estado. entrevistas. escenarios. casos de uso.

Los actores en el proceso, que pueden ser individuos u otros sistemas, se representan como figuras sencillas. Cada clase de interacción se constituye como una elipse con etiqueta. Líneas vinculan a los actores con la interacción. De manera opcional, se agregan puntas de flecha a las líneas para mostrar cómo se inicia la interacción. entrevistas. escenarios. casos de uso.

identifican las interacciones individuales entre el sistema y sus usuarios u otros sistemas. deben documentarse con una descripción textual. Entonces pueden vincularse con otros modelos en el UML que desarrollará el escenario con más detalle. entrevistas. escenarios. casos de uso.

es un estándar de facto para modelado orientado a objetos, así que los casos de uso y la adquisición basada en casos ahora se utilizan ampliamente para adquisición de requerimientos. UML. Etnografía. casos de uso.

es una técnica de observación que se usa para entender los procesos operacionales y ayudar a derivar requerimientos de apoyo para dichos procesos. Un analista se adentra en el ambiente laboral donde se usará el sistema. Observa el trabajo diario y toma notas acerca de las tareas existentes en que intervienen los participantes. UML. Etnografía. casos de uso.

ayuda a descubrir requerimientos implícitos del sistema que reflejan las formas actuales en que trabaja la gente, en vez de los procesos formales definidos por la organización. UML. Etnografía. casos de uso.

La etnografía es muy efectiva para descubrir dos tipos de requerimientos: 1. Requerimientos que se derivan de la forma en que realmente trabaja la gente, en vez de la forma en la cual las definiciones del proceso indican que debería trabajar. 2. Requerimientos que se derivan de la cooperación y el conocimiento de las actividades de otras personas.

puede combinarse con la creación de prototipos. informa del desarrollo del prototipo, de modo que se requieren menos ciclos de refinamiento del prototipo. Más aún, la creación de prototipos se enfoca en ella al identificar problemas y preguntas que entonces pueden discutirse con el especialista. etnografía. casos de uso. UML.

es un proceso donde un grupo de personas del cliente del sistema y el desarrollador del sistema leen con detalle el documento de requerimientos y buscan errores, anomalías e inconsistencias. Una vez detectados y registrados, recae en el cliente y el desarrollador la labor de negociar cómo resolver los problemas identificados. revisión de requerimientos. La validación de requerimientos. Comprobación de requerimientos.

es el proceso de verificar que los requerimientos definan realmente el sistema que en verdad quiere el cliente. Se traslapa con el análisis, ya que se interesa por encontrar problemas con los requerimientos. revisión de requerimientos. La validación de requerimientos. Comprobación de requerimientos.

es importante porque los errores en un documento de requerimientos pueden conducir a grandes costos por tener que rehacer, cuando dichos problemas se descubren durante el desarrollo del sistema o después de que éste se halla en servicio. revisión de requerimientos. La validación de requerimientos. Comprobación de requerimientos.

En la validación de requerimientos. Un usuario quizá crea que necesita un sistema para realizar ciertas funciones. Sin embargo, con mayor consideración y análisis se logra identificar las funciones adicionales o diferentes que se requieran. Los sistemas tienen diversos participantes con diferentes necesidades, y cualquier conjunto de requerimientos es inevitablemente un compromiso a través de la comunidad de participantes. Comprobaciones de validez. Comprobaciones de consistencia. Comprobaciones de totalidad.

En la validación de requerimientos. Los requerimientos en el documento no deben estar en conflicto. Esto es, no debe haber restricciones contradictorias o descripciones diferentes de la misma función del sistema. Comprobaciones de validez. Comprobaciones de consistencia. Comprobaciones de totalidad.

En la validación de requerimientos. El documento de requerimientos debe incluir requerimientos que definan todas las funciones y las restricciones pretendidas por el usuario del sistema. Comprobaciones de validez. Comprobaciones de consistencia. Comprobaciones de totalidad.

En la validación de requerimientos. Al usar el conocimiento de la tecnología existente, los requerimientos deben comprobarse para garantizar que en realidad pueden implementarse. Dichas comprobaciones también tienen que considerar el presupuesto y la fecha para el desarrollo del sistema. Comprobaciones de realismo. Comprobaciones de consistencia. Comprobaciones de totalidad.

En la validación de requerimientos. Para reducir el potencial de disputas entre cliente y contratista, los requerimientos del sistema deben escribirse siempre de manera que sean comprobables. Esto significa que usted debe ser capaz de escribir un conjunto de pruebas que demuestren que el sistema entregado cumpla cada requerimiento especificado. Comprobaciones de validez. Verificabilidad. Comprobaciones de totalidad.

técnicas de validación de requerimientos. Los requerimientos se analizan sistemáticamente usando un equipo de revisores que verifican errores e inconsistencias. Revisiones de requerimientos. Creación de prototipos. Generación de casos de prueba.

técnicas de validación de requerimientos. En esta aproximación a la validación, se muestra un modelo ejecutable del sistema en cuestión a los usuarios finales y clientes. Así, ellos podrán experimentar con este modelo para constatar si cubre sus necesidades reales. Revisiones de requerimientos. Creación de prototipos. Generación de casos de prueba.

técnicas de validación de requerimientos. Los requerimientos deben ser comprobables. Si las pruebas para los requerimientos se diseñan como parte del proceso de validación, esto revela con frecuencia problemas en los requerimientos. Si una prueba es difícil o imposible de diseñar, esto generalmente significa que los requerimientos serán difíciles de implementar, por lo que deberían reconsiderarse. Comprobación de la validez. Creación de prototipos. Generación de casos de prueba.

Los ____________ son los requerimientos que se asocian con las actividades centrales, de lento cambio, de una organización. También estos requerimientos se relacionan con actividades laborales fundamentales. requerimientos duraderos. requerimientos volátiles. requerimientos parciales.

Por el contrario, los __________ tienen más probabilidad de cambio. Se asocian por lo general con actividades de apoyo que reflejan cómo la organización hace su trabajo más que el trabajo en sí. requerimientos duraderos. requerimientos volátiles. requerimientos parciales.

es el proceso de comprender y controlar los cambios en los requerimientos del sistema. Es necesario seguir la pista de requerimientos individuales y mantener los vínculos entre los requerimientos dependientes, de manera que pueda valorarse el efecto del cambio en los requerimientos. También es preciso establecer un proceso formal para hacer cambios a las propuestas y vincular éstos con los requerimientos del sistema. administración de requerimientos. planeación de requerimientos. recopilación de requerimientos.

primera etapa esencial en el proceso de administración de requerimientos. establece el nivel de detalle que se requiere en la administración de requerimientos. Planeación de la administración de requerimientos. Administración del cambio en los requerimientos. Proceso de mejora en los requerimientos.

En la etapa de Planeación de la administración de requerimientos, Cada requerimiento debe identificarse de manera exclusiva, de forma que pueda tener referencia cruzada con otros requerimientos y usarse en las evaluaciones de seguimiento. Identificación de requerimientos. Un proceso de administración del cambio. Políticas de seguimiento.

En la etapa de Planeación de la administración de requerimientos, Éste es el conjunto de actividades que valoran el efecto y costo de los cambios. Identificación de requerimientos. Un proceso de administración del cambio. Políticas de seguimiento.

En la etapa de Planeación de la administración de requerimientos, Definen las relaciones entre cada requerimiento, así como entre los requerimientos y el diseño del sistema que debe registrarse. en este proceso también tiene que definir cómo mantener dichos registros. Identificación de requerimientos. Un proceso de administración del cambio. Políticas de seguimiento.

En la etapa de Planeación de la administración de requerimientos, La administración de requerimientos incluye el procesamiento de grandes cantidades de información acerca de los requerimientos. Las herramientas disponibles varían desde sistemas especializados de administración de requerimientos, hasta hojas de cálculo y sistemas de bases de datos simples. Herramientas de apoyo. Un proceso de administración del cambio. Políticas de seguimiento.

necesita apoyo automatizado y herramientas de software, para lo cual deben seleccionarse durante la fase de planeación. administración de requerimientos. planeación de requerimientos. recopilación de requerimientos.

Los requerimientos tienen que mantenerse en un almacén de datos administrado y seguro, que sea accesible para todos quienes intervienen en el proceso de ingeniería de requerimientos. Almacenamiento de requerimientos. Administración del cambio. Administración del seguimiento.

este proceso se simplifica si está disponible la herramienta de apoyo activa. Almacenamiento de requerimientos. Administración del cambio. Administración del seguimiento.

permite la identificación de requerimientos relacionados. Algunas herramientas que están disponibles usan técnicas de procesamiento en lenguaje natural, para ayudar a descubrir posibles relaciones entre los requerimientos. Almacenamiento de requerimientos. Administración del cambio. Administración del seguimiento.

puede apoyarse con el uso de funciones disponibles en procesadores de texto, hojas de cálculo y bases de datos de PC. Sin embargo, para sistemas más grandes se requieren herramientas de apoyo más especializadas. administración de requerimientos. planeación de requerimientos. recopilación de requerimientos.

debe aplicarse a todos los cambios propuestos a los requerimientos de un sistema, después de aprobarse el documento de requerimientos. es esencial porque es necesario determinar si los beneficios de implementar nuevos requerimientos están justificados por los costos de la implementación. administración del cambio en los requerimientos. planeación de la administración de requerimientos. recopilación de requerimientos.

Es necesario seguir la huella de las relaciones entre requerimientos, sus fuentes y el diseño del sistema, de modo que usted pueda analizar las razones para los cambios propuestos, así como el efecto que dichos cambios tengan probablemente sobre otras partes del sistema. Es necesario poder seguir la pista de cómo un cambio se propaga hacia el sistema. Seguimiento de requerimientos. administración del cambio en los requerimientos. planeación de la administración de requerimientos.

El proceso comienza con la identificación de un problema en los requerimientos o, en ocasiones, con una propuesta de cambio específica. Durante esta etapa, el problema o la propuesta de cambio se analizan para comprobar que es válida. Este análisis retroalimenta al solicitante del cambio, quien responderá con una propuesta de cambio de requerimientos más específica, o decidirá retirar la petición. Análisis del problema y especificación del cambio. Análisis del cambio y estimación del costo. Implementación del cambio.

El efecto del cambio propuesto se valora usando información de seguimiento y conocimiento general de los requerimientos del sistema. El costo por realizar el cambio se estima en términos de modificaciones al documento de requerimientos y, si es adecuado, al diseño y la implementación del sistema. Una vez completado este análisis, se toma una decisión acerca de si se procede o no con el cambio de requerimientos. Análisis del problema y especificación del cambio. Análisis del cambio y estimación del costo. Implementación del cambio.

Se modifican el documento de requerimientos y, donde sea necesario, el diseño y la implementación del sistema. Hay que organizar el documento de requerimientos de forma que sea posible realizar cambios sin reescritura o reorganización extensos. Conforme a los programas, la variabilidad en los documentos se logra al minimizar las referencias externas y al hacer las secciones del documento tan modulares como sea posible. De esta manera, secciones individuales pueden modificarse y sustituirse sin afectar otras partes del documento. Análisis del problema y especificación del cambio. Análisis del cambio y estimación del costo. Implementación del cambio.

Si un nuevo requerimiento tiene que implementarse urgentemente, siempre existe la tentación para cambiar el sistema y luego modificar de manera retrospectiva el documento de requerimientos. Hay que tratar de evitar esto, pues casi siempre conducirá a que la especificación de requerimientos y la implementación del sistema se salgan de ritmo. Una vez realizados los cambios al sistema, es fácil olvidar la inclusión de dichos cambios en el documento de requerimientos, o bien, agregar información al documento de requerimientos que sea inconsistente con la implementación. Falso. Verdadero.

es el proceso para desarrollar modelos abstractos de un sistema, donde cada modelo presenta una visión o perspectiva diferente de dicho sistema. se ha convertido en un medio para representar el sistema usando algún tipo de notación gráfica, que ahora casi siempre se basa en notaciones en el Lenguaje de Modelado Unificado (UML). el modelado de sistemas. modelo. UML.

se usan durante el proceso de ingeniería de requerimientos para ayudar a derivar los requerimientos de un sistema, durante el proceso de diseño para describir el sistema a los ingenieros que implementan el sistema, y después de la implementación para documentar la estructura y la operación del sistema. el modelado de sistemas. modelo. UML.

se usan durante la ingeniería de requerimientos. Ayudan a aclarar lo que hace el sistema existente y pueden utilizarse como base para discutir sus fortalezas y debilidades. Posteriormente, conducen a los requerimientos para el nuevo sistema. el modelado de sistemas. Los modelos del sistema existente. Los modelos del sistema nuevo.

se emplean durante la ingeniería de requerimientos para ayudar a explicar los requerimientos propuestos a otros participantes del sistema. Los ingenieros usan tales modelos para discutir las propuestas de diseño y documentar el sistema para la implementación. En un proceso de ingeniería dirigido por modelo, es posible generar una implementación de sistema completa o parcial a partir del modelo del sistema. el modelado de sistemas. Los modelos del sistema existente. Los modelos del sistema nuevo.

es una abstracción del sistema a estudiar, y no una representación alternativa de dicho sistema. De manera ideal, una representación de un sistema debe mantener toda la información sobre la entidad a representar. Una abstracción simplifica y recoge deliberadamente las características más destacadas. el modelado de sistemas. modelo. UML.

Desde diferentes perspectivas, usted puede desarrollar diferentes modelos para representar el sistema. Por ejemplo: Una perspectiva externa. Una perspectiva de interacción. Una perspectiva estructural. Una perspectiva de comportamiento.

El UML tiene numerosos tipos de diagramas y, por lo tanto, soporta la creación de muchos diferentes tipos de modelo de sistema. la mayoría de los usuarios del UML consideraban que cinco tipos de diagrama podrían representar lo esencial de un sistema. Diagramas de actividad. Diagramas de caso de uso. Diagramas de secuencias. Diagramas de clase. Diagramas de estado.

Hay tres formas en que los modelos gráficos se emplean con frecuencia: Como medio para facilitar la discusión sobre un sistema existente o propuesto. Como una forma de documentar un sistema existente. Como una descripción detallada del sistema que sirve para generar una implementación de sistema.

el propósito del modelo es estimular la discusión entre los ingenieros de software que intervienen en el desarrollo del sistema. Los modelos pueden ser incompletos (siempre que cubran los puntos clave de la discusión) y utilizar de manera informal la notación de modelado. Como medio para facilitar la discusión sobre un sistema existente o propuesto. Como una forma de documentar un sistema existente. Como una descripción detallada del sistema que sirve para generar una implementación de sistema.

Cuando los modelos se usan como documentación, no tienen que estar completos, pues quizás usted sólo desee desarrollar modelos para algunas partes de un sistema. Sin embargo, estos modelos deben ser correctos: tienen que usar adecuadamente la notación y ser una descripción precisa del sistema. Como medio para facilitar la discusión sobre un sistema existente o propuesto. Como una forma de documentar un sistema existente. Como una descripción detallada del sistema que sirve para generar una implementación de sistema.

los modelos de sistema deben ser completos y correctos. La razón para esto es que se usan como base para generar el código fuente del sistema. Por lo tanto, debe ser muy cuidadoso de no confundir símbolos equivalentes, como las flechas de palo y las de bloque, que tienen significados diferentes. Como medio para facilitar la discusión sobre un sistema existente o propuesto. Como una forma de documentar un sistema existente. Como una descripción detallada del sistema que sirve para generar una implementación de sistema.

El Lenguaje de Modelado Unificado. es un conjunto compuesto por 13 diferentes tipos de diagrama para modelar sistemas de software. Surgió del trabajo en la década de 1990 sobre el modelado orientado a objetos, cuando anotaciones similares, orientadas a objetos, se integraron para crear el UML. Una amplia revisión (UML 2) se finalizó en 2004. El UML es aceptado universalmente como el enfoque estándar al desarrollo de modelos de sistemas de software.

En una primera etapa en la especificación de un sistema, debe decidir sobre las fronteras del sistema. Esto implica trabajar con los participantes del sistema para determinar cuál funcionalidad se incluirá en el sistema y cuál la ofrece el entorno del sistema. Modelos de contexto. UML. Esquemas.

puede colocarse deliberadamente, de modo que todo el proceso de análisis se realice en un sitio; puede elegirse de forma que sea innecesario consultar a un administrador particularmente difícil; puede situarse de manera que el costo del sistema aumente y la división de desarrollo del sistema deba, por lo tanto, expandirse al diseño y la implementación del sistema. una frontera de sistema. una delimitación del sistema. un contorno del sistema.

por lo general, muestran que el entorno incluye varios sistemas automatizados. Sin embargo, no presentan los tipos de relaciones entre los sistemas en el entorno y el sistema que se especifica. modelos de contexto. modelos del sistema existente. modelos del sistema nuevo.

intentan mostrar las actividades que incluyen un proceso de sistema, así como el flujo de control de una actividad a otra. El inicio de un proceso se indica con un círculo lleno; el fin, mediante un círculo lleno dentro de otro círculo. Los rectángulos con esquinas redondeadas representan actividades, esto es, los subprocesos específicos que hay que realizar. Puede incluir objetos en los gráficos de actividad. diagrama de actividad UML. graficos de Modelado. casos de uso.

las flechas representan el flujo de trabajo de una actividad a otra. Una barra sólida se emplea para indicar coordinación de actividades. Cuando el flujo de más de una actividad se dirige a una barra sólida, entonces todas esas actividades deben completarse antes del posible avance. Cuando el flujo de una barra sólida conduzca a algunas actividades, éstas pueden ejecutarse en forma paralela. diagrama de actividad UML. gráficos de Modelado. casos de uso.

destaca los problemas de comunicación que se lleguen a presentar. ayuda a entender si es probable que una estructura de un sistema propuesto obtenga el rendimiento y la confiabilidad requeridos por el sistema. Modelos de interacción. Modelos de contexto. Modelos de secuencia.

Modelos de interacción, que se utiliza principalmente para modelar interacciones entre un sistema y actores externos (usuarios u otros sistemas). Modelado de caso de uso. Diagramas de secuencia. UML.

Modelos de interacción, que se emplean para modelar interacciones entre componentes del sistema, aunque también pueden incluirse agentes externos. Modelado de caso de uso. Diagramas de secuencia. UML.

fue desarrollado originalmente por Jacobson y sus colaboradores (1993) en la década de 1990, y se incorporó en el primer lanzamiento del UML (Rumbaugh et al., 1999). Modelado de caso de uso. Diagramas de secuencia. UML.

representa una tarea discreta que implica interacción externa con un sistema. En su forma más simple, se muestra como una elipse, con los actores que intervienen representados como figuras humanas. Diagramas de caso de uso. Diagramas de secuencia. UML.

De manera formal, _______________________ deben emplear líneas sin flechas. Evidentemente, en este tipo de diagramas los mensajes pasan en ambas direcciones. Diagramas de caso de uso. Diagramas de secuencia. UML.

Los objetos y actores que intervienen se mencionan a lo largo de la parte superior del diagrama, con una línea punteada que se dibuja verticalmente a partir de éstos. Las interacciones entre los objetos se indican con flechas dirigidas. Modelado de caso de uso. Diagramas de secuencia. UML.

El rectángulo sobre las líneas punteadas indica la línea de vida del objeto tratado (es decir, el tiempo que la instancia del objeto está involucrada en la computación). Modelado de caso de uso. Diagramas de secuencia. UML.

La secuencia de interacciones se lee de arriba abajo. Las anotaciones sobre las flechas señalan las llamadas a los objetos, sus parámetros y los valores que regresan. Modelado de caso de uso. Diagramas de secuencia. UML.

* se modelan entidades del mundo real usando clases de objetos. Usted puede crear diferentes tipos de modelos de objetos, que muestren cómo se relacionan mutuamente las clases de objetos, cómo se agregan objetos para formar otros objetos, cómo interactúan los objetos entre sí, etcétera. Cada uno de éstos presenta información única acerca del sistema que se especifica. análisis de requerimientos orientado a objetos. diseño de requerimientos orientado a objetos. implementación de requerimientos orientado a objetos.

muestran la organización de un sistema, en términos de los componentes que constituyen dicho sistema y sus relaciones. Son modelos estáticos, que muestran la estructura del diseño del sistema, o modelos dinámicos, que revelan la organización del sistema cuando se ejecuta. modelos estructurales. modelos de interacción. modelos de contexto.

Modelo estructural que, pueden usarse cuando se desarrolla un modelo de sistema orientado a objetos para mostrar las clases en un sistema y las asociaciones entre dichas clases. diagramas de clase. diagramas de objetos. diagramas de caso.

Diagramas de clase. se considera como una definición general de un tipo de objeto del sistema. es un vínculo entre clases, que indica que hay una relación entre dicha clases.

pueden expresarse con diferentes niveles de detalle. Cuando se desarrolla un modelo, la primera etapa con frecuencia implica buscar en el mundo, identificar los objetos esenciales y representarlos como clases. La forma más sencilla de hacer esto es escribir el nombre de la clase en un recuadro. También puede anotar la existencia de una asociación dibujando simplemente una línea entre las clases. diagramas de clase. diagramas de objetos. modelos semánticos de datos.

se usan en el diseño de bases de datos. Muestran las entidades de datos, sus atributos asociados y las relaciones entre dichas entidades. Este enfoque para modelar fue propuesto por primera vez por Chen (1976), a mediados de la década de 1970; desde entonces, se han desarrollado diversas variantes (Codd, 1979; Hammer y McLeod, 1981; Hull y King, 1987), todas con la misma forma básica. diagramas de clase. diagramas de objetos. modelos semánticos de datos.

piense en entidades como clases de objeto simplificadas (no tienen operaciones), atributos como atributos de clase de objeto y relaciones como nombres de asociaciones entre clases de objeto. diagramas de clase. diagramas de objetos. modelos semánticos de datos.

es una técnica cotidiana que se usa para gestionar la complejidad. En vez de aprender las características detalladas de cada entidad que se experimenta, dichas entidades se colocan en clases más generales (animales, automóviles, casas, etcétera) y se aprenden las características de dichas clases. diagramas de clase. La generalización. modelos semánticos de datos.

los atributos y las operaciones asociados con las clases de nivel superior también se asocian con las clases de nivel inferior. En esencia, las clases de nivel inferior son subclases que heredan los atributos y las operaciones de sus superclases. Entonces dichas clases de nivel inferior agregan atributos y operaciones más específicos. diagramas de clase. generalización. modelos semánticos de datos.

significa que un objeto (el todo) se compone de otros objetos (las partes). Para mostrarlo, se usa un trazo en forma de diamante, junto con la clase que representa el todo. diagramas de clase. generalización. agregación.

son modelos dinámicos del sistema conforme se ejecutan. En ellos se muestra lo que sucede o lo que se supone que pasa cuando un sistema responde ante un estímulo de su entorno. Tales estímulos son de dos tipos: Datos y eventos. modelos estructurales. modelos de interacción. modelos de comportamiento.

son modelos de sistema que presentan una perspectiva funcional, donde cada transformación constituye una sola función o un solo proceso. se usan para mostrar cómo fluyen los datos a través de una secuencia de pasos del procesamiento. diagramas de clase. diagramas de objetos. diagramas de flujo de datos.

muestran la secuencia de acciones involucradas en el procesamiento de datos de entrada, así como la generación de una salida asociada. Son particularmente útiles durante el análisis de requerimientos, pues sirven para mostrar procesamiento “extremo a extremo” en un sistema. Esto es, exhiben toda la secuencia de acciones que ocurren desde una entrada a procesar hasta la salida correspondiente, que es la respuesta del sistema. Modelado dirigido por datos. Modelado dirigido por un evento. Modelado dirigido por secuencia.

Los son útiles porque el hecho de rastrear y documentar cómo los datos asociados con un proceso particular se mueven a través del sistema, ayuda a los analistas y diseñadores a entender lo que sucede. modelos de flujo de datos. modelos semánticos de datos. modelos estructurales.

son simples e intuitivos y, por lo general, es posible explicarlos a los usuarios potenciales del sistema, quienes después pueden participar en la validación del modelo. diagramas de clase. diagramas de objetos. diagramas de flujo de datos.

no soporta diagramas de flujo de datos, puesto que originalmente se propusieron y usaron para modelar el procesamiento de datos. La razón para esto es que los DFD se enfocan en funciones del sistema y no reconocen objetos del sistema. Diagramas de caso de uso. Diagramas de secuencia. UML.

muestra cómo responde un sistema a eventos externos e internos. Se basa en la suposición de que un sistema tiene un número finito de estados y que los eventos (estímulos) pueden causar una transición de un estado a otro. Modelado dirigido por datos. Modelado dirigido por un evento. Modelado dirigido por secuencia.

soporta modelado basado en eventos usando diagramas de estado, que se fundamentaron en gráficos de estado (Harel, 1987, 1988). Los diagramas de estado muestran estados y eventos del sistema que causan transiciones de un estado a otro. No exponen el flujo de datos dentro del sistema, pero suelen incluir información adicional acerca de los cálculos realizados en cada estado. Diagramas de caso de uso. Diagramas de secuencia. UML.

es un enfoque al desarrollo de software donde los modelos, y no los programas, son las salidas principales del proceso de desarrollo (Kent, 2002; Schmidt, 2006). Los programas que se ejecutan en una plataforma hardware/software se generan en tal caso automáticamente a partir de los modelos. ingeniería dirigida por modelo (MDE, por las siglas de Model-Driven Engineering). modelos de interacción. modelos de comportamiento.

tiene sus raíces en la arquitectura dirigida por modelo (MDA, por las siglas de Model-Driven Architecture), que fue propuesta por el Object Management Group (OMG) en 2001 como un nuevo paradigma de desarrollo de software. ingeniería dirigida por modelo (MDE, por las siglas de Model-Driven Engineering). modelos de interacción. modelos de comportamiento.

se enfoca en las etapas de diseño e implementación del desarrollo de software, mientras que la MDE se interesa por todos los aspectos del proceso de ingeniería de software. ingeniería dirigida por modelo. arquitectura dirigida por modelo. ingeniería de software.

permite a los ingenieros pensar sobre sistemas en un nivel de abstracción elevado, sin ocuparse por los detalles de su implementación. Esto reduce la probabilidad de errores, acelera el diseño y el proceso de implementación, y permite la creación de modelos de aplicación reutilizables, independientes de la plataforma de aplicación. ingeniería dirigida por modelo. arquitectura dirigida por modelo. ingeniería de software.

(Kleppe et al., 2003; Mellor et al., 2004; Stahl y Voelter, 2006) es un enfoque orientado a un modelos para el diseño y la implementación de software, que usa un subconjunto de modelos UML para describir un sistema. Aquí se crean modelos a diferentes niveles de abstracción. A partir de un modelo independiente de plataforma de alto nivel, es posible, en principio, generar un programa funcional sin intervención manual. ingeniería dirigida por modelo. arquitectura dirigida por modelo. ingeniería de software.

se crean modelos a diferentes niveles de abstracción. A partir de un modelo independiente de plataforma de alto nivel, es posible, en principio, generar un programa funcional sin intervención manual. ingeniería dirigida por modelo. arquitectura dirigida por modelo. ingeniería de software.

tipo de modelo de sistema abstracto: que modela las importantes abstracciones de dominio usadas en el sistema. En ocasiones, se llaman modelos de dominio. Un modelo independiente de computación (CIM). Un modelo independiente de plataforma (PIM). Modelos específicos de plataforma (PSM).

tipo de modelo de sistema abstracto: que modele la operación del sistema sin referencia a su implementación. se describe usualmente mediante modelos UML que muestran la estructura estática del sistema y cómo responde a eventos externos e internos. Un modelo independiente de computación (CIM). Un modelo independiente de plataforma (PIM). Modelos específicos de plataforma (PSM).

tipo de modelo de sistema abstracto: que son transformaciones del modelo independiente de plataforma con un modelo separado para cada plataforma de aplicación. En principio, puede haber capas del modelo, y cada una agrega cierto detalle específico de la plataforma. De este modo, el modelo de primer nivel podría ser específico de “middleware”, pero independiente de la base de datos. Cuando se elige una base de datos específica, podría generarse entonces un modelo específico de base de datos. Un modelo independiente de computación (CIM). Un modelo independiente de plataforma (PIM). Modelos específicos de plataforma (PSM).

debe ser posible la transformación completamente automatizada de modelos a código. Para lograr esto, usted tiene que ser capaz de construir modelos gráficos, cuya semántica esté bien definida. También necesita una forma de agregar a los modelos gráficos, información sobre la forma en que se implementan las operaciones definidas en el modelo. Esto es posible usando un subconjunto de. UML ejecutable. Diagramas de flujo de datos. Modelo de contexto.

tres tipos de modelo clave en UML ejecutable. que identifican las principales preocupaciones en el sistema. Se definen usando diagramas de clase UML que incluyen objetos, atributos y asociaciones. en los que se definen clases, junto con sus atributos y operaciones. en los que un diagrama de estado se asocia con cada clase y se usa para describir el ciclo de vida de la clase.

es como un lenguaje de programación de muy alto nivel, donde es posible referirse a los objetos y sus atributos, así como especificar acciones a realizar. UML ejecutable. lenguaje de acción. lenguaje de restricción de objeto (OCL).

El comportamiento dinámico del sistema puede especificarse de manera declarativa usando. UML ejecutable. lenguaje de acción. lenguaje de restricción de objeto (OCL).

se interesa por entender cómo debe organizarse un sistema y cómo tiene que diseñarse la estructura global de ese sistema. El diseño arquitectónico. Modelado del sistema. Ingeniería de requerimientos.

es la primera etapa en el proceso de diseño del software. Es el enlace crucial entre el diseño y la ingeniería de requerimientos, ya que identifica los principales componentes estructurales en un sistema y la relación entre ellos. El diseño arquitectónico. Modelado del sistema. Ingeniería de requerimientos.

es por lo general necesaria para estructurar y organizar la especificación. Por lo tanto, como parte del proceso de ingeniería de requerimientos, usted podría proponer una arquitectura de sistema abstracta donde se asocien grupos de funciones de sistemas o características con componentes o subsistemas a gran escala. El diseño arquitectónico. Modelado del sistema. La descomposición arquitectónica.

se interesa por la arquitectura de programas individuales. En este nivel, uno se preocupa por la forma en que el programa individual se separa en componentes. La arquitectura en pequeño. La arquitectura en grande. La arquitectura de en medio.

se interesa por la arquitectura de sistemas empresariales complejos que incluyen otros sistemas, programas y componentes de programa. Tales sistemas empresariales se distribuyen a través de diferentes computadoras, que diferentes compañías administran y poseen. La arquitectura en pequeño. La arquitectura en grande. La arquitectura de en medio.

es importante porque afecta el desempeño y la potencia, así como la capacidad de distribución y mantenimiento de un sistema (Bosch, 2000). La arquitectura en pequeño. La arquitectura en grande. La arquitectura de software.

Bass y sus colaboradores (2003) analizan tres ventajas de diseñar y documentar de manera explícita la arquitectura de software: La arquitectura es una presentación de alto nivel del sistema, que puede usarse como un enfoque para la discusión de un amplio número de participantes. En una etapa temprana en el desarrollo del sistema, aclarar la arquitectura del sistema requiere cierto análisis. Las decisiones de diseño arquitectónico tienen un efecto profundo sobre si el sistema puede o no cubrir requerimientos críticos como rendimiento, fiabilidad y mantenibilidad. Un modelo de una arquitectura de sistema es una descripción corta y manejable de cómo se organiza un sistema y cómo interoperan sus componentes. Por lo general, la arquitectura del sistema es la misma para sistemas con requerimientos similares.

Hofmeister y sus colaboradores (2000) proponen que una arquitectura de software sirve. como un plan de diseño para la negociación de requerimientos de sistema. como un medio para establecer discusiones con clientes, desarrolladores y administradores. herramienta esencial para la administración de la complejidad.

se modelan con frecuencia usando diagramas de bloques simples. Las arquitecturas de sistemas. Las arquitecturas de software. Los modelos de contexto.

Cada recuadro en el diagrama representa un componente. Los recuadros dentro de recuadros indican que el componente se dividió en subcomponentes. Las arquitecturas de sistemas. Las arquitecturas de software. Los modelos de contexto.

Las flechas significan que los datos y/o señales de control pasan de un componente a otro en la dirección de las flechas. Las arquitecturas de sistemas. Las arquitecturas de software. Los diagramas de bloque.

presentan una imagen de alto nivel de la estructura del sistema e incluyen fácilmente a individuos de diferentes disciplinas que intervienen en el proceso de desarrollo del sistema. Las arquitecturas de sistemas. Las arquitecturas de software. Los diagramas de bloque.

son una forma adecuada para describir la arquitectura del sistema durante el proceso de diseño, pues son una buena manera de soportar las comunicaciones entre las personas involucradas en el proceso. Las arquitecturas de sistemas. Las arquitecturas de software. Los diagramas de bloque.

Las aparentes contradicciones entre práctica y teoría arquitectónica surgen porque hay dos formas en que se utiliza un modelo arquitectónico de un programa: Una visión arquitectónica de alto nivel de un sistema es útil para la comunicación con los participantes de un sistema y la planeación del proyecto, ya que no se satura con detalles. Los participantes pueden relacionarse con él y entender una visión abstracta del sistema. La meta aquí es producir un modelo de sistema completo que muestre los diferentes componentes en un sistema, sus interfaces y conexiones. El argumento para esto es que tal descripción arquitectónica detallada facilita la comprensión y la evolución del sistema.

es un proceso creativo en el cual se diseña una organización del sistema que cubrirá los requerimientos funcionales y no funcionales de éste. Puesto que se trata de un proceso creativo, las actividades dentro del proceso dependen del tipo de sistema que se va a desarrollar, los antecedentes y la experiencia del arquitecto del sistema, así como de los requerimientos específicos del sistema. El diseño arquitectónico. Modelado del sistema. Ingeniería de requerimientos.

puede basarse en un patrón o un estilo arquitectónico particular. Un patrón arquitectónico es una descripción de una organización del sistema (Garlan y Shaw, 1993), tal como una organización cliente-servidor o una arquitectura por capas. El diseño arquitectónico. La arquitectura de un sistema de software. Los patrones arquitectónicos.

captan la esencia de una arquitectura que se usó en diferentes sistemas de software. Usted tiene que conocer tanto los patrones comunes, en que éstos se usen, como sus fortalezas y debilidades cuando se tomen decisiones sobre la arquitectura de un sistema. El diseño arquitectónico. La arquitectura de un sistema de software. Los patrones arquitectónicos.

se toman decisiones sobre cómo se controla la ejecución de componentes. Se desarrolla un modelo general de las relaciones de control entre las diferentes partes del sistema. El diseño arquitectónico. El proceso de modelado de control. Los patrones arquitectónicos.

si es un requerimiento crítico, la arquitectura debe diseñarse para localizar operaciones críticas dentro de un pequeño número de componentes, con todos estos componentes desplegados en la misma computadora en vez de distribuirlos por la red. Rendimiento. Seguridad. Protección.

si es un requerimiento crítico, será necesario usar una estructura en capas para la arquitectura, con los activos más críticos protegidos en las capas más internas, y con un alto nivel de validación de seguridad aplicado a dichas capas. Rendimiento. Seguridad. Protección.

si es un requerimiento crítico, la arquitectura debe diseñarse de modo que las operaciones relacionadas con la protección se ubiquen en algún componente individual o en un pequeño número de componentes. Rendimiento. Seguridad. Protección.

si es un requerimiento crítico, la arquitectura tiene que diseñarse para incluir componentes redundantes de manera que sea posible sustituir y actualizar componentes sin detener el sistema. Rendimiento. Disponibilidad. Protección.

si es un requerimiento crítico, la arquitectura del sistema debe diseñarse usando componentes autocontenidos de grano fino que puedan cambiarse con facilidad. Los productores de datos tienen que separarse de los consumidores y hay que evitar compartir las estructuras de datos. Rendimiento. Disponibilidad. Mantenibilidad.

indica las abstracciones clave en el sistema como objetos o clases de objeto. En este tipo de vista se tienen que relacionar los requerimientos del sistema con entidades. Una vista lógica. Una vista de proceso. Una vista de desarrollo.

muestra cómo, en el tiempo de operación, el sistema está compuesto de procesos en interacción. Esta vista es útil para hacer juicios acerca de las características no funcionales del sistema, como el rendimiento y la disponibilidad. Una vista lógica. Una vista de proceso. Una vista de desarrollo.

muestra cómo el software está descompuesto para su desarrollo, esto es, indica la descomposición del software en elementos que se implementen mediante un solo desarrollador o equipo de desarrollo. Esta vista es útil para administradores y programadores de software. Una vista lógica. Una vista de proceso. Una vista de desarrollo.

expone el hardware del sistema y cómo los componentes de software se distribuyen a través de los procesadores en el sistema. Esta vista es útil para los ingenieros de sistemas que planean una implementación de sistema. Una vista lógica. Una vista de proceso. Una vista física.

es una vista abstracta del sistema que puede ser la base para descomponer los requerimientos de alto nivel en especificaciones más detalladas, ayudar a los ingenieros a tomar decisiones sobre componentes que puedan reutilizarse, y representar una línea de producto. Una vista lógica. Una vista conceptual. Una vista física.

En la práctica, las _____________ casi siempre se desarrollan durante el proceso de diseño y se usan para apoyar la toma de decisiones arquitectónicas. Son una forma de comunicar a diferentes participantes la esencia de un sistema. vistas lógicas. vistas conceptuales. vistas físicas.

se diseñó para describir sistemas orientados a objetos y, en la etapa de diseño arquitectónico, uno quiere describir con frecuencia sistemas en un nivel superior de abstracción. UML. lenguaje de acción. lenguaje de restricción de objeto (OCL).

Arquitecturas de sistemas. UML. ADL. MVC.

MVC (modelo de vista del controlador). Descripción. Cuándo se usa. Ventajas. Desventajas.

Patrones arquitectónicos. patrones para el diseño organizacional. patrones de usabilidad. administración de la configuración.

se propusieron en la década de 1990, con el nombre de “estilos arquitectónicos” (Shaw y Garlan, 1996),. patrones arquitectónicos. patrones de usabilidad. patrones para el diseño organizacional.

se puede considerar como una descripción abstracta estilizada de buena práctica, que se ensayó y puso a prueba en diferentes sistemas y entornos. patrón arquitectónico. patrón de usabilidad. patrón para el diseño organizacional.

debe describir una organización de sistema que ha tenido éxito en sistemas previos. Debe incluir información sobre cuándo es y cuándo no es adecuado usar dicho patrón, así como sobre las fortalezas y debilidades del patrón. patrón arquitectónico. patrón de usabilidad. patrón para el diseño organizacional.

Este patrón es el soporte del manejo de la interacción en muchos sistemas basados en la Web. La descripción del patrón estilizado incluye el nombre del patrón, una breve descripción (con un modelo gráfico asociado) y un ejemplo del tipo de sistema donde se usa el patrón (de nuevo, quizá con un modelo gráfico). También debe incluir información sobre cuándo hay que usar el patrón, así como sobre sus ventajas y desventajas. patrón arquitectónico. patrón Modelo-Vista-Controlador. patrón para el diseño organizacional.

es otra forma de lograr separación e independencia. Aquí, la funcionalidad del sistema está organizada en capas separadas, y cada una se apoya sólo en las facilidades y los servicios ofrecidos por la capa inmediatamente debajo de ella. arquitectura de sistemas. arquitectura de software. arquitectura en capas.

soporta el desarrollo incremental de sistemas. Conforme se desarrolla una capa, algunos de los servicios proporcionados por esta capa deben quedar a disposición de los usuarios. La arquitectura también es cambiable y portátil. En tanto su interfaz no varíe, una capa puede sustituirse por otra equivalente. Más aún, cuando las interfaces de capa cambian o se agregan nuevas facilidades a una capa, sólo resulta afectada la capa adyacente. arquitectura de sistemas. arquitectura de software. arquitectura en capas.

Arquitectura en capas. Descripción. Cuándo se usa. Ventajas. Desventajas. ejemplo.

Este modelo es adecuado para aplicaciones en las que un componente genere datos y otro los use. Los ejemplos de este tipo de sistema incluyen sistemas de comando y control, sistemas de información administrativa, sistemas CAD y entornos de desarrollo interactivo para software. arquitectura de sistemas. arquitectura de repositorio. arquitectura en capas.

Arquitectura de repositorio. Descripción. Cuándo se usa. Ventajas. Desventajas. ejemplo.

se organiza como un conjunto de servicios y servidores asociados, y de clientes que acceden y usan los servicios. arquitectura de sistemas. arquitectura de repositorio. arquitectura cliente-servidor.

Un conjunto de servidores que ofrecen servicios a otros componentes, un conjunto de clientes que solicitan los servicios que ofrecen los servidores y una red que permite a los clientes acceder a dichos servicios, son componentes de este modelo: arquitectura de sistemas. arquitectura de repositorio. arquitectura cliente-servidor.

La ventaja más importante de este modelo consiste en que es una arquitectura distribuida. Éste puede usarse de manera efectiva en sistemas en red con distintos procesadores distribuidos. Es fácil agregar un nuevo servidor e integrarlo al resto del sistema, o bien, actualizar de manera clara servidores sin afectar otras partes del sistema. arquitectura de sistemas. arquitectura de repositorio. arquitectura cliente-servidor.

Patrón Cliente-servidor. Descripción. Cuándo se usa. Ventajas. Desventajas.

reflejan formas usadas comúnmente para organizar el control en un sistema. En ellos se incluyen el control centralizado, basado en un componente que llama otros componentes, y el control con base en un evento, donde el sistema reacciona a eventos externos. patrones arquitectónicos para control. patrones de usabilidad. patrones para el diseño organizacional.

es un modelo de la organización en tiempo de operación de un sistema, donde las transformaciones funcionales procesan sus entradas y producen salidas. Los datos fluyen de uno a otro y se transforman conforme se desplazan a través de la secuencia. Cada paso de procesamiento se implementa como un transformador. arquitectura de tubería y filtro. arquitectura de repositorio. arquitectura cliente-servidor.

Patrón de tubería y filtro (pipe and filter). Descripción. Cuándo se usa. Ventajas. Desventajas.

tienen la intención de cubrir las necesidades de una empresa u organización. Todas las empresas tienen mucho en común: necesitan contratar personal, emitir facturas, llevar la contabilidad, etcétera. Las empresas que operan en el mismo sector usan aplicaciones comunes específicas para el sector. arquitectura de aplicaciones. arquitectura de repositorio. arquitectura cliente-servidor.

puede reimplantarse cuando se desarrollen nuevos sistemas, pero, para diversos sistemas empresariales, la reutilización de aplicaciones es posible sin reimplementación. arquitectura de aplicaciones. arquitectura de repositorio. arquitectura en capas.

Cuando las transformaciones son secuenciales, con datos procesados en lotes, este modelo arquitectónico de tubería y filtro se convierte en. modelo secuencial en lote. arquitectura de repositorio. arquitectura cliente-servidor.

Como diseñador de software, usted puede usar modelos de arquitecturas de aplicación en varias formas: Como punto de partida para el proceso de diseño arquitectónico. Como lista de verificación del diseño. Como una forma de organizar el trabajo del equipo de desarrollo. Como un medio para valorar los componentes a reutilizar. Como un vocabulario para hablar acerca de los tipos de aplicaciones.

son aplicaciones centradas en bases de datos, que procesan los requerimientos del usuario mediante la información y actualizan ésta en una base de datos. Se trata del tipo más común de sistemas empresariales interactivos. Se organizan de tal forma que las acciones del usuario no pueden interferir unas con otras y se mantiene la integridad de la base. Aplicaciones de procesamiento de transacción. Sistemas de procesamiento de lenguaje. Aplicaciones de procesamiento de datos.

Son sistemas en los que las intenciones del usuario se expresan en un lenguaje formal (como Java). elabora este lenguaje en un formato interno y después interpreta dicha representación interna. los mejor conocidos son los compiladores, que traducen los programas en lenguaje de alto nivel dentro de un código de máquina. Aplicaciones de procesamiento de transacción. Sistemas de procesamiento de lenguaje. Aplicaciones de procesamiento de datos.

están diseñados para procesar peticiones del usuario mediante la información de una base de datos, o los requerimientos para actualizar una base de datos. sistemas de procesamiento de transacciones. Sistemas de procesamiento de lenguaje. Aplicaciones de procesamiento de datos.

es cualquier secuencia coherente de operaciones que satisfacen un objetivo, como “encontrar los horarios de vuelos de Londres a París”. Si la transacción del usuario no requiere el cambio en la base de datos, entonces sería innecesario empaquetar esto como una transacción técnica de base de datos. transacción. proceso. evento.

es una secuencia de operaciones que se trata como una sola unidad (una unidad atómica). Todas las operaciones en una transacción tienen que completarse antes de que sean permanentes los cambios en la base de datos. Esto garantiza que la falla en las operaciones dentro de la transacción no conduzca a inconsistencias. transacciones de bases de datos. transacciones de sistemas. transacciones de servidor.

pueden organizarse como una arquitectura “tubería y filtro” con componentes de sistema responsables de entradas, procesamiento y salida. sistemas de procesamiento de transacciones. Sistemas de procesamiento de lenguaje. Aplicaciones de procesamiento de datos.

permite acceso controlado a una gran base de información, tales como un catálogo de biblioteca, un horario de vuelos o los registros de pacientes en un hospital. Cada vez más, estos sistemas son sistemas basados en la Web, cuyo acceso es mediante un navegador Web. sistemas de información. sistemas de procesamiento de lenguaje. sistemas de procesamiento de datos.

esta capa, es responsable de implementar la interfaz de usuario. En este caso, la UI se implementó con el uso de un navegador Web. La capa superior. La segunda capa. La tercera capa.

esta capa, proporciona la funcionalidad de interfaz de usuario que se entrega a través del navegador Web. Incluye componentes que permiten a los usuarios ingresar al sistema, y componentes de verificación para garantizar que las operaciones utilizadas estén permitidas de acuerdo con su rol. La capa superior. La segunda capa. La tercera capa.

esta capa, incluye componentes de gestión de formato y menú que presentan información a los usuarios, así como componentes de validación de datos que comprueban la consistencia de la información. La capa superior. La segunda capa. La tercera capa.

esta capa, implementa la funcionalidad del sistema y ofrece componentes que ponen en operación la seguridad del sistema, la creación y actualización de la información del paciente, la importación y exportación de datos del paciente desde otras bases de datos, y los generadores de reporte que elaboran informes administrativos. La capa superior. La segunda capa. La tercera capa.

esta capa, que se construye al usar un sistema comercial de gestión de base de datos, ofrece administración de transacciones y almacenamiento constante de datos. La capa superior. La segunda capa. La capa baja.

por lo general, son ahora sistemas basados en la Web donde las interfaces de usuario se implementan con el uso de un navegador Web. Por ejemplo, los sistemas de comercio electrónico son sistemas de gestión de recursos basados en Internet, que aceptan pedidos electrónicos por bienes o servicios y, luego, ordenan la entrega de dichos bienes o servicios al cliente. sistemas de gestión de información y recursos. sistemas de procesamiento de lenguaje. sistemas de procesamiento de datos.

es responsable de todas las comunicaciones del usuario, y la interfaz de usuario se pone en función mediante un navegador Web;. El servidor Web. El servidor de aplicación. El servidor de la base de datos.

es responsable de implementar la lógica específica de la aplicación, así como del almacenamiento de la información y las peticiones de recuperación;. El servidor Web. El servidor de aplicación. El servidor de la base de datos.

mueve la información hacia y desde la base de datos y, además, manipula la gestión de transacciones. El servidor Web. El servidor de aplicación. El servidor de la base de datos.

convierten un lenguaje natural o artificial en otra representación del lenguaje y, para lenguajes de programación, también pueden ejecutar el código resultante. sistemas de gestión de información y recursos. sistemas de procesamiento de lenguaje. sistemas de procesamiento de datos.

traducen un lenguaje de programación artificial en código de máquina. compiladores. programas de aplicación. programas de bases de datos.

Componente de un compilador de lenguaje de programación, que toma valores simbólicos (tokens) y los convierte en una forma interna. Un analizador léxico. Una tabla de símbolos. Un analizador de sintaxis. Un árbol de sintaxis.

Componente de un compilador de lenguaje de programación, que contiene información de los nombres de las entidades (variables, de clase, de objeto, etcétera) usados en el texto que se traduce. Un analizador léxico. Una tabla de símbolos. Un analizador de sintaxis. Un árbol de sintaxis.

Componente de un compilador de lenguaje de programación, el cual verifica la sintaxis del lenguaje que se va a traducir. Emplea una gramática definida del lenguaje y construye un árbol de sintaxis. Un analizador léxico. Una tabla de símbolos. Un analizador de sintaxis. Un árbol de sintaxis.

Componente de un compilador de lenguaje de programación, es una estructura interna que representa el programa a compilar. Un analizador léxico. Una tabla de símbolos. Un analizador de sintaxis. Un árbol de sintaxis.

Componente de un compilador de lenguaje de programación, que usa información del árbol de sintaxis y la tabla de símbolos, para verificar la exactitud semántica del texto en lenguaje de entrada. Un analizador léxico. Un analizador semántico. Un analizador de sintaxis. Un árbol de sintaxis.

Componente de un compilador de lenguaje de programación, que “recorre” el árbol de sintaxis y genera un código de máquina abstracto. Un analizador léxico. Un analizador semántico. Un analizador de sintaxis. Un generador de código.

captan en un dominio características importantes de las arquitecturas del sistema. En esencia, incluyen todo lo que pueda estar en una arquitectura de aplicación aunque, en realidad, es muy improbable que alguna aplicación individual contenga todas las características mostradas en esta arquitectura. arquitectura de aplicaciones. arquitectura de repositorio. arquitectura de referencia.

En otros tipos de sistema de procesamiento de lenguaje, como un traductor de lenguaje natural, habrá componentes adicionales, por ejemplo. un diccionario y el código generado. Un árbol de sintaxis y Una tabla de símbolos. variables y funciones.

es la etapa del proceso de ingeniería de software en que se desarrolla un sistema de software ejecutable. Diseño e implementación. Ingeniería de requerimientos. Diseño arquitectónico.

es una actividad creativa donde se identifican los componentes del software y sus relaciones, con base en los requerimientos de un cliente. trata sobre cómo resolver un problema. El diseño de software. La implementación de software. Descubrimiento de requerimientos.

es el proceso de realizar el diseño como un programa. El diseño de software. La implementación de software. Descubrimiento de requerimientos.

suelen funcionar a partir de bosquejos informales del diseño y dejan a los programadores muchas de las decisiones de diseño. Las arquitecturas de sistemas. los métodos ágiles. Los modelos de contexto.

refieren que el diseño del software debe realizarse en una forma metódica. Diseñar un sistema incluye seguir los pasos del método, así como corregir el diseño de un sistema en niveles cada vez más detallados. Métodos de diseño estructurado. los métodos ágiles. Los modelos de contexto.

se constituye con objetos que interactúan y mantienen su propio estado local y ofrecen operaciones sobre dicho estado. La representación del estado es privada y no se puede acceder directamente desde afuera del objeto. sistemas orientado a objetos. Sistemas de aplicación. Sistemas interactivos.

son más fáciles de cambiar que aquellos sistemas desarrollados usando enfoques funcionales. Los objetos incluyen datos y operaciones para manipular dichos datos. En consecuencia, pueden entenderse y modificarse como entidades independientes. sistemas orientado a objetos. Sistemas de aplicación. Sistemas interactivos.

Para desarrollar un diseño de sistema desde el concepto hasta el diseño detallado orientado a objetos, hay muchas cuestiones por hacer: Comprender y definir el contexto y las interacciones externas con el sistema. Diseñar la arquitectura del sistema. Identificar los objetos principales en el sistema. Desarrollar modelos de diseño. Especificar interfaces.

Como todas las actividades creativas, éste no es un proceso secuencial tajante. se desarrolla al obtener ideas, proponer soluciones y corregir dichas soluciones conforme la información se encuentra disponible. Cuando surjan problemas, se tendrá inevitablemente que regresar y volver a intentar. El diseño de software. La implementación de software. Descubrimiento de requerimientos.

La primera etapa en cualquier proceso de diseño de software es desarrollar la comprensión de las relaciones entre el software que se diseñará y su ambiente externo. Esto es esencial para decidir cómo proporcionar la funcionalidad requerida del sistema y cómo estructurar el sistema para que se comunique con su entorno. permite también determinar las fronteras del sistema. La comprensión del contexto. Determinación de requerimientos. Especificación de requerimientos.

ayuda a decidir sobre las características que se implementarán en el sistema que se va a diseñar, así como sobre las de otros sistemas asociados. En este caso, es necesario decidir cómo se distribuirá la funcionalidad entre el sistema de control para todas las estaciones meteorológicas y el software embebido en la estación meteorológica en sí. El establecimiento de las fronteras del sistema. Un modelo de contexto del sistema. Un modelo de interacción.

es un modelo estructural, que muestra los otros sistemas en el entorno del sistema a desarrollar. Un modelo de comportamiento. Un modelo de contexto del sistema. Un modelo de interacción.

es un modelo dinámico que indica la forma en que el sistema interactúa con su entorno conforme se utiliza. Un modelo de comportamiento. Un modelo de contexto del sistema. Un modelo de interacción.

puede representarse mediante asociaciones, las cuales muestran simplemente que existen algunas relaciones entre las entidades que intervienen en la asociación. Por lo tanto, es posible documentar el entorno del sistema con un simple diagrama de bloques, que manifieste las entidades en el sistema y sus asociaciones. Un modelo de comportamiento. Un modelo de contexto del sistema. Un modelo de interacción.

En esta etapa del proceso de diseño, es necesario tener algunas ideas sobre los objetos esenciales en el sistema que se diseña. Conforme aumente su comprensión del diseño, corregirá estas ideas de los objetos del sistema. La descripción del caso de uso ayuda a identificar objetos y operaciones del sistema. Identificación de clase de objeto. Identificación del caso de uso. Diseño arquitectónico.

Hay varias propuestas sobre cómo identificar las clases de objetos en los sistemas orientados a objetos: Use un análisis gramatical de una descripción en lenguaje natural del sistema a construir. Objetos y atributos son sustantivos; operaciones o servicios son verbos. Utilice entidades tangibles (cosas) en el dominio de aplicación (como aeronave), roles (como administrador o médico), eventos (como peticiones), interacciones (como reuniones), ubicaciones (como oficinas), unidades organizacionales (como compañías),. Emplee un análisis basado en escenarios, donde a la vez se identifiquen y analicen varios escenarios de uso de sistema. A medida que se analiza cada escenario, el equipo responsable del análisis debe identificar los objetos, los atributos y las operaciones requeridos (Beck y Cunningham, 1989).

En esta etapa del proceso de diseño hay que enfocarse en los objetos en sí, sin pensar en cómo podrían implementarse. Una vez identificados los objetos, corrija el diseño del objeto. Busque características comunes y luego elabore la jerarquía de herencia para el sistema. Identificación de clase de objeto. Identificación del caso de uso. Diseño arquitectónico.

muestran los objetos o clases de objetos en un sistema. También indican las asociaciones y relaciones entre tales entidades. Dichos modelos son el puente entre los requerimientos y la implementación de un sistema. Deben ser abstractos, de manera que el detalle innecesario no oculte las relaciones entre ellos y los requerimientos del sistema. Sin embargo, deben incluir suficiente detalle para que los programadores tomen decisiones de implementación. modelos de comportamiento. modelos de contexto del sistema. modelos de diseño.

describen la estructura estática del sistema usando las clases de objetos y sus relaciones. Las relaciones importantes que pueden documentarse en esta etapa son las relaciones de generalización (herencia), las relaciones usa/usado por y las relaciones de composición. Modelos estructurales. Modelos dinámicos. Modelos de subsistema.

muestran las interacciones entre los objetos del sistema. Las interacciones que pueden documentarse incluyen la secuencia de peticiones de servicio realizadas por los objetos, así como los cambios de estado que activan las interacciones de dichos objetos. Modelos estructurales. Modelos dinámicos. Modelos de subsistema.

exponen los agrupamientos lógicos de objetos en subsistemas coherentes. Se representan mediante una forma de diagrama de clase en el que cada subsistema se muestra como un paquete con objetos encerrados. son modelos estáticos (estructurales). Modelos estructurales. Modelos dinámicos. Modelos de subsistema.

ilustran la secuencia de interacciones de objetos. Se representan mediante una secuencia UML o un diagrama de colaboración. son modelos dinámicos. Modelos estructurales. Modelos de secuencia. Modelos de subsistema.

muestran cómo los objetos individuales cambian su estado en respuesta a eventos. Se representan en UML a través de diagramas de estado. son modelos dinámicos. Modelos estructurales. Modelos de secuencia. Modelos de máquina de estado.

es un modelo estático útil, pues señala cómo está organizado un diseño en grupos de objetos relacionados lógicamente. Al igual que los modelos de subsistemas, puede diseñar también modelos de objeto detallados, que presenten todos los objetos en los sistemas y sus asociaciones (herencia, generalización, agregación, etcétera). Modelos estructurales. Modelos de secuencia. Modelos de subsistema.

son modelos dinámicos que describen, para cada modo de interacción, la secuencia de interacciones de objeto que tienen lugar. Cuando se documenta un diseño, debe producirse un modelo de este tipo por cada interacción significativa. Modelos estructurales. Modelos de secuencia. Modelos de subsistema.

se usan para modelar el comportamiento combinado de un grupo de objetos, pero quizá también se desee resumir el comportamiento de un objeto o un subsistema, en respuesta a mensajes y eventos. diagramas estructurales. diagramas de secuencia. diagramas de subsistema.

son modelos útiles de alto nivel de un sistema o la operación de un objeto. Por lo general, no se requiere uno de ellos para todos los objetos en el sistema. diagramas estructurales. diagramas de estado. diagramas de subsistema.

se preocupa por la especificación del detalle de la interfaz hacia un objeto o un grupo de objetos. Esto significa definir las firmas y la semántica de los servicios que ofrecerá el objeto o un grupo de objetos. El diseño de interfaz. Implementación de la interfaz. Control de la interfaz.

no se deben incluir detalles de la representación de datos, pues los atributos no se definen en una especificación de interfaz. Sin embargo, debe con tener operaciones para acceder a los datos y actualizarlos. diseño de interfaz. Implementación de la interfaz. Control de la interfaz.

se define mediante el lenguaje de restricción de objeto (OCL). También muestra una forma alternativa para representar interfaces en el UML. La semántica de la interfaz. Especificación de interfaz. Implementación de interfaz.

se derivaron de ideas planteadas por Christopher Alexander (Alexander et al., 1977), quien sugirió que había ciertos patrones comunes de diseño de construcción que eran relativamente agradables y efectivos. Los patrones de diseño. Los patrones de análisis. Los patrones de implementación.

es una descripción del problema y la esencia de su solución, de modo que la solución puede reutilizarse en diferentes configuraciones. El patrón. El modelo. la arquitectura.

son formas de describir mejores prácticas, buenos diseños, y captan la experiencia de tal manera que es posible que otros reutilicen esta experiencia. Los patrones y. los lenguajes de patrón.

se asocian usualmente con el diseño orientado a objetos. Los patrones publicados se suelen apoyar en características de objetos como herencia y polimorfismo para dar generalidad. Sin embargo, el principio universal de encapsular la experiencia en un patrón es igualmente aplicable a cualquier tipo de diseño de software. Los patrones de diseño. Los patrones de análisis. Los patrones de implementación.

se suelen apoyar en características de objetos como herencia y polimorfismo para dar generalidad. Sin embargo, el principio universal de encapsular la experiencia en un patrón es igualmente aplicable a cualquier tipo de diseño de software. Los patrones de diseño. Los patrones publicados. Los patrones de implementación.

Los cuatro elementos esenciales de los patrones de diseño, definidos por la “Banda de los cuatro” en su libro de patrones, son: Un nombre que sea una referencia significativa al patrón. Una descripción del área problemática que enuncie cuándo puede aplicarse el patrón. Una descripción de solución de las partes de la solución de diseño, sus relaciones y responsabilidades. No es una descripción concreta de diseño; es una plantilla para que una solución de diseño se instale en diferentes formas. Esto con frecuencia se expresa gráficamente y muestra las relaciones entre los objetos y las clases de objetos en la solución. Un estado de las consecuencias, los resultados y las negociaciones, al aplicar el patrón. Lo anterior ayuda a los diseñadores a entender si es factible usar o no un patrón en una situación particular.

La mayoría del software moderno se construye por la reutilización de los componentes o sistemas existentes. Cuando se desarrolla software, debe usarse el código existente tanto como sea posible. Reutilización. Administración de la configuración. Desarrollo de huésped-objetivo.

Durante el proceso de desarrollo se crean muchas versiones diferentes de cada componente de software. Si usted no sigue la huella de dichas versiones en un sistema de gestión de configuración, estará proclive a incluir en su sistema las versiones equivocadas de dichos componentes. Reutilización. Administración de la configuración. Desarrollo de huésped-objetivo.

La producción de software no se ejecuta por lo general en la misma computadora que el entorno de desarrollo de software. En vez de ello, se diseña en una computadora y se ejecuta en una computadora separada . estos sistemas son algunas veces del mismo tipo, aunque suelen ser completamente diferentes. Reutilización. Administración de la configuración. Desarrollo de huésped-objetivo.

En este nivel no se reutiliza el software directamente, sino más bien se utiliza el conocimiento de abstracciones exitosas en el diseño de su software. Los patrones de diseño y los arquitectónicos son vías de representación del conocimiento abstracto para la reutilización. El nivel de abstracción. El nivel objeto. El nivel componente. El nivel sistema.

En este nivel se reutilizan directamente los objetos de una librería en vez de escribir uno mismo en código. Para implementar este tipo de reutilización, se deben encontrar librerías adecuadas y descubrir si los objetos y métodos que ofrece ésta la funcionalidad que se necesita. El nivel de abstracción. El nivel objeto. El nivel componente. El nivel sistema.

En este nivel Los componentes son colecciones de objetos y clases de objetos que operan en conjunto para brindar funciones y servicios relacionados. Con frecuencia se debe adaptar y extender el componente al agregar por cuenta propia cierto código. Un ejemplo de utilización de este tipo es donde usted construye su interfaz de usuario mediante un marco. El nivel de abstracción. El nivel objeto. El nivel componente. El nivel sistema.

En este nivel En este nivel se reutilizan sistemas de aplicación completos. Usualmente esto implica cierto tipo de configuración de dichos sistemas. Puede hacerse al agregar y modificar el código (si reutiliza una línea de producto de software) o al usar la interfaz de configuración característica del sistema. La mayoría de los sistemas comerciales se diseñan ahora de esta forma, donde se adapta y reutilizan sistemas COTS (comerciales) genéricos. El nivel de abstracción. El nivel objeto. El nivel componente. El nivel sistema.

es el nombre dado al proceso general de gestionar un sistema de software cambiante. La meta de este proceso es apoyar el proceso de integración del sistema, de modo que todos los desarrolladores tengan acceso en una forma controlada al código del proyecto y a los documentos. Administración de la configuración. Reutilización. Desarrollo huésped-objetivo.

donde se da soporte para hacer un seguimiento de las diferentes versiones de los componentes de software. Los sistemas de este tipo incluyen facilidades para que el desarrollo esté coordinado por varios programadores. Esto evita que un desarrollador sobrescriba un código que haya sido enviado al sistema por alguien más. Gestión de versiones. Integración de sistema. Rastreo de problemas.

donde se da soporte para ayudar a los desarrolladores a definir qué versiones de componentes se usan para crear cada versión de un sistema. Luego, esta descripción se utiliza para elaborar automáticamente un sistema al compilar y vincular los componentes requeridos. Gestión de versiones. Integración de sistema. Rastreo de problemas.

donde se da soporte para que los usuarios reporten bugs y otros problemas, y también para que todos los desarrolladores sepan quién trabaja en dichos problemas y cuándo se corrigen. Gestión de versiones. Integración de sistema. Rastreo de problemas.

en el Desarrollo huésped-objetivo, ________ es más que sólo hardware. Incluye el sistema operativo instalado más otro software de soporte como un sistema de gestión de base de datos o, para plataformas de desarrollo, un entorno de desarrollo interactivo. Una plataforma. Un simulador. Un entorno.

En un sentido más amplio, puede hablarse de una plataforma de desarrollo y una plataforma de ejecución. Desarrollo huésped-objetivo. Cliente-servidor. Sistema distribuido.

aceleran el proceso de desarrollo para sistemas embebidos, pues cada desarrollador puede contar con su propia plataforma de ejecución, sin tener que descargar el software al hardware objetivo. Simuladores. Esquemas. Caso de uso.

muestran cómo los componentes de software se despliegan físicamente en los procesadores; es decir, muestra el hardware y el software en el sistema, así como el middleware usado para conectar los diferentes componentes en el sistema. Diagramas de despliegue UML. Diagramas de caso de uso. Diagramas de componentes.

Una plataforma de desarrollo de software debe ofrecer una variedad de herramientas para soportar los procesos de ingeniería de software. Éstas pueden incluir: 1. Un compilador integrado y un sistema de edición dirigida por sintaxis que le permitan crear, editar y compilar código. 2. Un sistema de depuración de lenguaje. 3. Herramientas de edición gráfica, tales como las herramientas para editar modelos UML. 4. Herramientas de prueba, como JUnit (Massol, 2003) que operen automáticamente un conjunto de pruebas sobre una nueva versión de un programa. 5. Herramientas de apoyo de proyecto que le ayuden a organizar el código para diferentes proyectos de desarrollo.

se agrupan con frecuencia para crear un entorno de desarrollo integrado (IDE), que es un conjunto de herramientas de software que apoyan diferentes aspectos del desarrollo de software, dentro de cierto marco común e interfaz de usuario. Las herramientas de desarrollo de software. Sistemas de aplicaciones. sistemas de procesamiento de datos.

es un marco para colocar herramientas de software, que brinden facilidades de gestión de datos para el software a desarrollar, y mecanismos de integración, que permitan a las herramientas trabajar en conjunto. Las herramientas de desarrollo de software. Un IDE de propósito general. sistemas de procesamiento de datos.

Si un componente se diseña para una arquitectura de hardware específica, o se apoya en algún otro sistema de software, tiene que desplegarse por supuesto en una plataforma que brinde el soporte requerido de hardware y software. Los requerimientos de hardware y software de un componente. Los requerimientos de disponibilidad del sistema. Comunicaciones de componentes.

Los sistemas de alta disponibilidad pueden necesitar que los componentes se desplieguen en más de una plataforma. Esto significa que, en el caso de una falla de plataforma, esté disponible una implementación alternativa del componente. Los requerimientos de hardware y software de un componente. Los requerimientos de disponibilidad del sistema. Comunicaciones de componentes.

Si hay un alto nivel de tráfico de comunicaciones entre componentes, por lo general tiene sentido desplegarlos en la misma plataforma o en plataformas que estén físicamente cercanas entre sí. Los requerimientos de hardware y software de un componente. Los requerimientos de disponibilidad del sistema. Comunicaciones de componentes.

es la demora entre el tiempo que transcurre desde el momento en que un componente envía un mensaje hasta que otro lo recibe. tiempo de transferencia. retardo. latencia de comunicaciones.

es un enfoque al desarrollo de software en que se publica el código de un sistema de software y se invita a voluntarios a participar en el proceso de desarrollo. Desarrollo de código abierto. sistemas de procesamiento de lenguaje. sistemas de procesamiento de datos.

el producto mejor conocido de código abierto, utilizado ampliamente como sistema servidor y, cada vez más, como un entorno de escritorio. Otros productos de código abierto importantes son Java, el servidor Web Apache y el sistema de gestión de base de datos mySQL. sistema operativo Linux. sistema operativo Windows. Sistema operativo Unix.

se conoce como licencia “recíproca”; de manera simple, significa que si usted usa software de código abierto que esté permitido bajo la licencia GPL, entonces debe hacer que dicho software sea de código abierto. La licencia pública general GNU. La licencia pública menos general GNU. La licencia Berkeley Standard Distribution.

licencia, en la que usted puede escribir componentes que se vinculen con el código abierto, sin tener que publicar el código de dichos componentes. Sin embargo, si cambia el componente permitido, entonces debe publicar éste como código abierto. La licencia pública general GNU. La licencia pública menos general GNU. La licencia Berkeley Standard Distribution.

es una licencia no recíproca, lo cual significa que usted no está obligado a volver a publicar algún cambio o modificación al código abierto. Puede incluir el código en sistemas propietarios que se vendan. Si usa componentes de código abierto, debe reconocer al creador original del código. La licencia pública general GNU. La licencia pública menos general GNU. La licencia Berkeley Standard Distribution.

el proceso de aplicar un método de análisis estructurado, tal como el análisis orientado a objetos (Larman,2002). Esto implica analizar el sistema y desarrollar un conjunto de modelos gráficos del sistema, como los modelos de caso de uso, que luego sirven como especificación del sistema. ingeniería de requerimientos. estudio de factibilidad. adquisición de requerimientos.

Prácticamente en todos los sistemas cambian los requerimientos. Las personas implicadas desarrollan una mejor comprensión de qué quieren que haga el software; la organización que compra el sistema cambia; se hacen modificaciones al hardware, al software y al entorno organizacional del sistema. A este proceso se le llama. administración de requerimientos. ingeniería de requerimientos. adquisición de requerimientos.

Las fuentes de información durante esta fase incluyen documentación, participantes del sistema y especificaciones de sistemas similares. Descubrimiento de requerimientos. Clasificación y organización de requerimientos. Priorización y negociación de requerimientos. Especificación de requerimientos.

en esta fase, los participantes varían desde administradores y usuarios finales de un sistema hasta participantes externos como los reguladores, quienes certifican la aceptabilidad del sistema. Descubrimiento de requerimientos. Clasificación y organización de requerimientos. Priorización y negociación de requerimientos. Especificación de requerimientos.

pueden venir del dominio de aplicación y de otros sistemas que interactúan con el sistema a especificar. Todos ellos deben considerarse durante el proceso de adquisición de requerimientos. requerimientos. datos técnicos. usuarios.

En su forma más general, un escenario puede incluir: 1. Una descripción de qué esperan el sistema y los usuarios cuando inicia el escenario. 2. Una descripción en el escenario del flujo normal de los eventos. 3. Una descripción de qué puede salir mal y cómo se manejaría. 4. Información de otras actividades que estén en marcha al mismo tiempo. 5. Una descripción del estado del sistema cuando termina el escenario.

que las compañías que administran proyectos que usan código abierto deben: Establecer un sistema para mantener la información sobre los componentes de código abierto que se descargan y usan. Tienen que conservar una copia de la licencia para cada componente que sea válida al momento en que se usó el componente.Las licencias suelen cambiar, así que necesita conocer las condiciones acordadas. Estar al tanto de los diferentes tipos de licencias y entender cómo está autorizado un componente antes de usarlo. Puede decidir el uso de un componente en un sistema, pero no en otro, porque planea usar dichos sistemas en diferentes formas. Estar al tanto de los diferentes tipos de licencias y entender cómo está autorizado un componente antes de usarlo. Puede decidir el uso de un componente en un sistema, pero no en otro, porque planea usar dichos sistemas en diferentes formas. Educar al personal acerca del código abierto. No es suficiente tener procedimientos para asegurar el cumplimiento de las condiciones de la licencia. También es preciso educar a los desarrolladores sobre el código abierto y el permiso de éste. Tener sistemas de auditoría. Los desarrolladores, con plazos ajustados, pueden sentirse tentados a quebrantar los términos de una licencia. Si es posible, debe tener software para detectar y evitar esto último. Participar en la comunidad de código abierto. Si se apoya en productos de código abierto, debe participar en la comunidad y ayudar a apoyar su desarrollo.