Resumen Análisis de Sistemas Final

Vista previa del material en texto

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 
Beneficios de JAD 12 
Desventajas potenciales de JAD 12 
Cuestionarios 12 
Planeación del uso de cuestionarios 13 
Escribir las preguntas 13 
Las ventajas que sacrifica al elegir uno y otro tipo de preguntas 14 
Diseño de cuestionarios 14 
Etnografía 15 
Escenarios 15 
Casos de uso 15 
Puntos de vista 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 
FM
 - 
IS
I
 
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 
Prototipos del Modelo Evolutivo 27 
Ventajas Modelo Evolutivo 27 
Desventajas Modelo Evolutivo 27 
¿Cuándo es conveniente utilizar el Modelo evolutivo? 27 
Modelo Espiral 27 
¿Qué se realizar en la Primera Iteración? 28 
Acciones comunes a todas las iteraciones 29 
¿Qué se realiza en cada iteración? 29 
Ventajas Modelo en Espiral 32 
Unidad 3: Marco de desarrollo. Proceso Unificado 33 
Temas 33 
Bibliografía 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 
FM
 - 
IS
I
 
¿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 
Conclusiones y sugerencias 60 
Diagrama de Transición de Estados 61 
Partes del Diagrama de Estados 62 
Contexto del objeto 62 
Partes del estado 64 
Pseudoestados 64 
Usos más comunes del Diagrama de Estados 65 
Conclusiones y sugerencias 66 
Unidad 5: El modelado del dominio del problema 67 
Temas 67 
Bibliografía 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 
FM
 - 
IS
I
 
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 
Requerimientos Funcionales 79 
Escribir los requisitos funcionales 79 
Requerimientos de dominio 80 
Ingeniería de los Requerimientos 81 
Proceso de la Ingeniería de Requerimientos 81 
Definición 81 
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 
FM
 - 
IS
I
 
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 
1° actividad: Analizar y comprender las actividades del usuario 98 
Tipo de información buscada con el prototipo 98 
Validación del prototipo con los usuarios finales 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 
Unidad 8: Análisis Orientado a Objetos 103 
Temas 103 
Bibliografía 103 
Casos de Uso y Requisitos funcionales 103 
Antecedentes 104 
Diagrama de Casos de Uso 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 111 
Modelo de Análisis 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 
FM
 - 
IS
I
 
Temas 118 
Bibliografía 118 
Validación de Requerimientos 118 
¿Por qué es importante validar los requerimientos? 119 
Técnicas para la validación de requerimientos 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 ochecklist 122 
Resumen de técnicas para verificar y validar los requerimientos 122 
 
 
 
6 de 112 
FM
 - 
IS
I
 
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 
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 
FM
 - 
IS
I
 
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 
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 
1. 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. 
2. ESTABLEZCA LOS OBJETIVOS DE LA ENTREVISTA Defina los objetivos de la entrevista a partir de los 
antecedentes investigados y de su propia experiencia. 
3. 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. 
4. 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. 
5. 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. 
8 de 112 
FM
 - 
IS
I
 
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 dedos párrafos. 
Los ​beneficios​ de utilizar preguntas abiertas son muchos, entre los cuales tenemos: 
1. El entrevistado baja la guardia. Pone al entrevistado confortable. 
2. El entrevistador puede percibir el vocabulario del entrevistado, lo cual refleja su educación, valores, 
posturas y creencias. 
3. Se proveen muchos detalles. 
4. Se descubren vías de cuestionamiento adicionales que de otra manera no se hubieran explotado. 
5. El entrevistado encuentra el proceso más interesante. 
6. Se permite una mayor espontaneidad. 
7. El entrevistador puede expresar mejor las preguntas. 
8. 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​: 
1. Las preguntas pueden generar muchos detalles irrelevantes. 
2. Se puede llegar a perder el control de la entrevista. 
3. Se permiten respuestas que pueden requerir demasiado tiempo. 
4. Podría parecer que el entrevistador no está preparado. 
5. Puede darse la impresión de que el entrevistador no tiene objetivos bien definidos. 
Debe considerar con cuidado las implicaciones de usar preguntas abiertas en las entrevistas. 
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. Ahorro de tiempo. 
2. Se pueden comparar las entrevistas con facilidad. 
3. Van directo al grano. 
4. Se mantiene el control sobre la entrevista. 
5. Se cubre mucho terreno con rapidez. 
6. Se obtienen datos relevantes. 
Sin embargo, las ​desventajas​ de usar preguntas cerradas son sustanciales. Entre las más comunes tenemos: 
1. Son aburridas para el entrevistado. 
2. No proporcionan detalles adicionales (debido a que el entrevistador provee el marco de 
referencia para el entrevistado). 
3. Se pierden las ideas principales por la razón anterior. 
4. No se puede generar una relación armónica o buena comunicación entre el entrevistador y el 
entrevistado. 
9 de 112 
FM
 - 
