€¦ · web viewingeniería de software es el estudio de los principios y metodologías para el...

Actividades / Productos de Trabajo Tareas Teoría Actividad de Aprendizaje Instrucciones DG y PW

1. Fundamentación

a. ¿Qué es la ingeniería de Software?

Ingeniería de software es una disciplina que ofrece métodos y técnicas para desarrollar y mantener software.

Algunas definiciones de Ingeniería de software son:

Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).

Ingeniería de software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)

Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como desarrollo de software o producción de software (Bohem, 1976).

Ingeniería de software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).

DW y PW:

b. Especificación de requisitos

La Especificación de Requisitos Software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación (Como por ejemplo restricciones en el diseño o estándares de calidad).

Básicamente, un requisito del software es una característica que se debe exhibir para solucionar un cierto problema en el del mundo real. La guía se refiere a requisitos de “software” porque se refiere a los problemas que se tratarán por el software. Por lo tanto, un requisito del software es una característica que se debe exhibir por el software desarrollado o adaptado para solucionar un problema particular.

¿Por qué son importantes los requisitos?

Un proceso efectivo de la Especificación de Requisitos se enfoca en la intersección de intereses de todos los Stakeholders.

Cliente Patrocinador Responsable de Administración de Proyectos Específicos (RAPE) Responsable de Gestión de Proyectos (RGPY) Responsable de Desarrollo y Mantenimiento de Software (RDM) Analistas Usuarios Desarrolladores Etc,

Definición de Requisito de Software

Una condición que debe ser cumplida para que el cliente encuentre ACEPTABLE el producto o servicio proporcionado. Una condición o capacidad necesitada por un usuario para solucionar un problema o lograr un objetivo. (IEEE Standard Glossary of Software

Engineering Terminology (1990) ) Constituyen la definición del sistema que se va a construir o mejorar Los requisitos son una especificación de lo que debe estar implementado. Son descripciones de cómo el sistema debe comportarse, o una

propiedad o atributo del sistema. Puede ser una restricción en el proceso de desarrollo del sistema. Un requisito es una propiedad que un producto debe tener para proveer valor a un Stakeholder.

Las especificaciones de Requisitos no incluyen:

Detalles de diseño o implementación Información de planeación de proyecto, o información de pruebas. Una solicitud informal de alguien en una reunión, un pasillo o un elevador o una llamada telefónica Solicitudes de clientes por medio de encuestas, correos electrónicos o buzones de sugerencias

Actividad 1

Elaborar un documento de Especificación de requisitos en base al anexo

dms_anexo_1.docx

Descargar Anexo: Anexo 1 (dms_anexo_1.docx)

Plantilla propuesta para realizar la actividad:

Descargar plantilla: Especificación de Requisitos (dms_especificacion_de_requisitos_plantilla.doc)

DW y PW: Al darle clic en cada uno de las palabras en negritas que aparezcan su definición (tooltip)

Stakeholders: «quienes pueden afectar o son afectados por las actividades del proyecto ». Partes involucradas en el proyecto.

Cambios

Figura 1:Sustituir palabras:

Requerimientospor “Requisitos”Ejemplo: Requerimientos del negocio seria “Requisitos del negocio”.

SRS por “Especificación de Requisitos”

Observaciones o comentarios durante reuniones de ventas o de publicidad

Para que sea un requisito: Debe ser solicitado formalmente Debe ser documentado Debe ser analizado formalmente para verificar el impacto en el proyecto Debe ser aprobado

Características que deben de tener los requisitos: Completo Correcto Factible Necesario Priorizado No ambiguo Verificable Rastreable

Algunos de los riesgos de requisitos más comunes:

Participación insuficiente del usuario Requisitos que crecen progresivamente Requisitos ambiguos Especificación mínima Pasar por alto clases de usuarios Planeación incorrecta

Las organizaciones que implementan un buen proceso de ingeniería de requisitos pueden cosechar múltiples beneficios. Los posibles beneficios que se podrían disfrutar en cuanto ahorro de tiempo y dinero:

1. Menos defectos en los requisitos2. Reducir el retrabajo3. Disminución de propiedades innecesarias4. Rápido desarrollo5. Disminución de la falta de comunicación6. Menos caos7. Estimaciones más aproximadas8. Satisfacción del cliente y del equipo

Existen niveles de requisitos

Figura 1 Niveles de Requisitos

Requisitos del Negocio: representan los objetivos de alto nivel de la organización o del cliente que requiere el sistema. Típicamente provienen del patrocinador principal del proyecto Describen porqué la organización está implementando el sistema (los objetivos a alcanzar).

Ejemplos:Reducir el tiempo de configuración del sistema en un 30% para considerar los cambios en los impuestos que ocurran.Estar entre los 3 mejores productos del mercado, facilitando al usuario la tarea de actualizar la definición de los virus.Incrementar las ventas en un 20% al proveer la capacidad a los usuarios de corregir errores ortográficos.

Los requisitos de negocio también pueden describirse como “features”. Una feature es un conjunto de requisitos funcionales relacionados que proveen una capacidad al usuario y conduce a la satisfacción de un objetivo de negocio. Por lo regular pueden verse como las características en la descripción de un producto, y que probablemente sean los puntos por los cuales un cliente tome la decisión de adquirir dicho producto.

Ejemplos:Actualización automática de cambios en códigos de impuestos.Actualización automática de protección contra nuevos virus.Corrector ortográfico.

Requisitos de Usuario: Describen los objetivos del usuario o tareas que los usuarios deben de ser capaces de ejecutar con el producto. Una de las formas para representar requisitos de usuario son los Casos de Uso.

Ejemplos de Casos de Uso serían:“Capturar una factura” (en algún sistema POS)“Dar de alta a un nuevo cliente” (en algún sistema de Ventas)“Realizar reservación” (en un sistema de línea hotelera sobre la Web) “Imprimir estado de cuenta” (en algún sistema bancario)

Requisitos Funcionales: Especifican la funcionalidad del software que los desarrolladores deben de construir en el producto para posibilitar a los usuarios a completar sus tareas y que a su vez satisfagan los requisitos del negocio. Por lo regular, estos requisitos complementan a los casos de uso.

Algunos ejemplos son:“El sistema deberá enviar vía e-mail la confirmación de la reservación al usuario”.“El sistema permitirá al usuario reordenar la visualización de las facturas: por cliente, por fecha y por concepto”.

Requisitos No Funcionales: Además de los requisitos funcionales existen los no funcionales. Entre los principales tipos de requisitos no funcionales se tienen los siguientes:

Atributos de calidad. Aumenta la descripción de la funcionalidad del producto describiendo las características en varias dimensiones que son importantes para los usuarios como para los desarrolladores.

Reglas de negocio. Incluyen políticas corporativas, regulaciones de gobierno, estándares de la industria, prácticas contables, algoritmos computacionales.

Restricciones. Impone restricciones sobre las opciones disponibles para el desarrollador para cuestiones de diseño y construcción del producto.

Ejemplo:Considera un programa de procesamiento de palabras.

Un requerimiento del negocio podría ser: “Incrementar las ventas en Latinoamérica en un 20% en el primer trimestre del próximo año al permitir a los usuarios corregir errores ortográficos en un documento, de manera eficiente.”

La portada de la caja del producto anuncia que un corrector ortográfico es incluido como una “feature” que satisface este requisito de negocio.

Los correspondientes requisitos de usuario podrían incluir tareas (casos de uso) tales como “Buscar errores ortográficos” y “Agregar palabra al diccionario global”.

El corrector ortográfico tiene muchos requisitos funcionales individuales, los cuales consisten en operaciones tales como “buscar y resaltar una palabra incorrecta”, “desplegar un cuadro de diálogo con sugerencias”, y “reemplazar globalmente palabras incorrectas con palabras correctas”.

La palabra “usabilidad” especificaría el significado de la palabra “eficiencia” en el requisito de negocio y corresponde a un atributo de calidad. Podemos encontrar otro requisito no funcional en forma de Restricción (“para el primer trimestre del próximo año”).

Especificación de Atributos de Calidad (Requisitos No Funcionales)

Interface con el UsuarioIU1. “Un usuario entrenado deberá ser capaz de registrar una petición completa de un producto de un vendedor en un promedio de 4 a 6 minutos.”IU2. “Un usuario quien nunca ha utilizado el sistema antes, deberá ser capaz de registrar una solicitud de un pedido de manera correcta en un tiempo no mayor a 10 minutos.”

Interfases Externas (con Software o Hardware)IE1. “El sistema deberá ser capaz de comunicarse con el módulo de RH.”

ConfiabilidadC1. “No más de 5 ejecuciones experimentales de 1000 pueden ser perdidas debido a fallas en el software.”

DisponibilidadD1. “El sistema estará disponible el 99.5 % del tiempo en días de trabajo entre las 6 am y las 12 am, y al menos el 99.95 % del tiempo en días de trabajo entre 4 pm y 6 pm.”

EficienciaE1. “Toda página web deberá ser cargada a lo más en 15 segundos sobre una conexión por modem de 50 KBps.”E2. “La autorización de una petición de retiro en un ATM no deberá tomar más de 10 segundos.”

MantenimientoM1. “Un programador deberá ser capaz de modificar los reportes existentes con 20 horas o menos de esfuerzo en desarrollo.”M2. “Las llamadas a funciones no deberán pasar de 2 niveles de anidamiento.”

PortabilidadP1. “El módulo de facturación deberá ser capaz de ejecutarse sobre cualquier terminal PC con sistema operativo Linux o Windows.”

InteroperatividadIO1. “El sistema interactuará con el sistema de nómina ya existente en la empresa.”

ReusabilidadRU1. “El módulo de facturación deberá ser capaz de reusarse para otros proyectos”

Restricciones de Diseño y ConstrucciónRDC1. “El sistema deberá ser desarrollado sobre la plataforma J2EE la cual es la infraestructura tecnológica de la empresa.”RDC2. “Todo el módulo de inventarios deberá ser construido utilizando las librerías existentes en la empresa.”

Legales y ReglamentariosLR1. “El sistema deberá implementar las regulaciones del gobierno actual.”LR2. “El costo unitario del producto será de $50 en compras de 100 o más unidades, y en compras de menos unidades el costo unitario será de $70.”LR3. “Por cada tres retardos que un empleado acumule a lo largo del mes actual, se le descontará un día de sueldo.”

c. Casos de Uso¿Qué es un caso de uso?

Describen una interacción típica entre un usuario (actores) y un sistema de cómputo. Es una técnica para capturar información de cómo un sistema o negocio trabaja actualmente, o de cómo se desea que trabaje Produce algo de valor para algún actor como el cálculo de algún resultado Describe qué hace un sistema pero no especifica cómo lo hace El caso de uso capta alguna función visible para el usuario. El caso de uso puede ser pequeño o grande. El caso de uso logra un objetivo discreto para el usuario. Un caso de uso debe ser simple, claro y conciso

¿Para que sirven los casos de uso?

Para capturar el comportamiento deseado del sistema sin tener que especificar como se implementa ese comportamiento Como medio de comprensión del sistema para desarrolladores, usuarios finales y expertos del dominio Ayudan a validar la arquitectura y a verificar el sistema en el transcurso del desarrollo de este

