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 comprender