IS
I
 
Por lo tanto, como entrevistador usted debe considerar con cuidado los tipos de preguntas que piensa utilizar. 
Atributos de las preguntas abiertas y las preguntas cerradas. 
 
 
 
 
 
 
 
 
 
 
Estructuras de las entrevistas 
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 
FM
 - 
IS
I
 
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. 
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 
FM
 - 
IS
I
 
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 
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 
FM
 - 
IS
I
 
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 
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. 
Escribir las preguntas 
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 
FM
 - 
IS
I
 
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: 
1. Use el lenguaje de los encuestados siempre que sea posible. Mantenga un vocabulario simple. 
2. Concéntrese en ser específico en vez de utilizar palabras imprecisas. Evite también las preguntas 
demasiado específicas. 
3. Trate de mantener las preguntas cortas. 
4. No use un tono condescendiente, al usar opciones redactadas en lenguaje de bajo nivel, para dirigirse a 
los encuestados. 
5. Evite la predisposición en sus palabras. Esto también significa evitar preguntas censurables. 
6. Dirija las preguntas a los encuestados apropiados (es decir, los que sean capaces de responder). No 
suponga que conocen demasiado. 
7. Asegúrese de que las preguntas sean correctas en el sentido técnico antes de incluirlas. 
8. Use software para verificar si el nivel de lectura es apropiado para los encuestados. 
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. Incluya mucho espacio en blanco. 
2. Incluya mucho espacio para escribir o teclear las respuestas. 
3. Facilite a los encuestados la acción de marcar con claridad sus respuestas. 
4. 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. Coloque primero las preguntas que sean importantes para los encuestados. 
2. Agrupe elementos de contenido similar. 
3. Introduzca primero las preguntas menos controversiales. 
14 de 112 
FM
 - 
IS
I
 
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 
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. 
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. 
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 
FM
 - 
IS
I
 
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. 
Ciclo de Vida para los Sistemas de Información 
● 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. 
¿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
 - 
IS
I
 
Estándar ISO/IEC 12207 para el ciclo de vida de los sistemas de información 
 
 
17 de 112 
FM
 - 
IS
I
 
Ciclo de vida del desarrollo de Sistemas 
 
 
● 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. 
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
 - 
IS
I
 
 
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 
FM
 - 
IS
I
 
● 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. 
 
¿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 
FM
 - 
IS
I
 
 
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 
Especificación 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. 
¿Qué es un modelo de proceso de desarrollo de software? 
● 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. 
 
 
21 de 112 
FM
 - 
IS
I
 
Modelo de Procesos de Desarrollo del Software 
Modelos de Procesos de Desarrollo del Software: Modelos Tradicionales 
 
 
22 de 112 
FM
 - 
IS
I
 
Modelo en Cascada (Sommerville) 
Roles sugeridos por cada fase 
 
23 de 112 
FM
 - 
IS
I
 
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 
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. 
Operación y Mantenimiento 
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 
FM
 - 
IS
I
 
● 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. 
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 
FM
 - 
IS
I
 
● 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. 
¿Cuándo es conveniente utilizar el Modelo evolutivo? 
● 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. 
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 
FM
 - 