¿Cómo se representan?

Un caso de uso se representa en UML como un óvalo:

Figura 2 Nombre del Caso de Uso

En UML, un actor se representa de la siguiente manera:

Figura 3 ActorActores

Representa un conjunto de roles que los usuarios de los casos de uso juegan al interactuar con éstos Representa un rol que es jugado por una persona, un dispositivo hardware u otro sistema que interactúe con nuestro sistema Se puede definir categorías generales de actores (como cliente) y especializarlos (como ClienteComercial) a través de relaciones de

generalización Un actor y un caso de uso se pueden comunicar a través de una asociación en donde cada uno de ellos pueden enviar y recibir mensaje.

Actividad 2

En base al anexo dms_anexo_2.docx

Realizar las siguientes actividades:

dms_anexo_2.docx


1.- Realice el diagrama de casos de uso del sistema. Este diagrama debería tener al menos una relación de inclusión o de extensión.2.- Tome de la pregunta anterior los dos casos de uso relacionados por la extensión o los dos casos de uso relacionados por la inclusión y realice sus respectivas descripciones textuales completas.

Figura 4 Ejemplo de actoresDiagramas de casos de uso

Los casos de uso pueden estar relacionados con actores o con otros casos de uso; gráficamente una relación vendrá dada por una línea entre los casos de uso y/o actores relacionados, siendo que el extremo de dicha línea dependerá del tipo de relación; en principio tenemos cuatro tipos posibles:

• Comunicación (relación entre un actor y un caso de uso con el que interactúa; se representa símplemente con una línea).• Uso (include, includes, uses; se representa por una flecha apuntando en el sentido de la relación).• Extensión (extend, extends; gráficamente la representación es la misma que para "uso").• Generalización (se trata del concepto de herencia, habitual en los diagramas de clases, pero aplicado entre casos de uso, e incluso entre actores; se representa por una flecha con un triángulo vacío por punta señalando en el sentido de la relación).

Por ahora nos centraremos en las relaciones de uso y extensión.

Relación <<include>>.Es una simple relación de inclusión, es decir, los escenarios o situaciones posibles detalladas en un caso de uso están incluidas en otro caso de uso (aquel del que, gráficamente, parte la flecha).

Relación <<extend>>.Este tipo de relación refleja situaciones particulares en un caso de uso que pueden ser tratadas (extendidas) por otro. En la descripción del caso de uso que es extendido debe haber una forma de indicar en que punto entra en juego el caso de uso que lo extiende (punto de extensión); esto se representa mediante una "etiqueta" (un texto significativo entre paréntesis) como referencia del lugar donde entraría a formar parte del caso de uso extendido.

Figura 5 Ejemplo de relaciones

flujo de eventos

Una vez expuestos los principales tipos de relación que vamos a encontrar en los diagramas de casos de uso es buen momento para hacer referencia a la descripción que acompaña a cada caso de uso. Hasta aquí hemos tenido en cuenta principalmente la representación gráfica, sin embargo, aparte de esta, un diagrama de casos de uso llevará asociada una descripción textual, en forma de flujos de eventos, de cada caso de uso representado. Surgen aquí dos tipos de apartado a tener en consideración:

Flujo de eventos principalSe trata de una descripción de los eventos que van aconteciendo en el uso habitual, es decir, cuando no se presenta ningún tipo de problema (es el denominado happy path).

Flujo de eventos excepcionalPodemos encontrar tantos apartados de este tipo como situaciones excepcionales se puedan plantear, siendo que para cada uno de estos escenarios atípicos se definirá el flujo de eventos correspondiente.

Ejemplo:

Caso de uso: Hacer pedido.Flujo de eventos principal:• includes(Validar Usuario)• El sistema muestra una lista con los datos de una serie de productos seleccionables• El cliente selecciona los items que desea comprar y sus respectivas cantidades.• El cliente valida la selección.• El sistema recoge la lista de items seleccionados por el cliente.• (Establecer prioridad)• El sistema envía los datos del pedido para su proceso.• Fin del caso de uso.

Flujo de eventos excepcional:• El cliente valida un pedido en que no ha seleccionado ningún producto.• El sistema vuelve a mostrar la lista de productos seleccionables.

Flujo de eventos excepcional:• El cliente valida un pedido en que la cantidad seleccionada para un producto excede de la disponible.• El sistema lo notifica al cliente y muestra la lista de productos seleccionados dando opción a cambiar la cantidad del producto.

En UML, cada caso de uso debe tener al menos un actor. Esta forma de ver el sistema nos ayuda a concebirlo como un todo.

Un diagrama de casos de uso es un diagrama que muestra un conjunto de casos de uso, actores y sus relaciones.

Son importantes para modelar el comportamiento de un sistema. Normalmente los casos de uso contienen:

o Casos de Usoo Actoreso Relaciones de dependencia, generalización y asociación.

Cubren principalmente el comportamiento del sistema, Es un tipo especial de diagrama, por su contenido particular. Para modelar el contenido de un sistema Para modelar los requisitos de un sistema Especificar que debería hacer el sistema, independientemente de cómo se haga, se especificará el comportamiento deseado del sistema.

Conclusiones:

Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué). Los Casos de Uso son qué hace el sistema desde el punto de vista del usuario. Es decir, describen un uso del sistema y cómo este interactúa

con el usuario. Los diagramas de casos de uso muestran las relaciones entre los casos de uso de un sistema y sus actores. En una relación << extends>>, un actor que lleve a cabo el caso de uso base puede realizar o no sus extensiones. Mientras, en una relación

<<include>> el actor que realiza el caso de uso base también realiza el caso de uso incluido.

d. Técnicas para recolectar requisitos

Existen diversas técnicas de recolección de requisitos:

Entrevistas Cuestionarios Talleres de Recolección de Requisitos Lluvia de Ideas Observar como trabajan los usuarios Prototipos Casos de uso (Escenarios)

Actividad 3

Escoger una técnica de recolección de requisitos y elaborar un resumen (mínimo una cuartilla)

e. Análisis y Diseño: Descripción Arquitectónica

La vista arquitectural de un sistema es abstracta, proporcionando detalles acerca de la implementación, los algoritmos, la representación de datos e incluso el comportamiento y la interacción entre elementos (cajas negras - black box).

Definición Arquitectura de Software

“La Arquitectura es definida por la práctica recomendada como la organización fundamental de un sistema, plasmada en sus componentes, sus relaciones a cada uno y el entorno, y los principios que gobiernan su diseño y evolución.” ( IEEE )

“La Arquitectura de Software de un programa o sistema de computadora es la estructura o estructuras del sistema, la cual comprende componentes de software, propiedades externamente visibles de dichos componentes, y las relaciones entre ellos.” (Software Engineering Institute, Carnegie Mellon University )

Implicaciones de la definición

Actividad 4




1.- Diseñar la vista Física y vista lógica.

DW y PW:

Cambios

Figura 6:Sustituir palabras:

Requerimientospor “Requisitos”Ejemplo: Requerimientos del negocio seria “Requisitos del negocio”.

Una arquitectura es una abstracción de sistemaso La arquitectura define componentes y cómo interactúan.o La arquitectura suprime información local; los detalles privados de un componente NO son parte de la arquitectura.

Los sistemas tienen muchas estructuras (vistas)o Ninguna vista por sí sola es la arquitectura.o El conjunto de vistas a documentar puede variar.

Todo sistema tiene una arquitecturao Todo sistema está compuesto de componentes y relaciones entre ellos.o En el caso más simple, un sistema está compuesto por un único componente, relacionado a él mismo.

Architecture Business Cycle – ABC

Los requisitos no determinan del todo la arquitectura, más bien está es además resultado de influencias en los ambientes técnicos, sociales y del negocio.Llamaremos a este ciclo de influencias, del ambiente a la arquitectura y de la arquitectura al ambiente como “El Ciclo de la Arquitectura de Negocios (Architecture Business Cycle - ABC)”.

¿Por qué es importante la Arquitectura de un sistema?La arquitectura afecta los aspectos técnicos y de negocio de una organización. Estas son influenciadas por:

Stakeholders de un sistema Factores técnicos y organizacionales Experiencia y conocimiento del arquitecto

1. Accionistas (Stakelholders) de un sistema

Muchas personas y organizaciones están interesadas en la construcción de un sistema de software. Llamamos a estos stakeholders: el cliente, los usuarios finales, los desarrolladores, el administrador del proyecto, etc. Los stakeholders tienen diferentes preocupaciones que desean que el sistema garantice,

El problema de fondo, por supuesto, es que cada stakeholder tiene diferentes preocupaciones y objetivos, algunos de los cuales pueden ser contradictorias. Estas pueden ser enumeradas y discutidas, por supuesto, en un artefacto como un documento de requisitos.

La realidad es que el arquitecto a menudo tiene que llenar los espacios en blanco y mediar los conflictos entre ellos.

Factores técnicos y organizacionales

Factores técnicos

Un caso en particular de los antecedentes del arquitecto y la experiencia se refleja en el entorno técnico. La arquitectura será influenciada por el ambiente actual tecnológico de la organización. Puede incluir prácticas estándar de la industria o las técnicas de ingeniería de software común en la comunidad profesional del arquitecto.

Factores organizacionales

Problemas del negocio a corto plazoo Amortizar la infraestructurao Mantener bajos los costos de instalación

Problemas del negocio a largo plazoo Invertir en una infraestructura para metas estratégicaso Invertir en personal

3. Experiencia y conocimiento del arquitecto

Los arquitectos desarrollan su criterio de sus experiencias pasadas: Anteriores experiencias exitosas conducirán a volver a ser aplicadas.

SRS por “Especificación de Requisitos”

Anteriores experiencias negativas serán excluidas en nuevos diseños.

Factores influenciados por una arquitectura

Estructura de la organización de desarrolloo Corto plazo: Unidades de trabajo son organizadas alrededor de unidades arquitectónicas para un sistema particular en construccióno Largo plazo: Cuando la empresa construye una colección de sistemas similares, unidades organizacionales reflejan componentes

comunes Metas empresariales

o El desarrollo de un sistema puede establecer una huella en un nicho de mercadoo Ser conocidos por desarrollar particulares tipos de sistemas llega a ser un arma de mercadotecniao La arquitectura llega a ser una ventaja para nuevas oportunidades en el mercado

Requisitos de clientes Conocimiento de sistemas similares conducen a los clientes a pedir características particulares Los clientes alterarán los requisitos sobre la disponibilidad de sistemas existentes

Experiencia del arquitecto La creación de nuevos sistemas afecta la experiencia del arquitecto

Importancia de una Arquitectura

Una arquitectura es importante por al menos tres razones: Provee un vehículo para comunicación entre los stakeholders Es la manifestación de las decisiones de diseño tempranas acerca del sistema Es una abstracción transferible y reutilizable de un sistema

¿Qué hace buena a una arquitectura?Una arquitectura debería ...

ser producto de un arquitecto o un pequeño grupo de arquitectos con un líder definido. estar bien documentada, con al menos una vista dinámica y una vista estática, utilizando una notación que los stakeholders puedan entender

