Resumen Análisis de Sistemas
Unidad 1: Los Sistemas de Información
7
Temas
7
Bibliografía
7
Rol del Analista en Sistemas
7
Rol del Ingeniero en Sistemas
7
Entrevista
8
Los cinco pasos para la preparación de una entrevista
8
Tipos de preguntas
9
Preguntas Abiertas
9
Preguntas Cerradas
9
Atributos de las preguntas abiertas y las preguntas cerradas.
10
Estructuras de las entrevistas
10
Diseño de Aplicación Conjunta (JAD)
12
12
Desventajas potenciales de JAD
12
SI
Beneficios de JAD
Cuestionarios
Escribir las preguntas
-I
Planeación del uso de cuestionarios
12
13
13
Las ventajas que sacrifica al elegir uno y otro tipo de preguntas
14
Diseño de cuestionarios
14
Escenarios
Casos de uso
Puntos de vista
FM
Etnografía
15
15
15
15
Unidad 2: El ciclo de vida de los Sistemas de Información y Sistemas de Software
17
Temas
17
Bibliografía
17
Ciclo de Vida para los Sistemas de Información
17
¿Qué es un estándar?
17
Estándar ISO/IEC 12207 para el ciclo de vida de los sistemas de información
18
Ciclo de vida del desarrollo de Sistemas
19
Ciclo de vida
19
Proceso de Ingeniería en Sistemas
20
Etapa Definición de requerimientos
20
Importancia del ciclo de vida de desarrollo
20
¿Qué es un proceso de desarrollo del software?
21
Actividades comunes a los procesos de desarrollo de software
22
¿Qué es un modelo de proceso de desarrollo de software?
22
Modelo de Procesos de Desarrollo del Software
23
1 de 112
Modelos de Procesos de Desarrollo del Software: Modelos Tradicionales
23
Modelo en Cascada (Sommerville)
24
Roles sugeridos por cada fase
24
Resumen de etapas
25
Definición de Requerimientos
25
Diseño del Software
25
Implementación y Prueba de Unidades
25
Integración y Prueba del Sistema
25
Operación y Mantenimiento
25
Descripción Modelo en Cascada
25
Desventajas Modelo en Cascada
25
Ventajas Modelo en Cascada
26
¿Cuándo es conveniente utilizar el Modelo en Cascada?
26
Modelo Evolutivo
26
27
Ventajas Modelo Evolutivo
27
Desventajas Modelo Evolutivo
27
¿Cuándo es conveniente utilizar el Modelo evolutivo?
27
SI
Prototipos del Modelo Evolutivo
Modelo Espiral
Acciones comunes a todas las iteraciones
¿Qué se realiza en cada iteración?
Ventajas Modelo en Espiral
-I
¿Qué se realizar en la Primera Iteración?
Temas
Bibliografía
28
29
29
32
33
FM
Unidad 3: Marco de desarrollo. Proceso Unificado
27
33
33
¿Por qué es importante aplicar una metodología de trabajo?
33
Proceso Unificado
34
Proceso Unificado Rational - RUP
36
Fases del Proceso Unificado Rational
38
Disciplinas o actividades del Proceso Unificado
38
Definiciones
39
Iteración en el UP
40
¿Qué es una iteración?
40
Artefactos
40
Artefactos de la fase de inicio
41
Marco de Desarrollo
41
Unidad 4: Modelos y herramientas para el modelado
43
Temas
43
Bibliografía
43
El Proceso de Modelado
43
¿Qué es un modelo?
43
2 de 112
¿Qué nos facilita el modelo?
43
El modelado en Sistemas de Información
44
La importancia de modelar
44
Principios del Modelado
44
Lenguaje de Modelado
44
Lenguaje Unificado de Modelado
44
¿Qué es UML?
45
¿Qué no es UML?
45
Objetivo del UML
45
Objetivos de los modelos
45
Historia Lenguaje Unificado de Modelado
46
Tipos Diagramas UML
48
Elementos y Diagramas del UML
48
Diagrama de Actividades
51
Usos comunes
52
Actividades para modelar un flujo de trabajo [Workflow]
54
Ejemplo
57
60
SI
Conclusiones y sugerencias
Diagrama de Transición de Estados
Contexto del objeto
Partes del estado
Pseudoestados
-I
Partes del Diagrama de Estados
FM
Usos más comunes del Diagrama de Estados
Conclusiones y sugerencias
Bibliografía
62
62
64
64
65
66
Unidad 5: El modelado del dominio del problema
Temas
61
67
67
67
Modelo del Dominio
68
Elementos del UML para Modelar
68
Elementos del UML para Modelar una Clase
68
¿Qué es una clase conceptual?
68
Fuentes de información para conocer el vocabulario del dominio del problema
69
Estrategias para identificar el nombre de las Clases Conceptuales
69
Lista de Categorías con ejemplos
70
Frases nominales
70
¿Qué son los Atributos?
70
Atributos válidos
71
Clases de Tipos de Datos no Primitivos
71
Unidad 6: Ingeniería de Requerimientos
72
Temas
72
Bibliografía
72
3 de 112
Ejemplos del dominio de Interés
73
Perspectivas de los requerimientos
73
¿Requerimientos o Requisitos?
73
Definición
74
Tipos de Requerimientos
74
Requerimientos No funcionales
74
Propiedades Emergentes de los sistemas
75
Requerimientos No funcionales
75
Clasificación de los requerimientos no funcionales
75
Usabilidad
76
Eficiencia
77
Fiabilidad
77
Espacio
78
Portabilidad
78
Estándares
78
Entrega
78
Fiabilidad
78
79
SI
Requerimientos Funcionales
Escribir los requisitos funcionales
Ingeniería de los Requerimientos
-I
Requerimientos de dominio
79
80
81
Proceso de la Ingeniería de Requerimientos
81
Definición
81
FM
Reflexiones
81
Documento Especificación de Requerimientos del Sistema
82
Documentar los requisitos
82
Audiencia del documento de los requerimientos
84
Uso del documento de requerimientos
84
Requerimientos del Usuario
85
Recomendaciones para escribir los requerimientos del usuario
85
Requerimientos del Sistema
85
Requerimientos de Software
86
Estándar IEEE 830-1998
86
Estructura sugerida para el documento IEEE 830-1998
86
Recomendaciones del Std IEEE 830-1998
87
Recomendaciones del /ISO/IEEE Std 29148
87
Unidad 7: Obtención y Análisis de los Requerimientos
90
Temas
90
Bibliografía
90
Procesos de la Ingeniería de Requerimientos
90
Actividades para obtener requerimientos
91
Modo de trabajo en la obtención de los requerimientos
91
4 de 112
Entrevista
91
Planificación de la entrevista
91
Ventajas y Desventajas
92
Ejemplo de preguntas
92
Cuestionarios
93
Ventajas y desventajas
93
Etnografía
94
Observación participativa
94
Escenarios
94
Ejemplo
94
Prototipo
95
Factores humanos a considerar en la elaboración del prototipo
95
Propósito del prototipo en el ciclo de vida del sistema
96
Ventajas de la elaboración de prototipos
96
Lineamientos o guías para la construcción de prototipos
97
Actividades que realizamos para elaborar el prototipo
97
98
Tipo de información buscada con el prototipo
98
SI
1° actividad: Analizar y comprender las actividades del usuario
98
Evaluar el diseño de a UI con los usuarios finales: Técnicas para la evaluación de la UI
98
3° actividad: Evaluar el diseño de la UI con los usuarios finales
99
Iteración el proceso de desarrollo del prototipo
99
Temas
Bibliografía
103
Casos de Uso y Requisitos funcionales
Antecedentes
Diagrama de Casos de Uso
103
103
FM
Unidad 8: Análisis Orientado a Objetos
-I
Validación del prototipo con los usuarios finales
103
104
104
Elementos del diagrama de Casos de Uso: Actores
106
Elementos del diagrama de Casos de Uso: Caso de Uso
108
Documentar los Casos de Uso
109
Formalidad breve del documento
109
Formalidad documento completo
109
Formalidad del Documento
110
Procedimiento Básico para definir los Casos de Uso
Modelo de Análisis
111
111
Consideraciones importantes acerca del Modelo del Análisis
112
Diferencias entre el Modelo de Casos de Uso y el Modelo del Análisis
112
Elementos del Modelo del Análisis
112
Reglas para tener en cuenta
114
Ejemplo
114
Unidad 9: Validación de Requerimientos
118
5 de 112
Temas
118
Bibliografía
118
Validación de Requerimientos
118
¿Por qué es importante validar los requerimientos?
119
119
Verificar los requerimientos
120
Técnicas para verificar los requerimientos
120
Reunión formal de revisión
121
Características de calidad que verificamos de cada requerimiento
121
Características de calidad que verificamos del documento ERS
121
Ejemplo lista de verificación o checklist
122
Resumen de técnicas para verificar y validar los requerimientos
122
FM
-I
SI
Técnicas para la validación de requerimientos
6 de 112
Análisis de Sistemas
Unidad 1: Los Sistemas de Información
Temas
●
●
●
●
Revisión de conceptos sobre Sistemas y Organizaciones.
Revisión de la Teoría General de Sistemas.
Rol profesional del Ingeniero en Sistemas de Información y del Analista de Sistemas.
Técnicas para la recolección inicial de información.
Bibliografía
●
Kendall y Kendall, Análisis y Diseño de Sistemas, 8va Edición.
○ Capítulo 4: Recopilación de Información: Métodos Interactivos
Rol del Analista en Sistemas
FM
-I
SI
El analista de sistemas evalúa de manera sistemática el funcionamiento de un negocio mediante el
examen de la entrada y el procesamiento de datos y su consiguiente producción de información, con el propósito
de mejorar los procesos de una organización. Muchas mejoras incluyen un mejor apoyo a las funciones de
negocios a través del uso de sistemas de información computarizados. Esta definición pone énfasis en un enfoque
sistemático y metódico para analizar- y en consecuencia mejorar- lo que sucede en el contexto específico creado
por un negocio.
Nuestra definición de analista de sistema es amplia. El analista debe tener la capacidad de trabajar con
todo tipo de gente y contar con suficiente experiencia en computadora. El analista desempeña diversos roles, en
ocasiones varios de ellos al mismo tiempo. Los tres roles principales del analista de sistemas son el de consultor,
experto en soporte técnico y agente de cambio.
Rol del Ingeniero en Sistemas
Un Ingeniero de Sistemas debe estar capacitado para asumir distintos roles y desempeñarse en su lugar
de trabajo según la necesidad de la empresa, clientes, superiores, etc. Algunas de las formas en las que el
ingeniero puede desempeñarse son las siguientes:
El Ingeniero en Sistemas puede formar y dirigir su propia empresa de servicios y consultoría en sistemas.
Se encuentra en capacidad de trabajar en casi todas las áreas del quehacer humano y los servicios que ofrece
pueden ser también como empleado en cualquier organización, ya sea pública o privada, en instituciones de
investigación y centros de estudio. También puede ocupar, entre otros, los puestos de analista programador,
ingeniero de soporte técnico, comercializador de equipo de cómputo y puede dirigir centros de Cómputo,
administrar el desarrollo de software y ser instructor.
En el caso del ingeniero de sistemas computacionales (especialización), es un profesional que puede
prestar sus servicios en cualquier organización productiva de bienes y servicios, de los sectores públicos, privados y
social. De igual forma estará capacitado para desempeñarse de manera independiente, prestando sus servicios
profesionales en todo lo relacionado a creación, mantenimiento, desarrollo de aplicaciones, así como la
adquisición, mantenimiento de equipo, creación de sistemas de redes y comunicación y la utilización de la
multimedia en su desarrollo profesional.
El ingeniero de sistema tiene una gran gama de desarrollo ocupacional en el mercado laboral, ya que no
solo se dedica a la programación o a la construcción de redes, puede verse involucrado en la aplicación de ahorro,
7 de 112
ya sea de tiempo o materiales de sistemas de producción, como por ejemplo en la forma en que se realiza la
producción de materiales manufacturados, entre otros trabajos.
Como ya se había mencionado antes, el Ingeniero del Sistema es una persona que vive actualizando su
conocimiento constantemente, por lo que debe estar a la vanguardia de las nuevas metodologías y tecnologías.
Debe tener un concepto general sobre qué herramientas utilizar para la realización de nuevos sistemas o para el
mantenimiento de aquellos ya presentes en las empresas.
El descubrimiento de los requerimientos es el proceso de recoger información sobre el sistema propuesto
y los existentes, y extraer los requerimientos de usuario y del sistema de esta información. Las técnicas del
descubrimiento son: entrevistas, Diseño de aplicación conjunta (JAD), cuestionarios, etnografía, escenarios, casos
de uso, puntos de vista. Estos métodos poseen sus propiedades compartidas, la base es hablar con las personas en
la organización y escucharlas para comprender sus interacciones con la tecnología, a través de una serie de
preguntas cuidadosamente elaboradas.
Entrevista
-I
SI
Una entrevista para recopilar información es una conversación dirigida con un propósito específico, en la
cual se usa un formato de preguntas y respuestas. En la entrevista hay que obtener las opiniones del entrevistado y
lo que siente sobre el estado actual del sistema, los objetivos de la organización y los personales, y los
procedimientos informales para interactuar con las tecnologías de la información.
Los objetivos son información importante que podemos obtener de las entrevistas. Los datos “duros”
pueden explicar el desempeño en el pasado, pero los objetivos proyectan el futuro de la organización. Trate de
averiguar a través de las entrevistas la mayor cantidad posible de objetivos de la organización, pues tal vez no
pueda determinarlos mediante los otros métodos de recopilación de datos.
Los cinco pasos para la preparación de una entrevista
2.
3.
4.
5.
ENTÉRESE DE LOS ANTECEDENTES Lea y comprenda todo lo que pueda sobre los antecedentes de los
entrevistados y la organización. El sitio Web corporativo, un informe anual actualizado, un boletín de
noticias corporativo o cualquier publicación que se emita para explicar el funcionamiento de la empresa al
público son fuentes útiles de información. En esta fase de investigación ponga especial atención al
lenguaje utilizado por los integrantes corporativos para describirse a sí mismos y a la compañía. Otro
beneficio de investigar la organización es aprovechar al máximo el tiempo invertido en las entrevistas, al
no tener que hacer preguntas generales sobre antecedentes.
ESTABLEZCA LOS OBJETIVOS DE LA ENTREVISTA Defina los objetivos de la entrevista a partir de los
antecedentes investigados y de su propia experiencia.
DECIDA A QUIÉN ENTREVISTAR Incluya personas clave de todos los niveles que se vean afectados por el
sistema en cierta forma. Su contacto de la organización también le puede dar ideas sobre las personas
que debe entrevistar.
PREPARE AL ENTREVISTADO Para preparar a la persona que va a entrevistar, llame por teléfono o envíe
un mensaje de correo electrónico con anticipación, de manera que el entrevistado esté preparado. Las
entrevistas se deben realizar por lo general en persona y no a través de correo electrónico. Deben durar
de 45 minutos a 1 hora como máximo.
DECIDA SOBRE LOS TIPOS DE PREGUNTAS Y SU ESTRUCTURA Redacte preguntas para cubrir las áreas
principales de la toma de decisiones que hayan descubierto al momento de determinar los objetivos de la
entrevista.
FM
1.
8 de 112
Tipos de preguntas
Preguntas Abiertas
Las preguntas abiertas describe las opciones que tiene el entrevistado para responder. La respuesta
puede constar de dos palabras o de dos párrafos.
Los ​beneficios​ de utilizar preguntas abiertas son muchos, entre los cuales tenemos:
1.
2.
3.
4.
5.
6.
7.
8.
El entrevistado baja la guardia. Pone al entrevistado confortable.
El entrevistador puede percibir el vocabulario del entrevistado, lo cual refleja su educación, valores,
posturas y creencias.
Se proveen muchos detalles.
Se descubren vías de cuestionamiento adicionales que de otra manera no se hubieran explotado.
El entrevistado encuentra el proceso más interesante.
Se permite una mayor espontaneidad.
El entrevistador puede expresar mejor las preguntas.
El entrevistador puede recurrir a ellas en caso de que tenga que improvisar.
Como puede ver, hay varias ventajas en cuanto al uso de preguntas abiertas. Sin embargo, también hay muchas
desventajas​:
SI
Las preguntas pueden generar muchos detalles irrelevantes.
Se puede llegar a perder el control de la entrevista.
Se permiten respuestas que pueden requerir demasiado tiempo.
Podría parecer que el entrevistador no está preparado.
Puede darse la impresión de que el entrevistador no tiene objetivos bien definidos.
-I
1.
2.
3.
4.
5.
Debe considerar con cuidado las implicaciones de usar preguntas abiertas en las entrevistas.
FM
Preguntas Cerradas
Una pregunta cerrada limita el entrevistado la respuesta disponible. Tal vez usted esté familiarizado con
las preguntas cerradas debido a los exámenes de opción múltiple de la universidad.
Hay un tipo especial de pregunta cerrada: la pregunta bipolar. Este tipo de pregunta limita incluso más al
entrevistado, ya que sólo le permite elegir uno de dos polos.
Los ​beneficios​ de usar preguntas cerradas de cualquier tipo incluyen:
1.
2.
3.
4.
5.
6.
Ahorro de tiempo.
Se pueden comparar las entrevistas con facilidad.
Van directo al grano.
Se mantiene el control sobre la entrevista.
Se cubre mucho terreno con rapidez.
Se obtienen datos relevantes.
Sin embargo, las ​desventajas​ de usar preguntas cerradas son sustanciales. Entre las más comunes tenemos:
1.
2.
3.
4.
Son aburridas para el entrevistado.
No proporcionan detalles adicionales (debido a que el entrevistador provee el marco de
referencia para el entrevistado).
Se pierden las ideas principales por la razón anterior.
No se puede generar una relación armónica o buena comunicación entre el entrevistador y el
entrevistado.
9 de 112
Por lo tanto, como entrevistador usted debe considerar con cuidado los tipos de preguntas que piensa utilizar.
Estructuras de las entrevistas
SI
Atributos de las preguntas abiertas y las preguntas cerradas.
FM
-I
USO DE UNA ESTRUCTURA DE PIRÁMIDE La organización inductiva de las preguntas de la entrevista se puede
visualizar en forma de pirámide. El entrevistador empieza con preguntas muy detalladas, a menudo cerradas.
Después expande los temas al permitir preguntas abiertas y respuestas más generalizadas.
USO DE UNA ESTRUCTURA DE EMBUDO El entrevistador usa un enfoque deductivo al empezar con preguntas
generalizadas y abiertas, para después reducir la cantidad de respuestas posibles mediante el uso de preguntas
cerradas. El método de la estructura de embudo ofrece una manera fácil y amigable de empezar una entrevista.
10 de 112
También es conveniente usar una secuencia de preguntas en forma de embudo cuando el entrevistado está
relacionado sentimentalmente con el tema y necesita libertad para expresar esos sentimientos.
FM
-I
SI
USO DE UNA ESTRUCTURA EN FORMA DE DIAMANTE A menudo es mejor utilizar una combinación de las dos
estructuras anteriores. En esta estructura el entrevistador empieza con preguntas fáciles y cerradas que permiten
al entrevistado entrar en calor; a la mitad se le pregunta lo que opina sobre temas amplios. Después, el
entrevistador restringe incluso más las preguntas para obtener respuestas específicas, con lo cual se produce un
cierre tanto para el entrevistado como para el entrevistador. La estructura de diamante combina las ventajas de
los otros dos métodos pero tiene la desventaja de que toma más tiempo que las otras dos estructuras.
11 de 112
Diseño de Aplicación Conjunta (JAD)
Las entrevistas personales consumen tiempo y son propensas a errores, por lo cual sus datos se pueden
malinterpretar. IBM desarrolló una metodología alternativa para entrevistar a los usuarios uno a uno, conocida
como diseño de aplicación conjunta (JAD).
Los motivos para usar JAD son reducir el tiempo (y por ende el costo) requerido por las entrevistas
personales, mejorar la calidad de los resultados de la evaluación de los requerimientos de información y mejorar el
grado de identificación del usuario con los nuevos sistemas de información como resultado de los procesos
participativos.
Se emplea como técnica que le permite a usted, como analista de sistemas, realizar el análisis de
requerimientos y diseñar la interfaz de usuario en forma conjunta con los usuarios, en un ambiente de grupo.
Beneficios de JAD
FM
-I
SI
Existen cuatro beneficios potenciales que usted, los usuarios y su equipo de análisis de sistemas deben
tener en consideración al sopesar las posibilidades de usar el diseño de aplicación conjunta.
➢ El primer beneficio potencial es el ahorro de tiempo en comparación con las entrevistas tradicionales cara
a cara. Algunas organizaciones han estimado que las sesiones JAD permiten ahorrar el 15 por ciento del
tiempo en comparación con el método tradicional.
➢ Además del ahorro en tiempo es posible efectuar un desarrollo rápido a través de JAD.
➢ Un tercer beneficio a considerar es la posibilidad de mejorar la posesión del sistema de información.
Debido a su naturaleza interactiva y alto grado de visibilidad, JAD ayuda a los usuarios a que se involucren
lo más pronto posible en los proyectos de sistemas y considera seriamente su retroalimentación. La
participación en una sesión JAD ayuda en un momento dado a reflejar las ideas del usuario en el diseño
final.
➢ Un beneficio final de participar en las sesiones JAD es el desarrollo creativo de los diseños. El carácter
interactivo de JAD tiene mucho en común con las técnicas de lluvias de ideas que generan nuevas
propuestas y combinaciones entre ellas, debido al entorno dinámico y estimulante.
Desventajas potenciales de JAD
Hay tres desventajas u obstáculos que también debemos sopesar al decidir si usaremos las entrevistas
convencionales o JAD.
➢ Todos los participantes comprometan mucho tiempo. Como JAD requiere su dedicación durante un
periodo de dos a cuatro días, no es posible realizar ninguna otra actividad en forma concurrente ni
postergar actividades, como se realiza comúnmente en las entrevistas cara a cara.
➢ El segundo obstáculo se produce cuando la preparación para las sesiones JAD es inadecuada en cualquier
aspecto, o si el informe de seguimiento y la documentación de las especificaciones están incompletos. En
estos casos, los diseños resultantes podrían ser insatisfactorios. Es necesaria la conjunción de muchas
variables correctas para que el JAD sea exitoso; en contraste, muchas cosas podrían salir mal.
➢ Tal vez las habilidades necesarias de la organización y su cultura no estén lo bastante desarrolladas como
para permitir el esfuerzo concertado requerido para ser productivos en un entorno JAD. Al final tendrá
que juzgar si la organización realmente está comprometida y preparada para esta metodología.
Cuestionarios
El uso de cuestionarios es una técnica de recopilación de información que permite a los analistas de
sistemas estudiar las posturas, las creencias, el comportamiento y las características de varias personas clave en la
organización. Las posturas son lo que las personas en la organización dicen desear; las creencias son lo que las
personas dan por cierto; el comportamiento es lo que hacen los miembros de la organización, y las características
12 de 112
son las propiedades de las personas u objetos. Las respuestas obtenidas a través de cuestionarios (también
conocidos como encuestas) en los que se utilizan preguntas cerradas se pueden cuantificar.
Además, es posible usar cuestionarios para encuestar a una muestra grande de usuarios de sistemas con
el fin de detectar problemas o llevar a la mesa de discusión cuestiones importantes antes de programar las
entrevistas.
Planeación del uso de cuestionarios
Escribir las preguntas
-I
SI
Cuando decidimos encuestar a los usuarios por correo electrónico o a través de Web, debemos tomar en
cuenta ciertos aspectos de planeación adicionales relacionados con la confidencialidad, la autenticación de la
identidad y los problemas de respuestas múltiples.
He aquí algunos lineamientos para ayudarlo a decidir si es apropiado utilizar cuestionarios. Considere el
uso de cuestionarios si:
1. Las personas a quienes necesita interrogar están esparcidas en un área amplia (distintas sucursales de la
misma corporación).
2. Hay gran cantidad de personas involucradas en el proyecto de sistemas, por lo que es importante saber
qué proporción de un grupo dado (por ejemplo, la gerencia) aprueba o desaprueba una característica
específica del sistema propuesto.
3. Se está por realizar un estudio exploratorio y desea medir la opinión general antes de que el proyecto de
sistemas tome cualquier dirección específica.
4. Desea estar seguro de que se identifiquen y consideren los problemas con el sistema actual en las
entrevistas de seguimiento.
Una vez que haya determinado que tiene buenos motivos para usar un cuestionario y después de que
haya señalado los objetivos a cumplir por medio de éste, podrá empezar a formular las preguntas.
FM
En una entrevista, el analista tiene la oportunidad de refinar una pregunta, definir un término confuso,
cambiar el curso del cuestionamiento, responder a una mirada desconcertada y en general, controlar el contexto.
En un cuestionario, muy pocas de estas oportunidades son posibles.
Los tipos de preguntas básicas que se utilizan en el cuestionario son abiertas y cerradas, como vimos en
las entrevistas. Debido a las restricciones que se imponen en los cuestionarios, se justifica un análisis adicional
sobre los tipos de preguntas.
PREGUNTAS ABIERTAS Recuerde que las preguntas (o declaraciones) abiertas son las que dejan abiertas todas las
posibles opciones de respuesta para el encuestado. Al escribir preguntas abiertas para un cuestionario, debemos
anticiparnos al tipo de respuesta que obtendremos. Por lo tanto, incluso cuando escriba una pregunta abierta, ésta
debe ser lo suficientemente estrecha como para guiar a los encuestados a responder en cierta forma específica.
En particular, las preguntas abiertas son adecuadas para las situaciones en las que queremos conocer las opiniones
de los miembros de la organización sobre cierto aspecto del sistema, ya sea un producto o un proceso.
PREGUNTAS CERRADAS Recuerde que las preguntas (o declaraciones) cerradas son aquellas que limitan o cierran
las opciones de respuestas disponibles para el encuestado.
Hay que utilizar preguntas cerradas cuando el analista de sistemas pueda enlistar de manera efectiva todas las
posibles respuestas a la pregunta y cuando todas éstas sean mutuamente exclusivas (al elegir una de ellas se
descarta la posibilidad de elegir cualquier otra).
Use preguntas cerradas cuando desee encuestar a una amplia muestra de personas. La razón se vuelve obvia al
momento de imaginar cómo se verán los datos que vamos a recolectar.
13 de 112
Las ventajas que sacrifica al elegir uno y otro tipo de preguntas
TERMINOLOGÍA DE LAS PREGUNTAS Al igual que en el caso de las entrevistas, el lenguaje de los cuestionarios es
un aspecto en extremo importante de su efectividad. Incluso si el analista de sistemas cuenta con un conjunto
estándar de preguntas relacionadas con el desarrollo de sistemas, es conveniente escribirlas de manera que
reflejen la terminología propia de la empresa.
He aquí algunos lineamientos que puede utilizar al elegir el lenguaje para su cuestionario:
5.
6.
7.
8.
SI
-I
3.
4.
Use el lenguaje de los encuestados siempre que sea posible. Mantenga un vocabulario simple.
Concéntrese en ser específico en vez de utilizar palabras imprecisas. Evite también las preguntas
demasiado específicas.
Trate de mantener las preguntas cortas.
No use un tono condescendiente, al usar opciones redactadas en lenguaje de bajo nivel, para dirigirse a
los encuestados.
Evite la predisposición en sus palabras. Esto también significa evitar preguntas censurables.
Dirija las preguntas a los encuestados apropiados (es decir, los que sean capaces de responder). No
suponga que conocen demasiado.
Asegúrese de que las preguntas sean correctas en el sentido técnico antes de incluirlas.
Use software para verificar si el nivel de lectura es apropiado para los encuestados.
FM
1.
2.
Diseño de cuestionarios
Un cuestionario bien diseñado y relevante puede ayudar a vencer parte de esta resistencia a responder. He aquí
algunas reglas para diseñar un buen cuestionario:
1.
2.
3.
4.
Incluya mucho espacio en blanco.
Incluya mucho espacio para escribir o teclear las respuestas.
Facilite a los encuestados la acción de marcar con claridad sus respuestas.
Mantenga un estilo consistente.
ORDEN DE LAS PREGUNTAS No existe una forma de ordenar las preguntas en el cuestionario que sea la mejor de
todas. Algunos lineamientos para ordenar preguntas son:
1.
2.
3.
Coloque primero las preguntas que sean importantes para los encuestados.
Agrupe elementos de contenido similar.
Introduzca primero las preguntas menos controversiales.
14 de 112
Etnografía
Es una técnica de observación que se puede utilizar para entender los requerimientos sociales y
organizacionales. Un analista se sumerge por sí solo en el entorno laboral donde se utilizara el sistema. Observa el
trabajo diario y anota las tareas reales de los participantes.
La etnografía ayuda a los analistas a descubrir los requerimientos implícitos que reflejan los procesos
reales más que los formales en los que la gente está involucrada.
Esta técnica es efectiva para el descubrimiento de 2 tipos de requerimientos:
●
●
Los requerimientos que se derivan de la forma en la que la gente trabaja realmente.
Los requerimientos que se derivan de la cooperación y conocimiento de las actividades de la gente.
Escenarios
SI
Muestra un esbozo de la interacción y se agregan detalles para crear una descripción completa de esta
interacción. Deben incluir.
● Una descripción de lo que se espera del sistema y los usuarios cuando el escenario comienza.
● Una descripción normal del flujo de eventos en el escenario.
● Una descripción de lo que pueda salir mal y cómo solucionarlo.
● Información de otras actividades que pueden llevar a cabo en el mismo tiempo.
● Una descripción del estado del sistema cuando termina.
Se puede hacer diagramas, capturar pantallas, etc.
-I
Casos de uso
Identifican las interacciones particulares con el sistema. Pueden ser documentadas con texto o vinculadas
a modelos UML que desarrollan ese escenario en más detalle.
FM
Puntos de vista
Un punto clave en el análisis orientado a puntos de vista es que reconoce varias perspectivas y
proporciona un marco de trabajo para describir conflictos en los requerimientos propuestos por los diferentes
stakeholders. Existen tres puntos genéricos de puntos de vista:
● Puntos de vista de los interactores: representa a las personas que interactúan directamente con el
sistema.
● Puntos de vista indirectos: representa a los stakeholders que no utilizan el sistema ellos mismos pero que
influyen en los requerimientos de algún modo.
● Puntos de vista del dominio: representa a las características y restricciones del dominio que influyen en
los requerimientos del sistema.
15 de 112
Unidad 2: El ciclo de vida de los Sistemas de Información y
Sistemas de Software
Temas
●
●
●
●
●
Ciclo de vida de los Sistemas de Información.
Proceso de desarrollo de los Sistemas.
Metodologías: Estructurada y orientada a objetos.
Componentes de un Sistema de Información
Modelos de proceso de desarrollo de Software
Bibliografía
●
●
Kendall & Kendall. 6a Ed. Capítulo 1, Rol del Analista
Sommerville. 7a Ed. Capítulo 2, Sistema socio-técnicos y 4, Procesos de Software.
●
●
-I
●
Desde el punto de vista de los Sistemas de Información, el ciclo de vida es el conjunto de fases [o
procesos] por las que pasa el sistema desde que se concibe [o inicio], se desarrolla hasta que se retira del
servicio finalizando su uso [desmantelamiento del sistema].
El conjunto de fases (procesos o actividades) del ciclo de vida involucra desde la planificación, la
distribución temporal, el desarrollo hasta el mantenimiento necesario durante la explotación del sistema.
Las fases o procesos están estandarizados de manera que puedan ser adaptados a las necesidades de
quien lo use.
El estándar para el ciclo de vida de los sistemas de información es el ISO/IEC/12207.
FM
●
SI
Ciclo de Vida para los Sistemas de Información
¿Qué es un estándar?
●
Un estándar es un documento establecido por consenso aprobado por un organismo reconocido, y que
ofrece reglas, guías o características para su uso repetidamente. Especifican qué hacer no cómo hacerlo.
○ International Organization for Standardization (ISO)
○ International Electronics Commission (IEC)
16 de 112
FM
-I
SI
Estándar ISO/IEC 12207 para el ciclo de vida de los sistemas de información
17 de 112
●
●
Las actividades asociadas al ciclo de vida del desarrollo de los SI son continuas.
Conforme se construye el sistema, el proyecto tiene cronogramas y fechas límite, hasta que el sistema se
instale y acepte.
La vida del sistema continúa mientras se mantiene y revisa.
Si el sistema necesita sustituirse debido a una nueva generación de tecnología, o si las necesidades de los
Sistemas de Información de la organización cambian significativamente, el sistema puede desmantelarse y
se iniciará un nuevo proyecto y ciclo comenzará de nuevo.
FM
●
●
-I
SI
Ciclo de vida del desarrollo de Sistemas
Ciclo de vida
●
●
No hay un acuerdo en la cantidad de fases que incluye el ciclo de vida del desarrollo de sistemas
Kendall y Kendall divide el ciclo de vida del desarrollo en siete fases las cuales pueden observar en la
siguiente figura:
18 de 112
FM
-I
SI
Proceso de Ingeniería en Sistemas
*Sommerville, enfoca el ciclo de vida del sistema como el Proceso de la Ingeniería de Sistemas
Etapa Definición de requerimientos
●
●
●
Involucra a la fase Análisis de Sistemas.
Se especifica qué es lo que el sistema deberá hacer es decir:
○ Las funciones que el sistema deberá proporcionar.
○ El comportamiento o propiedades esenciales y deseables.
○ La relación del sistema con otros sistemas de información.
Para lograr especificar el sistema, los analistas de sistemas entrevistamos (o hacemos cuestionarios) a los
clientes y usuarios finales del sistema.
Importancia del ciclo de vida de desarrollo
●
El Ciclo de Vida de Desarrollo de Sistemas sirve de base de los procesos utilizados para desarrollar un
sistema de información
19 de 112
Es conveniente seleccionar una metodología de trabajo porque:
○ Construir un ​sistema socio-técnico es una actividad compleja que requiere un gran esfuerzo
sobre todo de las personas.
○ El sistema tiene un conjunto de componentes como el ​software​, hardware, datos, documentos,
redes, etc., los cuales debemos gestionar.
○ Las personas que interactúan entre sí, tienen diferentes grados de conocimiento, asumen
diferentes ​roles​ y poseen diferentes intereses hacia el sistema.
○ Definir un ​marco de trabajo nos permite organizar el proceso de desarrollo definiendo el
cronograma de actividades, las pautas a seguir y también restricciones a cumplir.
FM
-I
SI
●
¿Qué es un proceso de desarrollo del software?
●
Un proceso de desarrollo del software es un conjunto completo de actividades y resultados asociados
necesarios para transformar los requerimientos de un cliente / usuario en un producto o sistema.
*Sommerville, cap 1.
20 de 112
Actividades comunes a los procesos de desarrollo de software
●
Existen cuatro actividades fundamentales comunes para todos los procesos de desarrollo:
Actividades comunes
Breve descripción de la actividad
Se define la funcionalidad del software y las restricciones sobre su operación. En
base al resultado obtenido, se construirá el sistema durante las siguientes fases
del proyecto.
Desarrollo
En base a la especificación resultado de la anterior actividad, se construye el
sistema de forma que cumpla todos los requisitos y restricciones solicitados por el
cliente.
Validación
El software es validado para asegurar que el producto generado es exactamente
lo que el cliente quiere.
Evolución
El software debe evolucionar para incorporar los cambios solicitados por el cliente
y por el mercado.
SI
Especificación
¿Qué es un modelo de proceso de desarrollo de software?
-I
●
●
Un modelo de proceso es una descripción simplificada de un proceso del software que presenta un visión
de ese proceso.
El modelo de proceso define el ciclo de vida que se adoptará para el proyecto de sistemas.
Los modelos de proceso pueden incluir:
○ Flujo de trabajo: muestra la secuencia de actividades en el proceso con sus entradas, salidas y
dependencias. Las actividades representan acciones humanas.
○ Flujo de documentos: muestra los documentos o artefactos que producen cada una de las
actividades y cómo esos documentos se transforman por acción de las personas o por las
computadoras.
○ Modelo de rol/acción: representa los roles de las personas involucradas en el proceso del
software y las actividades de los que son responsables.
FM
●
21 de 112
SI
Modelo de Procesos de Desarrollo del Software
FM
-I
Modelos de Procesos de Desarrollo del Software: Modelos Tradicionales
22 de 112
FM
-I
Roles sugeridos por cada fase
SI
Modelo en Cascada (Sommerville)
23 de 112
Resumen de etapas
Definición de Requerimientos
Se obtiene información acerca del ​dominio del problema​ y los ​requisitos​ que deberá cumplir el sistema.
Hay una gran interacción entre el cliente y analista de sistemas.
En este momento se define el alcance del sistema​, es decir, se define lo que el sistema va a hacer y lo que
no va a hacer.
Una vez terminada esta etapa, no se pueden pedir nuevos requisitos o cambios sobre los existentes.
Diseño del Software
Una vez definido completamente el problema y se conocen los requisitos, en esta etapa de Diseño se
define la arquitectura del sistema​, los ​módulos del sistema, las ​estructuras de datos​, las ​interfaces entre los
subsistemas​ y el ​diseño de los algoritmos​.
Implementación y Prueba de Unidades
En esta etapa, en Diseño del Software se materializa mediante la ​codificación de los programas ​en un
lenguaje de alto nivel. Las pruebas de unidades implica ​comprobar que los componentes de los programas (por
ejemplo las funciones, subrutinas, las clases) ​funcionen correctamente​.
Integración y Prueba del Sistema
Operación y Mantenimiento
-I
SI
La integración del sistema es un proceso gradual y se refiere a la actividad de conectar los componentes
del sistema (componentes de hardware, de software y de datos) con el fin de transferir información.
La integración de sistema nos exige crear "puentes" para ensamblar componentes que son muy diferentes
entre sí, por lo tanto el enlace o comunicación entre ellos se debe probar para validar que el sistema como un todo
funcione correctamente.
FM
Por lo general esta es la fase más larga del ciclo de vida. El sistema se instala y se pone en funcionamiento
práctico para los usuarios finales.
El mantenimiento gestiona los cambios e implica corregir defectos no descubiertos en etapas anteriores
también mejorar los programas (unidades del sistema) y adaptar el sistema a nuevos requerimientos.
Descripción Modelo en Cascada
●
●
●
Este modelo refleja un desarrollo marcado por la sucesión escalonada de las etapas que lo componen:
Análisis de requerimientos, diseño, codificación, pruebas e implementación.
Es necesario terminar por completo cada fase para pasar a la siguiente
Al aplicarlo en situaciones reales su rigidez genera problemas, porque muchas veces resulta difícil poder
disponer de requisitos completos o del diseño pormenorizado del sistema en las fases iniciales, creando
una barrera que impide avanzar.
Desventajas Modelo en Cascada
●
●
●
Los proyectos reales raras veces siguen el desarrollo secuencial que propone el modelo en cascada.
Los cambios pueden causar confusión cuando el equipo de desarrollo comienza a trabajar.
A menudo es difícil que el cliente exponga explícitamente todos los requisitos. El modelo en cascada así lo
requiere y tiene dificultades a la hora de acomodar la incertidumbre natural al comienzo de muchos
proyectos.
24 de 112
●
El cliente debe tener paciencia. Una versión del trabajo del (los) programa(s) no estará disponible hasta
que el proyecto esté muy avanzado. Un grave error puede ser desastroso si no se detecta hasta que se
revisa el programa.
Ventajas Modelo en Cascada
●
●
●
●
Produce sistemas bien documentados susceptibles de cambios fundamentalmente por la separación del
diseño y la implementación.
Funciona bien para proyectos pequeños donde los requisitos están bien entendidos.
Es un modelo en el que todo el trabajo está bien organizado y no se mezclan las fases. Es simple y fácil de
usar.
Es el modelo de proceso más antiguo y utilizado para el desarrollo de aplicaciones de software.
¿Cuándo es conveniente utilizar el Modelo en Cascada?
●
●
●
●
Las necesidades del cliente y los requerimientos del sistema se ​comprenden y están ​completamente
definidos​ y conocidos de antemano.
Es poco probable el pedido de cambio en los requerimientos.
El equipo de trabajo no tiene experiencia en el desarrollo de sistemas.
El sistema requiere documentación detallada de cada una de las fases.
FM
-I
SI
Modelo Evolutivo
●
●
●
●
Las actividades de especificación, desarrollo y validación son concurrentes.
No existe una especificación detallada del sistema y la documentación se minimiza.
El sistema se desarrolla en una serie de incrementos o versiones añadiendo funcionalidad a las anteriores.
Las versiones se muestran a los clientes y otros stakeholders para que ellos las evalúen y propongan
cambios y se continúa así hasta agotar el tiempo, el presupuesto o hasta que el cliente esté satisfecho.
Prototipos del Modelo Evolutivo
●
Prototipo exploratorio: El objetivo es trabajar con clientes hasta evolucionar a un sistema final, a partir de
una especificación inicial. Se debe comenzar con unas especificaciones bien entendidas.
25 de 112
●
Prototipo desechable o "throw-away": El objetivo es entender los requerimientos del sistema. Se puede
comenzar con especificaciones poco entendidas resolviendo las incertidumbres.
Ventajas Modelo Evolutivo
●
●
Continua revisión por parte del cliente​: Los clientes pueden validar las versiones del sistema y de esta
forma, dado que se inicia el trabajo con un esbozo del sistema, los posibles fallos conceptuales y otros
posibles motivos de disconformidad por parte del cliente pude ser detectados antes de que se impliquen
cambios en el sistema.
Permite cambios de requerimientos​: Permite la modificación de requerimientos sobre la marcha, y una
mayor implicación por parte del cliente en las pruebas y validación de requerimientos.
Desventajas Modelo Evolutivo
●
●
Desde la perspectiva de ingeniería y gestión, el modelo evolutivo tiene las siguientes desventajas:
El proceso no es visible: Los administradores tienen que hacer entregas regulares para medir el progreso.
Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión
del sistema.
A menudo los sistemas tienen una estructura deficiente: Origina un software que puede estar débilmente
estructurado y difícil de comprender y mantener. Los cambios continuos tienden a corromper la
estructura del software. Incorporar cambios en él se convierte cada vez más en una tarea difícil y costosa.
Se desarrollan sistemas pequeños y tamaño medio (hasta 500.000 líneas de código)
Es necesario resolver incertidumbres en la especificación del sistema.
No se recomienda para sistemas grandes, complejos y con período de vida largo donde diferentes equipos
desarrollan distintas partes del sistema. Es difícil establecer una arquitectura estable del sistema.
-I
●
●
●
SI
¿Cuándo es conveniente utilizar el Modelo evolutivo?
●
●
●
●
●
FM
Modelo Espiral
El Modelo Espiral, propuesto en 1988 por Barry Boehm.
El modelo reconoce la naturaleza iterativa del desarrollo y combina actividades de desarrollo con gestión
de riesgo, para minimizar y controlar el riesgo.
El modelo divide el desarrollo en cuatro regiones o sectores:
a. Determinar objetivos, alternativas y restricciones.
b. Evaluar alternativas, identificar y resolver los riesgos.
c. Desarrollar, verificar el producto del siguiente nivel.
d. Planificar las siguientes fases.
Cada una de las regiones están compuestas por un conjunto de tareas las cuales se adaptan a las
características del proyecto que va a emprenderse.
Ejemplo de tareas: Análisis de sistemas, Diseño de Sistemas, Construcción de programas, Pruebas,
Mantenimiento.
26 de 112
SI
●
●
●
Cada ciclo o iteración en la espiral representa una ​fase del proceso​ de desarrollo del software.
El ciclo más interno, ​1° iteración​, podría referirse a un estudio de la ​viabilidad del sistema​, es decir que
incluye por ejemplo:
○ El presupuesto: la viabilidad económica del proyecto
○ Un cronograma inicial de desarrollo con un Diagrama de Gantt
○ Restricciones tecnológicas [Hardware y Software]
○ Alternativas para el personal.
Luego se ​evalúan riesgos del proyecto y se construye ​prototipos de las alternativas y la simulación [es la
segunda región de la espiral]
Después se escribe un ​documento con el "concepto de las operaciones", el cual describe la funcionalidad
del sistema en un nivel alto, desde el punto de vista del usuario [es la tercera región de la espiral]
El "​concepto de las operaciones​" es el ​documento​ que produce la primera iteración.
FM
●
●
-I
¿Qué se realizar en la Primera Iteración?
27 de 112
SI
Acciones comunes a todas las iteraciones
●
-I
●
●
En cada iteración o ciclo de la espiral se hace un ​análisis de riesgo de las alternativas según los requisitos
y restricciones.
Se ​construyen prototipos​ para analizar las alternativas y seleccionar una.
Los prototipos pueden ser simples maquetas en papel, prototipos de interfaz de usuario o simulaciones
del sistema, dependiendo del riesgo a evaluar, según el ciclo en el proceso y del tipo de aplicación.
Cada vez que se pasa por la región de planificación se ajusta el costo y el calendario del proyecto.
FM
●
¿Qué se realiza en cada iteración?
●
●
●
●
En la ​segunda iteración​, una vez que se han evaluado los riesgos y se decide continuar con el proyecto, se
planifica definición de los requerimientos que se realizará en la siguiente fase del proceso [es la cuarta
región de la espiral]
A partir del documento "Concepto de las operaciones", en la segunda iteración se realiza el proceso de
definición de los requerimientos del sistema​.
Los requerimientos del sistema son validados por el cliente con los prototipos que evolucionan desde la 2°
región.
Luego se escribe un documento denominado Especificación de Requerimientos del Sistema.
28 de 112
●
SI
-I
●
En la ​tercera iteración se hace un plan de desarrollo, y se produce el ​Diseño del Sistema que es verificado
y validado.
En la ​cuarta iteración se hace un plan de integración y prueba​, se genera el software y se realizan las
pruebas de aceptación.
Se realiza la entrega y la puesta en servicio del sistema
FM
●
29 de 112
SI
-I
FM
30 de 112
SI
-I
FM
Ventajas Modelo en Espiral
●
●
●
●
●
●
Es un enfoque realista del desarrollo de Sistemas y de Software a gran escala.
Utiliza la ​construcción de prototipos​ como mecanismo de reducción de riesgos.
La construcción de prototipos facilita la validación de los requerimientos al entregar versiones del sistema
desde el final de la primera iteración.
El riesgo de sufrir retrasos en el proyecto es menor porque los problemas se identifican en etapas
tempranas y hay tiempo para subsanarlos.
El ​anaĺisis del riesgo​ se hace de ​forma explícita y clara​.
Utiliza el enfoque sistemático del ​modelo en cascada y el trabajo iterativo del ​modelo evolutivo​, lo cual
refleja de forma más realista la construcción del software.
31 de 112
Unidad 3: Marco de desarrollo. Proceso Unificado
Temas
●
●
●
Concepto sobre el marco de desarrollo: Fases, disciplinas, artefactos
Actividades iniciales del proyecto de sistemas.
La actividad Análisis de Sistemas.
Bibliografía
●
●
Larman 2a Ed.
○ Capítulo 2, Desarrollo iterativo.
○ Capítulo 4, Inicio.
Booch Jacobson Rumbaugh. 1a Ed.
○ Capítulo 1, Proceso Unificado.
¿Por qué es importante aplicar una metodología de trabajo?
SI
●
-I
●
La importancia de aplicar una metodología de trabajo, la podemos razonar desde los sistemas de
información, que también la bibliografía los identifica como sistemas ​socio técnicos​.
Los sistemas socio-técnicos no solamente incluyen ​hardware​, ​software sino también el conocimiento de
cómo debe usarse el sistema para alcanzar algún objetivo más amplio.
Los sistemas socio-técnicos incluyen a las ​personas como partes inherentes del sistema, son ​gobernados
por políticas y reglas organizacionales y pueden verse afectados por ​restricciones externas tales como
leyes nacionales y políticas reguladoras.
FM
●
32 de 112
SI
-I
Desarrollar sistemas socio-técnicos es una actividad compleja por eso necesitamos una metodología de
trabajo que nos proporcione:
1. Una guía para ordenar las actividades a realizar durante el proyecto de sistemas.
2. Pautas acerca de cómo se realizan los documentos o artefactos, que son el resultado del trabajo
en cada actividad.
3. Indicaciones sobre quiénes realizarán cada una de las actividades o tareas y las responsabilidades
de cada una de las personas que participan en el proyecto.
4. Un ciclo de vida que describa cómo organizar las actividades a lo largo del tiempo.
FM
●
Proceso Unificado
●
●
●
●
●
La metodologías fueron evolucionando con el tiempo y una metodología de trabajo es el Proceso
Unificado.
RUP [Proceso unificado Rational] es un modelo de proceso híbrido propuesta por Rational para el
desarrollo de proyectos de sistemas.
El modelo reúne elementos de todos los modelos de procesos genéricos [modelo en cascada, modelo
evolutivo], iteraciones de apoyo [modelo en espiral] e ilustra buenas prácticas en la especificación y el
diseño.
RUP se describe normalmente desde tres perspectivas:
1. Perspectiva dinámica​: muestra las fases del modelo sobre el tiempo.
2. Perspectiva estática​: muestra las actividades del proceso que se representan.
3. Perspectiva práctica​: sugiere buenas prácticas a utilizar durante el proceso.
UP es un modelo de proceso denominado Proceso Unificado, que está basado en el RUP.
33 de 112
SI
-I
●
El UP es un modelo adaptable, es decir que puede responder rápidamente a las necesidades cambiantes
de los clientes.
Aplicamos el modelo UP como un ​proceso ágil​, es decir:
○ Tiene un conjunto pequeño de actividades y artefactos
○ Es un proceso iterativo e incremental.
○ No hay un plan detallado para todo el proyecto. Hay un plan de alto nivel denominado Plan de
fase.
FM
●
34 de 112
FM
-I
SI
Proceso Unificado Rational - RUP
35 de 112
SI
-I
FM
36 de 112
Fases del Proceso Unificado Rational
Fase
Breve Descripción
Inicio
Estudiar e identificar los problemas / oportunidades / retos con respecto a la organización.
Además se determina quiénes usarán el sistema (personas u otros sistemas) y cuánto costará
el proyecto.
Si el aporte del sistema es de poca importancia entonces se puede cancelar el proyecto
después de esta fase.
Elaboración
Se desarrolla una visión detallada del dominio del problema y se representa la arquitectura
conceptual del sistema. Además se identifican los riesgos y se desarrolla el plan del proyecto.
Construcción
Comprende el diseño del sistema, programación y las pruebas. Se desarrollan e integran las
partes del sistema en la arquitectura. Al terminar esta fase se tiene un sistema de software
operativo y la documentación lista para entregar a los usuarios.
Transición
El sistema se convierte en versión beta. Esta versión la prueban los usuarios y reportan los
defectos. Al terminar esta fase se debe tener un sistema documentado y funcionando
correctamente en su entorno operativo.
Breve Descripción
-I
Actividades
SI
Disciplinas o actividades del Proceso Unificado
Se modelan los procesos de negocios.
Requerimientos
Se modelan los requerimientos del sistema.
Análisis y diseño
Implementación
FM
Modelado del negocio
Se crea y documenta el modelo del diseño creando modelos de la arquitectura.
Codifica y construye el software.
Pruebas
Se prueban los componentes y el sistema.
Despliegue
Se crea un release del producto, se distribuye a los usuarios y se lo instala en el
lugar de trabajo.
Configuración y cambios
Gestiona los cambios del sistema.
Gestión del proyecto
Gestiona el desarrollo del sistema.
Entorno
Herramientas de software disponibles para el equipo de desarrollo de software y
los artefactos a producir.
Definiciones
Incremental​: se inicia con una idea bien definida. Cada "iteración" construye una versión, se valida y luego
se refina con calidad.
La iteración permite avanzar desde una idea vaga hasta la realización completa con calidad.
37 de 112
Incremento vs Iteración
Una de las prácticas de ágil que suele malinterpretarse es la de encarar el proyecto por iteraciones. Una
iteración no es un incremento.
En los incrementos se tiene una idea completa del producto final. Al comenzar hay certeza absoluta sobre
el resultado final deseado, como en la siguiente imagen:
FM
-I
SI
En las iteraciones se va construyendo un borrado, se valida, y luego se sigue agregando calidad al
producto. Al comenzar no hay certeza absoluta sobre el resultado deseado, sino que se va construyendo a medida
que se avanza y se va viendo el producto. La siguiente imagen ilustra un comportamiento iterativo:
En un desarrollo iterativo se debería poder contar con un producto potencialmente productivo cada
iteración, aunque no sea la versión final y definitiva del mismo.
38 de 112
-I
SI
Iteración en el UP
●
●
●
●
FM
¿Qué es una iteración?
Para UP el concepto de iteración a un nivel genérico es un miniproyecto, es decir un recorrido más o
menos completo a lo largo de todos los flujos de trabajos principales.
Cada iteración incluye las siguientes actividades principales: Requerimientos, Análisis, Diseño,
Implementación [Programación], Testing [Prueba]
Al final de cada iteración se obtiene como resultado un producto que puede ser por ejemplo: un
documento, un modelo, una versión ejecutable del sistema, pero incompleto; es decir no está preparado
para ser entregado al cliente.
La duración de una iteración es entre dos a seis semanas. Pasos pequeños y rápida retroalimentación.
Artefactos
●
El ingeniero Civil puede ver el producto mientras lo está desarrollando, es decir el producto es visible de
forma obvia.
● Los sistemas de software son un producto intangible, para ver su progreso los ingenieros en sistemas
elaboramos documentos.
● Artefacto es un término general para identificar a los documentos o cualquier tipo de información creada,
producida o utilizada por el equipo de desarrollo.
● Un artefacto puede ser un diagrama y su texto, asociado, bocetos de la interfaz de usuario, código fuente,
código ejecutable, etc.
Hay dos tipos de artefactos:
39 de 112
●
●
Artefactos de Ingeniería​: son los artefactos creados durante las distintas fases del proceso
(requerimientos, análisis, diseño, implementación y prueba)
Artefactos de Gestión​: tienen un tiempo de vida corta, lo que dura el proyecto. Por ejemplo: plan de
desarrollo, plan de iteraciones, visión y análisis del negocio, etc.
Artefactos de la fase de inicio
Artefacto
Artefactos
Ingeniería
de
Visión y análisis del negocio
Describe los objetos y las restricciones de alto nivel, el
análisis del negocio y proporciona un informe para la
toma de decisiones.
Modelo de Casos de Uso
Describe los requisitos funcionales y no funcionales
relacionados
Especificación Complementaria
Describe otros requisitos, como las reglas del proceso
o requisito del dominio.
Glosario
Proporciona una definición de la terminología clave
del dominio del problema.
de
Prototipos
concepto
y
pruebas
de
Clarifican la visión y validan las ideas técnicas, como
por ejemplo los requerimientos.
SI
Artefacto
Gestión
Breve Descripción
Describe los riesgos del negocio, riesgos técnicos,
riesgos del personal, riesgos de la planificación y
además detalla las ideas para mitigarlos.
Plan de iteración
Describe qué hacer en la siguiente fase, es decir la
fase Elaboración
Plan de la fase y Plan de
desarrollo
Estimación de poca precisión de la duración y
esfuerzo de la fase inicio. Las herramientas, personas,
formación y otros recursos.
Marco de Desarrollo
Descripción de los pasos del UP y de los artefactos
adaptados para el proyecto.
Artefactos
Gestión
de
FM
-I
Lista de Riesgos y Plan de
Riesgos
Marco de Desarrollo
●
●
●
Marco de Desarrollo se denomina a un breve documento que se realiza en la actividad Entorno.
En el Marco de Desarrollo se decide la elección de los artefactos UP para un proyecto.
Los documentos Marco de Desarrollo no son los mismos para todos los proyectos de sistemas, en todos
los casos dependerá si es un proyecto nuevo en un campo donde se tenga experiencia o un proyecto
basado en la Web o si es un sistema de control de alguna máquina.
Ejemplo:
40 de 112
SI
-I
FM
41 de 112
Unidad 4: Modelos y herramientas para el modelado
Temas
●
●
●
●
●
Modelos: definición
Importancia de modelar.
Principios de modelado.
Lenguaje para el modelado.
Herramientas CASE.
Bibliografía
Booch Jacobson Rumbaugh. 1a Ed.
○ Capítulo 1, Por qué modelamos
○ Capítulo 2, Presentación del UML.
○ Capítulo 7, Diagramas.
○ Capítulo 20, Diagrama de Actividades.
○ Capítulo 22, Máquinas de Estado.
SI
●
El Proceso de Modelado
El modelado es el proceso de generar una representación:
○ Abstracta
○ Conceptual
○ Gráfica
○ Visual,
○ Física
○ Matemática
○ De un sistema o cualquier fenómeno natural
La representación se realiza con el fin de analizar, describir, explicar o simular el sistema
●
FM
-I
●
¿Qué es un modelo?
●
●
●
●
●
●
●
Un modelo es una simplificación de la realidad
Puede representar detalles o dar una vista de muy alto nivel
Un modelo es una ​representación abstracta de una especificación, diseño o un sistema, desde un punto
de vista particular.
A menudo se representa con uno o más diagramas.
El modelo tiene como objetivo expresar la esencia de algunos aspectos de lo que se está haciendo, sin
especificar detalles innecesarios.
Un modelo tiene que tener un significado preciso y bien entendido.
Una representación abstracta o conceptual ​no significa confusa​.
¿Qué nos facilita el modelo?
●
●
●
Nos proporciona un diseño o blueprint del futuro sistema a construir.
Nos permite visualizar distintas perspectivas o vistas del sistema.
Nos permite pensar y discutir sobre problemas y soluciones sin desviarnos de los objetivos.
42 de 112
El modelado en Sistemas de Información
●
●
Si la entidad a modelar es algo físico- un microprocesador, una casa o edificio, etc., podemos construir un
modelo idéntico en forma, pero más pequeño.
Si la entidad que se va a construir es un ​sistema de información​, el modelo toma formas diferentes por
ejemplo, debe ser capaz de:
○ Modelar los datos
○ Las funciones que permiten transformar los datos en información
○ El comportamiento del sistema cuando ocurren esas transformaciones.
La importancia de modelar
SI
Para nosotros, crear modelos es importante porque:
● Construimos los planos de un sistema que nos ayudan a disminuir la complejidad del desarrollo del
sistema:
○ Los modelos pueden involucrar ​planos detallados.
○ Podemos incluir en los modelos, los elementos que tienen gran influencia​.
○ Planos menos detallados​, es decir omitimos aquellos elementos menores que no son relevantes.
Pueden ser descritos desde diferentes perspectivas o vistas (cada vista incluye diferentes
modelos)
● Y fundamentalmente porque los modelos nos ayudan a comprender mejor el sistema que estamos
desarrollando
●
Principio 1​: Todo modelo puede ser expresado con diferentes niveles de precisión
Principio 2​: Los mejores modelos están ligados a la realidad.
Principio 3​: Un único modelo o vista no es suficiente. Para cualquier sistema se necesitan varias vistas
complementarias y entrelazadas.
Principio 4​: La elección acerca de qué modelos crear tiene una profunda influencia sobre cómo se
acomete un problema y cómo se forma una solución.
FM
●
●
●
-I
Principios del Modelado
Lenguaje de Modelado
●
●
●
Un lenguaje de modelado es una manera de expresar los distintos modelos que se producen en el proceso
de desarrollo.
Un lenguaje de modelado define una colección de elementos del modelo, que son aproximadamente
análogos a la pronunciación (palabras, sentencias, etc.) en el lenguaje hablado.
Un modelo está formado por elementos del modelo, tal como una sentencia está formada por palabras.
Lenguaje Unificado de Modelado
●
●
●
Un ejemplo de lenguaje de modelado es el UML (Lenguaje Unificado de Modelado)
El UML se centra en diagramas pero también puede utilizar texto.
El UML tiene una sintaxis y una semántica.
○ Sintaxis: el modelado se basa en diagramas, las reglas de formación de los diagramas determinan
qué diagramas son válidos.
○ Semántica: son las normas que determinan qué significa un diagrama correcto.
43 de 112
¿Qué es UML?
El UML es un lenguaje de modelado visual que se usa para ​visualizar​, ​especificar​, ​construir y ​documentar
artefactos de un sistema.
¿Qué no es UML?
UML no es un metodología, UML es una herramienta de modelado que se usa aplicando una metodología
de desarrollo.
Por ejemplo, los autores del UML han desarrollado el Proceso Unificado como una metodología de trabajo
pero es independiente del UML.
Objetivo del UML
El objetivo del UML es convertirse en un lenguaje de modelado de propósito general, diseñado como
estándar no propietario, que pueden usar todas las personas dedicadas al desarrollo de sistemas.
Objetivos de los modelos
Visualizar cómo es o queremos que sea un sistema
○ Visualizar se refiere a la forma gráfica para modelar, reconociendo además que algunas
cosas se modelan mejor textualmente.
○ UML es un lenguaje gráfico que ​tiene un conjunto de símbolos y detrás de cada símbolo
hay una semántica bien definida.
○ Esa semántica permite que distintos desarrolladores, comprendan e interpreten los
modelos sin ambigüedades, trascendiendo a un lenguaje de programación.
Especificar la estructura o el comportamiento de un sistema
○ Especificar​ significa construir modelos ​precisos​,​ no ambiguos​ y ​completos​.
○ UML cubre todas las decisiones de Análisis, Diseño e Implementación que deben
realizarse al desarrollar y desplegar un sistema con gran cantidad de software.
Guiar la construcción del sistema mediante plantillas
○ Guiar ​la construcción del sistema se refiere a que los modelos pueden conectarse de
forma directa a una gran variedad de lenguajes de programación.
○ Con UML se puede establecer correspondencias desde un modelo a un lenguaje de
programación como Java, C++ o Visual Basic, incluso almacenamiento persistente de
datos.
○ Esa correspondencia se denomina Ingeniería Directa.
○ Lo contrario también es posible, se puede construir un modelo en UML a partir de la
implementación.
Documentar y comunicar las decisiones que hemos adoptado
○ Documentar hace referencia a los artefactos o documentos que se producen como
consecuencia del desarrollo del sistema de información.
○ UML cubre la documentación para los siguientes artefactos del sistema:
●
●
FM
●
-I
SI
●
Ejemplos de Artefactos
Requisitos
Pruebas
Arquitectura
Prototipos
Planificación de proyectos
Versiones
44 de 112
Historia Lenguaje Unificado de Modelado
FM
-I
SI
El UML fue adoptado en noviembre de 1997 por OMG (Object Management Group) y desde entonces se
ha convertido en un estándar de facto para visualizar, especificar y documentar los modelos que se crean durante
el desarrollo de un sistema de información.
El UML ha ejercido un gran impacto en la comunidad de sistemas, tanto a nivel de desarrollo como de
investigación.
El UML es un lenguaje de modelado cuyo vocabulario y sintaxis están ideados para la representación
conceptual y física de un sistema.
45 de 112
SI
-I
FM
46 de 112
Tipos Diagramas UML
UML dispone de diagramas que representan el sistema de modelado desde diferentes perspectivas.
UML 2.0 tiene nueve diagramas fundamentales [13 son en total], agrupados de la siguiente manera:
1. Diagramas para modelar la estructura estática del sistema
[Vista Lógica]: ​Diagramas de Clases​, Diagramas de objetos, Diagramas de componentes
[Vista Física]: ​Diagrama de Despliegue
2. Diagramas para modelar el comportamiento dinámico del Sistema
Diagrama de Casos de Uso​, ​Diagrama de secuencia​, Diagrama de colaboración, ​Diagrama de Estados y ​Diagrama de
actividades​.
Elementos y Diagramas del UML
●
FM
-I
SI
Los diagramas en UML son la representación gráfica de un conjunto de elementos, visualizado la mayoría
de las veces como un grafo conexo de nodos [elementos] y arcos [relaciones]
● Los diagramas se dibujan para visualizar un sistema desde diferentes perspectivas como por ejemplo, la
vista dinámica o de comportamiento y la vista estructural o estática.
● Los elementos para realizar los diagramas en UML pueden ser:
○ Elementos estructurales
■ Son las partes estáticas del modelo y representan aspectos conceptuales o físicos.
○ Elementos de comportamiento
■ Son las partes dinámicas de los modelos UML
○ Elementos de agrupación
■ Son las partes organizativas de los modelos de UML
○ Elementos de notación
■ Son las partes explicativas de los modelos de UML
Ejemplos:
47 de 112
SI
-I
FM
48 de 112
FM
-I
SI
Mecanismos comunes
Se aplican en forma consistente a través de todo lenguaje
Relaciones
Son los bloques de construcción encargados de conectar los elementos entre sí
49 de 112
Diagrama de Actividades
FM
-I
●
Un Diagrama de Actividades muestra un proceso formado por actividades que se ejecutan de forma
secuencial o paralela.
Este diagrama es útil para modelar:
○ Los procesos de negocio
○ Flujos de trabajo
○ Flujos de datos
○ y/o Algoritmos complejos
SI
●
Usos comunes
Los diagramas de actividades se utilizan para modelar los aspectos dinámicos de un sistema.
50 de 112
●
●
Modelar un flujo de trabajo: Se utilizan para visualizar, especificar, construir y documentar ​procesos de
negocio​ que implican al sistema en desarrollo.
Modelar una operación: Se utilizan como diagrama de flujo para modelar los ​detalles de una
computación​. Es importante cuando se modela la bifurcación, la unión y la división.
FM
-I
SI
Ejemplo:
51 de 112
SI
-I
FM
Actividades para modelar un flujo de trabajo [Workflow]
●
●
●
●
●
●
●
●
Establecer un​ centro de interés​ para el flujo de trabajo.
Seleccionar los ​actores que tienen las responsabilidades de más alto nivel en cada parte del flujo de
trabajo global. En algunos casos crear una calle o participación por cada actor que se considere
importante.
Identificar las precondiciones del ​estado inicial​ del flujo de trabajo y las poscondiciones del e
​ stado final​.
Comenzar por el estado inicial del flujo de trabajo y especificar las actividades y acciones que tienen lugar
a lo largo del tiempo.
Modelar las acciones complicadas o los conjuntos de acciones como llamadas a Diagrama de Actividades
aparte.
Considerar los flujos que conectan las acciones y los nodos de actividad. Se comienza por los flujos
secuenciales, luego considerar las bifurcaciones y por último tener en cuenta las divisiones y las uniones.
Si existen objetos de datos importantes, representar el flujo de objetos.
En las organizaciones, los procesos de negocios son​ flujos de trabajo​ que representan las actividades.
Existen procesos que no son sencillos, que involucran a muchas personas y muchos pasos.
52 de 112
SI
-I
●
Aunque estos procesos pueden ser capturados en una descripción textual, una imagen nos ayuda a
comprender mejor el flujo de ejecución.
Las particiones permiten ver de forma más clara los múltiples ​actores involucrados y las a​ cciones
paralelas​ que se llevan a cabo en el proceso.
FM
●
53 de 112
SI
-I
FM
54 de 112
Ejemplo
Descripción del proceso de negocio - Alquilar Películas
FM
-I
SI
Cuando los socios alquilan videos deben presentar al empleado, la credencial de socio, junto con las
carátulas de los videos que desea alquilar.
El empleado consulta la lista de precios y calcular el total a pagar. El socio puede desistir del alquiler.
El socio paga el alquiler y el empleado entrega un recibo con los siguientes datos: nro de recibo, fecha
actual, apellido y nombre, nombre de la película, fecha de devolución y total a pagar.
El recibo puede contener varios conceptos de alquiler. El empleado actualiza la disponibilidad de las
películas. Entrega las películas y el socio se retira.
55 de 112
SI
-I
FM
56 de 112
SI
-I
FM
57 de 112
SI
-I
FM
Conclusiones y sugerencias
●
●
●
●
●
●
Modelar los​ elementos esenciales​ para comprender el proceso de negocio.
No es necesario mostrar todos los detalles, sólo mostrar aquellos que sean esenciales para la
comprensión.
Siempre dar un ​nombre al diagrama​ que comunique su propósito.
Modelar el flujo principal.
Minimizar los cruces de líneas.
Usar notas y colores para llamar la atención sobre las características más importantes del diagrama.
58 de 112
●
●
Especifica las secuencias de estados por las que pasa un objeto o un sistema a lo largo de su vida en
respuesta a eventos​.
Un ​estado es una condición o situación en la vida del objeto durante la cual satisface alguna condición,
realiza una actividad o espera un evento.
Un ​evento​ es la especificación de un acontecimiento significativo situado en el tiempo y en el espacio.
FM
●
-I
SI
Diagrama de Transición de Estados
59 de 112
Partes del Diagrama de Estados
●
●
Una ​transición es una relación entre dos estados, que indica que un objeto que está en un primer estado
realizará ciertas acciones y entrará en un segundo estado cuando ocurra un ​evento especificado y se
satisfagan algunas ​condiciones especificadas​.
Cuando se produce este cambio de estado se dice que la ​transición​ se ha ​disparado​.
Hasta que se dispara la transició,n se dice que el objeto está en ​estado origen​, después de dispararse está
en​ estado destino​.
FM
●
-I
SI
Contexto del objeto
60 de 112
●
●
SI
-I
●
Una ​transición tiene cinco partes: estado origen, evento disparado, condición de guarda, acción [atómica]
y estado de destino.
La ​condición de guarda se evalúa una vez cada vez que se activa su transición, un evento en cambio se
evalúa de forma contínua.
Puede haber transiciones sin evento disparador.
Puede haber autotransiciones, el estado origen y el estado destino son los mismos.
FM
●
61 de 112
●
●
FM
Pseudoestados
-I
SI
Partes del estado
Estado inicial​: indica el punto de comienzo por defecto del diagrama y se representa con un círculo negro.
Estado final​: indica que la ejecución de la máquina de estados o del estado que lo contiene ha finalizado.
Se representa como un círculo negro dentro de un círculo blanco
*Las líneas azules no son parte de los elementos del diagrama.
62 de 112
Usos más comunes del Diagrama de Estados
●
●
●
●
El Diagrama de Estados se utiliza para modelar los ​aspectos dinámicos​ de un sistema.
Este aspecto dinámico involucra el comportamiento dirigido por eventos.
Dirigido por eventos significa que el objeto o sistema es reactivo y su comportamiento es la respuesta a
eventos lanzados desde afuera de su contexto.
El Diagrama de Estados se utiliza para modelar por ejemplo:
○ Dispositivos físicos​: teléfonos, microondas, etc.
○ Transacciones y objetos de negocio​: Por ejemplo, para representar todos los posibles estados de
un paquete enviado por correo, por ejemplo [despachado, en tránsito, en aduana, retirado]
○ Manejo de eventos en una ventana de interfaz de usuarios​: Por ejemplo [maximizada,
minimizada, cerrada]
○ Operaciones del sistema en los casos de uso​: Dentro de un Caso de Uso se identifican una serie
de operaciones. Estas operaciones deben ocurrir en un orden determinado para ser consideradas
válidas.
○ Objetos o procesos que cambian​: por ejemplo estado de los procesos de un Sistema Operativo.
Conclusiones y sugerencias
SI
●
●
●
●
-I
●
Elegir el contexto para el diagrama de transición de Estados, puede ser un objeto, clase, o el sistema
global y un aspecto de la dinámica a modelar.
Dar un nombre al diagrama de transición de Estados, el nombre debe comunicar el propósito del
diagrama.
Un sistema puede tener más de un Diagrama de transición de Estados.
Colocar en el diagrama elementos esenciales para comprender el aspecto de la dinámica.
Minimizar los cruces de líneas.
Usar notas y colores para llamar la atención sobre las características más importantes del diagrama.
FM
●
63 de 112
Unidad 5: El modelado del dominio del problema
Temas
●
●
●
Modelo del dominio del problema: vista dinámica, vista estática.
Problemas de información en el dominio.
Documentar la información del dominio del problema.
Bibliografía
SI
●
-I
●
Larman. 2a Ed.
○ Capítulo 7, Identificación de otros requisitos. (7.2 y 7.4)
○ Capítulo 10, Modelo de dominio: Visualización de conceptos.
○ Capítulo 11, Modelo de dominio: Añadir Asociaciones.
○ Capítulo 12, Modelo de dominio: Añadir atributos.
Booch Jacobson Rumbaugh. 1a Ed.
○ Capítulo 2, El modelo de Objetos.
OMG Std.
○ Plantilla para la Especificación Complementaria.
○ Plantilla del Documento Visión.
FM
●
64 de 112
Modelo del Dominio
●
●
●
●
●
●
El Modelo del Dominio es una ​representación visual de las clases conceptuales u objetos del mundo real
en un dominio de interés.
No son componentes de software pero…
… son una fuente de inspiración para el diseño de los objetos software.
El modelo del Dominio es uno de los ​documentos más importantes que se crea durante el análisis de
sistemas.
No es redundante aclarar que al ser una ​representación visual​, es un modelo.
Recordemos entonces los beneficios que conseguimos a través del modelado:
○ Los modelos nos ayudan a comprender la ​complejidad​, es decir reducimos el problema para
centrarnos en un solo aspecto a la vez.
○ Los modelos son ​plantillas​ que nos ​guían​ en la construcción de un sistema
Elementos del UML para Modelar
-I
SI
Para realizar el Modelo del Dominio usamos de UML los siguientes bloques de construcción:
● Elementos
○ Elementos estructurales​: se usan para representar cosas que son materiales o conceptuales.
○ Sirven para modelar la ​parte estática ​del sistema.
○ En UML hay siete tipos de elementos estructurales. Para el Modelo del Dominio usaremos ​una
clase​.
● Relaciones
○ En UML hay cuatro tipo de relaciones: Dependencia, Asociación, Generalización y Realización.
○ Para el Modelo del Dominio usaremos: Asociación, Generalización.
Elementos del UML para Modelar una Clase
FM
En UML una clase se modela con un rectángulo dividido en tres secciones.
¿Qué es una clase conceptual?
●
●
Clases conceptuales​: Son las cosas significativas del vocabulario del ​dominio del problema acerca de las
cuales el sistema de información necesita conservar información.
El vocabulario varía según el dominio del problema, veamos algunos ejemplos:
65 de 112
Fuentes de información para conocer el vocabulario del dominio del problema
-I
SI
Al vocabulario del dominio del problema lo podemos obtener:
● Realizando las entrevistas o cuestionarios a los usuarios finales, gerentes, ingenieros de mantenimiento,
gerentes de marketing, consultores, clientes, etc.
● Consultando la descripción de los procesos de negocio.
● Modelando los procesos de negocios con el Diagrama de Actividades.
● Leyendo y entendiendo los antecedentes de los entrevistados y su organización, esta información por lo
general se encuentra en la Web corporativa. Al leer el material se recomienda poner especial atención al
lenguaje que utilizan los miembros de la organización.
Estrategias para identificar el nombre de las Clases Conceptuales
●
FM
Usar una lista de categorías.
Lugares, roles de las personas, objetos de datos, otros sistemas informáticos, otras organizaciones,
catálogos, transacciones, líneas de transacciones, políticas y reglas de la organización.
● Identificar las frases nominales en la descripción del proceso.
Cuando el ​alumno llega a la biblioteca solicita ​libros al ​bibliotecario​. El ​bibliotecario busca los ejemplares
disponibles en los ​estantes de la biblioteca​...
● Usar patrones del análisis.
66 de 112
-I
SI
Lista de Categorías con ejemplos
Frases nominales
●
●
Identificar los nombres y frases nominales en las descripciones textuales de un dominio es una técnica
para el análisis gramatical.
Podemos identificar las frases nominales en los siguientes artefactos: Documento Visión, Glosario,
Especificación Complementaria, Casos de Usos, Informe de la entrevista, entre otros.
Desventajas del Análisis gramatical:
○ A veces no es posible realizar una correspondencia directa de nombres a clases conceptuales.
○ Las palabras en lenguaje natural son ambiguas, es decir que frases nominales diferentes podrían
representar la misma clase conceptual o atributo.
FM
●
¿Qué son los Atributos?
●
●
●
●
●
●
●
Los atributos son un valor de datos lógico de una clase u objeto.
Los atributos representan la información relevante de las clases conceptuales del dominio que el sistema
necesita conocer o registrar.
Los atributos describen a las clases conceptuales.
Representan la información que el sistema necesita conocer o registrar.
En el modelo del dominio se incluyen aquellos atributos que implican una necesidad de registrar
información.
El documento de Casos de Uso y los Requerimientos de Datos nos permiten reconocer los atributos.
Los atributos elegidos en cada iteración completan el Glosario.
Atributos válidos
●
Los atributos en un modelo de dominio deberían ser preferentemente atributos simples o tipos de datos.
67 de 112
●
●
●
Los tipos de datos implican un conjunto de valores para los cuales no es significativa una identidad única en el contexto de nuestro modelo Los tipos de datos de los atributos más comunes incluyen: Booleano, Fecha, Número, String, Hora.
Otros atributos simples comprenden: Dirección, color, número de teléfono, código postal, tipos
enumerados.
Clases de Tipos de Datos no Primitivos
SI
-I
●
●
No todos los tipos de datos son primitivos, existen otros tipos de datos que se conocen como ​objetos
valor​.
Este tipo de atributo podría presentarse como una clase no primitiva en el Modelo del Dominio.
La siguiente guía nos ayuda a determinar si el atributo es una clase primitiva:
○ El atributo está compuesto por secciones separadas ej. Número de teléfono.
○ El atributo tiene otros atributos ej Precio de promoción
○ Hay operaciones asociadas con el atributo, como análisis sintáctico o validación ej. Número de
seguridad social.
○ Es una cantidad con una unidad ej. Pago unidad monetaria.
FM
●
68 de 112
Unidad 6: Ingeniería de Requerimientos
Temas
●
●
●
●
●
●
●
●
Ingeniería de los Requerimientos.
Requerimientos.
Tipos de Requerimientos.
Niveles para describir los Requerimientos.
Estándar IEEE 830.
Introducción a la gestión de proyectos.
Estudio de pre-factibilidad.
Estudio de viabilidad.
Bibliografía
SI
●
-I
●
Sommerville. 7a Ed.
○ Capítulo 6, Requerimientos del Software
○ Capítulo 7, Procesos de la Ingeniería de los Requerimientos.
IEEE Std.
○ 29148 - 2011. Guía para escribir los requisitos.
○ 830 - 1998, Plantilla para especificar los Requerimientos del Software.
Kendall & Kendall. 6a Ed.
○ Capítulo 3, Determinación de la viabilidad y Administración de las actividades de Análisis y
Diseño.
FM
●
69 de 112
-I
SI
Ejemplos del dominio de Interés
FM
Perspectivas de los requerimientos
¿Requerimientos o Requisitos?
En el contexto del análisis de Sistemas nosotros utilizaremos estos términos de manera indistinta. Es
decir, igualaremos Requerimientos = Requisitos.
70 de 112
La bibliografía recomendada para la materia utiliza el término requerimiento.
Sin embargo es importante entender el significado de ambas palabras:
Requerimiento​: es una petición que se hace de algo.
Requisito​: es una condición necesaria a cumplir.
-I
SI
Definición
FM
Tipos de Requerimientos
Requerimientos No funcionales
Son restricciones de los servicios o funciones ofrecidas por el sistema. Por
ejemplo: el tiempo de respuesta, el proceso de desarrollo del sistema, los
estándares a utilizar, usabilidad, seguridad, etc.
Requerimientos funcionales
Son declaraciones de los servicios que deberá proporcionar el sistema, la
manera que debe reaccionar a entradas particulares y cómo se debe
comportar en diferentes situaciones.
Requerimientos del dominio
Son requerimientos que provienen del dominio de aplicación del sistema y
que reflejan las características y restricciones de ese dominio. Pueden ser
funcionales o no funcionales.
Requerimientos No funcionales
●
●
Los requerimientos no funcionales hacen referencia a las ​propiedades emergentes no funcionales ​de los
sistemas de información, es decir no agregan funcionalidad a la aplicación.
Recordemos según la Teoría General de Sistemas:
○ Las ​propiedades emergentes​ son propiedades del sistema cuando este funciona como un todo.
○ No se pueden atribuir ninguna parte específica del sistema. Emergen cuando los componentes
del sistema han sido integrados y surgen de las complejas interrelaciones de los subsistemas.
71 de 112
Propiedades Emergentes de los sistemas
Existen 2 tipos:
● Propiedades emergentes funcionales​: Aparecen cuando todas las partes del sistema trabajan en forma
conjunta​ para cumplir un objetivo.
● Propiedades emergentes no funcionales​: Se refieren al comportamiento de los sistemas en su ​entorno
operativo​. Son factores críticos para los sistemas de información ya que un fallo mínimo de estas
propiedades puede hacer inutilizable el sistema. Ejemplo: fiabilidad, seguridad y protección, rendimiento,
usabilidad, etc.
Requerimientos No funcionales
●
●
●
●
Son limitaciones sobre los servicios y funciones que ofrece el sistema.
Se aplican al sistema como un todo, y afectan más la ​arquitectura global de un sistema que a los
componentes individuales.
Se conocen también como ​atributos de calidad del sistema y surgen a través de las necesidades del
usuario.
Afectan a las ​propiedades emergentes​, por ejemplo: fiabilidad, usabilidad, seguridad, desarrollo, etc.
SI
Clasificación de los requerimientos no funcionales
Especifican el comportamiento del producto. El producto puede ser el
Sistema o el Software
Requerimientos organizacionales
Se derivan de políticas y procedimientos existentes en la organización del
cliente y la del desarrollador.
Requerimientos externos
Se derivan de los factores externos al sistema y de su proceso de
desarrollo.
FM
-I
Requerimientos de producto
72 de 112
SI
-I
●
●
●
FM
Usabilidad
Requerimiento no funcional de usabilidad
Expresan cuán fácil será para el usuario utilizar el sistema. Depende de los componentes técnicos del
sistema, sus operarios o usuarios y su entorno de operaciones.
Se redactan según el tiempo de aprendizaje o formación del usuario, el tipo de interfaz de usuario que
utilizará el sistema, ventanas para la ayuda y mensajes de retroalimentación
Ejemplo:
R-US 1
El empleado de la Biblioteca deberá ser capaz de operar el sistema en tres horas, si es que ya está
familiarizado en los productos estándar de interfaz gráfica del usuario.​ [Hace referencia a la
facilidad de aprendizaje]
R-US 2
Un empleado que no haya usado la interfaz gráfica del usuario dispondrá de 5 días adicionales de
capacitación para aprender a usar el sistema. La capacitación requerirá 4 horas diarias [Hace
referencia al tiempo de capacitación]
R-US 3
Los usuarios del sistema no deben memorizar ningún comando para poder usar el sistema. Todas
las opciones disponibles deberán estar desplegadas con claridad en la barra de menú, conceptos de
menú, barra de herramientas o botón de comando. [Hace referencia a la facilidad de operación]
*[Identificación del requisito: R: Requisito US: Usabilidad Número: Secuencia
73 de 112
Eficiencia
●
●
●
Requerimientos no funcionales de Eficiencia
Están relacionados con la carga esperada que soportará el sistema. Por ejemplo, el número de terminales,
el número esperado de usuarios simultáneamente conectados, número de transacciones por segundo que
deberá soportar el sistema, espacio físico (almacenamiento) que usará el sistema, etc.
Estos requisitos deben ser mensurables, es decir podrán medirse. Se pueden escribir haciendo referencia
a un número o a un porcentaje. Por ejemplo, indicando "el 95% de las transacciones deben realizarse en
menos de 1 segundo"
Ejemplo:
Si el usuario hace correcciones a cualquier información presentada en la pantalla, la información se
actualizará dentro de los cinco segundos posteriores a su actualización
[Hace referencia al tiempo de respuesta]
R-RE 2
El sistema deberá responder a la solicitud de información de un empleado de la Biblioteca, en
menos de diez segundos desde el envío de la solicitud
R-RE 3
Hasta cuatro empleados de la Biblioteca podrán utilizar el sistema al mismo tiempo.
[Usuarios conectados simultáneamente]
SI
R-RE 1
Fiabilidad
●
●
●
●
●
-I
●
La ​fiabilidad es la probabilidad de que el sistema tenga operaciones libres de caídas durante un tiempo
definido en un entorno dado para un propósito específico. Es decir, que el sistema no falle.
La ​disponibilidad es la probabilidad de que el sistema, en un cierto momento, esté funcionando para
proporcionar los servicios a los usuarios.
La fiabilidad y la disponibilidad son propiedades de ​confiabilidad del sistema​.
¿Qué componentes pueden fallar?
○ Hardware del Sistema: falla debido a errores en su diseño, errores de fabricación, o debido a que
dichos componentes han llegado al final de su vida útil.
○ Software del Sistema: el software falla debido a errores en su especificación, diseño o
implementación
○ Operadores del Sistema: pueden provocar fallos debido a un uso incorrecto del sistema. Hoy en
día se considera la principal causa de fallos de funcionamiento del sistema.
Los sistemas que son no fiables, inseguros o desprotegidos son rechazados por los usuarios y éstos se
niegan a utilizarlos.
Los costos de los fallos de funcionamiento del sistema pueden ser enormes. Pueden ser pérdidas
económicas y/o daños a las personas o usuarios.
Los sistemas no confiables pueden provocar pérdida de información. La captura y mantenimiento de los
datos es muy cara y se debe invertir mucho dinero para proteger los datos de cualquier corrupción.
FM
●
R-Fiab 1
Ante un fallo del sistema, no se tardará más de 10 minutos en restaurar los datos del sistema – a un
estado válido – y volver a poner en marcha el sistema.
[Tolerancia a fallas]
R-Fiab 2
El sistema estará disponible, operacionalmente activo, desde las desde las 8:30 AM hasta las 21:00
PM durante el año académico, que abarca desde Febrero a Diciembre.
74 de 112
[Hace referencia al tiempo disponible del sistema]
Espacio
R-RE 1
En el sistema embebido la capacidad máxima de memoria será de 4 Mbytes
Portabilidad
RP 1
El sistema deberá operar con diferentes sistemas operativos. Tal como sistemas operativos con
licencia paga o sistemas operativos GNU
Estándares
El sistema se modelará con el estándar de UML (Lenguaje Unificado de Modelado Versión 2.0 ).
[Estándares para el modelado]
R-Std 2
El estándar genérico IEEE 830 – 1998 que documenta los requisitos del software, se adaptará para
el contexto de desarrollo. La información del documento permitirá la inclusión de nuevas
características del sistema.
[Estándares para la documentación]
R-Std 3
El sistema se desarrollará siguiendo el modelo: Proceso Unificado [UP], que consiste en cuatro
fases: inicio, elaboración, construcción y transición y un flujo de actividades: Requerimientos,
Análisis y Diseño, Implementación, prueba.
[Estándares para el proceso]
Entrega
FM
-I
SI
R-Std 1
R-Ent 1
La versión beta del sistema estará disponible en 90 días, a partir de la fecha del contrato de
desarrollo.
[Agenda de entregas]
R-Ent 2
Los documentos o artefactos que se entregarán al cliente son: Plan de desarrollo del Sistema,
Especificación de Requisitos del software, el sistema instalado y un manual técnico y material de
apoyo para el usuario final
[Documentación que se entrega]
Fiabilidad
R-Seg 1
El sistema implementará cortafuegos para proteger el acceso de virus.
R-Seg 2
Cada usuario deberá autenticarse mediante el ingreso de un nombre de usuario y contraseña. El
acceso será verificado por el sistema.
Requerimientos Funcionales
●
Expresan lo que deberá hacer el sistema / software.
75 de 112
●
Dependen:
○ El tipo de sistema que se esté desarrollando.
○ De los usuarios del sistema
○ Del enfoque general que se adopte para escribir estos requisitos.
● Por lo general se escriben en futuro
Ejemplo: "El sistema permitirá consultar los libros de la biblioteca"
Escribir los requisitos funcionales
●
FM
Ejemplo:
-I
SI
●
●
Para especificar los requerimientos funcionales utilizamos el lenguaje natural estructurado, anotando los
detalles de una forma estándar.
Esto nos ayuda a tener un grado de uniformidad en la redacción de los requerimientos.
Nosotros en Análisis de Sistemas usaremos la siguiente planilla
●
●
El uso de la planilla reduce la variabilidad en la especificación y los requisitos se organizan de forma más
efectiva.
Si necesitamos disminuir la ambigüedad podemos agregar modelos gráficos del sistema.
76 de 112
●
●
Para cálculos, se debemos escribir ejemplos que muestren cómo se realizan utilizando expresiones
matemáticas.
Al formato de la plantilla podemos agregar:
○ Una precondición que indique lo que se debe cumplir antes de invocar a la función.
○ Una poscondición que especifique lo que será verdad una vez invocada la función.
Requerimientos de dominio
Ingeniería de los Requerimientos
Proceso de la Ingeniería de Requerimientos
SI
●
-I
●
Los requerimientos del dominio son los fundamentos del dominio de aplicación. Si estos requerimientos
no se satisfacen, puede ser imposible hacer que el sistema funcione de forma satisfactoria.
Los requerimientos del dominio son las reglas del proceso, por ejemplo para el caso de la biblioteca, los
tipos de préstamos, el tiempo de préstamo, las condiciones para asociarse a la biblioteca, etc.
Ejemplo: "Debido a las restricciones en los derechos de autor, algunos documentos deberán borrarse
después de su llegada"
FM
●
77 de 112
SI
Definición
Reflexiones
●
●
●
●
●
●
La Ingeniería de Requerimientos es una disciplina de la ingeniería que procura sistematizar el proceso de
especificación de requisitos.
Es decir, apunta a mejorar la forma en que se comprenden y definen los servicios que deberán prestar los
sistemas de información o los sistemas de software.
La complejidad de los problemas a resolver exige que se preste más atención a su correcto entendimiento
antes de comprometer una solución.
La Ingeniería de Requerimientos abarca todas las actividades involucradas en descubrir, modelar, analizar,
y mantener un conjunto de requisitos para un sistema de información o sistemas de software.
La Ingeniería de Requerimientos no es simplemente un proceso técnico, abarca también características
fundamentalmente humanas.
Los requerimientos del sistema por: Preferencias y aversiones de los usuarios o cuestiones políticas y
organizacionales.
Actualmente existen nuevas formas de capturar los requerimientos que ayuden a resolver las influencias
de los usuarios y de la organización.
FM
●
-I
La Ingeniería de requerimientos son los procesos de descubrir, analizar, documentar y verificar los
requisitos del sistema, de forma sistemática y repetible.
78 de 112
SI
Documento Especificación de Requerimientos del Sistema
●
Los requisitos se escriben en un documento: el documento tiene como objetivos ser un contrato y
comunicar los requerimientos.
Los requerimientos se comunican a un conjunto de diversos lectores.
FM
●
-I
Documentar los requisitos
●
●
La diversidad de lectores significa que el documento tiene que presentar un equilibrio en la redacción de
los requisitos para poder comunicar, sin barreras del lenguaje, las características del sistema.
Como una buena práctica se organiza en el documento los requerimientos para el usuario / cliente, los
requerimientos del sistema y los técnicos (software).
79 de 112
Audiencia del documento de los requerimientos
Receptores
● Desarrolladores de
Software
● Ingenieros en Sistemas de
Información
● Ingenieros desarrolladores
● Ingenieros probadores
Lectores
Requerimientos del Software
● Requerimientos
funcionales y no
funcionales escritos en
lenguaje técnico
especializado y modelos
del software.
● Indican exactamente qué
deben implementar los
desarrolladores del
sistema.
SI
Emisores
● Analistas de Sistemas
● Ingenieros en Sistemas de
Información
Requerimientos del Sistema
● Requerimientos
funcionales y no
funcionales escritos en
lenguaje técnico
especializado y modelos
del sistema
● Se especifica la interfaz
entre los sistemas y la
arquitectura inicial del
sistema.
-I
Especificación de Requerimientos
FM
Receptores
● Usuarios finales
● Administradores clientes
● Contratistas
● Arquitectos del sistema
Lectores
Requerimientos del Usuario
● Requerimientos
funcionales y no
funcionales escritos en
lenguaje técnico
especializado y modelos
del software.
● Indican exactamente qué
deben implementar los
desarrolladores del
sistema.
● Definen las necesidades
de los usuarios.
Uso del documento de requerimientos
Clientes del Sistema
Especifican los requerimientos y los leen para verificar que
cumplen sus necesidades. Los clientes especifican los ​cambios​.
Administradores
Utilizan el documento de requerimientos para planificar una
oferta por el sistema y para ​planificar el proceso de desarrollo.
Ingenieros en Sistemas de Información
Utilizan los requerimientos para​ comprender qué sistema deberá
desarrollarse.
Ingenieros probadores
Utilizan el documento de requerimientos para desarrollar las
pruebas de validación.
80 de 112
Ingenieros encargados del mantenimiento
Utilizan el documento de requerimientos para ​comprender el
sistema y las relaciones entre sus partes.
Requerimientos del Usuario
Son declaraciones, en​ lenguaje natural y en diagramas ​de los servicios del sistema y sus restricciones.
Describen los requerimientos funcionales y no funcionales de tal forma que sean ​comprensibles para los
usuarios​ del sistema sin conocimiento técnico detallado.
● Pueden especificar el ​comportamiento externo del sistema​, es decir lo que el usuario podrá ver cuando el
sistema funcione.
● Explican, de ser posible, por qué se ha incluido el requerimiento y ​por qué ​es útil.
Ejemplo: El nuevo sistema de la Biblioteca - LibSys - permitirá que los usuarios - personal de la biblioteca - puedan
trabajar en línea accediendo a los datos de forma instantánea y cuando el estudiante de la facultad solicite
asociarse. LibSys permitirá registrar los datos de los libros gestionando el préstamo y devolución de los libros por
parte de los socios.
●
●
Recomendaciones para escribir los requerimientos del usuario
Utilizar​ formato estándar
Evitar, de ser posible, el uso de jerga informática.
Escribir en un ​lenguaje natural​, describiendo​ qué es necesario​ y no cómo se debe realizar.
Del lenguaje natural se debe tener en cuenta los siguientes problemas:
○ Falta de claridad
○ Confusión de requerimientos
○ Conjunción de requerimientos
El lenguaje se debe utilizar en forma consistente, es decir:
○ Los requisitos obligatorios: se escriben en futuro simple.
○ Los requisitos deseables: se escriben en futuro condicional.
●
-I
SI
●
●
●
●
FM
Requerimientos del Sistema
Son v​ersiones extendidas de los requerimientos del usuario y se utilizan como punto de partida para el
diseño del sistema.
● Especifican de manera ​completa y consistente al sistema entero, por esa razón es necesario diseñar una
arquitectura inicial ​del sistema para ayudar a estructurar la especificación de requerimientos.
● Se especifican en un ​lenguaje estructurado​ y se pueden formatear en una planilla.
● Pueden utilizarse como parte del ​contrato entre comprador y los desarrolladores del sistema​.
Ejemplo: Punto de partida : Rq del Usuario del Ejemplo anterior
Visión general del Sistema – Organización inicial del Sistema
Es un Sistema Interactivo que interconecta inicialmente 5 computadoras del usuario, está compuesto por
los siguientes Sub-Sistemas:
1. Datos: Almacena la información de los socios y de los recursos de la biblioteca que se prestan a los
socios.
2. Aplicación: Maneja todos los aspectos del préstamo y devolución de libros y sus reglas, registra nuevos
socios y consultas de recursos.
3. Presentación: Interfaz de usuario
4. Seguridad: Módulo de identificación y autenticación de usuarios que comprueba los usuarios
acreditados
81 de 112
Requerimientos de Software
●
●
●
Son la declaración oficial de​ qué deben implementar los desarrolladores del sistema​.
Incluyen tanto los ​requerimientos del usuario​ como los r​ equerimientos del sistema​.
Se documentan usando el estándar: ​IEEE 830-1998 y el nivel de detalle depende del tipo de sistema y del
proceso de desarrollo utilizado.
Ejemplo:
Requisito Funcional F01
Requisito:
El sistema permitirá consultar los datos del socio.
Prioridad:
Alta
Entrada:
Número de DNI
Proceso:
Buscar en el almacén de datos de Socios la coincidencia del número de DNi ingresado.
Si el socio existe
mostrar los datos personales del socio y la carrera que cursa.
En caso contrario
mostrar un mensaje de error.
Fin del si
Salida:
Apellido, Nombre, Domicilio, e-mail, carrera que cursa.
Mensaje de error en caso de ingresar un DNI inexistente o de haber ingresado un DNI erróneo.
●
●
●
El documento de los requerimientos del software se denomina Especificación de Requerimientos de
Software (ERS)
El instituto de Ingeniería Eléctrica y Electrónica (Institute of Electrical and Electronics Engineers - IEEE) es
un organismo que provee estándares.
Un estándar es una norma que establece un conjunto de criterios técnicos basados en un cuerpo de
conocimientos, para especificar un producto.
Un estándar para la documentación de los requisitos del software es el ​Std IEEE 830-1998​.
FM
●
-I
Estándar IEEE 830-1998
SI
Ref
Estructura sugerida para el documento IEEE 830-1998
Secciones:
1.
Introducción
1.1.
Propósito del documento.
1.2.
Alcance del producto.
1.3.
Definiciones acrónimos y abreviaturas.
1.4.
Descripción del documento.
2.
Descripción general
2.1.
Perspectiva del producto.
2.2.
Funciones del producto.
2.3.
Características del usuario.
3.
Requerimientos Específicos.
3.1.
Requerimientos funcionales.
3.2.
Requerimientos no funcionales.
4.
Apéndices
82 de 112
5.
Índice o Tabla de contenidos.
Recomendaciones del Std IEEE 830-1998
Para almacenar el documento el Estándar nos recomienda:
● El documento de la ERS se almacena según las versiones o correcciones. Porque los clientes o los
usuarios pueden solicitar cambios a los requisitos.
● Es fundamental destinar una carpeta con el nombre de nuestro proyecto o sistema.
● El esquema de nombre del documento de la Especificación de los Requerimientos, puede ser:
●
Al esquema de nombre, también se puede agregar el nombre o siglas del proyecto.
Recomendaciones del /ISO/IEEE Std 29148
El estándar nos recomienda tener en cuenta las siguientes características que deben cumplir los
requisitos:
Descripción del Requisito
SI
●
Significado
●
El requisito refleja alguna necesidad o problema real del cliente
No ambigua
●
El requisito tiene una única interpretación.
Completa
●
Incluye todos los requisitos significativos del software (relacionados
con la funcionalidad, ejecución, diseño, atributos de calidad o
interfaces externas).
Existe una definición de respuestas a todas las posibles entradas,
tanto válidas como inválidas, en todas las posibles situaciones.
FM
-I
Correcta
●
Verificable
●
El requisito bajo ciertas condiciones se puede medir.
Consistente
●
El requisito no es contradictorio y no entra en conflicto con otro
requisito.
Clasificación
●
El requisito tiene prioridades. Las prioridades pueden ser por escala
numérica o cualitativa.
●
Los requisitos funcionales se redactan según la siguiente tabla:
Ref.
Es un nombre que identifica de forma unívoca al requisito.
Requisito:
Escribimos en una oración o un párrafo el requisito funcional según las recomendaciones
del estándar.
Prioridad:
Es la urgencia o la importancia del requisito para su desarrollo. Usamos la siguiente escala:
Alta - Media - Baja.
83 de 112
Entrada:
Son los datos que el proceso necesita para iniciar su funcionamiento.
Proceso:
Es una descripción precisa de lo que se realizará. Es una lógica del requisito. Especificar el
proceso reduce la ambigüedad. Usamos un lenguaje estructurado o seudocódigo, según
las estructuras de control que aprendimos en la materia Algoritmos y Estructura de Datos.
Para ayudarnos podemos utilizar Diagramas de actividades para modelar el algoritmo.
Salida:
Información que entrega el proceso cuando finaliza su ejecución. La información pueden
ser datos o mensajes, de error, confirmación o notificación.
●
Sugerencias para redactar los requisitos:
○ Redactar los requisitos usando el verbo en futuro.
○ Evitar en lo posible el uso de la voz pasiva.
○ A veces también se redactan los requisitos especificando lo que el sistema no deberá
hacer.
○ [Sujeto] [Verbo] [modificador] [objeto] [valor]
FM
-I
SI
Ejemplo:
❏ El sistema mostrará en orden ascendente las facturas pagadas de los clientes.
❏ Si el usuario hace correcciones a cualquier información presentada en la pantalla], el [sistema]
[mostrará] la [información][actualizada] dentro de los [5 segundos posteriores a la actualización]
❏ Si el estado del socio es moroso [ condición ], el sistema [ sujeto ]deberá contar [ verbo ] los
ejemplares [ objeto ] adeudados [ modificador ] desde el último préstamo realizado por el socio
hasta la fecha actual [ restricción ]
● Estas sugerencias nos facilitan la redacción de los requisitos y nos ayudan a comunicar de manera
efectiva los requisitos, evitando las ambigüedades u omisiones.
● Las palabras entre corchetes son aclaratorias. Se eliminan de la descripción del requisito
● Tenemos libertad dentro de los límites de las regla de nuestro idioma, de cambiar la estructura,
por ejemplo, la restricción puede ir a continuación del verbo o suprimirla.
● Siempre se deben documentar los requerimientos, aunque sea un breve documento que
describa al negocio y los requerimientos de confiabilidad del sistema.
● El contenido del documento depende del tipo de sistema que se desarrolle y del proceso de
desarrollo utilizado.
Por ejemplo:
● Sistemas grandes: (incluye interacción de hardware y software) los requerimientos se definen con mucho
detalle y se escriben en un documento con un formato estándar, por ejemplo IEEE 830-1998.
● Sistemas pequeños y medios: (modelo evolutivo) Los requerimientos no son tan detallados. Se definen los
requerimientos del usuario y los requerimientos del sistema no funcionales de alto nivel. Los diseñadores
y programadores utilizan su juicio para decidir cómo satisfacer los requerimientos
● Modelos ágiles: los requerimientos se escriben en tarjetas y se recogen incrementalmente.
84 de 112
Unidad 7: Obtención y Análisis de los Requerimientos
Temas
●
●
●
●
●
Descubrimiento de los requerimientos.
Técnicas para descubrir requerimientos: entrevistas, cuestionarios, etnografía.
Información del dominio de descubrir requerimientos.
Clasificación y organización de los requerimientos.
Prototipos iniciales para descubrir y validar los requerimientos.
Bibliografía
●
●
-I
SI
●
Kendall & Kendall. 6a Ed.
○ Capítulo 4. Recopilación de la información: Métodos interactivos.
○ Capítulo 6. Elaboración de prototipos, RAD y programación extrema.
Larman. 2a Ed.
○ Capítulo 6. Modelo de Casos de Uso: escritura de requisitos en contexto.
Sommerville. 7a Ed.
○ Capítulo 7. Procesos de la Ingeniería del Software.
○ Capítulo 16. Diseño de interfaces de Usuario.
FM
Procesos de la Ingeniería de Requerimientos
●
●
El proceso de obtención de los requerimientos es el proceso de ​recoger información sobre el sistema
propuesto​ y​ los existentes ​con el propósito de extraer los ​requerimientos del usuario del sistema​.
Las fuentes de información son:
○ La documentación
85 de 112
○
○
Los stakeholders
Especificación de sistemas similares.
Actividades para obtener requerimientos
1.
2.
3.
4.
Descubrir los requerimientos
a. Interactuar con los stakeholders utilizando técnicas de comunicación.
Clasificar y organizar los requerimientos.
Ordenar los requerimientos por prioridades.
Documentar los requerimientos
Modo de trabajo en la obtención de los requerimientos
FM
-I
SI
Trabajamos de manera iterativa - en espiral . y realizamos las actividades de la Ingeniería de los
requerimientos.
Entrevista
●
●
Una entrevista para la recolección de información es una conversación dirigida con un propósito
específico que usa formato de preguntas y respuestas.
Se obtiene información sobre:
○ Opinión del entrevistado
○ Estado actual del sistema
○ Objetivos de la organización
○ Objetivos personales
○ Procedimientos informales
Planificación de la entrevista
Actividades
Lectura de material disponible
Breve descripción
Leer información a cerca del entrevistado y la organización.
86 de 112
Definición de objetivos
Organizar los temas que se van abordar durante la entrevistas.
Decidir a quién entrevistar
Se debe incluir a personas de todos los niveles.
Preparar al entrevistados
Realice una cita por anticipado con quienes vaya a entrevistar, indicando el
objetivo de la misma.
Decidir los tipos de pregunta y
estructura de la entrevista
Decidir los tipos de pregunta y estructura.
Escribir las preguntas para tratar los objetivos principales:
● Estructura pirámide
● Estructura rombo
● Estructura embudo
Realización
Hacer la entrevista
Ventajas y Desventajas
Ventajas
Desventajas
Las desventajas esenciales son el tiempo y el dinero.
Generalmente la gente tiende a ser más sincera
cuando habla que cuando escribe
Las personas que van a ser entrevistadas, deben ser
elegidas cuidadosamente, ya que ninguno está
disponible en abundancia.
-I
SI
Es el medio más directo para obtener información de
lo que hacen los stakeholders
No se puede utilizar para obtener información en
grandes cantidades, para esto se debe utilizar otras
técnicas de relevamiento.
Puede establecer una mejor relación con el usuario y
disminuir su resistencia al cambio.
No es una técnica para tener conocimiento sobre las
restricciones organizacionales porque existen sutiles
diferencias de poder entre las personas de la
organización.
FM
El entrevistador puede hacer preguntas abiertas y
dejar que el entrevistado responda en su propio estilo,
e incluso darle otra orientación si descubre un área
fértil de investigación, que no fue considerada al
elaborar la entrevista.
Ejemplo de preguntas
●
●
Encontrar los objetos de datos que se utilizan en el proceso de negocio
○ ¿Qué nombre tiene el formulario? ¿Cuál es el objetivo del formulario?
○ ¿Quien lo llena?
○ ¿Dónde es enviado? O ¿De dónde viene?
○ ¿Quién usa el formulario?
○ ¿Qué autoridad lleva?
○ ¿Qué estados tiene? (Pagado, autorizado, entregado)
○ ¿Qué cantidad de formularios realizan por día?
○ ¿Cuánto tiempo guardan el/los formularios?
Encontrar los datos que se utilizan en el proceso de negocio
○ ¿De dónde provienen los datos que utiliza el proceso de negocio?
○ ¿Para qué se usa cada dato?
○ ¿Cuál es el formato de los datos tanto para la entrada como para la salida?
87 de 112
●
-I
SI
●
○ ¿Cuán exactos deben ser los datos?
○ ¿Con qué grado de precisión deben hacerse los cálculos?
○ ¿Qué datos necesita cada área que participa en el proceso de negocio?
○ ¿Qué dato modifica cada área?
○ ¿Cuáles son los datos que se almacenan en este proceso?
○ ¿Existen datos que no son utilizados?
○ ¿Qué datos se originan en fuentes externas a la organización?
Conocer las reglas de negocio que se cumplen en el proceso de negocio
○ ¿Existen procedimientos escritos que el proceso de negocio deba cumplir?
○ ¿Cuáles son los controles en el proceso de negocio?
○ ¿Qué decisiones debe tomar para ejecutar la tarea?
○ ¿Debe cumplir alguna política del negocio?, por ejemplo de clientes, proveedores, personal, etc?
○ ¿Existen políticas de descuentos; políticas de pago?
○ ¿Las reglas de proceso de negocio podrían cambiar?
Conocer en detalle las actividades que se realizan en el proceso.
○ ¿Qué es lo que da inicio a la actividad?
○ ¿Quiénes participan en el proceso de negocio? ¿Que departamentos de la organización
participan en el proceso de negocio?
○ ¿Cuánto tiempo se tarda en realizarla?
○ ¿Qué retrasos ocurren o pueden ocurrir?
○ ¿Qué pasos constituyen la actividad? (describir la actividad paso a paso) ¿Existen actividades
paralelas?
○ ¿Existe algún tipo de control desarrollado en el proceso en cuestión?
○ ¿Cómo termina la actividad?
Cuestionarios
●
Consisten en una serie de preguntas escritas a las que hay que contestar también por escrito (ya sea en
papel o utilizando algún software)
Tipo de información que se busca con los cuestionarios:
○ Actitudes: lo que las personas dicen que quieren.
○ Creencias: lo que las personas piensan lo que realmente es verdad.
○ Comportamiento: es lo que las personas hacen.
○ Características: son las propiedades de las personas o cosas.
FM
●
Ventajas y desventajas
Ventajas
Desventajas
Obtener un alto volumen de información a un costo
relativamente bajo y en menos tiempo.
Tiene limitaciones sobre el tipo de preguntas que se
pueden realizar.
Elimina cualquier influencia sobre quien contesta.
Suelen ocurrir problemas de interpretación, tanto en
las preguntas como en las respuestas.
La información puede ser sincera ya que puede ser
anónima.
Si no tiene control sobre el grupo que responde,
puede tener una tasa de retorno muy baja y una
muestra pequeña será estadísticamente insignificante.
Su uso puede ser rápido y eficiente.
88 de 112
Único medio factible para relevar un gran número de
personas o para grandes distancias entre la fuente y el
encuestador.
Etnografía
●
●
●
●
●
La etnografía es una técnica de observación que se puede utilizar para entender los requerimientos
sociales y organizacionales.
El analista de sistemas se sumerge por sí solo en el entorno laboral donde se utilizará el sistema y observa
el trabajo diario y anota las tareas reales en las que los participantes están involucrados.
La ventaja de la etnografía es que permite descubrir los requerimientos implícitos que reflejan los
procesos reales más que los formales en los que la gente está involucrada.
El analista no interrumpe a los trabajadores o los distrae de sus tareas.
Detalles a tener en cuenta:
○ Cuando las personas están siendo observadas directamente, tienden a mejorar las funciones que
realizan y el rendimiento de las mismas. Puede ser necesario que haga varias visitas para
acostumbrarlos a su presencia y hacer que retornen a sus hábitos normales.
○ Se puede presentar resistencia de las personas a ser observadas.
La etnografía es especialmente efectiva para descubrir los siguientes requerimientos:
1. Requerimientos que se derivan de la forma en la que la gente trabaja realmente.
2. Requerimientos que se derivan de la cooperación y conocimiento de las actividades de la gente.
SI
●
Observación participativa
-I
El analista temporalmente realiza las actividades del grupo
Puede ser útil al estudiar las actividades de una organización complicada. Con esta técnica, el
analista puede "aprender haciendo". Se puede aprender mucho en corto tiempo, a pesar de
poder sentirse un intruso.
FM
●
●
Escenarios
●
●
●
●
Son descripciones abstractas de la secuencia del ​trabajo del usuario​ (no del sistema informático)
Casos de uso del negocio​ es una técnica basada en escenarios.
Actualmente la técnica de Casos de Usos del negocio es la más utilizada.
Se puede documentar con texto o con modelos.
Ejemplo
Objetivo
Descripción
Registrar el pedido del cliente.
1.
2.
3.
El cliente envía una orden de pedido que incluye los datos del cliente y los datos de
los productos solicitados.
El empleado revisa el pedido. Lo completa si es necesario y completa su
procesamiento enviándolo al jefe técnico quien se encarga de análisis del pedido.
El Jefe técnico analiza la viabilidad de cada producto.
a. Si el producto está en el catálogo de productos entonces puede fabricarse.
b. Caso contrario es considerado un producto especial y se considera lo
siguiente:
c. Si es viable la fabricación del producto es aceptada.
d. Si no es viable el producto especial no será fabricado.
89 de 112
4.
Una vez estudiado el pedido completo, el Jefe Técnico informa al departamento
comercial la aceptación o rechazo de cada producto pedido.
Si todos los productos de un pedido son aceptados se crea una orden de trabajo y se
la envía al jefe de Producción quedando pendiente hasta su lanzamiento.
5. El jefe Comercial comunica al cliente el resultado final del análisis de su pedido.
Prototipo
●
●
●
●
●
●
Un prototipo es una versión inicial de un sistema. Se usa para:
○ Demostrar conceptos o ideas
○ Validar requerimientos con el usuario / cliente
○ Informarse más del problema y sus posibles decisiones.
Un prototipo es un modelo a escala o facsímil de lo real, pero no tan funcional para que equivalga al
producto final.
El prototipo es la primera vista clara del usuario del futuro sistema.
Los prototipos se presentan en muchas formas y tamaños.
Los prototipos pueden ser tan simples como un conjunto de ​pantallas dibujadas en hojas de papel ​o tan
sofisticado como programas que​ permitan la animación​ de las pantallas.
Es una representación, o un modelo a escala reducida, que permite visualizar el comportamiento de lo
que será el futuro sistema.
Permite conocer el​ comportamiento del sistema​ y las ​reacciones de los usuarios ante el mismo​.
SI
●
Factores humanos a considerar en la elaboración del prototipo
Incremento del estrés
-I
Memoria limitada
Descripción
Podemos recordar instantáneamente alrededor de siete elementos de
información. Por lo tanto, si a los usuarios se les presenta demasiada
información al mismo tiempo, es posible que no puedan asimilarla.
FM
Factores
Cuando los sistemas fallan y emiten mensajes de aviso y alarmas, a menudo
aumentan el estrés de los usuarios, incrementando así la posibilidad de que
cometan errores.
Capacidades físicas diferentes
El prototipo no se elabora para las propias capacidades y suponr que todos
los otros usuarios serán capaces de adaptarse.
Preferencias de interacción
A algunas personas les gusta trabajar con imágenes, otras con texto. La
manipulación directa es natural para algunas personas, pero otras prefieren
un estilo de manipulación basado en comandos.
Propósito del prototipo en el ciclo de vida del sistema
●
●
El prototipo abarca diferentes fases del ciclo de vida. El objetivo del prototipo en cada fase es diferente.
Para la etapa de análisis de requerimientos el principal objetivo del prototipo es derivar y validar los
requerimientos esenciales, manteniendo abiertas, al mismo tiempo, las opciones de implementación.
Ventajas de la elaboración de prototipos
●
●
Modificar el prototipo en las primeras etapas del desarrollo.
Oportunidad de suspender el desarrollo de un sistema que no sea funcional.
90 de 112
●
La posibilidad de desarrollar un sistema que acerque más a satisfacer las necesidades y expectativas de los
usuarios.
Lineamientos o guías para la construcción de prototipos
Guías para la construcción de prototipos:
● Trabajar en módulos manejables:
○ Un módulo manejable es aquel que permite a los usuarios interactuar con características claves
del sistema, pero el módulo se puede construir de forma separada de otros módulos.
○ Realizar un modelo funcional con algunas características del sistema.
● Construir rápidamente el prototipo:
○ La rapidez es esencial para la elaboración exitosa del prototipo.
○ La elaboración temprana permite comprender mejor los requerimientos.
○ Los usuarios pueden utilizar el sistema muy temprano en el ciclo de vida, en lugar de esperar
hasta que se termine el sistema.
● Modificar el prototipo en iteraciones sucesivas:
○ Desarrollar el prototipo de manera que pueda soportar modificaciones.
○ Hacer el prototipo modificable significa que se lo debe crear en módulos que no sean demasiado
interdependientes.
FM
-I
SI
Actividades que realizamos para elaborar el prototipo
1° actividad: Analizar y comprender las actividades del usuario
En el proceso de análisis del usuario, se desarrolla una comprensión de las tareas que éste realiza, su
entorno de trabajo, los otros sistemas que utiliza, cómo interactúan con el resto de las personas en su trabajo, etc.
91 de 112
Es una actividad crítica, porque si no se entiende lo que los usuarios quieren hacer con el sistema, no se
podrá llevar a cabo un diseño real y eficaz de la interfaz de usuario.
Para desarrollar esta comprensión, puede utilizar técnicas como entrevistas, observaciones, análisis de
tareas, etnografía o comúnmente es una mezcla de todas ellas.
Tipo de información buscada con el prototipo
●
●
●
SI
●
Reacciones del usuario:
○ Son recopiladas por medio de observaciones, entrevista. Estas se diseñan para recoger la opinión
de cada persona acerca del prototipo cuando interactúa con el usuario.
○ Por medio de estas reacciones el analista descubre si el prototipo se ajusta a los requerimientos
del usuario.
○ Ejemplo: uso del color, lectura fácil, reconoce íconos fácilmente.
Sugerencias del usuario:
○ Las sugerencias son el producto de la interacción de los usuarios con el prototipo.
○ Estas sugerencias se dirigen hacia formas de refinación, cambio o limpieza del prototipo para que
se ajuste mejor a las necesidades de los usuarios.
○ Las sugerencias son recolectadas de aquellos que experimentan con el prototipo, mediante un
periodo de tiempo específico.
○ El tiempo que pasan los usuarios con el prototipo depende por lo general de su dedicación e
interés en el proyecto de sistemas.
○ Ejemplos: eliminar captura de datos redundantes, eliminar hojas de cálculo (archivos volátiles),
encontrar datos nuevos.
Son capacidades nuevas del sistema que no habían sido pensadas antes de la interacción con el prototipo.
Van más allá de las características típicas actuales añadiendo algo nuevo e innovador.
Ej: Explorar ambientes de destino posibles: interfaces gráficas, página web, portátiles, lectores de código
de barras.
-I
●
●
●
●
●
FM
Validación del prototipo con los usuarios finales
Cuestionarios​ que recopilan información de lo que opinan los usuarios de la interfaz.
La ​observación de los usuarios cuando trabajan con el sistema y "piensan en voz alta" de cómo tratan de
utilizar el sistema para llevar a cabo alguna tarea.
Videos​ del uso típico del sistema.
La inclusión de ​código en el software que recopila información de los recursos más utilizados y de los
errores más comunes.
Evaluar el diseño de a UI con los usuarios finales: Técnicas para la evaluación de la UI
●
●
Cuestionarios:
○ Es una técnica económica para evaluar la UI
○ Los cuestionarios se pueden utilizar aun antes que esté disponible el sistema ejecutable si se
construyen y evalúan maquetas en papel de la interfaz
○ Preguntando por la experiencia y conocimientos permite conocer si los usuarios con cierto tipo
de conocimientos tienen problemas con la interfaz.
○ Ejemplo de preguntas: Indique el valor en una escala de 1 a 5 de cuál es la comprensión de los
mensajes de error.
Observación:
○ Se observa cómo utilizan el sistema los usuarios, ver los recursos que utilizan, los errores
cometidos, etc.
92 de 112
○
Se complementan, con sesiones en las cuales los usuarios conversan sobre lo que tratan de
hacer, qué piensan del sistema y cómo tratan de utilizarlo para llevar a cabo sus objetivos.
3° actividad: Evaluar el diseño de la UI con los usuarios finales
Iteración el proceso de desarrollo del prototipo
-I
Los prototipos se hacen en refinamientos sucesivos, a través de la evaluación y su modificación a raíz de
los comentarios sobre el mismo.
FM
●
SI
Técnicas para la evaluación de la UID:
● Uso de videos:
○ Se graba las sesiones para su análisis posterior
○ Grabar las sesiones es relativamente de bajo costo.
○ El análisis completo por medio de video es caro y requiere de un equipo de evaluación
especializado con varias cámaras enfocadas al usuario y a la pantalla.
○ El análisis de los videos permite descubrir:
■ Demasiados movimientos de las manos.
■ Movimientos forzados del ojo.
● La inclusión de código en el software:
○ Instrumentar código que recopile estadísticas de utilización permite mejorar las interfaces de
varias formas.
○ Se pueden detectar operaciones más comunes.
○ Las interfaces se pueden reorganizar para que sean más rápidas de seleccionar.
○ Los usuarios pueden enviar sus opiniones a los diseñadores para que de esta manera se obtenga
retroalimentación.
93 de 112
SI
-I
FM
94 de 112
Unidad 8: Análisis Orientado a Objetos
Temas
●
●
●
●
●
●
●
●
Análisis Orientado a Objetos.
Conceptos del paradigma orientado a objetos.
Patrones del Análisis.
Modelo de Dominio.
Casos de Uso: Diagrama y especificación de Casos de Uso.
Diagrama de Secuencia.
Diagrama de transición de estados.
Modelo de Análisis (diagrama de colaboración del análisis).
Bibliografía
●
FM
-I
SI
●
Booch Jacobson Rumbaugh. 1a Ed.
○ Capítulo 8. Análisis.
Larman. 2a Ed.
○ Capítulo 6. Modelo de Casos de Uso: escritura de requisitos en contexto.
○ Capítulo 7. identificación de otros requisitos.
○ Capítulo 9. Modelo de Casos de Uso: Representación de los Diagramas de Secuencia del Sistema.
○ Capítulo 10. Modelo del Dominio: Visualización de conceptos.
○ Capítulo 11. Modelo del Dominio Añadir Asociaciones.
○ Capítulo 12: Modelo del Dominio: Añadir Atributos.
○ Capítulo 13: Modelo de Casos de Uso: Añadir detalles con los contratos de las operaciones.
○ Capítulo 29. Modelado del comportamiento con Diagramas de estado.
Casos de Uso y Requisitos funcionales
●
●
●
●
●
●
●
●
Los Casos de Uso nos ayudan a ​descubrir​ y ​registrar​ los ​requisitos funcionales​.
Los Casos de Uso son historias de uso de un sistema para alcanzar los ​objetivos o necesidades ​de las
personas involucradas en el sistema de información
Los Casos de Uso no son una herramienta exclusiva de la Ingeniería de los Requerimientos.
También se usan en el modelo de proceso UP - Proceso Unificado - en la disciplina Requisitos.
Los Casos de uso son requisitos, ante todo ​requisitos funcionales​. También se los utiliza para representar
los requerimientos no funcionales.
Los Casos de uso se modelan con el UML en un Diagrama de Casos de uso.
Los Casos de uso son ​documentos de texto q
​ ue describen las interacciones entre el usuario y el sistema.
Ejemplo de una historia de uso, escrito en formato breve::
Nombre del Caso de Uso​: Realizar alquiler de películas.
Descripción Breve​: Los socios solicitan alquilar videos presentando al empleado la credencial de socio,
junto con las carátulas de los videos que desea alquilar. El empleado utiliza el sistema para registrar cada
video. El sistema muestra el detalle del alquiler y calcula el total a pagar. El empleado ingresa los datos del
pago. El sistema valida y registra. El sistema imprime el recibo de alquiler. El sistema actualiza la
disponibilidad de la película. El cliente se retira con el recibo y las películas alquiladas.
95 de 112
*​Historia de uso del sistema: simple y entendible por los stakeholders. El sistema informático ayudará a conseguir
los objetivos o necesidades de los usuarios.
Antecedentes
●
●
●
La idea de utilizar Casos de uso para describir los requerimientos funcionales fue introducida por Ivar
Jacobson en 1986.
La idea tuvo gran influencia y es ampliamente reconocida, principalmente por su simplicidad y utilidad.
El texto Writing Effective Use Case del autor Alistair Cockburn es uno de los primeros trabajos escritos y
publicados de 1992 en adelante.
Los Casos de Uso son una herramienta de comunicación que resume el comportamiento de un sistema y
sus actores.
El documento de Caso de Uso y el Diagrama de Caso de Uso son los artefactos que utilizamos para
comunicar a los stakeholders, el comportamiento del sistema y sus actores, durante todo el ciclo de vida del
sistema.
FM
-I
SI
Diagrama de Casos de Uso
●
●
El Diagrama de Casos de Uso es una representación del ​contexto del sistema​.
El Diagrama de Casos de Uso muestra:
○ Los límites del sistema,
○ Lo que permanece fuera del sistema, es decir el ambiente o entorno del sistema y resume el
comportamiento de un sistema.
○ Los requisitos funcionales del sistema.
96 de 112
Elementos del diagrama de Casos de Uso: Actores
Actores
Ejemplos
Cajeros, cliente, proveedores
Sistemas informáticos externos a la organización
Sistemas de autorización de tarjetas de créditos
Sistema de AFIP
Sistema VERAZ
Otras organizaciones
-I
FM
Sistemas informáticos que pertenecen a la
organización
SI
Roles de personas
Sistema de control de la producción
Sistema de alumnos
Sistema de RRHH
Municipalidad
Ministerio de Educación
UTN
Un actor es algo con comportamiento, como por ejemplo una persona (identificada con un rol), una organización,
un sistema informático.
Tipo de actores
Principales
Son los usuarios directamente beneficiados con el
sistema.
Se identifican porque es necesario encontrar los
objetivos del usuario​.
De apoyo
Proporcionan un servicio, de información por ejemplo.
Por lo general es otro sistema de información pero
también pueden ser organizaciones.
Se identifica porque el sistema necesita definir las
interfaces y protocolos​.
97 de 112
Pasivos
Pueden modificar o cambiar el caso de uso.
Por ejemplo organizaciones tributarias del gobierno.
Se los identifica porque debemos asegurarnos que
todos los interesados en el sistema se han identificado
Preguntas para encontrar actores
¿A quienes el sistema va a beneficiar?
¿Quién/Quiénes usarán el sistema?
¿Qué roles cumplen los usuarios con respecto al sistema?
¿Quiénes van a interactuar directamente con el sistema? (quienes crean o ingresan datos al sistema)
¿Quiénes van a supervisar, mantener, consultar o recibir información del sistema?
¿Con qué sistema de información se comunicará el nuevo sistema?
SI
*Sugerencia: El nombre de las calles del Diagrama de actividades nos ayudan a descubrir actores
FM
-I
Elementos del Diagrama de Casos de Uso: Caso de Uso
Nombre del Caso de Uso
Es único para cada Caso de Uso. El nombre debe ser descriptivo, es decir con
pocas palabras describe qué objetivo del usuario se obtiene con el Caso de Uso.
Generalmente comienza con un verbo que indica la función principal.
Ejemplos
Gestionar Alumnos
Gestionar Préstamos de Libros
Comprar Productos
Generar Reportes
*​Un caso de uso es una colección de escenarios con éxito y fallos relacionados, que describe a los actores utilizando
un sistema para satisfacer un objetivo.
Un escenario es una secuencia específica de acciones e interacciones entre los actores y el sistema objeto de
estudio; también se denomina instancia de Caso de Uso.
98 de 112
Preguntas para encontrar casos de uso
¿Cuáles son las principales tareas de un actor?
¿Qué tareas del actor pueden automatizarse?
¿Qué información tiene el actor que consultar, actualizar, modificar?
¿Cómo realiza el actor estas actividades?
¿Qué cambios del exterior debe informar el actor al sistema?
¿Qué información debe el sistema comunicar al actor?
*Sugerencia: Las actividades seleccionadas en el diagrama de actividades nos ayudan a encontrar los casos de uso.
Los objetos de datos del diagrama de actividad nos ayudan a identificar la información del sistema.
Documentar los Casos de Uso
SI
●
●
Para cada Caso de Uso identificado debemos especificar y documentar.
Se escribe un documento para indicar detalladamente la forma en la que el actor interactúa con el
sistema.
Los casos de uso se documentan con formatos diferentes según la necesidad.
Los grados de formalidad son los siguientes:
○ Breve​: Resumen de un párrafo que describe un escenario de éxito.
○ Completo​: Es más elaborado. Describe con detalle todos los pasos y variaciones. En el
documento hay secciones de apoyo como precondiciones y garantías de éxito.
Formalidad breve del documento
Ejemplo:
-I
●
●
FM
Sistema de Terminal de Punto de Venta -TPDVUn cliente llega a una caja con los artículos para comprar. El cajero utiliza el sistema Terminal de Punto de
Venta para registrar cada artículo que compra el cliente. El sistema muestra el detalle de cada línea de venta y el
subtotal. El sistema calcula el total a pagar. El cliente paga y el cajero registra los datos del pago. El sistema valida
y registra. El sistema actualiza el stock de productos. El sistema emite el recibo de pago. El cliente se retira con los
artículos y el recibo.
Formalidad documento completo
La estructura propuesta para el documento, es la siguiente:
1. Nombre del Caso de Uso​: Nombre único que identifica al caso de uso.
2. Actores participantes​: Roles de los actores principales, actores pasivos o actores de apoyo.
3. Precondiciones​: Son las condiciones que se deben cumplir para inciar el caso de uso. Se asumen
como verdaderas.
4. Poscondiciones​: Representan el estado del sistema después que el Caso de Uso se ha ejecutado.
5. Flujos de Eventos​: Describe la interacción entre el actores y el sistema. El flujo de eventos está
formado por: el flujo básico y el flujo alternativo.
a. Flujo Básico​. Escenario principal de éxito: el elemento que da inicio al caso de uso, la
secuencia de eventos de éxito cuando el caso de uso comienza a funcionar, la secuencia
de eventos que se pueden repetir y cómo termina el caso de uso.
i.
Evento 1
99 de 112
b.
ii.
Evento 2
iii.
Evento n
Flujos alternativos o extensiones​: describe las situaciones opcionales; los posibles
errores, diferentes variantes del caso de uso y recursos de hardware o software que
podrían bloquearse.
Ejemplo:
Nombre del Caso de Uso: ...
Actores: ...
Precondición: ,..
Poscondición: …
FM
-I
SI
Escenario principal de éxito – Flujo Básico –
1. El Cliente llega a un TDV con mercancías a comprar
2. El Cajero comienza una nueva venta
3. El Cajero ingresa el identificador del artículo
4. El Sistema registra la línea de la venta y muestra la descripción del articulo y precio unitario y suma
parcial. El precio se calcula a partir de un conjunto de reglas de precios
El Cajero repite los pasos 3-4 hasta que se indique
5. El Sistema presenta el total con los impuestos calculados
6. El Cajero le dice al Cliente el total y pide que le pague
7. El Cliente paga y el Sistema gestiona el pago.
8. El Sistema registra la venta completa y envía la información de la venta y el pago al Sistema de
Contabilidad externo (para la contabilidad y las comisiones) y al Sistema de Inventario (para actualizar el
inventario).
9. El Sistema presenta el recibo.
10 El Cliente se va con el recibo y las mercancías.
Formalidad del Documento
●
●
●
Para los dos tipos de formalidad, se debe escribir de manera esencial.
Esencial significa que se evitan los ​detalles de la interfaz de usuario y se centra en los ​objetivos o
intenciones del usuario​.
Entonces, nos preguntamos ¿proponemos las interfaces de usuario?
○ Durante el proceso de descubrimiento de los requisitos
■ Investigamos y preguntamos acerca de los objetivos de los usuarios finales.
■ Por ejemplo un objetivo podría ser "identificarse y autenticarse en el sistema"
■ No pensamos en el mecanismo que alcanza el objetivo, es decir no pensamos en un
cuadro de diálogo, que contenga identificador del usuario y contraseña.
○ Así podemos abrir la visión a soluciones nuevas y mejoradas.
■ Por ejemplo podríamos usar un lector biométrico para identificar y autenticar al usuario.
○ Trabajamos de manera iterativa, con una comunicación personal y ​continua entre los
desarrolladores del sistema y alguien que entienda el dominio del problema.
○ Si podemos realizar las interfaces de usuario pero con el objetivo de encontrar nuevos requisitos
o de validar los requisitos​ que ya hemos especificado.
○ En Análisis de Sistemas, para escribir el caso de uso ​evitemos los detalles de la interfaz de
usuario​, es decir escribamos los casos de uso ​independientemente de los detalles de la
tecnología​.
100 de 112
FM
-I
SI
Procedimiento Básico para definir los Casos de Uso
101 de 112
Modelo de Análisis
●
●
El modelo del Análisis nos permite ​validar la especificación​ de los Casos de Uso.
La validación consiste en:
○ Disminuir la ambigüedad propia de los requisitos del usuario, completar o corregir los requisitos.
○ Descubrir nuevos conceptos en el Modelo del Dominio
Consideraciones importantes acerca del Modelo del Análisis
●
●
●
●
El Modelo del Análisis no considera el ambiente de implementación, es decir:
○ No incluye al lenguaje de programación.
○ No incluye manejador de base de datos,
○ No incluye configuración de hardware, etc
El Modelo del Análisis modela el sistema bajo condiciones ideales, es un modelo conceptual del
comportamiento del sistema.
Para realizar el modelo es posible invertir 10 minutos de nuestro tiempo
Si nos lleva más tiempo, es preferible reescribir el Caso de Uso.
Diferencias entre el Modelo de Casos de Uso y el Modelo del Análisis
Modelo del Análisis
SI
Modelo de Casos de Uso
Se escribe con el lenguaje de los ​desarrolladores​.
Representa la ​vista externa​ del sistema.
-I
Se escribe con el lenguaje del cliente, es decir con
lenguaje natural​.
Representa la ​vista interna ​del sistema. Utiliza clases
conceptuales ​borde, control y entidad
No debería contener redundancias, inconsistencias​,
etc, entre requisitos.
Captura la funcionalidad del sistema​, incluida la
funcionalidad significativa para la arquitectura del
sistema
Esboza cómo llevar a cabo la funcionalidad, ​incluida la
funcionalidad significativa para la arquitectura del
sistema.
Sirve como primera aproximación al diseño.
Utilizado como ​contrato​ entre el ​cliente​ y los
desarrolladores​ sobre ​qué debería​ y qué no debería
hacer el sistema
Utilizado por los ​desarrolladores​ para ​comprender
cómo debería darse forma al sistema.
FM
Puede contener redundancias, inconsistencias​, etc
entre requisitos
Elementos del Modelo del Análisis
●
●
Podemos utilizar tres elementos: Clase entidad, Clase Borde, Clase Control.
Con UML, existen dos formas de representar los elementos:
102 de 112
SI
-I
FM
103 de 112
Ejemplo
●
●
●
Un ejemplos para trabajar los requisitos y el Caso de Uso para el ingreso al sistema mediante
autenticación del usuario.
Los requisitos se refinaron en cada iteración realizando talleres de validación con los usuarios finales.
En la próxima sección observamos el avance del trabajo, realizando y proponiendo prototipos del usuario.
Luego documentamos el Caso de Uso
FM
●
-I
SI
Reglas para tener en cuenta
104 de 112
SI
-I
FM
Caso de Uso​: Ingresar al sistema
Precondiciones​:
● El estudiante de la facultad está conectado a internet y ha ingresado a la página del sistema de Gestión de
Constancias de Alumno Regular.
● Los datos de lo usuarios están almacenados en el Sistema.
● El estudiante todavía no ingresó al sistema.
Poscondiciones​:
● Se inicia la sesión del estudiante en el sistema.
Flujo normal de los eventos - Flujo de éxito
1. Este caso de uso comienza cuando un estudiante desea autenticarse en el sistema.
2. El Sistema presenta el inicio de sesión.
3. El estudiante ingresa su legajo y contraseña.
4. El sistema valida los datos de legajo y contraseña.
5. El sistema inicia sesión.
6. El sistema presenta la información para generar la constancia de alumno regular.
Extensiones o Flujos Alternativos
3.a- El estudiante ingresa legajo o contraseña incorrecta.
1. El sistema señala el error y rechaza la entrada
2. El estudiante puede ingresar nuevamente su legajo y contraseña.
3. Retornar al paso 4 del flujo normal de los eventos.
3b- El estudiante ingresa legajo o contraseña en blanco.
1. El sistema señala el error y rechaza la entrada.
2. El estudiante puede ingresar nuevamente su legajo y contraseña105 de 112
3. Retornar al paso 4 del flujo normal de los eventos.
__________________
FM
-I
SI
¿Cómo trabajar utilizando estos datos?
● Leer con atención las precondiciones para buscar información acerca de dónde se encuentran los datos.
● Leamos las poscondiciones para saber qué hace el proceso.
● Del flujo de éxito identificamos:
○ Los conceptos trabajando con la lista de categorías.
○ Los atributos
○ Las ventanas de usuario
○ El origen de los datos/información
○ Los procesos del Caso de Uso
○ Considerar tener en línea el modelo del dominio
106 de 112
SI
-I
FM
107 de 112
Unidad 9: Validación de Requerimientos
Temas
●
●
●
●
●
Validar los requisitos: Concepto de validación.
Prototipos: componentes que facilitan la interacción hombre-máquina
Prototipos de interfaz de usuario.
Herramientas CASE para la creación de prototipos inicialesRevisiones de los requerimientos.
Bibliografía
●
SI
●
Sommerville. 7a Ed.
○ Capítulo 7. Procesos de la Ingeniería de los requerimientos.
ISO/IEC/IEEE 29148 Std.
○ Systems and software engineering.
○ Life cycle processes
○ Requirements engineering
●
●
La ​validación de requerimientos trata de mostrar que éstos realmente definen el sistema que el cliente
desea.
Coincide parcialmente con el análisis ya que este implica encontrar problemas con los requerimientos.
La validación de los requerimientos es ​importante porque los errores en el documento de requerimientos
puede conducir a importantes costos, daños personales o que el proyecto se cancele al repetir el trabajo
cuando son descubiertos durante el desarrollo o después que el sistema esté en uso.
FM
●
-I
Validación de Requerimientos
108 de 112
-I
SI
¿Por qué es importante validar los requerimientos?
Técnicas para la validación de requerimientos
Una técnica de validación es la ​construcción de prototipos
○ Un prototipo es útil en todas las actividades de desarrollo (análisis, diseño, codificación, prueba,
implementación).
○ Un objetivo del prototipo puede ser ​derivar y validar los requerimientos esenciales​.
○ La validación con el uso de prototipos se enfoca en el contenido de información de las ventanas y
los eventos del usuario.
FM
●
109 de 112
●
●
La revisión de requerimientos es una actividad ​manual ​que involucra a personas tanto de la organización
del cliente como el equipo de desarrollo del sistema.
El documento de los requerimientos se verifica para encontrar anomalía y omisiones.
Las revisiones de requerimientos pueden ser informales o formales.
-I
●
SI
Verificar los requerimientos
●
●
●
FM
Técnicas para verificar los requerimientos
Inspecciones o revisiones.
Listas de comprobación o checklist.
Chequeo contra estándares.
Revisiones
Descripción de la actividad
Informales
Los contratistas deben tratar los requerimientos con
tantos stakeholders del sistema como sea posible.
Formales
El equipo de desarrollo le explica cada requerimiento a
los clientes.
Los revisores deben comprobar lo siguiente:
● ¿Puede probarse el requerimiento?
(Verificabilidad)
● ¿Las personas comprenden correctamente los
requerimientos? (Comprensibilidad)
● ¿Está claramente establecido el origen del
requerimiento? (Rastreabilidad)
● ¿Puede cambiarse el requerimiento sin causar
efectos a gran escala en otros
requerimientos? (Adaptabilidad)
Los conflictos, contradicciones, errores y omisiones en
los requerimientos se registran formalmente en el
informe de revisión.
110 de 112
Reunión formal de revisión
¿Quiénes participan en la reunión?
● Ingenieros (Revisores)
● Clientes y Usuarios.
¿Qué artefactos debo tener disponibles?
● Prototipos IU, impresos.
● ERS
¿Qué documentos obtengo después de la reunión?
● Problemas detectados
● Acta de la reunión
Características de calidad que verificamos de cada requerimiento
Característica
Breve descripción
Un requisito es correcto si refleja alguna necesidad real, es decir, representa una necesidad
planteada por el usuario.
No ambiguo
Un requisito no es ambiguo cuando tiene una sola interpretación. Para eliminar la
ambigüedad se pueden utilizar modelos. Si un término tiene más de una interpretación, se
debe definir con precisión en el glosario.
Completo
Un requisito es completo si se han incluido las posibles respuestas del sistema a los datos
de entrada, tanto válidos como no válidos.
Verificable
Un requisito es verificable si existe un proceso finito y no costoso para demostrar que el
sistema cumple con el requisito.
Trazable
Cada requisito debe estar identificado con una referencia para facilitar el conocimiento de
su origen y de su destino.
FM
-I
SI
Correcto
Características de calidad que verificamos del documento ERS
Característica
Breve descripción
Validez
Se razona y analiza si el conjunto de requerimientos contenidos en la ERS coincide con las
necesidades de los usuarios.
Consistencia
Los requerimientos en el documento ERS no deben contradecirse ni deben existir
requerimientos ambiguos
Completitud
El documento de los requerimientos debe incluir todas las funciones y restricciones
propuestas por el usuario del sistema.
Realismo
Se deberá asegurar que la tecnología propuesta para el sistema se podrá implementar.
También se considerará el presupuesto y la agenda.
Verificabilidad
Escribir un conjunto de pruebas que demuestran que el sistema a entregar cumple cada
uno de los requerimientos especificados.
Reducir la posibilidad de discusión entre el cliente y los desarrolladores.
111 de 112
Ejemplo lista de verificación o checklist
Resumen de técnicas para verificar y validar los requerimientos
Técnicas
Descricpción
Los requerimientos se analizan sistemáticamente por un equipo de
revisores.
Construcción de prototipos
Se muestra un modelo ejecutable del sistema a los usuarios finales y a
los clientes. Estos pueden experimentar con el modelo para ver si
cumple sus necesidades reales.
Generación de casos de pruebas
Se deben escribir pruebas para los requerimientos antes de que se
escriba el código del programa.
Si una prueba es difícil o imposible de diseñar, significa que los
requerimientos serán difíciles de implementar y se los debería
considerar nuevamente.
FM
-I
SI
Revisiones
112 de 112