IS
I
 
¿Qué se realizar en la Primera Iteración? 
● Cada ciclo o iteración en la espiralrepresenta 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. 
 
27 de 112 
FM
 - 
IS
I
 
Acciones comunes a todas las iteraciones 
● 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. 
¿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 
FM
 - 
IS
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 
 
29 de 112 
FM
 - 
IS
I
 
 
30 de 112 
FM
 - 
IS
I
 
 
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 
FM
 - 
IS
I
 
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? 
● 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. 
 
32 de 112 
FM
 - 
IS
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. 
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 
FM
 - 
IS
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. 
34 de 112 
FM
 - 
IS
I
 
Proceso Unificado Rational - RUP 
 
35 de 112 
FM
 - 
IS
I
 
 
36 de 112 
FM
 - 
IS
I
 
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. 
 
Disciplinas o actividades del Proceso Unificado 
 
Actividades Breve Descripción 
Modelado del negocio Se modelanlos procesos de negocios. 
Requerimientos Se modelan los requerimientos del sistema. 
Análisis y diseño Se crea y documenta el modelo del diseño creando modelos de la arquitectura. 
Implementación 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 
FM
 - 
IS
I
 
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: 
 
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 
FM
 - 
IS
I
 
 
 
Iteración en el UP 
¿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 
FM
 - 
IS
I
 
● 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 Breve Descripción 
Artefacto de 
Gestión 
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. 
Artefactos de 
Ingeniería 
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. 
Prototipos y pruebas de 
concepto 
Clarifican la visión y validan las ideas técnicas, como 
por ejemplo los requerimientos. 
Artefactos de 
Gestión 
Lista de Riesgos y Plan de 
Riesgos 
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. 
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 
FM
 - 
IS
I
 
 
 
 
41 de 112 
FM
 - 
IS
I
 
 
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. 
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 
¿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 
FM
 - 
IS
I
 
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 
Para nosotros, crear modelos es importante porque: 
● Construimos los planos de un sistema que nos ayudan a disminuir la complejidad deldesarrollo 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 
Principios del Modelado 
● 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. 
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 
FM
 - 
IS
I
 
¿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: 
Ejemplos de Artefactos 
Requisitos Pruebas 
Arquitectura Prototipos 
Planificación de proyectos Versiones 
44 de 112 
FM
 - 
IS
I
 
Historia Lenguaje Unificado de Modelado 
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 
FM
 - 
IS
I
 
 
 
 
 
46 de 112 
FM
 - 
IS
I
 
 
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 
● 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 
FM
 - 
IS
I
 
 
 
48 de 112 
FM
 - 
IS
I
 
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 
FM
 - 
IS
I
 
 
 
Diagrama de Actividades 
● 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 
Usos comunes 
Los diagramas de actividades se utilizan para modelar los aspectos dinámicos de un sistema. 
50 de 112 
FM
 - 
IS
I
 
● 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. 
Ejemplo: 
51 de 112 
FM
 - 
IS
I
 
 
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 responsabilidadesde 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 ​estado 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 
FM
 - 
IS
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 ​acciones 
paralelas​ que se llevan a cabo en el proceso. 
53 de 112 
FM
 - 
IS
I
 
 
54 de 112 
FM
 - 
IS
I
 
Ejemplo 
Descripción del proceso de negocio - Alquilar Películas 
 
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 
FM
 - 
IS
I
 
56 de 112 
FM
 - 
IS
I
 
57 de 112 
FM
 - 
IS
I
 
 
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 
FM
 - 
IS
I
 
Diagrama de Transición de Estados 
● 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. 
59 de 112 
FM
 - 
IS
I
 
Partes del Diagrama de Estados 
Contexto del objeto 
 
● 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​. 
60 de 112 
FM
 - 
IS
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. 
 
61 de 112 
FM
 - 
IS
I
 
Partes del estado 
 
Pseudoestados 
● 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 
FM
 - 
IS
I
 
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 
● 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. 
 
 
63 de 112 
FM
 - 