fácilmente. presentarse como una implementación incremental, para poder diseñar un esqueleto del sistema, mostrando primero la mínima funcionalidad

y después como puede ir creciendo. ser diseñada por arquitectos que cuentan con los requisitos funcionales y no funcionales del sistema.

EJEMPLO. Representación de una Arquitectura de Software poco informativa.

Figura 6 Ejemplo Representación de una Arquitectura de Software poco informativa.¿Qué está mal en el diagrama?

Muchas cosas no están especificadas:

o ¿Qué tipo de componentes son?o ¿Qué tipo de conectores son?o ¿Qué significan los círculos y las flechas?o ¿Cuál es el significado del “layout” (jerárquico)?o ¿Por qué está el proceso de control al nivel más alto?

Figuras y flechas dibujadas solitas no son una arquitectura; sin embargo son un punto de partida ¿Cuál estructura? El software se compone de muchas estructuras:

o Móduloso Tareaso Funcioneso Hardwareo Clases

De esta manera, al ver figuras y líneas debemos preguntar:o ¿Qué representan las figuras?o ¿Qué significan las flechas/líneas?

Lenguajes para documentar arquitecturas

Para documentar una arquitectura se pueden utilizar ADLs (Architecture Description Languages) También, una arquitectura puede ser modelada con UML.

Documentación de la Arquitectura

En una casa hay planos para cuartos, cableado eléctrico, plomería, ventilación, etc. Cada una de estos planos constituye una “vista” de la casa. Estas vistas son:

Usadas por diferentes personas Usadas para conseguir diferentes cualidades en la casa Usadas como una descripción y prescripción

Entonces, lo mismo es con una arquitectura de software

Las 4+1 vistas de Kruchten

El enfoque 4+1 vistas fue desarrollado originalmente por Philippe Kruchten en 1995. Las distintas vistas del enfoque responden a las necesidades de las distintas partes interesadas: clientes, programadores, administradores, etc.

La vista de desarrollo le dice al programador como iniciar y organizar su código; la vista física ayuda a los administradores de sistemas a decidir la infraestructura que se ha de dedicar al sistema; la vista de procesos es útil para realizar análisis de integridad y tomar decisiones de integración con otros sistemas; finalmente, la vista lógica le sirve a los usuarios y clientes a visualizar la funcionalidad que el sistema les provee.

(Planos Arquitect´onicos: El Modelo de “4+1” Vistas de la Arquitectura del Software¤, Philippe Kruchten)Figura 7 Vistas de Kruchten

Vista Lógica

La arquitectura lógica apoya principalmente los requisitos funcionales –lo que el sistema debe brindar en términos de servicios a sus usuarios. El sistema se descompone en una serie de abstracciones clave, tomadas (principalmente) del dominio del problema en la forma de objetos o clases de objetos. Aquí se aplican los principios de abstracción, encapsulamiento y herencia. Esta descomposición no sólo se hace para potenciar el análisis funcional, sino también sirve para identificar mecanismos y elementos de diseño comunes a diversas partes del sistema.

Figura 8 Ejemplo de Vista lógica

Vista de Desarrollo

Es usada para describir los módulos del sistema. Los módulos son bloques de construcción más grandes que las clases y los objetos y varía acorde al entorno de desarrollo. Paquetes, subsistemas y librerías de clases son considerados módulos.

También se puede utilizar para estudiar el alojamiento de los archivos en el sistema y el entorno de desarrollo. Alternativamente, es una buena manera para ver las capas del sistema en una arquitectura en capas. Una arquitectura en capas típica podría contener la capa de Interfaz de Usuario, una capa de lógica del negocio y una capa de persistencia.

Figura 9 Ejemplo de vista de Desarrollo

El ejemplo es un diagrama de paquetes mostrando cómo los paquetes están anidados en el sistema.

Vista Física

Describe cómo la aplicación es instalada y cómo se ejecuta en una red de computadoras. Esta vista toma en cuenta los requisitos no funcionales como disponibilidad, confiabilidad, rendimiento y escalabilidad.

Figura 10 ejemplo de Vista Física

Vista de Escenarios

Esta vista consiste de casos de usos y escenarios que describen o consolidan las otras vistas. La vista de casos de uso consiste de diagramas de casos de uso detallando las acciones y condiciones dentro de cada caso de uso.

Figura 11 Ejemplo de Vista de Escenarios

Vista de Procesos

Se refiere más al control de la concurrencia. A cómo los procesos interactuarán entre sí (protocolos de concurrencia) No muy tomada en cuenta en el desarrollo de sistemas de información.

Resumiendo: Vista lógica nos permitirá alcanzar los requerimientos funcionales. ¿Cuáles partes van juntas? ¿Cuáles son las clases y sus relaciones? Vista de proceso ayuda a lograr los requerimientos no-funcionales, como el desempeño y la disponibilidad. ¿Cuáles necesidades de control

hay? ¿Qué actividades pueden ser concurrentes? ¿Qué sincronización debe haber? Vista de desarrollo ayuda a administrar el proyecto. ¿Cuál parte hará cada elemento del equipo de gente? ¿Que partes pueden reusarse? Vista física ayuda a alcanzar los requerimientos no-funcionales, haciendo una vista más concreta que la de proceso. ¿Cuales partes correrán

en la misma computadora? Vista Escenarios nos permite representar la parte funcional de un sistema.

f. Análisis y Diseño: Descripción Detallada

¿Qué es el Diseño del Sistema?

Definición lógica de la forma en que se construye el software que cumplirá con los requisitos

Actividad 5


El CÓMO del sistema Incluye: Funciones, módulos, tablas, bases de datos, clases, hardware, componentes, etc.

¿Qué es UML?

El UML modela sistema mediante el uso de objetos que forman parte de él así como, las relaciones estáticas o dinámicas que existen entre ellos.

UML puede ser utilizado por cualquier metodología de análisis y diseño orientada por objetos para expresar los diseños. UML es un Lenguaje de Modelado Unificado basado en una notación gráfica la cual permite: especificar, construir, visualizar y documentar los

objetos de un sistema programado. Este lenguaje es el resultado de la unificación de los métodos de modelado orientados a objetos de Booch, Rumbaugh (OMT: Object Modeling

Technique) y Jacobson (OOSE: Object-Oriented Sotfware Engineering). UML es un lenguaje de modelado que sirve para visualizar, especificar , construir y documentar un sistema software.

UML para visualizar

Símbolos con semántica bien definida. UML transciende al lenguaje de programación. Modelo explícito, que facilita la comunicación.

UML para especificar Especificar es equivalente a construir modelos que cumplan las condiciones de no ambigüedad y completitud. UML cubre la especificación del análisis, diseño e implementación de un sistema software.

UML para construir

No es un lenguaje de programación Pero sus modelos pueden conectarse a una gran variedad de lenguajes de programación

UML para documentar

UML cubre la documentación de un sistema:o Requisitoso Arquitecturao Diseñoo Código fuenteo Planificacióno Pruebaso Prototiposo Versiones

Los 9 diagramas de UML



1.- Realice el diagrama de clases2.- Realice el diagrama de secuencia

Figura 12 Diagramas de UML

Diagramas de caso de uso

Estos ya se vieron en la fase de requisitos

Ejemplo

Figura 13 Ejemplo Diagrama caso de uso

Diagrama de clases

Un diagrama de clases o estructura estática muestra el conjunto de clases y objeto importantes que forman parte de un sistema, junto con las relaciones existentes entre clases y objetos. Muestra de una manera estática la estructura de información del sistema y la visibilidad que tiene cada una de las clases, dada por sus relaciones con los demás en el modelo.

Clase: representa un conjunto de entidades que tienen en común propiedades, operaciones, relaciones y semántica.Una clase es un constructor que define la estructura y comportamiento de una colección de objeto denominados instancia de la clase.En UML la clase está representada por un rectángulo con tres divisiones internas, son los elementos fundamentales del diagrama.

Figura 14 Ejemplo de claseAtributo: Representa una propiedad de una entidad. Cada atributo de un objeto tiene un valor que pertenece a un dominio de valores determinado.Las sintaxis de una atributo es: Visibilidad <nombre>: tipo = valor { propiedades}Donde visibilidad es uno de los siguientes:

+ público.

# protegido. - privado.

Operación: El conjunto de operaciones que describen el comportamiento de los objetos de una clase.La sintaxis de una operación en UML es: Visibilidad nombre (lista de parámetros): tipo que retorna { propiedades}

Figura 14 Ejemplo Clase

Objeto: es una instancia de una clase. Se caracteriza por tener una identidad única, un estado definido por un conjunto de valores de atributos y un comportamiento representado por sus operaciones y métodos.

Los atributos no deberían usarse para relacionar conceptos en el modelo conceptual, solamente para describir estos conceptos. Una de las violaciones más comunes a esta regla consiste en agregar atributos como llaves foráneas.

Las operaciones son utilizadas para manipular los atributos o realizar otras acciones. Normalmente son llamadas funciones, pero están dentro de una clase y pueden aplicarse solo a objetos de esa clase.

Se conoce como la firma de la operación a el nombre de la operación su tipo de valor que regresa y los parámetros que utiliza.

Un objeto se especifica con una firma o con precondición, post-condición algoritmo y el efecto que tiene sobre un objeto. La precondición debe ser cierta antes de que la operación pueda ejecutarse. La post-condición debe ser cierta después de que la operación sea ejecutada. Estas especificaciones son como propiedades para una operación. Las propiedades usualmente no se muestran directamente en los diagramas

de clases.

Una clase persistente es aquella cuyos objetos existen aún después de que el programa que los creó ha salido. Se describe la persistencia poniendo la propiedad de “persistent ” dentro del compartimiento del nombre.

Un constructor es una operación que comparte el mismo nombre que la clase y no tiene tipo definido de retorno, se utilizan generalmente para inicializar la memoria requerida por el objeto y para colocarlo en un estado inicial estable. Algunos lenguajes proveen un constructor default para las clases en caso de que no se proporcione.

Relaciones entre clases

Asociación, es una conexión entre clases, lo que significa que también es una conexión entre los objetos de esas clases. En UML, una asociación es una relación que describe un conjunto de ligas, que están definidas como una conexión semántica entre un conjunto de objetos

Nombre: Identifica la asociación entre los objetos, caracterizándola.Rol: Identificado como un nombre a los finales de la línea, describe la semántica de la relación en el sentido indicado. Cada asociación tiene dos roles; cada rol es una dirección en la asociación. El rol puede estar representado en el nombre de la clase.

Figura 15 ejemplo de asociación

Las restricciones en las asociaciones, permiten que se siga cierta regla:

Figura 16 Ejemplo de Restricción

Hay asociaciones que establecen una relación en ambas direccionesLa multiplicidad es la cantidad de objetos de una clase que se relacionan con un objeto de la clase asociada:

Figura 15 Ejemplo Multiplicidad

La asociación recursiva es una asociación de una clase a sí misma, una conexión entre objetos de la misma clase

Figura 16 Ejemplo asociación recursiva

Los roles en una asociación especifican el papel que juega un objeto en una relación, se indica con un string colocado cerca de la terminal de la asociación siguiente a la clase a la cual se aplica.

