El documento presenta la metodología utilizada para el levantamiento de requerimientos. Describe los objetivos, conceptos claves, el proceso metodológico que incluye reuniones preliminares, lanzamiento, modelado de procesos, casos de uso, entregables y bibliografía. El proceso metodológico involucra múltiples etapas como elaboración de documentos, revisión de artefactos, especificación de requerimientos y cierre de la fase.
La presentación Fundamentos de Calidad del Software - Modelos y Estándares, contiene elementos que permiten hacerse a una idea del contexto en el que se mueve el aseguramiento de la calidad del software en sus dos manifestaciones (procesos y producto) y en sus dimensiones de gestión y desarrollo.
Luis Eduardo Peláez Valencia
luiseduardo.pelaez@gmail.com
Keywords: SQA, Aseguramiento de la calidad del software, Calidad del software, Modelos y Estándares.
Estandares y modelos de calidad del softwareaagalvisg
La calidad del software puede parecer un concepto alejado de la vida diaria de la mayoría de las personas, pero nada más lejos de la realidad, en este documento encontraras los estándares para crear un software de calidad.
La presentación Fundamentos de Calidad del Software - Modelos y Estándares, contiene elementos que permiten hacerse a una idea del contexto en el que se mueve el aseguramiento de la calidad del software en sus dos manifestaciones (procesos y producto) y en sus dimensiones de gestión y desarrollo.
Luis Eduardo Peláez Valencia
luiseduardo.pelaez@gmail.com
Keywords: SQA, Aseguramiento de la calidad del software, Calidad del software, Modelos y Estándares.
Estandares y modelos de calidad del softwareaagalvisg
La calidad del software puede parecer un concepto alejado de la vida diaria de la mayoría de las personas, pero nada más lejos de la realidad, en este documento encontraras los estándares para crear un software de calidad.
Objetivo: Caracterizar las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos de un producto determinado conociendo de forma precisa el problema que van a resolver para que la solución que se construya sea correcta y útil.
Semana 1 trazabilidad y modelos de trazabilidadGiovani Ramirez
La trazabilidad o rastreabilidad se define como la "aptitud para rastrear la historia, la aplicación o la localización de una entidad mediante indicaciones registradas" (ISO 1994)
UML. un analisis comparativo para la diagramación de softwareYaskelly Yedra
El propósito de este trabajo fue realizar un análisis comparativo entre el Lenguaje de Modelado Unificado (UML) con el desarrollo estructurado y los métodos orientados a objetos, a partir de los bloques de construcción de UML, con la finalidad de observar como surgió, evolucionó y se consolidó el UML como herramienta para la construcción de software. Los bloques de construcción de UML y los métodos de desarrollo estructurado y orientados a objetos se conforman con: elementos, relaciones y diagramas. A partir de esas similitudes, este trabajo utiliza el método de análisis comparativo para descubrir las semejanzas y diferencias de los distintos métodos cuando se construye software. Como conclusión del análisis se tiene que UML no garantiza el éxito de un proyecto, pero permite a los ingenieros centrarse en la entrega de un producto, utilizando un lenguaje de modelación estándar que además de ser consistente es soportado directamente por las mejores herramientas de software en una forma unificada.
El Ciclo de Vida del Software propone algunos modelos para explicar las fases o etapas que cumple el producto de software desde los requerimientos inicial hasta su nueva entrega.
Tema N° 6 Técnicas para el Levantamiento y Recolección de RequisitosSaraEAlcntaraR
Tema N° 6 Técnicas para el Levantamiento y Recolección de Requisitos correspondiente a la Unidad II.- Ingeniería de Requisitos del Saber Ingeniería del Software II, dictado en el PNF en Informática de la UPTP "Luis Mariano Rivera".
Este documento muestra los conceptos de diferentes autores sobre el tema de calidad y calidad de software, se pretende dar a conocer los diferentes significados que pueden estar relacionados con un mismo tema.
Podrá buscar la información aquí mencionada pues se da a conocer la URL donde fue encontrada la informacion
Objetivo: Caracterizar las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos de un producto determinado conociendo de forma precisa el problema que van a resolver para que la solución que se construya sea correcta y útil.
Semana 1 trazabilidad y modelos de trazabilidadGiovani Ramirez
La trazabilidad o rastreabilidad se define como la "aptitud para rastrear la historia, la aplicación o la localización de una entidad mediante indicaciones registradas" (ISO 1994)
UML. un analisis comparativo para la diagramación de softwareYaskelly Yedra
El propósito de este trabajo fue realizar un análisis comparativo entre el Lenguaje de Modelado Unificado (UML) con el desarrollo estructurado y los métodos orientados a objetos, a partir de los bloques de construcción de UML, con la finalidad de observar como surgió, evolucionó y se consolidó el UML como herramienta para la construcción de software. Los bloques de construcción de UML y los métodos de desarrollo estructurado y orientados a objetos se conforman con: elementos, relaciones y diagramas. A partir de esas similitudes, este trabajo utiliza el método de análisis comparativo para descubrir las semejanzas y diferencias de los distintos métodos cuando se construye software. Como conclusión del análisis se tiene que UML no garantiza el éxito de un proyecto, pero permite a los ingenieros centrarse en la entrega de un producto, utilizando un lenguaje de modelación estándar que además de ser consistente es soportado directamente por las mejores herramientas de software en una forma unificada.
El Ciclo de Vida del Software propone algunos modelos para explicar las fases o etapas que cumple el producto de software desde los requerimientos inicial hasta su nueva entrega.
Tema N° 6 Técnicas para el Levantamiento y Recolección de RequisitosSaraEAlcntaraR
Tema N° 6 Técnicas para el Levantamiento y Recolección de Requisitos correspondiente a la Unidad II.- Ingeniería de Requisitos del Saber Ingeniería del Software II, dictado en el PNF en Informática de la UPTP "Luis Mariano Rivera".
Este documento muestra los conceptos de diferentes autores sobre el tema de calidad y calidad de software, se pretende dar a conocer los diferentes significados que pueden estar relacionados con un mismo tema.
Podrá buscar la información aquí mencionada pues se da a conocer la URL donde fue encontrada la informacion
La definición de una estrategia de negocio desde los altos niveles directivos adquiere distintos matices y dimensiones a medida que se traduce en actividades y responsabilidades durante su implementación a través de la estructura organizacional. Establecer objetivos es el primer paso pero, ¿Cómo identificar las áreas que hoy requieren atención para poder lograr ese objetivo?, ¿Cómo mantener alineadas las estrategias definidas y las actividades diarias de cada miembro de una organización?
En esta sesión nos enfocaremos en discutir cuales son las mejores prácticas para mantener sincronía entre la definición de los procesos de negocio y la realidad de una organización a fin de obtener información clara, objetiva y concisa del plan de acción a ejecutar para alcanzar los objetivos planteados.
2. Agenda
► Objetivos
► Conceptos Claves
► Metodología de Levantamiento
► Modelamiento de Procesos
► Casos de Uso
► Entregables y Criterios de Aceptación
► Bibliografía
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
3. Objetivos
► Conocer las reglas de juego que se tendrán para llevar a
cabo el levantamiento de requerimientos
► Conocer el proceso metodológico que será utilizado
para llevar a cabo el levantamiento de requerimientos en
TC
► Conocer en detalle el proceso de especificación de
requerimientos funcionales utilizando casos de uso
► Identificar las características principales de los casos de
uso
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
4. Conceptos claves
► Proceso: Es un conjunto de pasos parcialmente
ordenados que buscan alcanzar una meta u objetivo
► Disciplina: Es una colección de actividades
interrelacionadas asociadas a un área específica de
trabajo
► Flujo de Trabajo: Un flujo de trabajo es una secuencia
de actividades que produce un resultado significativo y
es observable
► Actividad: Una actividad es algo que un rol hace para
proveer un resultado significativo dentro del contexto de
un proyecto
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
5. Conceptos claves
► RUP: Rational Unified Process (Proceso Unificado de
Desarrollo). Metodología que integra mejores prácticas
para la ejecución de las diferentes etapas de un proceso
de desarrollo
► Diagrama de proceso: Modelo de procesos; también
diagrama de actividades del proceso
► Caso de uso: Un caso de uso es un artefacto cuyo
objetivo principal es capturar el comportamiento del
sistema, a través de una secuencia de acciones (flujo de
trabajo), que desde la perspectiva del usuario final
permiten alcanzar los objetivos deseados
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
8. Metodología
Reunión de Lanzamiento
El cliente tiene sus
Procesos modelados ?
Presentaciones generales
del negocio
NO
SI
Revisar documentación
entregada por el cliente
Documentación
suficiente ?
Recolectar documentación
adicional
SI
Convenciones Roles
NO
Solicitar documentación
adicional
Cliente
Analista Líder
Analista
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
9. Metodología
Elaboración y ajustes del
documento de Visión
Revisión Documento
de Visión
Revisión OK ?
Aprobación Documento
de Visión
NO
SI
Documento
aprobado ?
SI
Preparación agenda
de entrevistas
Convenciones Roles
Cliente
Notificar compromiso
a entrevistados
HEINSOHN Software House |
Preparación y ejecución
de entrevistas
Analista Líder
Analista
HEINSOHN Software House | Fábrica software
10. Metodología
Preparación y Ejecución de Entrevistas
Elaboración del modelo
de proceso propuesto
Solicitar entrevistas
adicionales
Identificación de
Reglas de Negocio
Identificación y
elaboración del
Glosario
Convenciones Roles
Cliente
Analista Líder
Analista
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
11. Metodología
Aprobación Modelo
de Procesos
Modelo de
Procesos OK ?
Revisión Artefactos
de Proceso
Revisión OK ?
NO
Ajuste Artefactos
de Proceso
NO
SI
SI
Aprobación Definición
Preliminar del Alcance
Definición Preliminar
del Alcance
Ajustes Definición
Preliminar del Alcance
Definición
Preliminar OK ?
Convenciones Roles
NO
Cliente
SI
Planeación detallada
de especificaciones
HEINSOHN Software House |
Aprobación
planeación detallada
Analista Líder
Analista
HEINSOHN Software House | Fábrica software
12. Metodología
Aprobación planeación detallada
Aprobar ajustes a la
definición del alcance
Refinar definición
del alcance
Aprobación casos de
uso terminados
Especificar casos
de uso
Crear relaciones
de trazabilidad
Especificar Reglas
de Negocio
Casos de uso
aprobados ?
NO
Refinar Glosario
SI
Solicitar y ejecutar
Sesiones de aclaraciones
HEINSOHN Software House |
Elaborar arquitectura
de casos de uso
HEINSOHN Software House | Fábrica software
13. Metodología
Aprobación planeación detallada
Especificar requerimientos
No funcionales
Aprobación Artefactos
de Requerimientos
Elaborar y documentar
Prototipo / StoryBoards
Revisión Artefactos
de Requerimientos
Artefactos OK ?
NO
Ajustes Artefactos
de Requerimientos
SI
NO
Artefactos OK ?
NO
SI
Cerrar fase de
requerimientos
HEINSOHN Software House |
Cambios en los
requerimientos ?
Convenciones Roles
SI
Cliente
Procedimiento de
Control de Cambios
Analista Líder
Analista
HEINSOHN Software House | Fábrica software
15. Elementos
Inicio
Final
cd Due Diligence pre para ...
«ROL Analista de DD»
Pr0074 Seleccionar
archiv os planos
► Estados Inicial y Final: Todo
proceso debe tener un inicio y un fin.
Los elementos Inicio no reciben
ninguna entrada y los elementos
Final no generan ninguna salida
► Actividad: Representa un paso
atómico de un proceso
Actividad
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
16. Elementos
Enlace
► Enlace: Los enlaces se utilizan para
representar la transición de un
estado a otro y el paso de una
actividad a otra
► Decisión: Se utiliza para representar caminos
alternativos en el flujo del proceso. Tiene una
única entrada y puede tener dos o más salidas.
Por cada salida se tiene una expresión booleana
que será evaluada al llegar a la bifurcación. Las
condiciones deben ser excluyentes y se deben
contemplar todos los posibles casos que se
puedan generar
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
17. Elementos
► Fork / Join: Para representar las
tareas concurrentes que pueden
formar parte de un proceso se utiliza
el elemento Fork. En el diagrama de
ejemplo las actividades 2 y 3 se
pueden ejecutar concurrentemente.
El elemento Join se utiliza para
representar la unión al flujo de
control secuencial del proceso
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
18. Elementos
► Signal Sending: Representa el
envío de un mensaje
► Signal Receipt: Representa la
recepción de un evento o mensaje
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
20. ¿Qué es un caso de uso?
► Artefacto cuyo objetivo principal es capturar el
comportamiento del sistema, a través de una secuencia
de acciones (flujo de trabajo), que desde la perspectiva
del usuario final permiten alcanzar los objetivos
deseados
► Un caso de uso describe lo QUE debe hacer el sistema
para satisfacer un requisito, NO COMO debe hacerlo
► El caso esta compuesto por uno o más flujos (secuencia
de acciones) y es invocado por un actor (usuario o
sistema)
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
21. ¿Qué es un caso de uso?
► Los casos de uso describen la interacción del usuario
con el sistema
Acción 1
Acción 2
Actor
Acción 3
Sistema
► La especificación de la interacción debe contemplar
posibles flujos alternos ante distintas condiciones que se
pueden dar en medio
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
22. Elementos de Caso de Uso
► Actor: Es un rol que un usuario juega en el
sistema. No necesariamente es una
persona. Puede estar representado por un
grupo de usuarios, otro sistemas o hardware
► Flujo Básico de Eventos: Corresponde al
flujo de eventos cuando todas las
circunstancias son ideales (todas las
validaciones son cruzadas exitósamente).
● Se deben numerar cada uno de los pasos
● En cada paso hay que describir la acción
efectuada por el actor o por el sistema
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
23. Elementos de Caso de Uso
► Flujos Alternos: Toda situación que impida que se
pueda llevar a cabo el flujo normal como está
presupuestado. Habitualmente validaciones.
● Tipos de validaciones:
• Sintácticas : Inherentes a la naturaleza del dato : Obligatoriedad,
tipo de dato, rango y formato
• Semánticas : A partir del significado del dato o conjunto de datos
(Reglas del Negocio)
● Se debe indicar el paso en el que se da la situación, la
situación, la acción del sistema y a qué paso se retorna
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
24. Elementos de Caso de Uso
► Pre-condiciones: Preconcepciones acerca del sistema
que deben darse para que se pueda llevar a cabo el
caso de uso como esta concebido
► Post-condiciones: Especifica cual es el resultado de
valor que genera el caso de uso (cómo modifica su
entorno)
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
25. Ejemplo
CASO DE ESTUDIO DEL RESTAURANTE “O SOLE MIO”
El restaurante “O Sole Mío” desea construir una solución que le permita
administrar la elaboración de los diversos platos que ofrece a sus clientes. Para
esto, el administrador quiere que se maneje una relación de cada plato junto con
los ingredientes necesarios para elaborarlo. Cada relación de ingrediente debe
tener la cantidad y costo del mismo. De esta manera, también será posible
establecer el costo del plato. El precio cobrado a los clientes siempre será un
porcentaje fijo por encima de la suma de los costos de los ingredientes que se
requieren para su elaboración. Con esta información registrada, Don Vittorio
Corleogni (su gerente y dueño) desea obtener solo dos servicios:
•Que el cocinero, cuando lea una orden escrita por un mesero, consulte en el
sistema el plato y conozca cómo elaborar el mismo, junto con sus ingredientes y
cantidades.
•Que el cajero, al momento de elaborar la cuenta, consulte cada plato y el
sistema le diga cuánto cobrar por él. Con ésta información, el cajero puede
calcular (con calculadora) el costo total de la cuenta.
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
26. Ejemplo
Casos de uso
Asociaciones
uc Primary Use Cases
System Boundary
Consultar elaboración
de plato
Roles
Cocinero
Consultar plato
Caj ero
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
27. Ejemplo
► Consultar elaboración de un plato
● Breve Descripción: Permite la consulta de la
elaboración e ingredientes de un plato
● Entradas: Código del plato. Es un campo
alfanumérico. Es obligatorio
● Flujo Básico de Eventos
1. El sistema solicita le sea ingresado el código del plato
2. El actor digita el código del plato y acepta
3. El sistema despliega la información del plato: nombre, elaboración
y la lista de ingredientes con código, nombre y cantidad
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
28. Ejemplo
► Flujos alternativos
● Código del plato no ingresado
1. Si en el paso 1, no se ingresa ningún codigo, el sistema informa
del error y retorna al paso 1 (Obligatoriedad)
● Código del plato no existente
2. Si en el paso 1 se ingresa un código de plato que no existe
registrado en el sistema, el sistema informa del error y retorna al
paso 1 (validación semántica)
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
29. Ejemplo
► Pre-condiciones
● El sistema cuenta con todo el registro de los platos y sus
elaboraciones
► Post-condiciones
● El sistema despliega los datos de la elaboración del plato
junto con sus ingredientes
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
30. Relaciones de los casos de uso
► Herencia
● Relación entre
actores en la cual
los roles hijos
heredan todos los
casos de uso en
los cuales
interviene el
padre
uc Primary Use Cases
System Boundary
Consultar estado de
cartera
Funcionario de Pedidos
(from Actors)
Registrar pedidos
personas naturales
Funcionario de pedidos
de personas naturales
(from Actors)
Registrar pedidos
personas j urídicas
Funcionario de pedido de
personas j urídicas
(from Actors)
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
31. Relaciones de los casos de uso
► Inclusión
● Se factoriza una interacción en un conjunto de casos (al
menos 2)
uc Primary Use Cases
Consultar estado
cartera
«include»
«include»
Administrador
Cancelar pedido
(from Actors)
Los dos casos de uso incluyen
en su narración la validación del
usuario y password
HEINSOHN Software House |
Validar usuario y
passw ord
1.
2.
3.
El sistema solicita le sea ingresado el usuario y la
palabra clave
El actor digita los datos y acepta
El sistema verifica el usuario y el password y
genera un mensaje de éxito
HEINSOHN Software House | Fábrica software
32. Relaciones de los casos de uso
► Extensión
● Permite que se pueda extender un flujo de eventos de un
caso hacia otro caso de uso bajo una situación
excepcional
uc Primary Use Cases
Consultar pedido
«extend»
Cancelar pedido
Administrador
(from Actors)
Luego de consultar un pedido, el actor puede ir al caso de uso
de Cancelar pedido
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
33. Malas prácticas
► El sistema solicita le sea ingresado el dato del plato
● El diseñador y el programador NO saben cuál es el dato. Debe
enunciarse específicamente qué datos son ingresados en cada
paso de un caso de uso.
► El sistema despliega la información del plato
● El diseñador y el programador no saben cuáles son los datos
que se deben desplegar o contemplar en este caso de uso
► El sistema despliega la información del plato: nombre, elaboración y
lista de ingredientes
● El diseñador y el programador NO saben qué datos desplegar
para los ingredientes = información incompleta
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
34. Algunos entregables
► Documento de visión
► Cronograma y resumen del proyecto
► Definición preliminar de alcance
● Casos de uso suficientes que soportan el proceso
► Modelo de procesos
► Matriz de trazabilidad de Procesos vs. Casos de uso
► Especificaciones de casos de uso
► Glosario
► Reglas de negocio
● Solo las utilizadas por algún caso de uso
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software