IS
I
 
 
 
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 
● 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. 
 
64 de 112 
FM
 - 
IS
I
 
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 comprenderla ​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 
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 
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 
FM
 - 
IS
I
 
 
Fuentes de información para conocer el vocabulario del dominio del problema 
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 
● 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 
FM
 - 
IS
I
 
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. 
¿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 
FM
 - 
IS
I
 
● 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 
● 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. 
 
 
 
 
 
68 de 112 
FM
 - 
IS
I
 
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 
● 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. 
69 de 112 
FM
 - 
IS
I
 
Ejemplos del dominio de Interés 
 
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 
FM
 - 
IS
I
 
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. 
Definición 
 
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 
FM
 - 
IS
I
 
Propiedades Emergentes de los sistemas 
Existen 2 tipos: 
● Propiedades emergentes funcionales​: Aparecen cuando todas laspartes 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. 
Clasificación de los requerimientos no funcionales 
 
Requerimientos de producto 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. 
72 de 112 
FM
 - 
IS
I
 
 
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 
FM
 - 
IS
I
 
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: 
 
R-RE 1 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] 
Fiabilidad 
● 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. 
 
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 
FM
 - 
IS
I
 
[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 
 
R-Std 1 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 
 
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 
FM
 - 
IS
I
 
● 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 
● Para especificar los requerimientos funcionales utilizamos el lenguaje natural estructurado, anotando losdetalles 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 
 
Ejemplo: 
 
● 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 
FM
 - 
IS
I
 
● 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 
● 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" 
Ingeniería de los Requerimientos 
Proceso de la Ingeniería de Requerimientos 
 
77 de 112 
FM
 - 
IS
I
 
 
Definición 
La Ingeniería de requerimientos son los procesos de descubrir, analizar, documentar y verificar los 
requisitos del sistema, de forma sistemática y repetible. 
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. 
78 de 112 
FM
 - 
IS
I
 
Documento Especificación de Requerimientos del Sistema 
 
Documentar los requisitos 
● 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. 
 
● 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 
FM
 - 
IS
I
 
Audiencia del documento de los requerimientos 
Emisores 
● Analistas de Sistemas 
● Ingenieros en Sistemas de 
Información 
 
Especificación de Requerimientos 
Receptores 
● Desarrolladores de 
Software 
● Ingenieros en Sistemas de 
Información 
● Ingenieros desarrolladores 
● Ingenieros probadores 
 
Lectores 
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. 
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. 
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 
FM
 - 
IS
I
 
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. 
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 
FM
 - 
IS
I
 
Requerimientos de Software 
● Son la declaración oficial de​ qué deben implementar los desarrolladores del sistema​. 
● Incluyen tanto los ​requerimientos del usuario​ como los ​requerimientos 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: 
Ref 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. 
Estándar IEEE 830-1998 
● 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​. 
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 
FM
 - 
IS
I
 
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 Significado 
Correcta ● 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. 
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 
FM
 - 
IS
I
 
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] 
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 
FM
 - 
IS
I
 
 
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 
● 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. 
 
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 
FM
 - 
IS
I
 
○ Los stakeholders 
○ Especificación de sistemas similares. 
Actividades para obtener requerimientos 
1. Descubrir los requerimientos 
a. Interactuar con los stakeholders utilizando técnicas de comunicación. 
2. Clasificar y organizar los requerimientos. 
3. Ordenar los requerimientos por prioridades. 
4. Documentar los requerimientos 
Modo de trabajo en la obtención de los requerimientos 
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 Breve descripción 
Lectura de material disponible Leer información a cerca del entrevistado y la organización. 
86 de 112 
FM
 - 
IS
I
 
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 
Es el medio más directo para obtener información de 
lo que hacen los stakeholders 
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. 
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. 
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. 
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 
FM
 - 
IS
I
 
○ ¿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. 
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 
FM
 - 
IS
I
 