Figura 17 Ejemplo de roles

Tipos de asociaciones

Asociación calificada (Qualified association). Representa la información de identidad y reduce la multiplicidad de uno a muchos por una de uno a uno.

Figura 18 Ejemplo Asociación calificada

Asociación Or {or}. En algunos modelos no todas las combinaciones de asociación son válidas

Ejemplo 19 Asociación Or

Asociación Ordenada {ordered}. Cuando los enlaces entre objetos pueden tener un orden implícito {ordered} {ordenadas por incremento de tiempo}.

Clase de Asociación. Una clase puede estar unida a una asociación. Se usa para agregar información extra sobre un enlace; por ejemplo, el tiempo en que el link fue creado. Cada enlace está asociado a un objeto de la clase de asociación.

Figura 20 ejemplo clase de asociación

Asociación ternaria (Ternary association). Más de dos clases pueden asociarse con otra, la asociación ternaria asocia tres clases.

Figura 21 Ejemplo Asociación ternaria

Una agregación, es un caso especial de asociación, indica que la relación entre las clases es de alguna forma parte de un “todo”. Se describen diferentes niveles de abstracción. Se indica con rombo en blanco en el lado de la clase que agrupa a las demás. Se puede tener una restricción en una agregación, como en la relación {O} que se indica con línea punteada

Figura 22 ejemplo agregación

Una composición es una agregación donde cada componente puede pertenecer tan solo a un todo. Se representa con diamante sólido.

