actividades / productos de instrucciones dg y pw …€¦ · una condición o capacidad necesitada...
TRANSCRIPT
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
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:
Requerimientos por
“Requisitos”,
Ejemplo:
Requerimientos del
negocio seria
“Requisitos del
negocio”.
SRS por
“Especificación de
Requisitos”
Solicitudes de clientes por medio de encuestas, correos electrónicos o buzones de sugerencias
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 requisitos
2. Reducir el retrabajo
3. Disminución de propiedades innecesarias
4. Rápido desarrollo
5. Disminución de la falta de comunicación
6. Menos caos
7. Estimaciones más aproximadas
8. 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 Usuario
IU1. “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.”
Confiabilidad
C1. “No más de 5 ejecuciones experimentales de 1000 pueden ser perdidas debido a fallas en el software.”
Disponibilidad
D1. “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.”
Eficiencia
E1. “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.”
Mantenimiento
M1. “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.”
Portabilidad
P1. “El módulo de facturación deberá ser capaz de ejecutarse sobre cualquier terminal PC con sistema operativo Linux o Windows.”
Interoperatividad
IO1. “El sistema interactuará con el sistema de nómina ya existente en la empresa.”
Reusabilidad
RU1. “El módulo de facturación deberá ser capaz de reusarse para otros proyectos”
Restricciones de Diseño y Construcción
RDC1. “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 Reglamentarios
LR1. “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 Actor
Actores
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
Actividad 2
En base al anexo dms_anexo_2.docx
Realizar las siguientes actividades:
dms_anexo_2.docx
Descargar Anexo: Anexo 2
(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.
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.
Figura 4 Ejemplo de actores
Diagramas 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.
Cliente Online
Hacer Pedido
Validar Usuario
Hacer PedidoUrgente
**
«extends»
<<includes>>
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 principal
Se 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 excepcional
Podemos 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 Uso
o Actores
o 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
Actividad 4
En base al anexo dms_anexo_1.docx
Realizar las siguientes actividades:
Descargar Anexo: Anexo 1
(dms_anexo_1.docx)
DW y PW:
Cambios
Figura 6:
Sustituir palabras:
Requerimientos por
“Requisitos”,
Ejemplo:
software, propiedades externamente visibles de dichos componentes, y las relaciones entre ellos.” (Software Engineering Institute, Carnegie Mellon University
)
Implicaciones de la definición
Una arquitectura es una abstracción de sistemas
o 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 arquitectura
o 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 plazo
o Amortizar la infraestructura
o Mantener bajos los costos de instalación
Problemas del negocio a largo plazo
o Invertir en una infraestructura para metas estratégicas
o Invertir en personal
1.- Diseñar la vista Física y vista lógica.
Requerimientos del
negocio seria
“Requisitos del
negocio”.
SRS por
“Especificación de
Requisitos”
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.
Anteriores experiencias negativas serán excluidas en nuevos diseños.
Factores influenciados por una arquitectura
Estructura de la organización de desarrollo
o Corto plazo: Unidades de trabajo son organizadas alrededor de unidades arquitectónicas para un sistema particular en construcción
o 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 mercado
o Ser conocidos por desarrollar particulares tipos de sistemas llega a ser un arma de mercadotecnia
o 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ódulos
o Tareas
o Funciones
o Hardware
o 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?
Actividad 5
Definición lógica de la forma en que se construye el software que cumplirá con los requisitos
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 Requisitos
o Arquitectura
o Diseño
o Código fuente
o Planificación
o Pruebas
o Prototipos
o Versiones
Los 9 diagramas de UML
En base al anexo dms_anexo_1.docx
Realizar las siguientes actividades:
Descargar Anexo: Anexo 1
(dms_anexo_1.docx)
1.- Realice el diagrama de clases
2.- 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 clase
Atributo: 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 direcciones
La 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 Venta
Figura 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 objetos
Diagrama 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 condiciones
o 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 condiciones
o 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 uso
o 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.
Figura 45 Ejemplo Diagrama de componente
Página Web con controles ActiveX.
Figura 46 Ejemplo Diagrama de componente
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 como
o Dispositivos
o Procesadores
o 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ódigo
C:
#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ódigo
C:
#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 bits
h Manipulador de 16 bits (handle)
l Entero largo de 32 bits
lbl Objeto Label
lp Puntero a entero largo de 32 bits
lpfn Puntero largo a una función que devuelve un entero
lpsz Puntero largo a una cadena terminada con cero
n Entero de 16 bits
p Puntero a entero de 16 bits
e Enumeración
pt Coordenadas (x, y) empaquetadas en un entero de 32 bits
rgb Valor de color RGB empaquetado en un entero de 32 bits
sz Cadena terminada en cero
txt Cajas de texto
w 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
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.
1. Responda las siguientes preguntas
¿Qué significan las siglas MoProSoft?
¿Qué es MoProSoft?
¿Para qué se puede utilizar MoProSoft?
¿Cómo se distingue MoProSoft de modelos de procesos
similares?
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.
¿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ósito
Es 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ósito
Propósito
Es 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
1. Responda las siguientes preguntas
¿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
Indicadores
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
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.
Actividades
1. Responda las siguientes preguntas
¿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ón Responsable 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 de
Software (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.
Actividades
1. Responda las siguientes preguntas
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 de
Software (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
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.
Roles involucrados por actividad
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
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
Actividades
1. Responda las siguientes preguntas
¿Cómo se relacionan los procesos de MoProSoft?
¿Cuáles son los procesos relacionados con el proceso
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
La siguiente imagen ilustra la relación entre los procesos
.
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).
de Desarrollo y Mantenimiento de Software?
1. Flecha en dirección
a Gestión de
Proyectos.
2. Flecha en dirección
a Gestión de
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.
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?
DW, PW: Animar el esquema
de Actividades. La
animación debe de ser
secuencialmente donde
aparecerá primero el
recuadro de Plan de
Desarrollo, después ser el
siguiente orden
1. Fase de Inicio
2. Fase de Requisitos.
3. Fase de Análisis y
Diseño
4. Fase Construcción
5. Fase de Integración
y Pruebas
• 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.
• 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
¿Qué roles participan en cada actividad?
6. Fase de Cierre
7. Entregable
8. Llamada Ovalada
Todas las actividades con sus
respectivas flechas de
relación.
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
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
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
entendimiento
común y
obtener su
compromiso con
el proyecto.
Comunicación directa con el equipo de trabajo, sin generar evidencia alguna.
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 Inicio
Rol 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:
Recomendaciones
Para 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
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.
trabajo según su
rol, de acuerdo
al
Plan 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. 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
genere
satisfacció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)
Plantilla propuesta para realizar la actividad:
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
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
Actividad 9
versión
preliminar del
Manual de
Usuario o
modificar el
manual
existente.
documentación definitiva del Manual de Usuario. 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)
Plantilla propuesta para realizar la actividad:
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
Actividad de
aprendizaje
Fase de Requisitos
A continuación se identifican las tareas esperadas a Nivel 1 de madurez del proceso de Desarrollo y Mantenimiento de Software.
A2. Fase de Requisitos
Rol 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.
AN
CL
US
DU
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
2. 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 A2. Fase de requisitos 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:
Recomendaciones
Para 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).
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
al
Plan de
Desarrollo
actual.
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.
a. Análisis y Diseño
A3.2.
Documentar o
modificar el
Análisis y Diseño:
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?
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.
• 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.
¿Cuál es el detalle de cada componente?
¿Cómo debo construir cada componente?
¿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)
Plantilla propuesta para realizar la actividad:
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.
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 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
Actividad de
aprendizaje
Fase de Análisis y Diseño
A continuación se identifican las tareas esperadas a Nivel 1 de madurez del proceso de Desarrollo y Mantenimiento de Software.
A3. Fase de Análisis y Diseño
Rol Descripción de la tarea
RDM A3.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al Plan de
Desarrollo actual.
Actividades
3. 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 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
AN
DI
DU
A3.2. Documentar o modificar el Análisis y Diseño:
• 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.
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:
Recomendaciones
Para 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).
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
A4.1. Distribuir
tareas a los
miembros del
equipo de
trabajo según su
rol, de acuerdo
al
Plan de
Desarrollo
actual.
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.
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álisis
y Diseño.
b. Configuración de
Software
A4.5. Incorporar
Componentes 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 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
Actividad de
aprendizaje
Fase de Construcción
A continuación se identifican las tareas esperadas a Nivel 1 de madurez del proceso de Desarrollo y Mantenimiento de Software.
A4. Fase de Construcción
Rol Descripción de la tarea
RDM A4.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al Plan de
Desarrollo actual.
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
4. 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 A4. Fase de construcción 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:
Recomendaciones
Para 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).
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
A5.1. Distribuir
tareas a los
miembros del
equipo de
trabajo según su
rol, de acuerdo
al
Plan de
Desarrollo
actual.
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.
a. Software
A5.2. Realizar
integración.
• Integrar los
componentes
Integrar los componentes en subsistemas o en el sistema Software
en subsistemas 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)
Plantilla propuesta para realizar la actividad:
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)
Plantilla propuesta para realizar la actividad:
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.
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 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 Requisitos
2. Análisis y Diseño
3. Manual de Usuario
4. Manual de Operación
13. Diagrama de flujo de
la fase de
Integración y
Pruebas
Actividad de
aprendizaje
Fase de Integración y Pruebas
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 Pruebas
Rol Descripción de la tarea
RDM A5.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al Plan de
Desarrollo actual.
PR
RPU
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.
Actividades
5. 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 A5. Fase de Integración y
Pruebas 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:
Recomendaciones
Para 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).