Ú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. 
Observación participativa 
● El analista temporalmente realiza las actividades del grupo 
● Puede ser útil al estudiar las actividades de una organización complicada. Con esta técnica, elanalista puede "aprender haciendo". Se puede aprender mucho en corto tiempo, a pesar de 
poder sentirse un intruso. 
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 Registrar el pedido del cliente. 
Descripción 1. El cliente envía una orden de pedido que incluye los datos del cliente y los datos de 
los productos solicitados. 
2. 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. 
3. 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 
FM
 - 
IS
I
 
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​. 
Factores humanos a considerar en la elaboración del prototipo 
Factores Descripción 
Memoria limitada 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. 
Incremento del estrés 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 
FM
 - 
IS
I
 
● 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. 
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 
FM
 - 
IS
I
 
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 
● 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. 
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 
FM
 - 
IS
I
 
○ 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 
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. 
Iteración el proceso de desarrollo del prototipo 
● 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. 
 
93 de 112 
FM
 - 
IS
I
 
 
94 de 112 
FM
 - 
IS
I
 
 
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 
● 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 ​que 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 
FM
 - 
IS
I
 
*​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. 
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 
FM
 - 
IS
I
 
Elementos del diagrama de Casos de Uso: Actores 
 
 
Actores Ejemplos 
Roles de personas 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 
Sistemas informáticos que pertenecen a la 
organización 
Sistema de control de la producción 
Sistema de alumnos 
Sistema de RRHH 
Otras organizaciones 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 
FM
 - 
IS
I
 
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? 
*​ Sugerencia: El nombre de las calles del Diagrama de actividades nos ayudan a descubrir actores 
 
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 
FM
 - 
IS
I
 
 
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 
● 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: 
Sistema de Terminal de Punto de Venta -TPDV- 
 
Un 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 
FM
 - 
IS
I
 
ii. Evento 2 
iii. Evento n 
b. 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: … 
 
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
 - 
IS
I
 
Procedimiento Básico para definir los Casos de Uso 
 
101 de 112 
FM
 - 
IS
I
 
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 de Casos de Uso Modelo del Análisis 
Se escribe con el lenguaje del cliente, es decir con 
lenguaje natural​. 
Se escribe con el lenguaje de los ​desarrolladores​. 
Representa la ​vista externa​ del sistema. Representa la ​vista interna ​del sistema. Utiliza clases 
conceptuales ​borde, control y entidad 
Puede contener redundancias, inconsistencias​, etc 
entre requisitos 
No debería contener redundancias, inconsistencias​, 
etc, entre requisitos. 
Captura la funcionalidad del sistema​, incluida la 
funcionalidad significativa para la arquitectura delsistema 
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. 
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 
FM
 - 
IS
I
 
 
 
 
 
 
 
 
 
 
 
 
 
103 de 112 
FM
 - 
IS
I
 
Reglas para tener en cuenta 
 
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 
104 de 112 
FM
 - 
IS
I
 
 
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ña- 
105 de 112 
FM
 - 
IS
I
 
3. Retornar al paso 4 del flujo normal de los eventos. 
__________________ 
 
¿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 
FM
 - 
IS
I
 
 
 
107 de 112 
FM
 - 
IS
I
 
 
 
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 iniciales- 
● Revisiones de los requerimientos. 
Bibliografía 
● 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 
Validación de Requerimientos 
● 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. 
108 de 112 
FM
 - 
IS
I
 
 
¿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. 
109 de 112 
FM
 - 
IS
I
 
Verificar los requerimientos 
● 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. 
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 
 
Los conflictos, contradicciones, errores y omisiones en 
los requerimientos se registran formalmente en el 
informe de revisión. 
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) 
110 de 112 
FM
 - 
IS
I
 
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 
Correcto 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. 
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 cumplecada 
uno de los requerimientos especificados. 
Reducir la posibilidad de discusión entre el cliente y los desarrolladores. 
111 de 112 
FM
 - 
IS
I
 
Ejemplo lista de verificación o checklist 
Resumen de técnicas para verificar y validar los requerimientos 
 
Técnicas Descricpción 
Revisiones 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. 
 
112 de 112 
FM
 - 
IS
I