Un juego del gato (#)Figura 23 Ejemplo Composición

La generalización es una relación entre un elemento más general y uno más específico. El elemento más específico puede tener solo información adicional. Se utiliza sobre tipos, nunca sobre instancias (una clase puede heredar otra clase, pero un objeto no puede heredar otro objeto).

La clase específica o subclase, hereda todo de la clase general, llamada superclase. Los atributos, operaciones y todas las asociaciones son heredadas. Una clase puede ser superclase y subclase si esta en una jerarquía de clases. En gráficas de jerarquía, las clases están conectadas unas con otras, vía relaciones de generalización.

Figura 24 Ejemplo de Generalización

Una interfaz es un conjunto de operaciones que especifica cierto aspecto de la funcionalidad de una clase, y es un conjunto de operaciones que una clase presenta a otras. Se usa el símbolo de clase pero sin atributos, solamente con las operaciones:

Figura 25 Ejemplo de Interfaz

Adicionalmente la interfaz puede ser representada como un circulo conectado con una línea a la clase

Figura 26 Ejemplo de Interfaz 2

Modelo Conceptual de Punto de VentaFigura 26 Ejemplo de diagrama de clases

Diagrama de objetos

Un diagrama de objetos en UML usa la misma notación que los diagramas de clases, ya que los objetos solo son instancias de la misma clase.

Figura 27 Ejemplo diagrama de objetosDiagrama de interacción

Estos son modelos que describen como los grupos de objetos que colaboran en algunos ambientes. Por lo general, un diagrama de interacción captura el comportamiento de un único caso de uso. Hay dos tipos de diagramas de interacción: diagramas de secuencia y diagramas de colaboración.

Un diagrama de secuencia muestra la forma en que los objetos se comunican entre sí al transcurrir el tiempo. Constan de objetos y representando en una línea vertical el tiempo, se indican las operaciones que ejecuta el objeto o activación se representan mediante un rectángulo cuya altura va en relación a la duración de la operación.

Los mensajes van de un objeto a otro se representan con líneas. Pueden ser simples (transfieren control), sincrónicos (esperan respuesta) o asincrónicos (no espera respuesta)

Figura 28 Ejemplo de diagrama de secuencia

Para ilustrar los diagramas de secuencia se usará el siguiente caso de uso:

La ventana Entrada de pedido envía un mensaje “prepara” a Pedido.El Pedido envía entonces un mensaje “prepara” a cada línea de pedido dentro del Pedido.Cada Línea de pedido revisa el Artículo de inventario correspondiente.- Si esta revisión devuelve “verdadero”, la Línea de pedido descuenta la cantidad apropiada de Artículo de inventario del almacén.Si no sucede así, quiere decir que la cantidad del Artículo de inventario ha caído más abajo del nivel de reorden y entonces dicho Artículo de inventario solicita una nueva entrega.

Figura 29 ejemplo de diagrama de secuencia

De el objeto se desprende una línea vertical conocida como línea de vida del objeto y representa el tiempo de duración del objeto durante la interacción.

Los mensajes representados por líneas están en orden de arriba hacia abajo. La autodelegación es un mensaje que un objeto se manda a sí mismo.

Una condición indica cuándo se envía un mensaje, el cual se enviará solo si la condición es verdadera. Una iteración muestra cuando un mensaje se envía varias veces a varios objetos receptores, como sucedería cuando se itera sobre una

colección. El regreso indica el regreso de un mensaje, no un nuevo mensaje. Los regresos SATURAN los diagramas y tienden a oscurecer el flujo, El borrado de un objeto se muestra con una X grande. Los objetos pueden autodestruirse o pueden ser destruidos mediante otro mensaje.

Cuando utilizar los diagramas de secuencias, se sugieren para:o Son útiles para ver la interacción entre los objetos, debido a que pone énfasis en la secuencia y es fácil apreciar el orden en el que

ocurren las cosas.o Cuando se desee ver el comportamiento de varios objetos en un caso de uso y la secuencia de los mensajes.

No se sugieren para:o No son convenientes para representar el comportamiento condicional, debido a que son para mostrar un comportamiento simple, se

sugiere usar mejor diagramas separados para cada una de las condicioneso No sirve para ver el comportamiento de un solo objeto a través de muchos casos de uso (usar mejor un diagrama de estados)

o Si quiere ver el comportamiento a través de muchos casos de uso o muchos procesos mejor utilice un diagrama de actividad.

Diagramas de Colaboración:Es una forma de representar interacción entre los objetos, es decir, las relaciones entre ellos y la secuencia de los mensajes de las iteraciones que están indicadas por un número A diferencia de los diagramas de secuencia, pueden mostrar el contexto de la operación (cuáles objetos son atributos, cuáles temporales, etc) y ciclos en la ejecución. Muestra como varios objetos colaboran en un solo caso de uso.

El mensaje se representa como una flecha cerca de la línea de asociación entre dos objetos. Esta flecha apunta al objeto receptor. El tipo de mensaje se mostrará en una etiqueta cerca de la flecha.El mensaje le indicará al objeto receptor que ejecute una de sus operaciones.Un diagrama de secuencias puede ser convertido en uno de colaboraciones y viceversa.Se agregará una cifra al mensaje para indicar la secuencia propia del mensaje.

Figura 30 Ejemplo de diagrama de colaboración

Ejemplo de un diagrama de colaboraciones:o El actor es el usuario quien inicia la interacción al oprimir una tecla, se inicia la siguiente secuencia:

La GUI notifica al sistema operativo que se oprimió la tecla El sistema operativo le notifica a la CPU El sistema operativo actualiza la GUI La CPU notifica a la tarjeta de video La tarjeta de video envía un mensaje al monitor El monitor presenta el carácter alfanumérico en la pantalla, con lo que se hará evidente al usuario.

Figura 31 Ejemplo de diagrama de colaboración

Cuando utilizar los diagramas de colaboración, se sugieren para:o Es la mejor forma si se quiere mostrar los objetos y mostrar como se reconectan estáticamente unos con otros.o Cuando se desee ver el comportamiento de varios objetos en un caso de uso.o Sirven para mostrar la colaboración entre los objetos, sin embargo, no sirven tan bien para la definición precisa del comportamiento

No se sugieren para:o No son convenientes para representar el comportamiento condicional, debido a que son para mostrar un comportamiento simple, se

sugiere usar mejor diagramas separados para cada una de las condicioneso No sirve para ver el comportamiento de un solo objeto a través de muchos casos de uso (usar mejor un diagrama de estados)o Si quiere ver el comportamiento a través de muchos casos de uso o muchos proceso mejor utilice un diagrama de actividad.

Diagrama de Estados

Diagrama de Estados:Muestra el conjunto de estado por los cuales pasa un objeto durante su vida en una aplicación junto con los cambios que permiten pasar de un estado a otro. Esta representado principalmente por los siguientes elementos:

Estado. Elemento. Transición.

Estado: Identifica un período de tiempo del objeto (no instantáneo) en el cual el objeto esta esperando alguna operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos.

Figura 32 ejemplo de Estado

Las actividades cuentan con sucesos y acciones de entrada (qué sucede cuando el sistema entra al estado), salida (Qué pasa cuando el sistema sale del estado) y de hacer (que sucede cuando el sistema está en el estado)

Se puede agregar ciertos detalles a las líneas de transición, para indicar un suceso que provoca una transición (la que desencadena un suceso) y la actividad de cómputo que se ejecute y haga que suceda la modificación de estado.

Figura 33 Ejemplo de un suceso

Las condiciones de seguridad permiten establecer una relación entre estados que dependen de que se cumpla dicha condición.

Figura34 Ejemplo de condiciones de seguridad

Subestados. Cuando un estado se encuentra dentro de otro estado, se conocen como subestados.

Se dice que pueden suceder en forma secuencial cuando suceden uno tras de otro y se representan dentro del cuadro de estado original, ligados secuencialmente. También has subestados concurrentes cuando pueden ocurrir al mismo tiempo. Se representan dentro del estado original, separados por línea punteada.

Figura 35 Ejemplo de Subestado

Cuando utilizar los diagramas de estados:Se tendría que hacer uno por cada clase del sistema, pero se sugiere hacerlos solo para aquellos que presenten un estado interesante y cuando la construcción de tales diagramas ayude a aclarar lo que sucede. Algunos sugieren usarlos en los objetos de interfaz de usuario y de control, debido a que tienen el tipo de comportamiento que es útil describir mediante diagramas de estado. En caso de que se desee representar las secuencias general de acciones de vario objetos y casos de uso, es mejor utilizar el diagrama de actividades

Diagrama de Actividades

Describen como se coordinan las actividades, muestran como puede ser implementada una operación que debe realizar muchas tareas diferentes y se desea mostrar cuales son las dependencias esenciales entre ellas.

Un diagrama de actividades es un caso especial de un diagrama de estados en el cual casi todos los estados son estados de acción (identifican que acción se ejecuta al esta en él) y casi todas las transiciones son enviadas al terminar la acción ejecutada en el estado anterior.Generalmente modelan los pasos de un algoritmo y puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto.Sirven para representar transiciones internas, sin hacer mucho énfasis en transiciones o eventos externos.

Elementos de un diagrama de actividades:La actividad se muestra como una caja con nombre con las esquinas muy redondeadas, representa cuando la actividad ha terminado

Figura 36 Actividad

La transición se muestra como una flecha, normalmente no se les pone etiqueta, a menos que se tenga una condición.

Figura 37 Transición

Barras de sincronización, indica coordinación de actividades y no se puede pasar de la barra hasta que todas las actividades previas a la barra han sido terminadas. Se utilizan para la ejecución de actividades en paralelo.

Figura 38 Barras de sincronización

Las indicaciones, permiten que se ejecuten otras actividades, usando un pentágono convexo para el envío del un evento y uno cóncavo para la recepción del evento.

Figura 39 Indicadores

Diamantes de decisión se usan para mostrar decisiones como una alternativa a las condiciones, para separar transiciones dejando el mismo estado.

Marcas de inicio y fin se usan para indicar donde empieza el diagrama y donde termina. Particiones y líneas de responsabilidad, Al poner muchas actividades relacionadas entre sí, se pueden colocar de acuerdo al objeto o al actor

que las ejecuta, o a cuál caso de uso pertenecen Las principales diferencias entre los diagramas de estado y los diagramas de actividades son: Los diagramas de actividades normalmente NO incluyen eventos, porque los únicos eventos de interés es la terminación de las actividades. Las actividades se pretende que se continúen a lo largo del diagrama sin quedarse estancadas.

Figura 40 Ejemplo diagrama de actividades

Cuando utilizar diagramas de actividades:o Debido a que manejan y promueven el comportamiento en paralelo, son una herramienta muy útil para el modelado de flujo de

trabajo y para la programación multihilos.o Se recomienda usarlos para:

El análisis de un caso de uso. Para comprender qué acciones deben ocurrir y cuáles son las dependencias de comportamiento. Asignando posteriormente los métodos a los objetos y mostrando tales asignaciones mediante diagramas de secuencia o colaboración.

La comprensión del flujo de trabajo, a través de numerosos casos de uso. Para representar y entender el comportamiento de las interacciones entre los casos de uso. Ayuda a aclarar situaciones dominadas por flujo de trabajo.

Cuando se trata de aplicaciones multihilos. Son adecuados en éste usoo No sirven para:

Tratar de ver como colaboran los objetos. Usar mejor diagramas de secuencia o colaboración. Para tratar de ver como se comporta un objeto durante su período de vida. Es mejor usar un diagrama de estados.

Diagrama de Componentes

Los diagramas de componentes describen los elementos físicos reemplazables del sistema y sus relaciones Muestran las opciones de realización incluyendo código fuente, binario y ejecutable Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por

otro componente

Hay diferentes tipos de componentes y cada uno con diferentes tipos de dependencia , Clasificándolos en relación con el proceso de compilación un componente podría ser:

Código fuente, el cual depende de que otros componentes estén disponibles al momento de compilación. Código objeto binario, (biblioteca de clases) que depende de cualquier código objeto al cuál se ligara desde un programa ejecutable. Una aplicación ejecutable, la cuál puede depender de otros programas ejecutables al tiempo de ejecución.

Los detalles dependen del lenguaje de programación usado, se pueden usar estereotipos como «compilar» ó «ligar», igualmente se pueden usar estereotipos para diferenciar los diferentes tipos de componentes, por ejemplo: «archivo» , «biblioteca» , «ejecutable» , «tabla», «documento»

Cada clase del modelo lógico se realiza en dos componentes: la especificación y el cuerpo. La especificación contiene la interfaz de la clase mientras que el cuerpo contiene la realización de la clase. En el caso de clases parametrizables se puede dar una especificación genérica. Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente se refiere a los servicios

ofrecidos por otro. Los distintos componentes pueden agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación. Son paquetes

estereotipados en «subsistemas» para incorporar la noción de biblioteca de compilación y de gestión de configuración.

Un diagrama de componentes mostrando las dependencias de tiempo de compilación:

Figura 41 Ejemplo diagrama de componentes

La interfaz se puede representar por una línea con un círculo

Figura 42 Ejemplo interfaz

Si un componente implementa clases se puede establecer la relación entre el componente y las clases como sigue:

Figura 43 Ejemplo Diagrama de componente con clases

Solo se podrán ejecutar las operaciones dentro de un componente a través de su interfase. La relación entre un componente y su interfase se conoce como realización. Un componente puede acceder a los servicios de otro componente mediante el uso de su interfase, al que proporciona el servicio se dice que provee una interfaz de exportación, al que accede a un servicio se dice que utiliza una interfaz de importación.

Figura 44 Ejemplo Diagrama de componente

Se puede sustituir un componente por otro si el nuevo contiene las mismas interfases que el anterior. Se puede reutilizar un componente en otro sistema si éste puede acceder al componente reutilizado mediante sus interfases.


Página Web con controles ActiveX.


Diagrama de Distribución

Los diagramas de distribución muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos.

Un nodo representa todo tipo de equipo de cómputo y se representa por un cubo:

Figura 47 Ejemplo de un nodo

La vista de despliegue representa la disposición de las instancias de componentes de ejecución en instancias de nodos conectados por enlaces de comunicación.

Un nodo es un recurso de ejecución tal comoo Dispositivoso Procesadoreso Memoria

Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse. Esta vista permite determinar las consecuencias de la distribución y la asignación de recursos.

Figura 48 Ejemplo Diagrama de distribución

Figura 49 Ejemplo Diagrama de distribución

Las conexiones entre nodos se puede poner mediante una relación

Figura 50 Ejemplo conexiones entre nodos

g. Documentación de Código

Documentación de código

La documentación interna de un programa incluye elementos cuyo objetivo es facilitar la inteligibilidad del mismo. No es lo mismo tardar 5 minutos en entender un código que tardar un par de horas en intentar saber que es lo que hace porque no tiene unos buenos comentarios y no está correctamente estructurado. La mayoría de los desarrollos de sistemas se llevan a cabo por parte de un equipo. Una buena documentación interna del código que se está desarrollando favorece la comunicación entre los distintos miembros del equipo, mejorando su productividad.

Los tres elementos más significativos de la documentación de código son la elección de nombres significativos, los comentarios y la indentación. Veremos, a continuación, cada uno de ellos:

Elección de nombres significativos

La elección de nombres significativos para los identificadores (tanto de constantes, como variables, funciones...) es crucial para que un programa sea inteligible.

Consideremos las siguientes sentencias

código:

e = v * t espacio = velocidad * tiempo

La primera de las sentencias es más concisa, pero la segunda aporta mucha más información al lector de la misma.

El nombre de los identificadores debe elegirse de forma que no deje lugar a duda sobre su objetivo o el significado del valor que va a contener.

Comentarios

La posibilidad de expresar comentarios en lenguaje natural como parte del listado del código fuente es algo que aparece en todos los lenguajes de programación. Los comentarios permiten al programador comunicarse con otros lectores del código, resultando una clara guía de comprensión durante las etapas de mantenimiento.

Indotación

La forma en que el código fuente aparece en el listado supone una importante contribución a la legibilidad del mismo. La indentación realza las construcciones lógicas y los bloques del código.

No es lo mismo:CódigoC:

#include <stdio.h>

int main () { int y, a; for (y=0;y<=10;y++) for (a=0;a<=10;a++) printf("%i x %i = %in", y, a, y*a); return 0; }

Que

CódigoC:

#include <stdio.h>

int main () { int y, a; for (y=0;y<=10;y++) for (a=0;a<=10;a++) printf("%i x %i = %in", y, a, y*a);

return 0;

}

Aunque ejecute lo mismo. El segundo trozo de código es más legible que el primero.

Notación Húngara

Es un método ampliamente usado sobre todo para convención de nombres de variables. El inventor de esta notación, Charles Simonyi, nació en Hungría, por eso el nombre. Consiste en tener variables autodocumentadas agregando un prefijo de tres caracteres o menos para indicar su tipo. Las abreviaturas de los tipos de datos pueden variar dependiendo del lenguaje de programación.

Algunos ejemplos:

b Booleano (int)by BYTE o UCHAR (unsigned char)c Carácter (un byte)dw Entero largo de 32 bits sin signo (double word)f Flags empaquetados en un entero de 16 bitsh Manipulador de 16 bits (handle)l Entero largo de 32 bitslbl Objeto Labellp Puntero a entero largo de 32 bitslpfn Puntero largo a una función que devuelve un enterolpsz Puntero largo a una cadena terminada con ceron Entero de 16 bitsp Puntero a entero de 16 bitse Enumeraciónpt Coordenadas (x, y) empaquetadas en un entero de 32 bitsrgb Valor de color RGB empaquetado en un entero de 32 bitssz Cadena terminada en cerotxt Cajas de textow Entero corto de 16 bits sin signo (word)

En un sentido más categórico, si tengo un contador, primero va las letras que me dicen que es un número entero (n) y luego el nombre de la variable que sea significativo para su uso.Por ejemplo un contador que me sirve para saber cuantos hay conectados en una pagina:int nContPerPag; n de número entero, Cont de contador, Per de personas, Pag de pagina.

Notación camello

La notación Camel consiste en escribir los identificadores con la primera letra de cada palabra en mayúsculas y el resto en minúscula: EndOfFile. Se llama notación “Camel” porque los identificadores recuerdan las jorobas de un camello. Existen dos variantes:

Existen en principio dos variantes de esta notación, la UpperCamelCase y la lowerCamelCase. La principal diferencia entre ambas es que en el caso del upper la primera letra siempre se escribirá en mayúscula mientras que en la segunda la primera palabra siempre será entera en minúsculas.

UpperCamelCase: la primera letra es mayúscula.

lowerCamelCase: la primera letra es minúscula.

En el lenguaje Java, se usa la notación CamelCase en identificadores para clases. La notación Camel se utiliza también en publicidad y marcas comerciales: PlayStation, easyJet, etc

2. MoProSoft Definición de MoProSoft

1. Responda las siguientes preguntas

¿Qué significan las siglas MoProSoft?

MoProSoft es un conjunto integrado de procesos de Gestión e Ingeniería de Software, compuesto por prácticas reconocidas.

El modelo de procesos MoProSoft tiene tres categorías de procesos: Alta Dirección, Gerencia y Operación que reflejan la estructura típica de una organización.

¿Por qué se desarrollo MoProSoft?

Para sugerir a las organizaciones que se dedican al desarrollo y mantenimiento de software, el tipo de prácticas que les pueden ayudar a mejorar su forma de trabajar y por lo tanto su desempeño.

Esta fue la apuesta que motivó a la SE para apoyar este proyecto para convertirlo en la norma mexicana para la industria de software.

¿Para quién es MoProSoft?

MoProSoft está dirigido tanto a empresas como a áreas internas dedicadas al desarrollo y/o mantenimiento de software.

Las organizaciones que no cuentan con procesos establecidos pueden usar el modelo ajustándolo de acuerdo a su contexto y necesidades, mientras que las organizaciones con procesos establecidos pueden usarlo como referencia para identificar elementos faltantes.

¿Qué es MoProSoft?

¿Para qué se puede utilizar MoProSoft?

¿Cómo se distingue MoProSoft de modelos de procesos similares?

¿Cómo se distingue MoProSoft de modelos de procesos similares?

Tiene una estructura de procesos acorde a la estructura de las organizaciones de software (Alta Dirección, Gerencia y Operación) que no tiene ningún otro modelo.

Destaca el papel de la Alta Dirección en la planeación estratégica, como promotor del buen funcionamiento de la organización, a lo que no se atreve ningún otro modelo para esta industria.

Integra los elementos para la administración de proyectos en un sólo proceso.

Está orientado a mejorar los resultados en las organizaciones de desarrollo de software, contribuyendo a los objetivos de negocio y no simplemente es un marco de referencia para una certificación o evaluación.

Sirve de base para las organizaciones que no cuentan con procesos establecidos y como punto de referencia para las organizaciones que ya tienen procesos establecidos.

No requiere de una estructura organizacional compleja para poder ser aplicado. Se adapta a la organización de cualquier tamaño, sobre todo a la pequeña y mediana.

Establece un mecanismo para mantener el capital intelectual y para hacer un uso adecuado de los recursos materiales de la organización.

Está basado en los principales estándares internacionales, que aplican a la industria de software, pero siendo práctico.

Sirve de base para alcanzar evaluaciones exitosas con otros modelos o normas, tales como ISO 9000:2008 o CMMI-DEV.

Es fácil de entender y aplicar.

1. Arquitectura Las categorías de procesos

Categorías de Procesos

La categoría de Alta Dirección contiene el proceso de Gestión de Negocio.

La categoría de Gerencia está integrada por los procesos de Gestión de Procesos, Gestión de Proyectos y Gestión de Recursos. Éste último está constituido por los subprocesos de Recursos Humanos y Ambiente de Trabajo, Bienes, Servicios e Infraestructura y Conocimiento de la Organización.

La categoría de Operación está integrada por los procesos de Administración de Proyectos Específicos y de Desarrollo y Mantenimiento de Software.

Actividades

1. Conteste las siguientes preguntas

¿Cuál es la función de los procesos de la Categoría de Alta Dirección?

¿Cuál es la función de los procesos de la Categoría de Gerencia?

¿Cuál es la función de los procesos de la Categoría de Operación?

DW, PW: Animar el esquema. Al colocar el cursor en el proceso de Desarrollo y Mantenimiento de Software que se resalte y al darle clic. desplegar la información correspondiente, especificada a continuación:

PropósitoEs la realización sistemática de las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevos o modificados cumpliendo con los requerimientos especificados.

3. Desarrollo y Mantenimiento de Software

a. PropósitoPropósitoEs la realización sistemática de las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevos o modificados cumpliendo con los requerimientos especificados.

Actividades


¿Cuál es el propósito del proceso de Desarrollo y Mantenimiento de Software?

¿Cuáles son los resultados esperados en la implementación efectiva del proceso de Desarrollo y Mantenimiento de Software?

b. Objetivos e Los objetivos establecen una forma específica, medible, alcanzable y acotada en el tiempo de lograr el propósito del proceso. Cada objetivo tiene uno o Actividades

Indicadores

más indicadores que guían la medición del mismo

Objetivos e Indicadores

O3 Llevar a cabo las actividades de las fases de un ciclo mediante el cumplimiento del Plan de Desarrollo actual. I3 (O3) I3 (O3) Las actividades planificadas en cada fase de un ciclo se realizan conforme a lo establecido en el Plan de Desarrollo.


¿Cuáles son los indicadores que podrían utilizarse para evaluar la efectividad del cumplimiento de los objetivos del proceso de Desarrollo y Mantenimiento de Software?

c. Roles Involucrados Roles involucrados

En cada proceso están definidos los roles responsables por la ejecución de las prácticas. Los roles se asignan al personal de la organización de acuerdo a sus habilidades y capacitación para desempeñarlos.

¿Qué es un rol? Un rol es responsable por un conjunto de actividades de uno o más procesos. Un rol puede ser asumido por una o más personas de tiempo parcial o completo.

En el proceso de Desarrollo y Mantenimiento de Software, participan los siguientes roles:

Rol CapacitaciónResponsable de la Administración del Proyecto Específico (RAPE)- Autoridad -

Capacidad de liderazgo con experiencia en la toma de decisiones, planificación estratégica, manejo de personal y desarrollo de software.

Responsable de Desarrollo y Mantenimiento deSoftware (RDM)- Responsable -

Analista Conocimiento y experiencia en el desarrollo y mantenimiento de software.

Analista (AN) Conocimiento y experiencia en la obtención, especificación y análisis de los requisitos.

Diseñador de Interfaz de Usuario (DU) Conocimiento en diseño de interfaces de usuario y criterios ergonómicos.

Diseñador (DI) Conocimiento y experiencia en el diseño de la estructura de los componentes de software.

Programador (PR) Conocimiento y/o experiencia en la programación, integración y pruebas unitarias.

Responsable de Manuales (RM) Conocimiento en las técnicas de redacción y experiencia en el desarrollo y mantenimiento de software.

Equipo de Trabajo (ET) Conocimiento y experiencia de acuerdo a su rol.Cliente (CL) Interpretación del estándar de la especificación de

Actividades


En el contexto de MoProSoft, ¿Qué es un rol?

¿Cuáles son los roles involucrados en el proceso de Desarrollo y Mantenimiento de Software?

¿Qué rol es el responsable por la ejecución del proceso?

¿Qué rol valida la ejecución del proceso y el cumplimiento de su propósito?

¿Cuál es la responsabilidad principal del RDM?

¿Cuáles serían las funciones del RDM en una organización?

DW, PW: Animar el esquema de Roles involucrados por actividad. Al colocar el cursor encima de cada rol. desplegar la información correspondiente, especificada a continuación:

Responsable de la Administración del Proyecto Específico (RAPE)

Capacidad de liderazgo con experiencia en la toma de decisiones, planificación estratégica, manejo de personal y desarrollo de software.

Responsable de Desarrollo y Mantenimiento deSoftware (RDM)

Conocimiento y experiencia en el desarrollo y mantenimiento de software.

Analista (AN)Conocimiento y experiencia en la obtención, especificación y análisis de los requisitos.

Diseñador de Interfaz de Usuario (DU)Conocimiento en diseño de interfaces de usuario y criterios ergonómicos.

Diseñador (DI)Conocimiento y experiencia en el diseño de la estructura de los componentes de software.

Programador (PR)

requisitos.Usuario (US) Ninguna.

Roles involucrados por actividad

Conocimiento y/o experiencia en la programación, integración y pruebas unitarias

Responsable de Manuales (RM)Conocimiento en las técnicas de redacción y experiencia en el desarrollo y mantenimiento de software.

Equipo de Trabajo (ET)

Conocimiento y experiencia de acuerdo a su rol.

Cliente (CL)

Interpretación del estándar de la especificación de requisitos.

Usuario (US)Ninguna.

d. Procesos relacionados Procesos relacionados

La relación entre procesos se establece mediante la identificación de los productos de trabajo de Entrada y Salida y la definición de las responsabilidades de los roles que participan en más de un proceso.

Los procesos relacionados con el proceso de Desarrollo y Mantenimiento de Software son: Administración de Proyectos Específicos

La siguiente imagen ilustra la relación entre los procesos

Actividades


¿Cómo se relacionan los procesos de MoProSoft?

¿Cuáles son los procesos relacionados con el proceso de Desarrollo y Mantenimiento de Software?

DW, PW: Animar el esquema de Procesos Relacionados. La animación debe de ser secuencialmente donde aparecerá primero el recuadro de todos los procesos, después ser el siguiente orden

1. Flecha en dirección a Gestión de Proyectos.

2. Flecha en dirección a Gestión de

.

Cuál es la relación entre estos procesos?

El proceso de Desarrollo de Software busca lograr un entendimiento claro de las necesidades del cliente para generar un producto consistente que cumpla con sus necesidades. Solamente se relaciona con el proceso de Administración de Proyectos Específicos, el cual le proporciona un Plan de Desarrollo.

El Plan de Desarrollo es la principal entrada para este proceso, contiene todo lo necesario para que el RDM pueda realizar sus actividades de su proceso. (Descripción del producto, Entregables, Equipo de Trabajo y Calendario del proyecto).

Procesos.3. Flecha en dirección

a Gestión de Recursos.

4. Flecha en dirección a Desarrollo y Mantenimiento de Software

e. Ciclo de actividades El modelo de procesos MoProSoft considera 5 niveles de madurez (1-5), siendo el nivel 1 el nivel menor de madurez. El nivel 1 denominado Proceso Realizado consiste en obtener los resultados o salidas esperadas de los procesos definidos en MoProSoft, por lo que las actividades y las tareas que se definen en este modelo simplificado han sido delimitadas para cumplir con este nivel. En los niveles superiores de madurez se van incorporando nuevas prácticas a los procesos, lo que permitirá ejercer un mayor control sobre su ejecución.

Ciclo de Actividades

El proceso de Desarrollo y Mantenimiento de Software se compone de uno o más ciclos de desarrollo. Cada ciclo está compuesto de las siguientes fases:

• Inicio: Revisión del Plan de Desarrollo por los miembros del Equipo de Trabajo para lograr un entendimiento común del proyecto y para obtener el compromiso de su realización.

• Requisitos: Conjunto de actividades cuya finalidad es obtener la documentación de la Especificación de Requisitos y Plan de Pruebas de Sistema, para conseguir un entendimiento común entre el cliente y el proyecto.

• Análisis y Diseño: Conjunto de actividades en las cuales se analizan los requisitos especificados para producir una descripción de la estructura de los componentes de software, la cual servirá de base para la construcción. Como resultado se obtiene la documentación del Análisis y Diseño y Plan

Actividades

1. Conteste las siguientes preguntas

¿Qué actividades componen el flujo del proceso de Desarrollo y Mantenimiento de Software?

¿Cuáles son las actividades esperadas en el Nivel 1 para el proceso de Desarrollo y Mantenimiento de Software?

¿Cuáles son los productos que se generan en cada una de ellas?

¿Qué roles participan en cada actividad?

DW, PW: Animar el esquema de ActividadesLa animación debe de ser secuencialmente donde aparecerá primero el recuadro de Plan de Desarrollo, después ser el siguiente orden

1. Fase de Inicio2. Fase de Requisitos.3. Fase de Análisis y

Diseño4. Fase Construcción5. Fase de

Integración y Pruebas

6. Fase de Cierre7. Entregable

de Pruebas de Integración.

• Construcción: Conjunto de actividades para producir Componente(s) de software que correspondan al Análisis y Diseño, así como la realización de pruebas unitarias. Como resultado se obtienen el (los) Componente(s) de software probados.

• Integración y Pruebas. Conjunto de actividades para integrar y probar los componentes de software, basados en los Planes de Pruebas de Integración y de Sistema, con la finalidad de obtener el Software que satisfaga los requisitos especificados. Se genera la versión final del Manual de Usuario, Manual de Operación y Manual de Mantenimiento. Como resultado se obtiene el producto de Software probado y documentado.

• Integración y Pruebas. Conjunto de actividades para integrar y probar los componentes de software, basados en los Planes de Pruebas de Integración y de Sistema, con la finalidad de obtener el Software que satisfaga los requisitos especificados. Se genera la versión final del Manual de Usuario, Manual de Operación y Manual de Mantenimiento. Como resultado se obtiene el producto de Software probado y documentado.

• Cierre: Integración final de la Configuración de Software generada en las fases para su entrega. Identificación y documentación de las Lecciones Aprendidas. Generación del Reporte de Mediciones y Sugerencias de Mejora.

Para generar los productos de cada una de estas fases se realizan las siguientes actividades:

· Distribución de tareas, se asignan las responsabilidades de cada miembro del Equipo de Trabajo de acuerdo al Plan de Desarrollo.

Actividades

En la imagen, claramente se puede apreciar (mediante las líneas y flechas) la relación entre las seis actividades del proceso de Desarrollo y Mantenimiento de Software, siendo la Fase de Inicio el inicio del ciclo de las actividades

8. Llamada Ovalada

Todas las actividades con sus respectivas flechas de relación.

4. Fase de Inicio

A1 Fase de Inicio

• Fase de Inicio: Revisión del Plan de Desarrollo por los miembros del Equipo de Trabajo para lograr un entendimiento común del proyecto y para obtener el compromiso de su realización.

Minuta A1.1. Revisar con los miembros del equipo de trabajo el Plan de Desarrollo actual para lograr un entendimiento común y obtener su

Como primera tarea de este proceso el Responsable de Desarrollo y Mantenimiento de Software ,el RDM) se debe de reunir con el equipo de trabajo para revisar el Plan de Desarrollo actual y obtener un entendimiento común y el compromiso con el proyecto. Esta reunión puede ser de manera formal o informal.

Formal Minuta de reunión con el equipo de trabajo donde se obtenga el entendimiento común del Plan de desarrollo y el compromiso con el proyecto.

Informal Comunicación directa con el equipo de trabajo, sin generar evidencia alguna.

compromiso con el proyecto.

5. Diagrama de flujo de la fase de Inicio

Actividad de aprendizaje

Fase de Inicio

A continuación se identifican las tareas esperadas a Nivel 1 de madurez del proceso de Desarrollo y Mantenimiento de Software.

A1. Fase de InicioRol Descripción de la tarea

ET A1.1. Revisar con los miembros del equipo de trabajo el Plan de Desarrollo actual para lograr un entendimiento común y obtener su compromiso con el proyecto.

Actividades

1. Diseñar un diagrama de flujo

Utilizando la notación, simbología o herramienta que considere más indicada, desarrolle un diagrama de flujo, donde se especifiquen las tareas de la actividad A1. Fase de Inicio y los productos generados en cada una de ellas.

Para realizar este ejercicio, se puede consultar el Modelo de Procesos para la Industria de Software (MoProSoft) v1.3, por Niveles de Capacidad de Procesos). (ver anexo MoProSoft v1.3 - Por Niveles de Capacidad de Procesos.pdf)

Nota: Considerar solamente las tareas correspondientes a Nivel 1 de madurez del proceso de Desarrollo y Mantenimiento de Software.

El diagrama de flujo de trabajo deberá reflejar:- Tareas- Roles responsables- Productos (documentos o artefactos)

generados

A continuación se presentan un esquema de diagrama de flujo, a manera de ejemplo:

RecomendacionesPara el diseño del diagrama de flujo puede utilizarse simbología básica, notación 1UML o notación 2BPMN y/o usar herramientas de apoyo como por ejemplo Microsoft Visio,

StarUML o BizAgi Process Modeler.

1UML - Lenguaje Unificado de Modelado (por sus siglas en inglés, Unified Modeling Language).2BPMN - Notación para el Modelado de Procesos de Negocio (por sus siglas en inglés, Business Process Modeling Notation).

6. Fase de Requisitos

A2 Fase de Requisitos

• Fase Requisitos: Conjunto de actividades cuya finalidad es obtener la documentación de la Especificación de Requisitos y Plan de Pruebas de Sistema, para conseguir un entendimiento común entre el cliente y el proyecto.

Minuta A2.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo alPlan de

Como primera tarea de cada actividad del proceso de Desarrollo y Mantenimiento de Software, el RDM se debe de reunir con el equipo de trabajo, para asignarle las tareas correspondientes de la fase de requisitos. La asignación de tareas es de acuerdo al rol a desempeñar de los miembros del equipo de trabajo, según lo establece el Plan de Desarrollo actual. Esta reunión puede ser de manera formal o informal.

Formal Minuta de reunión con el equipo de trabajo donde se asignen tareas según su rol de acuerdo al Plan de Desarrollo.

Informal Comunicación directa con el equipo de trabajo, para asignarle tareas según su rol, sin generar evidencia alguna.

Desarrollo actual.

a. Especificación de Requisitos

A2.2. Documentar o modificar la Especificación de Requisitos.

• Identificar y consultar fuentes de información (clientes, usuarios, sistemas previos, documentos, etc.) para obtener nuevos requisitos.• Analizar los requisitos identificados para delimitar el alcance y su factibilidad, considerando las restricciones del ambiente del negocio del cliente o del proyecto.• Elaborar o modificar el prototipo de la interfaz con el usuario.• Generar o actualizar la Especificación de Requisitos.

Guías para la especificación de requisitos

Usar siempre palabras como “debe”, “deberá”, “permitirá”, “podrá” y evitar palabras como “podría”, “debería”, “tal vez”. Asignar un identificador único a cada requisito. Para los Requisitos No Funcionales que son Atributos de Calidad, especificar métricas de cómo el requisito se debe cumplir y no dejar frases

tales como “que lo haga rápido”, “que lo haga bien”, entre otras. Es mejor especificar cosas como “que responda en menos de 30 segundos”, “que se inserten el 100% de los registros”, etc.

Jamás suponer o asumir algo Especificar todo lo más claro posible pues hay que tomar en cuenta que los que diseñarán el sistema son otras personas. Cuidar el no incluir palabras ambiguas, un síntoma sería que dos personas entendieran cosas distintas del requisito.

Especificación de Requisitos: Documento que se compone de una introducción y una descripción de requisitos.a) introducción - descripción general del software y su uso en el ámbito de negocio del cliente;b) descripción de requisitos:i) funcionales - necesidades establecidas que debe satisfacer el software cuando es usado en condiciones especificas, las funcionalidades deben ser adecuadas, exactas y seguras;ii) interfaz con usuario - definición de aquellas características de la interfaz de usuario que permiten que el software sea fácil de entender, aprender, que generesatisfacción y con el cual el usuario pueda desempeñar su tarea eficientemente, incluyendo la descripción del prototipo de la interfaz;interfaces externas – definición de las interfaces con otro software o con hardware;iv) confiabilidad - especificación del nivel de desempeño del software con respecto a la madurez, tolerancia a fallas y recuperación;v) eficiencia - especificación del nivel de desempeño del software con respecto al tiempo y a la utilización de recursos;vi) mantenimiento - descripción de los elementos que facilitarán la comprensión y la realización de las modificaciones futuras del software;vii) portabilidad - descripción de las características del software que permitan su transferencia de un ambiente a otro;viii) restricciones de diseño y construcción - necesidades impuestas por el cliente;ix) interoperatividad – la capacidad de que dos o más sistemas o componentes puedan intercambiar información y usarla;x) reusabilidad - propiedad de todo producto o subproducto de software o parte de él, para que pueda aprovecharse o utilizarse por varios usuarios como producto final o en el desarrollo del propio software o la realización de otros productos software;xi) legales y reglamentarios - necesidades impuestas por leyes, reglamentos, entre otros.

Utilizar alguna de las técnicas de recolección para hacer el levantamiento de requisitos.

Actividad 7

Generar el documento de Especificación de requisitos considerando el proyecto piloto seleccionado por la organización para la implantación de MoProSoft.

Descargar ejemplo: Especificación de requisitos (dms_especificacion_de_requisitos.doc)


Descargar plantilla: Especificación de requisitos (dms_especificacion_de_requisitos_plantilla.doc)

Nota:Si no utiliza la plantilla propuesta para el documento Especificación de Requisitos, debe de asegurarse que la plantilla que utilicen contenga como mínimo todas las siguientes puntos:

1. Introducción.2. Funcionales.3. Interfaz con usuario.4. Interfaces con otro software y hardware.5. Confiabilidad.6. Eficiencia.7. Mantenimiento.8. Portabilidad.9. Interoperatividad.10. Reusabilidad.11. Restricciones de diseño y construcción.12. Legales y reglamentarios.

Nota 2: Si los requisitos del proyecto piloto no contemplan algún requisito mencionado en la lista superior, no borrar el elemento, solo especificar que no tiene ese tipo de requisito

Ejemplo: Requisitos de Reusabilidad: El software no tiene requisitos de reusabilidad.

Actividad 8

En base a los requisitos del proyecto piloto elaborar un prototipo de interfaz con el usuario.

b. Manual de Usuario Preliminar

A2.10. Documentar la versión preliminar del Manual de Usuario o modificar el manual existente.

Documentar la versión preliminar del Manual de usuario en base a los requisitos obtenidos por el cliente, y el prototipo de interfaz de usuario, El manual de usuario preliminar puede contener solamente la descripción del prototipo y su funcionalidad. En la fase de integración y pruebas se realizara la documentación definitiva del Manual de Usuario.

Actividad 9

Elaborar el documento de Manual de Usuario preliminar del proyecto piloto a presentar en la verificación.

Descargar ejemplo: Manual de Usuario (dms_manual_de_usuario.doc)


Descargar plantilla: Manual de Usuario (dms_manual_de_usuario_plantilla.doc)

c. Configuración de Software

A2.13. Incorporar Especificación de Requisitos y Manual de Usuario a la Configuración de Software.

Conjunto consistente de productos de software, que incluye:a) Especificación de Requisitos;b) Análisis y Diseño;c) Software;d) Manual de Usuario;e) Manual de Operación;

Recolectar el documento de Especificación de Requisitos y el Manual de Usuario Preliminar e incorporarlos a la Configuración de software

Actividad 10

Generar la Configuración de Software en un archivo comprimido (zip o rar) con el documento de Especificación de requisitos y manual de usuario preliminar del proyecto piloto y subirla como tarea para revisión.

Nota: Únicamente las versiones finales de los documentos de Especificación de requisitos y manual de usuario preliminar.

7. Diagrama de flujo de la Fase de Requisitos


Fase de Requisitos


A2. Fase de RequisitosRol Descripción de la tarea

RDM A2.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al Plan de Desarrollo actual.

ANCLUSDU

A2.2. Documentar o modificar la Especificación de Requisitos.

• Identificar y consultar fuentes de información (clientes, usuarios, sistemas previos, documentos, etc.) para obtener nuevos requisitos.• Analizar los requisitos identificados para delimitar el alcance y su factibilidad, considerando las restricciones del ambiente del negocio del cliente o del proyecto.• Elaborar o modificar el prototipo de la interfaz con el usuario.• Generar o actualizar la Especificación de Requisitos.

RM A2.10. Documentar la versión preliminar del Manual de Usuario o modificar el manual existente.

RDM A2.13. Incorporar Especificación de Requisitos y Manual de Usuario a la Configuración de Software.

Actividades


Utilizando la notación, simbología o herramienta que considere más indicada, desarrolle un diagrama de flujo, donde se especifiquen las tareas de la actividad A2. Fase de requisitos y los productos generados en cada una de ellas.




generados


RecomendacionesPara el diseño del diagrama de flujo puede utilizarse simbología básica, notación 1UML o notación 2BPMN y/o usar herramientas de apoyo como por ejemplo Microsoft Visio, StarUML o BizAgi Process Modeler.


8. Fase de Análisis y Diseño

A3 Fase de Análisis y Diseño

• Análisis y Diseño: Conjunto de actividades en las cuales se analizan los requisitos especificados para producir una descripción de la estructura de los componentes de software, la cual servirá de base para la construcción. Como resultado se obtiene la documentación del Análisis y Diseño y Plan de Pruebas de Integración.

Minuta

A3.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo alPlan de Desarrollo actual.


Formal• Minuta de reunión con el equipo de trabajo donde se asignen tareas según su rol de acuerdo al Plan de Desarrollo.Informal• Comunicación directa con el equipo de trabajo, para asignarle tareas según su rol, sin generar evidencia alguna.

a. Análisis y Diseño A3.2. Documentar o modificar el Análisis y Diseño:

• Analizar la

Documento que contiene la descripción textual y gráfica de la estructura de los componentes de software.

¿Cuál es la estructura del sistema? ¿Qué componentes lo forman? ¿Cómo se relacionan esos componentes? ¿Cuál es el detalle de cada componente? ¿Cómo debo construir cada componente?

Actividad 12

Generar el documento de análisis y diseño considerando el proyecto piloto seleccionado por la organización para la implantación de MoProSoft.

Especificación de Requisitos para generar la descripción de la estructura interna del sistema y su descomposición en subsistemas, y éstos a su vez en componentes, definiendo las interfaces entre ellos.

• Describir el detalle de la apariencia y el comportamiento de la interfaz con base en la Especificación de Requisitos de forma que se puedan prever los recursos para su implementación.

• Describir el detalle de los componentes que permita su construcción de manera evidente.

• Generar o actualizar el Análisis y Diseño.

¿Cómo podré probar cada componente?

¿Qué lleva el documento de análisis y diseño?

Descripción Arquitectónica. Contiene la estructura interna del sistema, es decir, la descomposición en subsistemas. Así como la identificación de los componentes que integran los subsistemas y las relaciones de interacción entre ellos.

Descripción Detallada. Contiene el detalle de los componentes que permita de manera evidente su construcción y prueba en el ambiente de programación.

Actividades principales del diseño

Interacción entre los objetos: Diagrama de Interacción Estructura estática del sistema: Diagrama de Clases

Interacción entre objetos

Figura 51 Ejemplo Diagrama de Interacción

Estructura estática

Descargar ejemplo: Análisis y diseño (dms_analisis_y_diseño.doc)

Descargar ejemplo: Análisis y diseño – Modelo Funcional(dms_analisis_y_diseño_modelo_funcional.doc)


Descargar plantilla: Análisis y diseño (dms_analisis_y_diseño_plantilla.doc)

Descargar plantilla: Análisis y diseño– Modelo Funcional

(dms_analisis_y_diseño_modelo_funcional_plantilla.doc)

Nota:Si no utiliza la plantilla propuesta para el documento análisis y diseño, debe de asegurarse que la plantilla que utilicen contenga como mínimo las siguientes puntos:

Descripción Arquitectónica y descripción detallada

Figura 51 Ejemplo Diagrama de Clases

b. Configuración de Software

A3.10. Incorporar Análisis y Diseño a la Configuración de Software.


Recolectar el documento de Análisis y Diseño e incorporarlos a la Configuración de software

Actividad 13

Agregar el documento Análisis y Diseño del proyecto piloto a la Configuración de Software (archivo “rar” o “zip”), y subirla como tarea, para revisión.

Nota: Únicamente la versión final del documento de Análisis y Diseño.

9. Diagrama de flujo de la Fase de Análisis y Diseño


Fase de Análisis y Diseño


A3. Fase de Análisis y DiseñoRol Descripción de la tarea


AN A3.2. Documentar o modificar el Análisis y Diseño:

Actividades


Utilizando la notación, simbología o herramienta que considere más indicada, desarrolle un diagrama de flujo, donde se especifiquen las tareas de la actividad A3. Fase de análisis y diseño y los productos generados en cada una de ellas.

Para realizar este ejercicio, se puede consultar el Modelo de Procesos para la Industria de

DIDU • Analizar la Especificación de Requisitos para generar la descripción de la estructura interna

del sistema y su descomposición en subsistemas, y éstos a su vez en componentes, definiendo las interfaces entre ellos.• Describir el detalle de la apariencia y el comportamiento de la interfaz con base en la Especificación de Requisitos de forma que se puedan prever los recursos para su implementación.• Describir el detalle de los componentes que permita su construcción de manera evidente.• Generar o actualizar el Análisis y Diseño.

RDM A3.10. Incorporar Análisis y Diseño a la Configuración de Software.

Software (MoProSoft) v1.3, por Niveles de Capacidad de Procesos). (ver anexo MoProSoft v1.3 - Por Niveles de Capacidad de Procesos.pdf)



generados




10. Fase de Construcción

A4 Fase de Construcción

• Construcción: Conjunto de actividades para producir Componente(s) de software que correspondan a los definidos en la fase de análisis y Diseño, así como la realización de pruebas unitarias. Como resultado se obtienen el (los) Componente(s) de software probados.

Minuta





a. Componentes A4.2. Construir o modificar el(los) Componente(s) de software:• Implementar o modificar Componente(s)

En base al documento análisis y diseño, construir el software utilizando el lenguaje de programación especificado en el documento de Especificación de Requisitos, elemento requisitos de diseño y construcción.

Actividad 13

Construir los componentes e ir subiendo avances semanalmente sobre el progreso de estos.

con base a la parte detallada del Análisisy Diseño.

b. Configuración de Software

A4.5. Incorporar Componentes a la Configuración de Software.


Recolectar los componentes e incorporarlos a la Configuración de software

Actividad 14

Agregar los componentes de software a la Configuración de Software (archivo “rar” o “zip”), y resguardarla en la Base de Conocimiento de la organización

.

11. Diagrama de flujo de la Fase de Construcción


Fase de Construcción


A4. Fase de ConstrucciónRol Descripción de la tarea


PR A4.2. Construir o modificar el(los) Componente(s) de software:• Implementar o modificar Componente(s) con base a la parte detallada del Análisis Diseño.

RDM A4.5. Incorporar Componentes a la Configuración de Software.

Actividades


Utilizando la notación, simbología o herramienta que considere más indicada, desarrolle un diagrama de flujo, donde se especifiquen las tareas de la actividad A4. Fase de construcción y los productos generados en cada una de ellas.




generados




12. Fase de integración y Pruebas

A5 Fase de Integración y Pruebas

• Integración y Pruebas. Conjunto de actividades para integrar y probar los componentes de software, con la finalidad de obtener el Software que satisfaga los requisitos especificados. Se genera la versión final del Manual de Usuario y Manual de Operación. Como resultado se obtiene el producto de Software probado y documentado.

Minuta





a. Software A5.2. Realizar integración.• Integrar los componentes en subsistemas

Integrar los componentes en subsistemas o en el sistema Software

o en el sistema del Software

b. Manual de Operación

A5.3. Documentar el Manual de Operación o modificar el manual existente.

Documento electrónico o impreso que contenga la información indispensable para la instalación y administración del software, así como el ambiente de operación (sistema operativo, base de datos, servidores, etc.), éste deberá ser redactado en términos comprensibles al personal responsable de la operación.

Elementos propuestos para el manual de operación:• Configuración

– Pasos de Instalación• Software• Base de Datos• Aplicación

– Pasos de Parametrización• Configuración de Base de Datos• Configuración del Software

• Ambiente de Operación– Hardware y Software

• Características

Actividad 16

Generar el manual de operación considerando el proyecto piloto seleccionado por la organización para la implantación de MoProSoft.

Descargar ejemplo: Manual de Operación (dms_manual_de_operacion.doc)


Descargar plantilla: Manual de Operación (dms_manual_de_operacion_plantilla.doc)

c. Manual de Usuario

A5.8. Documentar el Manual de Usuario o modificar el existente.

Documento electrónico o impreso que describe la forma de uso del software con base a la interfaz del usuario. Éste deberá ser redactado en términos comprensibles a los usuarios.

Preguntas que deben hacerse para hacer el Manual de Usuario

1. ¿Qué hace el software, para qué sirve?Describir en forma breve que hace el software, cuál es su utilidad. Explicando primero a grandes rasgos de qué se trata el software y después tratando los diferentes puntos específicos relacionados al software.

2. ¿Cómo funciona el software?Explicar la manera en que el software hace las cosas pues puede haber muchas formas distintas de obtener un resultado final o de hacer algo.

3. ¿Cuales son los conceptos usados por el programa?Explicar los diferentes conceptos involucrados en el programa. La idea es explicar con más detalle lo que significa cada cosa.

4. ¿Qué necesita saber el usuario para usar el programa?Explicar una "guía breve" que será como un compendio, y aparte tendrá todo tipo de instrucciones para usar el programa, así como ejemplos, tutoriales y recomendaciones. Además explicar cuestiones como: ¿Qué necesita tener o conseguir antes de instalarlo?, ¿Cómo instalarlo?, ¿Cómo configurar el programa?

Actividad 17

Generar el manual de usuario considerando el proyecto piloto seleccionado por la organización para la implantación de MoProSoft.

Nota: Actualizar el manual de usuario preliminar a Manual de Usuario (versión final)

Descargar ejemplo: Manual de Usuario (dms_manual_de_usuario.doc)


Descargar plantilla: Manual de Usuario (dms_manual_de_usuario_plantilla.doc)

d. Configuración de Software

A5.11. Incorporar Software, Manual de Operación y Manual de Usuario a la Configuración de Software.


Recolectar el manual de operación y el manual de usuario e incorporarlos a la Configuración de software

Actividad 18

Agregar el Software, manual de operación y manual de usuario a la Configuración de Software (archivo “rar” o “zip”), y resguardarla en la Base de Conocimiento de la organización

Actividad 19

Subir la ultima versión de la configuración de Software para revisión que contenga únicamente los siguientes documentos:

1. Especificación de Requisitos2. Análisis y Diseño3. Manual de Usuario4. Manual de Operación

13. Diagrama de flujo Actividad de Fase de Integración y Pruebas Actividades

de la fase de Integración y Pruebas

aprendizaje A continuación se identifican las tareas esperadas a Nivel 1 de madurez del proceso de Desarrollo y Mantenimiento de Software.

A5. Fase de Integración y PruebasRol Descripción de la tarea


PRRPU

A5.2. Realizar integración.Integrar los componentes en subsistemas o en el sistema del Software

RM A5.3. Documentar el Manual de Operación o modificar el manual existente.

RM A5.8. Documentar el Manual de Usuario o modificar el existente.

RDM A5.11. Incorporar Software, Manual de Operación y Manual de Usuario a de Software.


Utilizando la notación, simbología o herramienta que considere más indicada, desarrolle un diagrama de flujo, donde se especifiquen las tareas de la actividad A5. Fase de Integración y Pruebas y los productos generados en cada una de ellas.




generados



€¦ · web viewingeniería de software es el estudio de los principios y metodologías para el...

Documents