You are on page 1of 88

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

La Universidad Católica de Loja
MODALIDAD ABIERTA Y A DISTANCIA

Departamento de Ciencias de la Computación y Electrónica
Sección Ingeniería del Software y Gestión de Tecnologías de la
Información

Fundamentos de Ingeniería de
Software

Guía didáctica
4 créditos

Titulación
¡ Informática

Ciclo

V

Autores:

Ing. Marco Patricio Adab Espinoza
Ing. Danilo Rubén Jaramillo Hurtado

18505

Asesoría virtual:
www.utpl.edu.ec

FUNDAMENTOS DE INGENIERÍA DEL SOFTWARE
Guía didáctica

Marco Patricio Abad Espinoza
Danilo Rubén Jaramillo Hurtado
Corrector de estilo: Carlos Vacacela
UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA
CC Ecuador 3.0 By NC ND
Diagramación, diseño e impresión:
EDILOJA Cía. Ltda.
Telefax: 593-7-2611418
San Cayetano Alto s/n
www.ediloja.com.ec
edilojainfo@ediloja.com.ec
Loja-Ecuador
Primera edición
Novena reimpresión
ISBN físico-978-9942-08-019-6
ISBN digital-978-9942-04-218-7

Esta versión impresa y digital, ha sido acreditada bajo la licencia Creative Commons Ecuador 3.0 de reconocimiento -no comercial- sin obras
derivadas; la cual permite copiar, distribuir y comunicar públicamente la obra, mientras se reconozca la autoría original, no se utilice con fines
comerciales ni se realicen obras derivadas. http://www.creativecommons.org/licences/by-nc-nd/3.0/ec/
Abril, 2016

2. Índice
2. Índice................................................................................................................................. 3
3. Introducción.................................................................................................................... 5
4. Bibliografía..................................................................................................................... 6
4.1. Básica......................................................................................................................... 6
4.2. Complementaria......................................................................................................... 6

5. Orientaciones generales para el estudio........................................................... 8
6. Proceso de enseñanza-aprendizaje para el logro de competencias..... 11
PRIMER BIMESTRE
6.1.
6.2.
6.3.
6.4.

Competencias genéricas............................................................................................. 11
Planificación para el trabajo del alumno.................................................................... 11
Sistema de evaluación de la asignatura (primero y segundo bimestres).................. 13
Orientaciones específicas para el aprendizaje por competencias............................... 14

UNIDAD 1: INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE................................................... 14
1.1. La naturaleza del software......................................................................................... 15
1.2. La naturaleza única de las webapps.......................................................................... 16
1.3. El proceso del software.............................................................................................. 17
1.4. La práctica de la ingeniería de software..................................................................... 18
Autoevaluación 1.................................................................................................................. 20

UNIDAD 2: PROCESOS DE CONSTRUCCIÓN DEL SOFTWARE........................................................ 21
2.1. Ingeniería de requerimientos...................................................................................... 22
2.2. Preparar el camino a la obtención.............................................................................. 24
2.3. Indagación de los requerimientos............................................................................... 25
2.4. Desarrollo de casos de uso......................................................................................... 25
2.5. Elaboración del modelo de los requerimientos........................................................... 27
2.6. Validación de los requerimientos................................................................................ 27
2.7. Diseño en el contexto de la ingeniería del software.................................................. 28
2.8. El proceso de diseño................................................................................................... 29
2.9. Conceptos de diseño.................................................................................................. 29
2.10. Modelo del diseño...................................................................................................... 30
Autoevaluación 2.................................................................................................................. 31

UNIDAD 3: CICLOS DE VIDA DEL SOFTWARE............................................................................. 32
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.

Un modelo general de proceso.................................................................................. 32
Evaluación y mejora de procesos............................................................................... 33
Modelos prescriptivos................................................................................................ 34
Fases del proceso unificado........................................................................................ 36
Modelo de proceso personal y de equipo................................................................... 36
¿Qué es un proceso ágil?.......................................................................................... 37

3.7. Programación extrema............................................................................................... 38
3.8. Otros modelos ágiles.................................................................................................. 39
Autoevaluación 3.................................................................................................................. 41

SEGUNDO BIMESTRE
6.5. Competencias genéricas............................................................................................. 43
6.6. Planificación para el trabajo del alumno.................................................................... 43
6.7. Orientaciones específicas para el aprendizaje por competencias............................... 45

UNIDAD 4: APLICACIÓN DE UN MODELO DE PROCESOS RUP..................................................... 45
4.1. Mejores prácticas de la ingeniería del software......................................................... 45
4.2. Características principales del RUP............................................................................. 50
4.3. Navegando por el proceso unificado de desarrollo..................................................... 52
4.4. Desarrollo de software con el Proceso Unificado...................................................... 55
Autoevaluación 4.................................................................................................................. 66

UNIDAD 5: MODELADO DEL SOFTWARE: ANÁLISIS, DISEÑO ARQUITECTURA............................... 68
5.1. Modelado de requerimientos...................................................................................... 68
5.2. Modelado basado en escenarios................................................................................ 69
5.3. Modelado UML para casos de uso............................................................................. 72
5.4. Modelado basado en clases....................................................................................... 72
5.5. Arquitectura de software............................................................................................ 74
5.6. Géneros y estilos arquitectónicos............................................................................... 74
5.7. Breve taxonomía de estilos arquitectónicos............................................................... 74
5.8. Diseño arquitectónico................................................................................................. 75
Autoevaluación 5.................................................................................................................. 76

UNIDAD 6: CALIDAD DEL SOFTWARE........................................................................................ 77
6.1. Conceptos de calidad.................................................................................................. 77
6.2. Calidad del software................................................................................................... 78
6.3. Dilema de la calidad del software.............................................................................. 79
6.4. ¿Cómo lograr la calidad del sotware?....................................................................... 79
Autoevaluación 6.................................................................................................................. 81

7. Solucionario.................................................................................................................... 82

generalmente se escucha hablar de aplicaciones basadas en la Web. por lo que adjuntamos un disco con algunas herramientas adicionales para ayudarle en ese requerimiento. la presente asignatura se ha organizado en 6 unidades distribuidas en dos bimestres con los temas siguientes: la unidad 1 estudia lo que es el software. El software y los sistemas de información constituyen hoy en día algunos de los recursos más importantes de las organizaciones. casi de manera automática. no obstante. la unidad 2 le muestra en qué consisten el proceso de desarrollo de software y se complementa con la unidad 3 en la que se estudian varios métodos de desarrollo de software conocidos como ciclos de vida. con esto concluimos el primer bimestre. sin embargo esto está muy lejos de la realidad. y no solo en el contexto empresarial sino a todo nivel. El segundo bimestre está diseñado para enseñarle a organizar sus proyectos basados en el proceso de desarrollo unificado y a personalizarlos si es necesario. tiene una valoración de 4 créditos académicos. vale acotar que podría necesitar mucha más información. y la presente asignatura se enfoca precisamente. Bienvenido al mundo de la ingeniería del software ! 5 . no obstante. Tenemos más de 10 años de experiencia en la ingeniería del software.PRELIMINARES Guía didáctica: Fundamentos de Ingeniería de Software 3. La mayoría de las personas consideran que es una actividad en la cual un programador se sienta frente al computador y empieza a producir el software. luego en la unidad 5 revisaremos algunos de los modelos importantes del proceso de construcción de software para culminar en la unidad 6 estudiando algunos principios sobre la calidad del software. y. En este sentido. Naturalmente esta área de conocimiento es demasiado amplia como para ser abarcada en una sola asignatura. en presentar los fundamentos en los que se sustenta esta disciplina para producir software de calidad. somos sus tutores y estaremos con ustedes para guiar el proceso de aprendizaje de esta asignatura. Le manifestamos nuestro deseo de que estos conocimientos les ayuden no solo a aprobar la asignatura sino les sirva en la práctica. el desarrollo de software hoy en día es una de las actividades más complicadas y que más herramientas necesita debido a la complejidad de las aplicaciones que deben desarrollarse. de modo que pueda ajustarlo a sus necesidades. hemos hecho el esfuerzo de sintetizar los aspectos más importantes que le permitirían tener una idea completa de lo que se requiere para un desarrollo profesional adecuado. Por lo tanto. los sistemas de información y la terminología básica de la ingeniería del software. no siempre se lo mira así. A los profesionales que se dedican a esta ardua labor de construir software se los conoce como ingenieros de software. sin embargo.o ciclo de la carrera de Ingeniería en Informática que se oferta en la Escuela de Ciencias de la Computación. no resulta extraño pensar que su desarrollo debe ser considerado como una de las actividades que mayor profesionalismo exige. Introducción La asignatura de Fundamentos de Ingeniería del Software es una asignatura troncal de carrera que se imparte en el 5. ubicuidad. Consideramos que el estudio de la presente asignatura le será de mucha utilidad. aplicaciones móviles etc.

Recomendamos su lectura para afianzar las bases no solo del proceso unificado. tenemos acceso gracias a un convenio académico. Roger Pressman. como universidad. y Jaramillo D. • Abad. Jacobson I. Madrid. (2003). Addison Wesley. Rumbaugh J.Guía didáctica: Fundamentos de Ingeniería de Software PRELIMINARES 4. sino también de la ingeniería del software. McGraw-Hill Interamericana de Editores. M.1. Es escrito por los propios autores del Lenguaje Unificado de Modelado que calza perfectamente en el Proceso Unificado de Desarrollo.. LojaEcuador: UTPL. Este texto es de singular importancia para el estudio de la unidad 4 de la guía didáctica. Este es un material oficial de entrenamiento de IBM Rational. Madrid. (2000). El proceso unificado de desarrollo de software. El autor del texto. Ingeniería de software: un enfoque práctico. Recomendamos su lectura sobre todo para fundamentar los principios del modelado de software. Este texto es de singular importancia para el estudio de las unidades 4 y 5 en lo relacionado al proceso unificado y al modelado de componentes de diseño. al cual. 4. (2010). Rumbaugh J. por ello debe comenzar su estudio a partir de la guía. Sin las orientaciones dadas en esta guía el proceso será complejo y extenso. Essentials of Rational Unified Process: Course Material. Bibliografía 4. • IBM Corp. (2011): Guía didáctica de Fundamentos de Ingeniería del Software. además tiene ejercicios y autoevaluaciones que lo hacen ideal para un estudiante a distancia. R. La presente guía de estudio está diseñada para orientar el proceso de enseñaza aprendizaje y se complementa con actividades y ejercicios de autoevaluación que le permitirán medir su grado de avance. Booch G. El contenido es importante para aprender el RUP y sirve de apoyo para la unidad 4. tiene mucha experiencia en el campo de la ingeniería del software. • Booch G. El lenguaje unificado de modelado.2. es escrito por los autores del Proceso Unificado de Desarrollo y presenta amplia información para aplicar de manera efectiva el proceso unificado de desarrollo a una amplia variedad de proyectos. 6 . (2006). Complementaria • Jacobson I. México. Básica • Pressman. Addison Wesley. El texto se ha seleccionado debido a que la forma como plantea los contenidos es didáctica y fácil de seguir.

C. Disponible en http://users. http://www. • Cueva. [Consulta: 15-042010] En esta dirección encuentra un ejemplo muy práctico de cómo trabajar con una documentación de especificación de requisitos.pdf. Enterprise Edition. Una aplicación para jugar al hex.es/asignaturas/facultad/lsi/ejemplorup/Requisitos. [En línea].pdf. Herramientas • Rational Rose.com/modulos/descargas/Anexo%202. html#EspCU. Análisis orientado a objetos.um. • UNIVERSIDAD DE SALAMANCA. 7 . (2003).nosololinux.uniovi. Recurso OCW • Fundamentos de Ingeniería del Software (2009). el mismo que puede ser tomado como referencia para la comprensión de los temas que se trabajan en esta asignatura.es/ ingenierias/fundamentos-de-ingenieria-del-software. Oviedo. [Consulta: 15-04-2010] En esta dirección encontrará el documento que le ayudará a comprender el modelado visual con UML. Universidad de Murcia. J.PRELIMINARES Guía didáctica: Fundamentos de Ingeniería de Software Direcciones electrónicas • López. [Consulta: 15-04-2010] Ejemplo de desarrollo software utilizando la metodología rup.es/~cernuda/pfc/aoo.pdf. procesos de desarrollo y modelado de componentes de software. http://ocw.upv. Salamanca: España.di.dsic. (2007). Disponible en http://hex. Valencia España. Disponible en http://hex. • Rational Unified Process. España. Desarrollo de un sistema para la gestión de artículos deportivos. Curso de Ingeniería de software que le servirá para complementar su estudio en los apartados de conceptos.nosololinux.com/ modulos/descargas/Anexo%202.

Se trata del Proceso Unificado de Desarrollo. El Entorno Virtual de Aprendizaje: donde podrá interactuar con sus profesores a través de una orientación del trabajo semanal. Recuerde que cuenta con su profesor tutor para la comprensión de los temas. Utilice técnicas de estudio como el subrayado.ibm. totalizan 6 puntos. damos algunos lineamientos que le ayudarán a aprovechar su tiempo y lograr mejores resultados: 1.com/developerworks/university/membership/guidelines. el mismo se detalla en la carátula de la evaluación a distancia. para ello debe familiarizarse con las formas de 8 . 4. le permiten aplicar y reforzar los conocimientos adquiridos mediante su desarrollo. además contiene ejercicios de autoevaluación que le permitirán medir su grado de comprensión y la necesidad de tutoría por parte del docente. por lo tanto. le permitirá construir modelos en UML. foros. 5. la comunicación con él será fundamental. dedique al menos 8 horas semanales. Muchos estudiantes empiezan estudiando directamente el texto. Adicionalmente usted cuenta con un DVD que contiene instaladores de dos productos de software importantes para realizar sus prácticas. su valoración es de 4 puntos que. 3. publicación de recursos. La tutoría personal: es un tiempo semanal que. desarrollo de ejercicios prácticos. cuadros sinópticos y sobre todo mapas conceptuales. Los trabajos a distancia: son actividades teóricas y prácticas que acompañan a la guía didáctica de cada una de las materias. La entrega de estos trabajos con su respectiva carátula es obligatoria y no recuperable. ambos productos los puede usar legalmente con licencia conferida por IBM Rational bajo el convenio académico. 2. Por lo tanto. Vale acotar que no todos los capítulos del texto se consideran para la asignatura y tampoco cubren todos los contenidos. pero como verá más adelante no es recomendable hacerlo. 2. El tiempo que dedique a la lectura y desarrollo de los ejercicios es fundamental.html En cuanto a la forma de trabajo. por lo que el estudio debe hacerse siguiendo las instrucciones de la guía didáctica. Los detalles del acuerdo se pueden visualizar en la URL http://www. para ello se publicará un horario en el cual podrán asistir personalmente o contactarse vía telefónica. sumados a la calificación de participación en el EVA. lo cual significa que si no entrega alguno de estos no tendrá opción a la evaluación presencial. uso de mensajería electrónica para resolver inquietudes. El texto básico: le servirá para desarrollar los contenidos principales conforme se lo indica en la guía didáctica. todo este trabajo tendrá una valoración de 2 puntos. Orientaciones generales para el estudio Para el estudio de la presente asignatura el estudiante contará con las siguientes herramientas básicas: 1. y debe enviarlos a su profesor. 6. edición 2003. La guía didáctica: le orientará sobre cómo y qué temas estudiar. como profesores. dedicamos para atender las inquietudes en relación a los contenidos o desarrollo de trabajos. es una aplicación que se instala en la máquina y la herramienta Rational Rose Enterprise.Guía didáctica: Fundamentos de Ingeniería de Software PRELIMINARES 5.

En caso de que su resultado no sea satisfactorio le sugerimos volver a revisar los temas y acudir a su tutor para aclarar sus dudas. Este ícono se usará para solicitarle la lectura de una sección del texto básico. ya sea por teléfono (consultar horario de tutoría). En el caso de la presente asignatura usaremos parte de este material. por lo tanto trate de cumplir con estas según se lo indica. email. para ello requiere acceso a Internet. en este sentido intentamos que estas autoevaluaciones tengan respuestas no triviales de modo que si usted tiene dudas. por lo que su desarrollo es de suma importancia para afianzar el proceso de enseñanza aprendizaje. Cuando encuentre este ícono se le solicitará que realice una actividad de autoevaluación que le permitirán medir su nivel de asimilación. chat. bibliotecas digitales y también la documentación que su profesor le acerca a través del EVA. y otras herramientas tecnológicas. sino solamente las partes indicadas en los lugares donde encuentre este ícono. Utilizaremos este ícono para darle orientaciones específicas o técnicas respecto al desarrollo de ejercicios. Una vez resueltas las autoevaluaciones de la guía didáctica puede comparar sus respuestas con el solucionario que consta al final de la guía.PRELIMINARES Guía didáctica: Fundamentos de Ingeniería de Software comunicación que tiene. 3. Al final encontrará un solucionario. actividades o sobre algún contenido específico de la asignatura. En la guía didáctica encontrará la planificación del trabajo con las actividades sugeridas para cada unidad. 9 . Utilizaremos este focalizador para solicitarle el uso de un recurso OCW (Open Course Ware) que son recursos educativos diseñados por varias universidades y que están disponibles para su uso libre por parte de estudiantes y profesionales que deseen estudiarlos. o actividades en el computador. Recuerde que no debe leer todo el texto. 4. Recuerde además que existe una variada información en Internet. acuda a la tutoría o a algún otro medio que le permita solucionarla. Las autoevaluaciones que se presentan al final de cada unidad así como las que constan en el texto básico le ayudarán a comprender de mejor manera cada uno de los temas. a lo largo del presente documento encontrará los siguientes focalizadores: Se usará para reflejar actividades de trabajo personal que incluye desarrollo de ejercicios. Como ayudas. Este focalizador se usará para llamar su atención sobre aspectos generales de la materia o consideraciones al respecto del origen del contenido y su utilidad. distribuidas en el tiempo.

En el presente cuadro constan los parámetros y puntajes que se tomarán en cuenta en el primero y segundo bimestres. con la particularidad de que en la carrera de Ingeniería en Informática se incluye de manera obligatoria la participación en el EVA. Utilizamos esta imagen para sugerir el desarrollo de algunas actividades que. deberá presentarse a un examen supletorio calificado sobre 20 que reemplaza la nota bimestral correspondiente.Guía didáctica: Fundamentos de Ingeniería de Software PRELIMINARES La presencia de este ícono. si bien no forman parte de la asignatura. Estas preguntas no son evaluables. Los estudiantes aprueban cuando han logrado un mínimo de 28 puntos. en caso de que algún estudiante no obtenga una nota mínima de 14 puntos. puede ser interesante que ahonde en el tema. cada uno de los cuales se califica sobre 20 puntos. La asignatura se encuentra dividida en dos bimestres. sin embargo le resultará útil responderlas. Instrumento Trabajo a distancia: - Objetiva - Ensayo - Interacción EVA Evaluación presencial TOTAL 10 Puntaje 2 puntos 2 puntos 2 puntos 14 puntos 20 PUNTOS . denota una actividad de reflexión en base a preguntas planteadas cuya respuesta le permitirá profundizar o comprender mejor un tema. Estrategias de evaluación El sistema de estudios de la Modalidad Abierta y a Distancia de la Universidad Técnica Particular de Loja contempla los siguientes parámetros de evaluación.

La práctica de complejidad del la Ingeniería de software. Descarga y lectura del bloque 1 del recurso OCW. 6. • Compromiso con la calidad. procesar y analizar información procedentes de fuentes diversas. 11 .Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE 6. análisis y síntesis. usabilidad y seguridad de los sistemas. Reconoce los roles que las personas cumplen frente a los proyectos de desarrollo de software. El proceso del software Identifica los factores que inciden en la 1.1.1). software. La naturaleza Asocia los sistemas única de las con su nivel de webapps importancia en la organización. Planificación para el trabajo del alumno COMPETENCIAS ESPECÍFICAS Evalúa y asegura la accesibilidad. Lectura del capítulo 1 Semana 1: del texto básico como se señala en la guía didáctica 4 horas de autoestudio y complementado con las actividades de la unidad 1 de 4 horas de interacción. Competencias genéricas • Capacidad de abstracción. 1.3. • Habilidades para buscar. Desarrollo de la evaluación a distancia preguntas de la 1 a 6.2.4. La naturaleza del aplicaciones y su uso software en el mundo real. 1. la guía didáctica. • Conocimiento sobre el área de estudio y la profesión. Proceso de enseñanza-aprendizaje para el logro de competencias PRIMER BIMESTRE 6.1.2. INDICADORES DE APRENDIZAJE CONTENIDOS UNIDADES/TEMAS ACTIVIDADES DE APRENDIZAJE CRONOGRAMA ORIENTAIVO Tiempo estimado Reconoce los tipos de 1. Investigar los diferentes tipos de aplicaciones y ejemplos concretos de cada tipo (ejercicio 1. Realizar la interacción en el EVA: foro. Desarrollo de la primera autoevaluación. aplicaciones y servicios informáticos.

5.2.4.3.1. de uso. PRIMER BIMESTRE CONTENIDOS ACTIVIDADES DE APRENDIZAJE UNIDADES/TEMAS CRONOGRAMA ORIENTAIVO Tiempo estimado 2. Programación extrema. Fases del proceso software. guía didáctica. 2.7.Guía didáctica: Fundamentos de Ingeniería de Software COMPETENCIAS ESPECÍFICAS Definie requerimientos. 12 horas de interacción.4: del texto básico y desarrollo de las actividades de 12 horas de autoestudio Preparar el aprendizaje de la unidad 2 de y camino. autoevaluación correspondiente a la unidad Desarrollos de 2. Modelo proceso personal y de equipo. Lectura de los capítulos 5 y 8 Semanas 2. Desarrollar los ejercicios que se proponen en la guía. 2.7.   INDICADORES DE APRENDIZAJE Identifica requerimientos y los clasifica en funcionales y no funcionales a partir de planteamientos iniciales.2 Evaluación proyectos. distancia.8. 3. Qué es un proceso ágil. casos de uso. Desarrollo de la evaluación a Elaboración del distancia preguntas 7 a la 14. 2. desarrollo y los aplica para organizar los 3. soluciones a proyecto de desarrollo de 3. implementa.5. 2. y mejora de procesos. Iniciar el desarrollo de la El proceso de parte de ensayo del trabajo a diseño. 3.6: del texto básico conforme se señala en la unidad 3 de la 8 horas de autoestudio. Validación de los requerimientos. Abstrae casos de uso a partir de requerimientos definidos. Modelos el planteamiento de prescriptivos. 8 horas de interacción. la guía didáctica. Otros modelos ágiles. Diseño en el contexto de la Descarga y lectura del ingeniería del bloque 2 del recurso OCW.6. administra y optimiza soluciones software centralizadas. integra. Ingeniería de requerimientos. Lectura de los capítulos 2. 2. Unidades de la 1 a la 3 Repaso general de la materia. Modelo del diseño.3. 12 8 horas de autoestudio y 8 horas de interacción. 3.1 Un modelo principios de general de cada modelo de proceso. unificado.6. Semanas 7 y 8 Desarrollo del cuestionario de repaso en el EVA.3. Conceptos de diseño. Actividades en el EVA: cuestionario. 2. Indagación de los Desarrollo de la requerimientos. software. modelo de los requerimientos.8.10. 2. . Aplica los principios del desarrollo ágil en 3. distribuidas o soluciones Web. diseña. 3. Reconoce los componentes de un caso de uso.3 Semanas 5. Identifica los 3. Manejar organizaciones de tecnología y administración de Recursos de TI.4. 2.9.   Termina el desarrollo del trabajo a distancia. Desarrollo de autoevaluación. Modela componentes de software a partir del modelo de casos 2. Tareas en el EVA.

pero debe responderlas con el fin de autocomprobar su proceso de aprendizaje. Autoevaluación * 2. Heteroevaluación Contribución en el trabajo colaborativo y de equipo X Presentación. debe desarrollarla y entregarla en su respectivo centro universitario. Señor estudiante: Tenga presente que la finalidad de la valoración cualitativa es principalmente formativa. puntualidad.Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE 6. ** Recuerde que la evaluación a distancia consta de dos partes: una objetiva y otra de ensayo. que equivale al 70%. 13 .3. orden y ortografía X Dominio del contenido X X X Investigación (cita fuentes de consulta) X Aporta con criterios y soluciones X X X X Puntaje 10% 20% 30% 2 4 TOTAL 6 70% 14 20 puntos Actividades presenciales y en el EVA PORCENTAJE Máximo 1 punto (completa la evaluación a distancia) Análisis y profundidad en el desarrollo de temas Estrategia de aprendizaje Conocimientos Emite juicios de valor argumentadamente Para aprobar la asignatura se requiere obtener un puntaje mínimo de 28/40 puntos. responsabilidad X X X Esfuerzo e interés en los trabajos X X X 3. * Son estrategias de aprendizaje. Sistema de evaluación de la asignatura (primero y segundo bimestres) Formas de evaluación Interacción en el EVA Prueba objetiva y de ensayo X X X X Cumplimiento. Coevaluación Parte de ensayo X X Respeto a las personas y a las normas de comunicación X X Creatividad e iniciativa Habilidades Evaluación presencial X Comportamiento ético Competencia: criterio Actitudes Evaluación a distancia ** Parte objetiva 1. no tienen calificación.

Orientaciones específicas para el aprendizaje por competencias UNIDAD 1: INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE El software en la actualidad es considerado como un elemento clave en las organizaciones. .Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE 6. Sin embargo. no avance si no logra comprender el contenido básico de la asignatura. Lenguaje de Diagramas entidad-relación. instituciones. Scripts para creación de base de datos. Manuales técnicos.. los cuales pueden variar de acuerdo a la metodología y al tipo de proyecto con el que trabaje: Tabla 1. Observación directa. industrias. pues casi todos hemos trabajado con un procesador de texto. Diagrama de clases Aplicación construida. programación. como futuro ingeniero en informática. 14 CONSTRUCCIÓN Diagramas de flujo de datos. casos de uso. etc. Etapas y artefactos genéricos para el desarrollo de aplicaciones de software LEVANTAMIENTO DE INFORMACIÓN ANÁLISIS DISEÑO Encuestas. desarrollar software con la urgencia y calidad requeridas es un problema difícil de resolver a pesar de las tecnologías y herramientas de las que se dispone. PRUEBAS E IMPLEMENTACIÓN Plan de pruebas.1. La evolución del software en los últimos años ha sido muy significativa convirtiéndose en la solución a múltiples problemas de procesamiento de información hasta ser considerada también como herramienta especializada. En esta asignatura se expondrán algunas actividades que le ayudarán. que serán de mucha utilidad para comprender los apartados siguientes.1 presenta una idea de las etapas que se pueden desarrollar para construir una aplicación. Requerimientos modelados. Requerimientos Especificación de Arquitectura. Manual de usuarios. Estimado estudiante: inicie entonces con el estudio de los conceptos generales de la ingeniería del software (IS). La tabla 1. el hogar. etc. así como sus artefactos. su contabilidad. Instaladores. Plan de implementación. a desarrollar software de calidad y en los tiempos que se planifica. una hoja electrónica y la mayoría de pequeños negocios cuentan ya con programas donde llevan el control de sus ventas.4.

La naturaleza del software Revise el apartado 1. los cuales han tenido un proceso de desarrollo. lo que necesita es que su tareas diarias se las organice de mejor manera. puede buscar estos recursos tanto en el texto como en Internet. sería importante que realice la lectura detallada de las mismas. Es conveniente que encuentre el concepto de software que se presenta en el texto básico. del mercado de las aplicaciones para teléfonos celulares se ha desarrollado a una escala increíblemente alta. pruebas y mantenimiento que le ha permitido que sea utilizado por un usuario. C++ .1. vehículos. que al final de todo. software que permite desarrollar nuevo software como java. Linux etc. la respuesta es la siguiente: software es realizado por un ingeniero de software. Si ya realizó la lectura de estas características. y cientos de tiendas más de aplicaciones para Android. microondas.1 “La naturaleza del software” aplique la técnica del subrayado. entonces proceda a responder la pregunta: ¿qué es el software de computadoras?. Photoshop. sistema operativo Windows. Un concepto que se va a necesitar mucho en esta asignatura es el de software. etc. en este mar de aplicaciones. hoy en día. es posible encontrar en las tiendas de aplicaciones móviles como Apple Store. En el texto básico se presentan tres características del software que lo hace diferente al hardware. de los expuestos. juegos. se lo encuentra en celulares. Mac OS.. son programas que se ejecutan en las computadoras. si asocia la palabra software con las funciones del computador y los usos que se le pueden dar en los diferentes ámbitos. . mejor aún. a la medida para un usuario final. ante esta interrogante. como ejemplo de este tipo de software se puede mencionar un sistema de facturación para una farmacia. cajeros automáticos y todo lo que usted pueda imaginar.. Conteste las siguientes preguntas: ¿cuáles cree que podrían ser las causas para que exista la diferencia entre la curva idealizada del software y la curva real del mismo? ¿Se desgasta el software? ¿Por qué? Se decía en un inicio que el software como tal existe en cualquier lugar y dispositivo imaginable. Excel. entenderlo. Ahora ya tiene claro la definición de software y.. hornos. los desarrolladores los utilizan para realizar nuevo software. surge la interrogante: ¿qué dominios de aplicaciones se tiene que construir? 15 .PRIMER BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software 1.net. desde el dispositivo más simple como un reloj digital hasta los sistemas de lanzamientos de naves espaciales de la NASA. los últimos son conocidos como lenguajes de alto nivel. es momento de hacer algo con esta información. de ser posible compararlo con el de otros autores para una mejor comprensión. OVI de Nokia. etc. Se dice también que es la parte lógica de un sistema de computación o la parte suave. Con estos antescedentes se puede hablar de software de aplicaciones como Word. Autocad. televisores. puesto que beneficiará la comprensión de este tema.

Este tipo de aplicaciones presenta un grupo primordial de atributos que pueden ser revisados en el apartado 1.2. que hace referencia al número de usuarios conectados al mismo tiempo a una aplicación. Un tema que no se debe olvidar y por la naturaleza de las organizaciones es el 1.2. también son un apoyo para las funciones básicas del negocio. debe ser tomado en consideración por los equipos de desarrollo de cada una de las empresas.Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE Ejercicio 1. La naturaleza única de las webapps Se debe tener claro el término webapps y cómo se lo va a utilizar en esta asignatura. Naturaleza de las WEBAPP del texto básico donde se encontrará la concurrencia. son modificados continuamente y a pesar de dar problemas de actualización.1 1. hemos visto sitios de interés que permiten realizar búsqueda de automóviles donde se pueden hacer pequeños cálculos para las compras o ingresar a la sección electrónica de un banco. Sistema de facturación utilizado por la tienda Supermaxi. donde se puede realizar muchas transacciones o páginas que permiten buscar información científica con tendencias y resultado de investigaciones. De los problemas y puntos por evaluar que se encuentran al final del capítulo realice el ejercicio 1. pues al estar ahí. WEKA. 2. ¿cuando encontramos sistemas heredados es mejor no hacer nada y seguirlos manteniendo? 1. Las aplicaciones Web son una categoría mencionada en el apartado de dominio del software y que en los actuales momentos están teniendo mucho auge. este tema se presenta en el texto básico. En base a la categorización de los dominios del software del texto básico realice un cuadro resumen de los dominios del software y luego clasifique los siguientes tipos de software: Portal de búsquedas de información científica: isi of knowledge.3 Software heredado.1.2. Utilice el siguiente cuadro para encontrar palabras clave por cada uno de estos atributos: 16 . será entonces: ¿una simple página Web? o ¿un sitio donde puedan estar integradas todas las aplicaciones?. Lenguaje de programación Java. Con estas explicaciones responda a las siguientes preguntas ¿Qué tipos de cambios se hacen a los sistemas heredados?. el software heredado son programas que fueron desarrollados tiempo atrás.1 y 1.

1.1 para que nos ayude a recordar: Comunicación Planeación Modelado Construcción Despliegue Figura 1.3. Ingeniería del software del texto básico.3. con la finalidad de obtener productos de calidad. Para comprender estos conceptos revise al inicio del apartado 1.Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE Rendimiento Uso intensivo de redes Concurrencias Carga impredecible Gran número de usuarios a la vez Disponibilidad Orientadas a los datos Contenido sensible Inmediatez Seguridad Estética Evolución continua Si terminó de encontrar las palabras clave. las realidades que se deben aceptar para elaborar software. El crecimiento de acceso de usuario a los sistemas. Actividades estructurales del proceso de software 17 . Una estructura general podrá constar de actividades las cuales las plasmamos en la figura 1. También aquí se mencionan cuatro temas: • • • • ¿Cómo el software está en el diario vivir de las personas? ¿Cómo las necesidades de los usuarios van aumentando cada día? La importancia de software para la toma de decisiones. ¿Qué podemos concluir de esto? ¿Se debe hacer ingeniería con el software en todas sus formas y a través de todos sus dominios? ¿Cree que esta afirmación es correcta o no? ¿Por qué? Dentro de la ingeniería del software al proceso se lo define como “conjunto de actividades. El proceso del software Recuerde la definición de ingeniería de software que se encuentra en el texto planteada por Fritz Bauer “es el establecimiento y uso de principios fundamentales de la ingeniería con objeto de desarrollar en forma económica software que sea confiable y que trabaje con eficiencia en máquinas reales”. que es de gran importancia. y claro como un futuro profesional en el desarrollo de software debe tener claro estos conceptos.1. acciones y tareas que se ejecutan cuando va a crearse algún producto del trabajo”… como lo expone el texto básico. ahora continúe entonces con el siguiente apartado. de ahí que la ingeniería de software se base en actividades estructuradas que van a ser aplicadas a todos los proyectos software. Lea detenidamente cada uno de estos apartados que se presentan en el texto básico.

donde se evalúa el progreso de desarrollo y permite tomar acciones para corregir en caso de que estas no se estén cumpliendo de acuerdo a una planificación inicial. léalas y desarrolle la autoevaluación. repitiendo estas tareas hasta llegar a la finalización del proyecto. si no hay información adecuada. ¿en qué etapa o actividad estructural estaremos entonces?. etc. ¿Cuál es su opinión? 1.4. 18 . “Práctica de la ingeniería del software” del texto la esencia plasmada en cuatro puntos que se muestran en la figura 2. Ya hemos visto y conocido las actividades estructurales del proceso de software.5. Cada proyecto se diferencia de otro debido a su naturaleza. Luego responda a lo siguiente: Suponga que está realizando un proyecto de desarrollo para la empresa DANCAR que se encarga de la compra-venta de vehículos.1.Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE Esta estructura del proceso se encuentra en el texto básico donde se detalla cada una de estas cinco actividades. entonces la actividad de control y seguimiento de proyectos diferenciará el tipo de proyecto o el proceso será el mismo para cualquier proyecto. Etapas del proceso de solución de problemas.1. y si la estructura de proceso incluye actividades que se las denomina sombrilla será conveniente entonces conocer dichas actividades: Menciono la primera: seguimiento y control de proyectos de software. ¿qué debe hacer adicionalmente en esta actividad? De acuerdo al tipo de proyecto que estemos realizando estas actividades se podrán realizar en forma interactiva de acuerdo al progreso del mismo. Por ejemplo. La práctica de la ingeniería de software Encontramos en el apartado 1. debe presentar un plan de desarrollo del mismo...Estos temas pueden ser ampliados ya que existe mucha documentación en Internet. A continuación revise las actividades sombrilla y familiarícese con cada una de ellas. Entender el problema Planear la solución Ejecutar el plan Examinar la exactitud del resultado Figura 2. si hace falta personal. una línea de especialización en esta área es la PMO. Tenemos que tener claro que cada iteración contribuirá para que el software vaya aumentando sus funcionalidades y a la vez este proceso lo irá haciendo más complejo.

y desarrolle un cuadro sinóptico que sintetice cada uno de los mitos del software. para lo cual es necesario desarrollar las autoevaluaciones de conocimiento. En varios apartados del texto se hace referencia a este ejercicio. ampliar las funcionalidades o crear un producto nuevo”1. (2010). Cit. En el texto básico se va realizando un ejercicio práctico. Revise el tema 1 de este recurso. no se olvide que cualquier inquietud debe ser conversada con su tutor. el cual debe consideralo para la comprensión de los temas. Deberá ahora usted revisar las otras etapas.PRIMER BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software Hablaremos de la primera etapa: entender el problema. Revise el apartado 1. por lo que nos conviene comprobar cuánto hemos asimilado de los temas tratados. la de adaptar un sistema de terceros. Los mitos del software son un tema muy interesante que le permitirá entender y contraponer las creencias erróneas sobre el software y el proceso que se utiliza para obtenerlo. 1 Pressman R.2. OpenCourseWare (OCW) es un ejemplo de las iniciativas que en los últimos tiempos han emergido para promover el acceso libre y sin restricciones al conocimiento. De esta manera le invitamos a revisar el recurso http://ocw. donde usted podrá ir reafirmando sus conocimientos sobre estos temas. Debemos recordar que no somos especialistas en todas las áreas y si estamos hablando de un producto especializado como por ejemplo un sistema para un dentista pues tendremos que pedir la ayuda necesaria primero para entender el tema y luego con los involucrados buscar la posible solución del problema. En lo posible siga el desarrollo de este ejercicio. 20 19 . del cliente y profesional. buscar y entender lo que realmente se quiere conseguir y luego pasar a identificar una solución del mismo. “Principios generales”.es/ingenierias/fundamentosde-ingenieria-del-software/material-de-clase. Le recomendamos que haga una revisión de estos tanto en el ámbito de la administración.5. Antes de terminar con esta unidad queremos poner en consideración este enunciado que habla mucho de la realidad del software: 1 “Todo proyecto de software se desencadena por alguna necesidad de negocios: la de corregir un defecto de un sistema existente. Ed. Hemos concluido el estudio de esta unidad.um. p. contrastándolos con lo que sucede en el mundo real.

( ) La robótica (los proyectos que se trabajan en esta área) pueden ser consideraciones como software de ingeniería y ciencias. ( ) Existen 4 etapas en la esencia de la práctica de la ingeniería del software para llegar a la solución. 4. 6. ( ) Cree que la siguiente afirmación es una preocupación sobre el desarrollo de software. los elementos que se obtuvieron ¿pueden ser reutilizados en otros proyectos similares?. Como estrategia le recomendamos que primero ubique el tema sobre el que le habla la pregunta. de igual manera. Ir a solucionario 20 . ( ) Se puede decir que el software es un proceso dual. La aplicación de las mismas puede variar en su orden. ( ) Las actividades sombrilla son complementadas por actividades estructurales del proceso de software. ( ) La ingeniería de software es una tecnología con varias capas. 5. ubique la información necesaria en el texto o en la guía didáctica y fundamente su respuesta. 9. 8. o sea que primeramente es un producto y que luego es una herramienta para entregar otro producto. 2. ( ) Los mitos del software que se presentan han desencadenado que administradores y trabajadores se equivoquen aun cuando el conocimiento del software avanza. 7. ( ) La ingeniería de requisitos está orientada a trabajar de forma conjunta entre las personas involucradas en el proyecto antes de empezar el desarrollo del mismo.Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE Autoevaluación 1 Lea detenidamente cada una de las preguntas planteadas en la siguiente tabla y determine si la proposición es verdadera o falsa. ( ) Cuando se ha resuelto un problema. 10. ( ) Si tenemos un proyecto de software y un proyecto de manufacturación podemos realizar una administración de los mismos. 1. ¿El control de avance del proyecto se ha vuelto muy complicado? 3.

De no ser así se debe realizar una especificación detallada de las alternativas que se han seleccionado además de tener una definición de la planificación inicial del proyecto. Hasta ahora ya se ha realizado una inversión en un equipo para realizar el estudio de factibilidad. la empresa podrá adoptar estos cambios. en el cual se establece si la organización cuenta con la tecnología (servidores. entonces nos centraremos en el proceso de obtención de requerimientos para iniciar el proyecto. existen leyes o reglamentos que pudieran invalidar el proyecto o si se sustentan en el reglamento interno de la organización. para lo cual nos ayudaremos con técnicas de recolección de información. A partir de esto tendremos un listado de las necesidades para realizar un estudio de factibilidad del proyecto que comprende los siguientes aspectos: • Económico que busca establecer cuáles serán los beneficios frente a la inversión realizada. Luego de haber realizado estas tareas. calendarios. El proceso comienza con la recolección de información sobre el proyecto a desarrollar y determinar cuál es el nivel de comprometimiento que hay de los directivos de la organización. planes de trabajo. La planificación inicial podría identificar aéreas de riesgo. • Operativo. estas deben ser evaluadas a través de un análisis y un estudio que nos permita determinar la factibilidad de ejecutar el mismo. Comencemos el estudio de la presente unidad. 21 . o determinar un desarrollo interno o externo del mismo. con el tema PRINCIPIOS QUE GUÍAN LA PRÁCTICA del capítulo 4 del texto básico. técnicas de comunicación entre los componentes del proyecto. forma de interactuar con el cliente. en este sentido hoy en día pesan mucho las normativas ambientales. Para ello se vale de técnicas de evaluación financiera de proyectos o modelos económicos como análisis de valor ganado o la tasa interna de retorno. luego elabore un mapa conceptual sobre estos principios. • Técnico. maquinas) • Legal. Las alternativas que se pueden encontrar luego del estudio de viabilidad pueden determinar la compra de un producto ya comercial y no esperar mucho tiempo en el desarrollo.PRIMER BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software UNIDAD 2: PROCESOS DE CONSTRUCCIÓN DEL SOFTWARE ¿Cómo inicia un proyecto? Si bien un proyecto de software nace con la idea de solventar unas necesidades. estos gastos no deben ser un impedimento para que la empresa desista de realizar el proyecto por cualquiera de los factores revisados. presupuestos.

p.Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE Ahora que ya conoce los principios empecemos el estudio con dos temas importantes. es importante describir y detallar en qué consiste la ingeniería del software para la consolidación de cualquiera de los proyectos que se emprenda. Una mala práctica por parte de los programadores es el pretender escribir código sin información ni insumos suficientes para poder hacerlo. Cit. a estos aspectos se les llama ingeniería de requisitos. En la figura 2. 2 “ENTENDER LOS REQUERIMIENTOS DE UN PROBLEMA ES UNA DE LAS TAREAS MÁS DÍFICILES QUE ENFRENTA EL INGENIERIO DE SOFTWARE”2. esto le ayudará a comprender este tema. Siempre que vamos a desarrollar una determinada aplicación o un sistema para nuestros clientes. técnicas y herramientas que permiten mantener y documentar las necesidades o requisitos generales para el desarrollo de estas aplicaciones. Realice una lectura de cada una de las tareas de la ingeniería de requisitos. métodos y herramientas que las personas dedicadas al desarrollo de software deben aplicar durante el ciclo de vida.1. Los grandes sistemas software constituyen actualmente un elemento común en nuestra sociedad. el primero es la obtención de los requerimientos (su modelado en la unidad 5) y el proceso de diseño que se tiene que cumplir para la construcción del software. Descripción del sistema Modelado de análisis Modelado del diseño Figura 2. convirtiéndose día a día en imprescindibles para la industria. estas tareas las encuentra en el apartado 5. 2. Por tanto. elaboración. conceptos.1.1 podemos ver a la ingeniería de requerimientos ayudando en la descripción del sistema y también siendo la base para el diseño del mismo. estas son: concepción. Ingeniería de requerimientos La práctica de la ingeniería de software consta de principios. indagación. Es importante entonces entender lo que el cliente desea antes de comenzar a diseñar (modelar el diseño) o construir (etapa de codificación con una herramienta de programación) un software. 101. “Ingeniería de requerimientos”. validación y administración. Paso de necesidades al modelo de diseño. es un grave error querer construir algo luego de la primera entrevista con un cliente o usuario. 2 Pressman R. métodos. Ed.1. ponemos en marcha principios. el comercio y las personas. negociación. (2010). 22 . especificación.

la de validación. Del resultado de este proceso podemos llegar a su validación determinando si: • • El modelo que se obtiene es lo que el cliente pide. Las especificaciones nuevas que se han realizado satisfacen al cliente.com/ modulos/descargas/Anexo%202. Esta etapa es de suma importancia si no se quiere correr el riesgo de realizar una mala implementación debido a que no se hizo una buena especificación. Al existir versiones de prueba de esta herramienta sería recomendable que usted. donde encontrará un documento de especificación de requerimientos que le ayudará a comprender cuál es el proceso que se debe seguir en esta etapa. Cuando estamos hablando sobre la mala definición de la frontera del sistema ¿podría decirnos a qué tarea nos referimos?. donde entendemos como validación de los requisitos al proceso de comprobación si dichos requisitos son correctos. Todo esto se verá reflejado tanto en la calidad del software como en el costo. Entonces se necesitará administrar esto para lo cual existen herramientas automatizadas que nos permiten comprobar la trazabilidad. hablaremos de una de estas tareas. Otra de las actividades es la administración de los requerimientos para software. puesto que se deberá corregir el sistema. las consiga desde Internet y las trabaje. ya que estos cambian constantemente y su modificación será a través de toda la vida del sistema. como por ejemplo Requisite Pro.PRIMER BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software Ahora bien.pdf. De esta manera es fundamental que al terminar la etapa de modelado de requerimientos se realice el proceso de comprobación mediante una comparación de las conversaciones iniciales que se realizaron con las especificaciones que se obtuvieron.nosololinux. A continuación se presenta también una plantilla que se puede utilizar para la especificación de los requisitos: 23 . En este apartado podemos revisar la siguiente dirección electrónica: http://hex.

etc.1. Escuchar a todos y seleccionar los diferentes puntos de vista. Entrada 3.2. 24 . Propósito 1. Alcance 1. siglas y abreviaturas 1. Requisito Funcional 2. Interfaces de comunicaciones 3. Referencias 1.2.1.2.4. donde aprenderá los fundamentos que sustentan el proceso de requerimientos. 3. Restricciones generales 2. Establecer las bases.2. Contenido 1. Otros requisitos 3.1. es decir difundir qué se va hacer a los miembros de la organización 2. Si vamos a trabajar el proceso de obtención de requerimientos se debe: 1.1. 6.1. o sea posibles candidatos. Establecer un diálogo anterior para que las personas estén preparadas y de ser posible darles una idea del tema que se va a tratar.1. La historia de la revisión 2. es decir todos quienes participen.4.5.1.2. Suposiciones y dependencias 3.2.3.2. “Establecer las bases” del texto básico. Interfaces de hardware 3. 5. Proceso 3.5.2.1. Descripción general 2.1.4. Atributos de calidad 3.5. Interfaces del usuario 3. Requisito funcional 1 3. Interfaces de software 3. Definiciones.1.1.2.3. Requisitos específicos 3. Pedir la colaboración de los participantes en el proyecto. Vista panorámica 2. Características del usuario 2.3.1.2. Salida 3.Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE Plantilla de IEEE para las especificaciones de requisitos de software. Funciones del producto 2. Preparar el camino a la obtención Revise el apartado 5.1.1. 4. Perspectiva del producto 2.3.4. 3. Requisitos de rendimiento 3. Requisitos de la Interfaz Externos 3.1. Introducción 3.4. Comenzar con preguntas de tipo general.3.1.6. Hacer una lista de las personas que se beneficiarán de forma directa o indirecta. Introducción 1.2.2. Requisitos funcionales 3.

Si ya ha revisado estos temas vamos a listar algunas actividades que usted debe corroborarlas: • En las reuniones de trabajo participan los stakeholders y los ingenieros de sistemas. Indagación de los requerimientos Podemos mencionar que en este proceso vamos a averiguar los posibles requerimientos. combina elementos de la solución del problema. Algunos tópicos a considerar: 25 . o sea vamos a hacer un análisis preliminar de los requerimientos. En los casos de uso se narra una interacción entre el usuario final y el sistema. Siendo fases primordiales dentro del proceso de desarrollo de software estos temas deben ser revisados en el apartado 5. 2. • Cada vez que se van recabando los requerimientos se tiene más clara la visión de cómo serán las características del sistema.PRIMER BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software Continuemos con el ejemplo de la empresa DANCAR que se encarga de la compra-venta de vehículos. además liste posibles preguntas que usted realizaría y qué estrategia utilizará. Despliegue de la función de calidad. el mismo que cuenta con 3 sucursales en la ciudad y la contabilidad se la lleva en cada una de ellas. La indagación de los requerimientos. Desarrollo de casos de uso Un caso de uso describe el comportamiento del sistema en distintas condiciones. “Indagación de los requerimientos” del texto básico. • En función del tamaño del sistema. Indagación de los productos de trabajo. los productos de trabajo generado durante la indagación varían. Encontrará entonces los siguientes temas: • • • • Recabación de los requerimientos en forma colaborativa. es recomendable la participación del equipo de trabajo para la correcta identificación de las necesidades y de los elementos que permitan la solución del problema. formales y emocionantes. • Existen tipos de requerimientos como son los requerimientos normales. Lo primero que debemos hacer para escribir un caso de uso es identificar ACTORES que estarán involucrados. Elabore una lista de cuáles serían los posibles participantes en el proceso de obtención de requerimientos. • Para mejorar la captura de requerimientos de forma colaborativa el documento que se analizará en la reunión debe ser repartido con anterioridad.3. Escenarios de uso. 2.3.4. • Para una mayor explicación sobre un servicio se puede escribir miniespecificaciones.

A continuación vamos a revisar un ejemplo de plantilla para la especificación de caso de uso y una breve descripción de cada uno de sus componentes. realizar el caso de uso [caso de uso]} … … … Precondición Secuencia normal Postcondición Excepciones Rendimiento Frecuencia Importancia Urgencia Comentarios 26 q El sistema deberá realizar la/s acción /es descrita/s en {los pasos [primer paso] al [último paso]. Un actor es cualquier cosa que se comunique con el sistema. Todo actor tiene uno o más objetivos cuando utiliza el sistema. un actor representa una clase de entidades externas. quedaría bien} {inmediatamente. Un actor no necesariamente es un usuario final. realizar el caso de uso [caso de uso]} 2b Si [Situación que produce una alternativa] el sistema deberá {<acción a realizar>. Los actores representan los papeles que desempeñan las personas. puede esperar} <otras consideraciones en formato libre> . Un usuario final puede tener varios papeles. … n …. realizar el caso de uso [caso de uso]} … …. <postcondición del caso de uso> Paso Acción p En el caso de que [situación que provoca la excepción] el sistema deberá {<acción a realizar>. Revise las preguntas que se sugiere realizar para desarrollar casos de uso una vez que se identificó un actor. Esta llamada especificación de caso de uso variará en su forma puesto que como se lo lleve determinará el equipo de trabajo. hay presión. el paso [número de paso]} en un máximo de [cota de tiempo] Este caso de uso se espera que se lleve a cabo una media de [número de veces] al [unidad temporal] {vital.Guía didáctica: Fundamentos de Ingeniería de Software • • • • • • PRIMER BIMESTRE Los actores son personas que usan el producto software. <Identificador> <nombre descriptivo> Descripción El sistema deberá permitir a [lista actores] en [instante en el que se puede realizar el caso de uso] [funcionalidad que define el caso de uso] según se describe en el siguiente caso de uso: <precondición del caso de uso> Paso Acción 1 {<acción a realizar>. importante. realizar el caso de uso [caso de uso]} 2 <Situación que produce una alternativa> 2a Si [Situación que produce una alternativa] el sistema deberá {<acción a realizar>.

pues realmente no hay un solo modelo de especificación de casos de uso. 2.es/asignaturas/ facultad/lsi/ejemplorup/Requisitos. El costo de corregir un error en las etapas finales es del 60 a 100 veces por encima que el costo de corregirlo en las etapas iniciales. es por eso que el que se adopta en el desarrollo de un proyecto software será el que el ingeniero seleccione o diseño. estas estimaciones siguen teniendo plena vigencia.7.PRIMER BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software En el Entorno Virtual de Aprendizaje encontrará una plantilla basada en RUP para la especificación de casos de uso que podría ayudarle para una mejor comprensión.1 “Elementos del modelado de requerimientos” pues nos permitirá ver diferentes formas de concebir los requerimientos además de determinar cuándo y en qué casos se utiliza cada uno de ellos. diagramas de estados. los costos de corrección de errores en la fase de prueba son mucho mayores que si los errores se corrigen en fases tempranas como la fase de requisitos o de análisis.5. En el texto básico en la página 115 tenemos un ejemplo de caso de uso. 27 . Tomemos en consideración que a mediados de los años setenta se realizó un estudio en donde se estima que el coste de corregir un error en un sistema software aumenta a medida que se avanza en el desarrollo. El modelado del análisis es una fotografía que nos permite ver los requerimientos en cualquier momento dado. Vamos a referirnos al siguiente proyecto que se presenta en la WEB http://users. diagramas de clases. función y comportamiento que se requieren para un sistema basado en computadora”.5. Sin embargo. Elaboración del modelo de los requerimientos Como lo expresa el texto básico “el objetivo del modelo de análisis es describir los dominios de información. como se puede ver con el que hemos planteado como ejemplo difieren en algunos aspectos.upv. debe considerar que puede plantear otras nuevas.6. Hemos encontrado en este apartado algunos temas como diagramas de actividades. A continuación se debe revisar el apartado sobre 5. 2. esto con la finalidad de determinar que <<el modelo de requerimientos es un reflejo correcto de las necesidades>>.dsic. “Validación de los requerimientos” del texto básico nos presenta este proceso que es de suma importancia puesto que una cosa es lo que el cliente está solicitando y otra lo que el ingeniero de software ha captado como información. Validación de los requerimientos El apartado 5. Si revisó las preguntas.html#EspCU para que se familiarice con los diagramas de casos de uso y la especificación de casos de uso. Al momento de revisar los requerimientos tenemos una serie de preguntas que deberíamos hacernos esto se encuentra plasmado en este apartado. claro está donde sea posible. De aquí que es necesario adelantar el proceso de prueba en las primeras etapas de desarrollo.

“Diseño en el contexto de la ingeniería de software” del texto básico. Basándonos en lo que se expresa en el texto básico: “el diseño de software se ubica en el área técnica de la ingeniería del software y se aplica sin importar el modelo del proceso que se utilice”. “EL MILAGRO MÁS COMÚN DE LA INGENIERÍA DE SOFTWARE ES LA TRANSICIÓN DEL ANÁLISIS AL DISEÑO Y DE ESTE AL CÓDIGO”. A nivel de componentes el diseño transforma los elementos estructurales de la arquitectura del software en una descripción. Recordemos siempre que el modelo de diseño se basa principalmente en el modelo de requerimientos. Después de realizar la especificación las preguntas que se presentan en el apartado del texto deben plantearse y responderse para garantizar que el modelo está correcto.7. Descripción del sistema Modelado de análisis Modelado del diseño Figura 201. 2. Richar Dué. 28 . luego de haber realizado un modelado de los requerimientos. en el análisis contaremos como entrada requisitos incompletos mientras que en la validación un conjunto comprobado de requisitos. Entonces es importante que usted sepa seleccionar a las personas que han de trabajar en este proceso de validación. Es una etapa fundamental en el proceso de desarrollo de software y se deben tener claros los conceptos que se asocian a este tema. así.Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE La revisión de requisitos se realiza con un grupo de personas que lee. analiza y discute el documento de especificación. tenemos que hacer el diseño para entrar recién al proceso de construcción. Como nos podemos dar cuenta la etapa de validación permite tener una definición precisa de las necesidades de los usuarios. Entonces el diseño de la arquitectura define la relación entre los elementos principales de la aplicación software. Diseño en el contexto de la ingeniería del software La etapa de diseño de software agrupa varios componentes necesarios para llegar al desarrollo de un sistema de alta calidad. nos estamos dando cuenta de la importancia que tiene el diseño. Transición del modelo de análisis al modelo de diseño. el diseño de interfaz en cambio se encarga de determinar la comunicación con los sistemas que interactúan y con las personas que lo utilizarán. Podemos entonces entender que. la interfaz y el diseño a nivel de componentes. Parte del diseño de clases puede llevarse a cabo junto con el diseño de la arquitectura del software. Podemos realizar una comparación entre el análisis y la validación. Además en el análisis veremos si los requisitos satisfacen las necesidades del cliente o si hemos levantado los requisitos correctos mientras que en la validación nos preguntamos si están bien descritos o si el documento describe el sistema. Revise entonces el apartado 8. para seguir con el diseño de la arquitectura. El modelo de diseño empieza por el diseño de datos o clases.1.

refinamiento. 29 . arquitectura. rediseño. Dentro de esto está incluida la abstracción (separar lo que se necesita del contexto general) ayudándonos a definir qué es lo que se quiere que se vea y de lo que no se debe ver. división de problemas. Pues determinados usuarios ni siquiera deben saber que existen ciertas funcionalidades. dentro de qué atributo se encuentra? Es importante considerar estos atributos de calidad puesto que al final nos servirán para realizar el proceso de validación del software. 2. esta palabra se asocia mucho a esta etapa. modularidad. Vamos a trabajar con el ocultamiento de información. Si se ha revisado estos lineamientos se dará cuenta que es muy importante la aplicación de principios de diseño.8. ¿El apartado de seguridad.1 del texto básico.2. clases de diseño. “El proceso del diseño” del texto básico. Como habrá visto. en el que podemos encontrar la definición de diseño. El proceso de diseño Este tema se ubica en el apartado 8. Este tema de ocultamiento de modularidad está presente sobre todo en los sistemas bancarios. pues el diseño es importante ya que permite.PRIMER BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software En la figura 8. patrones. identifíquela y determine cuál es su importancia Claramente el diseño es el plano para la construcción que se hará a partir de los requerimientos. Conceptos de diseño Estudie ahora los conceptos asociados al diseño y revise detalladamente cada uno de ellos: abstracción. entonces habrá notado que la importancia del diseño. se resume en una palabra: CALIDAD. Si ya revisó este apartado. conceptos de diseño orientado a objetos.9.1 Analice la figura 8. a un equipo de software. independencia funcional. aplicar una metodología de trabajo así como revisiones constantes. Ahora bien si revisa los atributos de calidad podremos darnos cuenta de que estos no se aplican con la misma severidad a todos los sistemas. evaluar la calidad esperada del mismo. Encontramos 8 lineamientos de la CALIDAD del software. Ocultamiento: decisiones de diseño que se oculten a las demás.1 del texto básico y determine la relación entre los elementos del análisis hacia el modelo. ocultamiento de la información. pues por ejemplo: la seguridad no será la misma para un sistema en una empresa que trabaja localmente que para un banco con sucursales en todo el mundo. Ejercicio 2. se puede ver esta relación que acabamos de mencionar así como los elementos que participan en cada parte del modelo de diseño que se encuentra en la pirámide. Se pretende de esta manera que algunos módulos sean accesibles solo a determinados módulos y no a todos. Realice un cuadro donde refleje los elementos y las relaciones entre los dos modelos. 2. aspectos. no olvide revisar detenidamente los otros apartados.

Modelo del diseño El apartado 8. como el de diseño es más aproximado a la solución (de aquí pasaremos a la construcción)..10. aquí podrá reforzar los conocimientos sobre los temas de requerimientos y diseño.es/ingenierias/fundamentos-de-ingenieria-delsoftware/material-de-clase. 30 . están separados con una línea entrecortada. Si nos fijamos en la tercera columna de la figura 8. pues bien.Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE Entonces es de suma importancia que revise cada uno de estos atributos de calidad para poder aplicarlos en el momento del desarrollo de aplicaciones. “El modelo de diseño” estudia el diseño desde 2 dimensiones: al igual que un plano cartesiano. De ser posible realice un cuadro sinóptico donde resuma los conceptos que encuentra. Entonces revise cada uno de los elementos columnas que se presentan.4 del texto básico. 2. es de importancia que revise la teoría.um. componentes y despliegue.4. interfaz. aquí encontramos los de arquitectura. el gráfico y los elementos que se muestran. Revise el OCW http://ocw. observe que el modelo de análisis y el modelo a diseño. Hemos concluido el estudio de esta unidad. por lo que nos conviene comprobar cuánto hemos asimilado de los temas tratados para lo cual es necesario desarrollar esta autoevaluación. en el modelo de análisis encontramos diagramas de secuencia y en el de diseño también. podemos ver que se ha realizado un refinamiento de este diagrama. en el eje de las x está la dimensión del proceso (tareas del proceso de software). y en el eje de las y está la dimensión de abstracción (modelos). bloque número 2.

( ) Las herramientas de administración de requerimientos permiten realizar una efectiva negociación entre todos los participantes del proyecto. 2. no es mencionado por el cliente se categoriza como: a) normal. 3. 5. Como estrategia le recomendamos que primero ubique el tema sobre el que le habla la pregunta. 10. 8. 6. c) especificación. Un requerimiento de confiabilidad del sistema que. ubique la información necesaria en el texto o en la guía didáctica y fundamente su respuesta. Si los clientes y usuarios piden más de lo que se puede alcanzar se debe llegar a una tarea de: a) indagación. La obtención de un documento escrito donde se haga constar los requerimientos está dentro de la tarea de: a) concepción. 9.PRIMER BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software Autoevaluación 2 Lea detenidamente cada una de las preguntas planteadas en la siguiente tabla y determine si la afirmación es verdadera o falsa. ( ) Con tareas de ingeniería de requerimientos. ( ) Un diagrama de estados se encuentra dentro de los modelos de requerimientos en sus elementos basados en escenarios. c) emocionante. ( ) La prioridad de los requerimientos es presentada por parte del cliente. Ir a solucionario 31 . ( ) Existen problemas en la obtención de requerimientos debido a que estos cambian. en muchos casos. 1. ¿se puede saber cómo interactuarán los usuarios finales con el software? 2. ¿este sería un requerimiento esperado? 7. ( ) Los requerimientos se realizan a fin de llegar a la construcción del sistema. SELECCIONE EL LITERAL CORRECTO 1. 3. 4. ( ) La validación de los requisitos se lo hace a la especificación de los mismos a fin de que estos contemplen ciertos atributos de calidad. c) negociación. ( ) El producto final de la ingeniería de requisitos es obtener un modelo de especificación de requisitos. este problema se puede superar con una buena negociación de requerimientos. b) esperado. ( ) En un software bancario el proceso de realizar transacciones lo realizamos a través de dispositivos táctiles. ( ) Para obtención de requerimientos podemos usar prototipos. b) elaboración. b) validación.

y dentro de cada actividad hay un conjunto de tareas que nos permitirán cumplir con dicha actividad. “Modelos de proceso” donde encontrará una amplia variedad de procesos de desarrollo y con esta información realice su propia definición sobre este tema.1 Como actividad identifique cuáles serían las ventajas de utilizar los patrones de proceso. en sí es estudiar cómo se construye software. Otro tema que encontramos en este apartado es flujo de procesos. dependerá del tipo de solución que se desee desarrollar así como de los recursos con los que se cuenta. es momento de acudir a la tutoría. Una actividad que le podría ayudar para la comprensión de este tema. Esta es una buena práctica.Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE UNIDAD 3: CICLOS DE VIDA DEL SOFTWARE Esperamos que los temas que se trataron en la unidad anterior estén comprendidos a plenitud. no olvide realizarla. o sea que no solamente pueden estar las cinco que revisamos en la unidad I. revisemos el capítulo 2. es la de realizar una comparación entre cada uno de los flujos de proceso. podemos distinguir en la figura 2. En la figura 2. En el apartado 2. Ahora bien. claro está. tenga en cuenta que la presente unidad se enfoca en el estudio de los ciclos de vida del software. varía más bien la interacción de las mismas.2 y este se complementa con la descripción del conjunto de tareas que se muestra a continuación de este apartado. si nos fijamos en la figura 2.1 encontramos parte de su explicación en el apartado 2.1. como se ve. volviendo al texto básico. las tareas dependiendo de la naturaleza del proyecto software difieren. “Identificación de un conjunto de tareas”. Ejercicio 3. Un modelo general de proceso Para empezar tratemos de responder a la siguiente pregunta: ¿qué es un modelo de proceso de software? Para encontrar la respuesta.1. 3. En uno de estos apartados se hace referencia a lo que se conoce como Ingeniería de requisitos. pero lo más importante es que aprenderá a diferenciar los modelos prescriptivos de los modelos ágiles diferenciando sus fortalezas y debilidades. recuerde lo que presentamos en un ejemplo anterior.3 de la unidad I. debe escogerse el conjunto de tareas que se adapte mejor a las necesidades de cada proyecto dependiendo de las características del equipo de desarrollo.1 del texto básico se muestra la estructura general para el proceso de software donde se consideran ya algunos de los puntos estudiados anteriormente como las actividades sombrillas. identificando las similitudes y diferencias que usted observa en la gráfica. revise los temas “Definición de actividad estructural”. “Un modelo general de proceso”. “Patrones del proceso” que se presentan en el texto básico. si no sucedió así. 32 .1. También podemos notar que existen varias actividades estructurales. 3 Apartado 1.2 del texto básico los diferentes tipos y como lo puede notar las actividades del modelo de proceso3 casi siempre son las mismas (ocasionalmente pueden variar).

Evaluación y mejora de procesos Por más que un proyecto de software se desarrolle a través de un proceso este no garantiza la entrega a tiempo del mismo. CMMI para servicios (CMMI-SVC o CMMI for Services).Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE El modelo general de procesos para la ingeniería de software ha de incluir un conjunto de actividades estructurales. De acuerdo al desarrollo y la naturaleza del proyecto debemos definir el conjunto de actividades.2. 3. funciones necesita cada Se obtienen y priorizan los requerimientos. • • • CMMI para el desarrollo (CMMI-DEV o CMMI for Development). Las mejores prácticas CMMI se publican en los documentos llamados modelos. Reuniones de trabajo informales. Lista inicial de requerimientos. 33 . Administraran los requerimientos. pero la formalidad y profundidad de cada actividad variará: Proyecto sencillo: Sistema de facturación para la empresa de Distribución de Materiales Eléctricos. Proyecto medio: sistema de Gestión Académico para el Colegio “La Dolorosa”. Entrevista a cada participante (se ha de anticipar la hora y los temas a tratar para que se preparen) Determina qué participante. En la actualidad hay tres áreas de interés cubiertas por los modelos de CMMI: desarrollo. Si le ha interesado este tema y quiere profundizar sus conocimientos podría revisar esta dirección electrónica que le presentará un detalle completo: http://www. Elaborar una lista de todas las personas que estarán involucradas. El proceso entonces debe evaluarse garantizando que se cumplan con estándares esenciales para la ingeniería del software. Estos modelos pueden referirse por un flujo diferente de proceso de cómo estarán organizadas las actividades. Seleccionar los participantes para el proyecto.edu/ cmmi/ The Carnegie Mellon Software Engineering Institute (SEI).sei. CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition). adquisición y servicios.cmu. así por los dos proyectos en la etapa de obtención de requerimientos podemos tener casi las mismas tareas. y que además satisfaga las necesidades de los usuarios y a la vez aún que represente utilidades para quien lo está haciendo. acciones y tareas. negociaciones de los requerimientos y validación de los mismos se obtiene la lista final de requerimientos (se puede dividir en subtareas). funciones necesidades y Luego de un proceso de reuniones.

sin embargo cada uno de los modelos pone más énfasis en determinada actividad.3.1 podemos apreciar algunos de estos modelos. así como el proceso que se realiza en cada uno podrá variar. se trata de un sistema de gestión académica donde en el centro está el proceso central de matriculación y expediente académico. donde cada una de las etapas tiene una contraparte que nos ayuda al aseguramiento de la calidad del producto final. 34 . este modelo se lo puede observar en la figura 2. Revisaremos ahora de cada uno de ellos. determinando algunas características esenciales. debe realizar una lectura detallada de cada uno y subrayar en el texto las partes más importantes. ¿Por qué? Esto es necesario para poder cumplir con cierta funcionalidad requerida y que luego se puede ir agregando componentes adicionales. Incremental Es un modelo para la producción de software en incrementos. Observe la figura 3.2 en la cual hemos representado un sistema con sus componentes. Modelos prescriptivos Estos modelos de proceso permiten poner orden en el desarrollo de software. en la figura 3. Es un modelo secuencial que empieza con el levantamiento de información y la identificación de requerimientos. Figura 3.1. Son conocidos también como modelos tradicionales. Algo que debe tener en cuenta es que la mayoría de los procesos de software han de incluir la actividades estructurales que hemos visto. y en sus alrededores otras funcionalidades que poco a poco pueden irse terminando para llegar a completar la solución definitiva.4 del texto básico.Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE 3. Cascada Conocido también como ciclo de vida clásico. cumpliendo con las etapas para terminar con la puesta en marcha del sistema. Modelos prescriptivos de desarrollo de software. Existe una variante que es el modelo en V.

Se dice que el primer entregable será la solución principal. los modelos anteriormente revisados son representados a través de elementos iterativos y concurrentes. Concurrentes Es conocido como de ingeniería concurrente.Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE Además debemos tener claro que cada una de las funcionalidades se crearán en base a un nuevo modelo de procesos. Ejemplo de modelo incremental. llenemos entonces el siguiente cuadro resumen: Comunicación Planeación Modelado Construcción Despliegue Cascada Incremental Evolutivo Concurrente Los modelos de procesos predictivos. han estado siendo aplicados por muchos años con la finalidad de organizar las actividades de desarrollo de software. 35 . Evolutivo El modelo espiral es un modelo definido inicialmente por Barry Boehm en 1988. propone un ciclo de desarrollo que evoluciona con cada iteración. Figura 3. donde se plasma la mayoría de los requerimientos básicos y luego se van agregando características suplementarias al producto final.4 relacionado con modelos de procesos especializado debe ser parte de una lectura realizada por usted para una comprensión de este tema. El apartado del texto básico 2.2. es hora de verificar cuánto entendió de este tema. Después de haber realizado la lectura. puesto que estos modelos no serán tratados en esta asignatura. como se lo menciona. Todos estos proponen un flujo de proceso pero basados siempre en las mismas actividades como lo demuestra el cuadro anterior.

pueden ser: modelos. 4 Pressman R. Cit. El sistema evoluciona con una serie de iteraciones. Fases del proceso unificado Hablaremos ahora acerca de Proceso Unificado de Desarrollo de Software (RUP) Está basado en componentes e interfaces bien definidas. personal de gestión. las personas que participan deben tener formación.2 Realice la siguiente actividad. componentes. Ejercicio 3. además de estar centrado en la arquitectura es un modelo iterativo e incremental. estos pueden encontrarse en cualquier documento de RUP. En cada iteración se persiguen unos objetivos concretos. • PROCESOS: conjunto de actividades para crear el producto también se puede decir que es una plantilla para crear proyectos. El proceso de desarrollo afecta a las personas. El trabajo se divide en miniproyectos. • PROYECTO: elemento organizativo de gestión.5. Se identifican trabajadores y artefactos. Se define en términos de flujos de trabajo (conjunto de actividades). p. prototipos. Cada iteración implementa un conjunto de casos de uso.Guía didáctica: Fundamentos de Ingeniería de Software PRIMER BIMESTRE 3. entrenamiento y experiencia. construcción y transición. 36 . (y en la mayoría de procesos). con esta frase podemos darnos cuenta que se puede aplicar un proceso de desarrollo personal que debe cumplir las etapas. Este modelo se ampliará con más detenimiento en la unidad 4 de esta guía como parte de la asignatura. código. aunque en cada una de ellas pueda omitirse o agregarse actividades que se considere. luego anótelas en la siguiente tabla. diagramas UML. el plan de prueba.4. elaboración. (2010). 48. tienen un conjunto de responsabilidades y ejecutan variedad de actividades. Modelo de proceso personal y de equipo “El mejor proceso del software es el que está cerca de las personas que harán el trabajo”4. documentación. • PERSONAS: pueden ser: arquitectos. e identifique sus similitudes y diferencias. 3. • PRODUCTO: estos son artefactos que se crean durante la vida del proyecto. A continuación va a encontrar el detalle de 4 aspectos que se distinguen dentro del RUP. Artefactos de ingeniería y de gestión. Analice las características del proceso personal de software y de proceso del equipo de software. desarrolladores. los cuales son una iteración que resulta en un incremento. ingenieros de prueba. clientes. usuarios. Ed. Las fases son: inicio. que construye el producto. utiliza el UML (Lenguaje Unificado de Modelado) principalmente dirigido por casos de uso.

PRIMER BIMESTRE

Guía didáctica: Fundamentos de Ingeniería de Software
Diferencias

Similitudes

Proceso personal de software

Proceso del equipo de software

¿Está seguro de que pudo responder? Recuerde que es importante realizar
cada una de las actividades propuestas, ellas le aseguran la comprensión
de los temas tratados.

3.6. ¿Qué es un proceso ágil?
Frente a los modelos prescriptivos, los modelos ágiles buscan entregar valor al cliente lo más temprano
posible anteponiendo este objetivo a cuestiones como los procesos, las herramientas los contratos, que,
si bien son importantes, tienen baja prioridad al momento de emprender en un proyecto con uno de los
denominados modelos ágiles.
El fundamento de estos modelos se encuentra en el denominado Agile Manifesto, cuya
fundamento es el que podemos apreciar en la figura 3.3, que fue establecido en 2001
por representantes de diferentes metodologías denominadas ágiles y son quienes
establecieron estos principios.

Figura 3.3 Manifiesto ágil5
5

Beck Kent et Al (2001) Agile Manifesto [En línea] EEUU:Utah. Disponible en http://agilemanifesto.org/ [Consulta 26 abril
2011]

37

Guía didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

Luego de leer este manifiesto resultaría sencillo encontrar las diferencias entre los
denominados modelos prescriptivos y los modelos ágiles. Lea pausadamente el
manifiesto y trate de identificar ¿cuáles serían las características de los modelos
prescriptivos En este sentido serían las contrarias a este manifiesto.
Vamos a tratar de comprender este tema que se lo revisa en el capítulo 3 del texto
básico, ya que es de mucha importancia por la acogida que tienen en la actualidad este
tipo de metodologías.
Con esta parte de la ingeniería de software conocida como ágil lo que se desea es llegar a cumplir con
las necesidades del cliente de forma correcta y además en la entrega incremental de las necesidades. Es
poder adaptarse a los cambios del software que se dan en el desarrollo.
Para entender bien el concepto de agilidad, revisemos la definición que plantea, en el
texto básico, Ivar Jacobson. ¿Qué puntos ha considerado abstraer de este concepto?
Compare esto con lo propuesto en el apartado 3.3 del texto básico donde podemos
encontrar la definición de un proceso ágil; después de leer este apartado comprenderá
claramente. Ahora responda a la interrogante: ¿cuáles son las características clave que
deben estar presentes entre los miembros del equipo de trabajo para que este sea eficiente?
Si revisa detenidamente la figura 3.1 del texto básico notará cómo los costos por los cambios disminuyen
significativamente con procesos ágiles durante el avance del desarrollo del software.
Quienes estén orientados hacia el desarrollo de los procesos agiles deberán conocer
los principios de agilidad y políticas de desarrollo ágil, estos temas se encuentran
en el texto básico en los apartados 3.3.1 y 3.3.2. Algo que no debemos olvidar es el
compromiso que debe haber en el equipo de desarrollo; estos se conocen como los factores humanos
que participan en el desarrollo de procesos ágiles, que se encuentran en el apartado 3.3.3.
Reflexione: ¿se puede construir un software con procesos ágiles que satisfagan las
necesidades de los clientes y tengan la claridad necesaria que permita luego realizar
nuevas adaptaciones?

3.7. Programación extrema
Más conocida como XP, calificado como el más utilizado de los procesos de desarrollo de software ágiles.
Este proceso está orientado a las organizaciones grandes.
Tengamos claro que, al hacer algo sencillo, con una “informalización” que nos lleva a procesos continuos,
nos consumirá tiempo que se verá reflejado en recursos, entonces debemos utilizar los procesos ágiles.
¿Cuándo los debemos utilizar? ¿El personal está consciente de lo que implican los procesos?
Valores
Son un total de 5 valores:

Comunicación entre los ingenieros de software y otros participantes.
Simplicidad, solo se debe realizar lo que se necesita.

38

Guía didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE



Retroalimentación del software implementado, el cliente y otros miembros del equipo.
Disciplina, adhesión a las prácticas que XP requiere.
Respeto entre sus miembros, otros participantes e integrantes del equipo.

El proceso XP
Usa un enfoque orientado a objetos, en la figura 3.2 del texto básico podemos observar claramente este
proceso empezando de una fase de planeación, para pasar al diseño y luego a la codificación y pruebas
que permitan incrementar las funcionalidades del software (nuevas requeridas). Debe realizar el estudio
de cada una de estas actividades que el XP propone.

3.8. Otros modelos ágiles
En la evolución de software existen muchas maneras de describir el proceso de desarrollo y métodos
para modelar; así mismo, en los modelos ágiles, existen muchos otros métodos que usted los puede ver
en la figura 3.4

Figura 3.4. Modelos ágiles6

DAS, SCRUM, MDSD, Cristal, DIC, DES, MA, PUA
Estos son algunos de los otros modelos ágiles de desarrollo; el apartado 3.5 del texto básico va haciendo
una descripción de cada uno de estos.
Hablemos de uno de estos modelos…
SCRUM
Scrum utiliza estas actividades: requerimientos, análisis, diseño, evolución y entrega. Cada una de estas
actividades ocurre con un patrón de proceso llamado sprint.
6

Beck Kent et Al (2001) Agile Manifiesto [En línea] EEUU:Utah. Disponible en http://agilemanifesto.org/ [Consulta 26 abril
2011].

39

Guía didáctica: Fundamentos de Ingeniería de Software

PRIMER BIMESTRE

Figura 3.5. Scrum. Fuente http://www.proyectosagiles.org/

Scrum acentúa el uso de un conjunto de patrones de proceso de software. Cada uno de esos patrones
de proceso define un grupo de acciones de desarrollo: retraso, sprint: reuniones, demostraciones
preliminares.
Atención: ¿Cuáles serían las diferencias y similitudes entre los modelos ágiles? Realice
un cuadro comparativo. Este trabajo debe ser presentado al profesor como parte de los
dos puntos de la interacción a través del EVA.

Ahora bien, a manera de cierre de la unidad, recurramos al recurso OCW http://ocw.
um.es/ingenierias/fundamentos-de-ingenieria-del-software/material-de-clase,
bloque número 3, para reforzar los conocimientos acerca de los modelos de procesos
de software.
Hemos concluido el estudio de esta unidad. Ahora nos conviene comprobar cuánto hemos asimilado
de los temas tratados. Desarrolle la tercera autoevaluación. Nuevamente reiteramos la importancia que
tiene el desarrollo de las preguntas de autoevaluación.

40

de acuerdo al avance de programación. Como estrategia le recomendamos que primero ubique el tema sobre el que le habla la pregunta. ( ) La primera entrega que se realiza en los procesos incrementales es el producto final que se va a entregar con un porcentaje mínimo de actualización. 10. en RUP se refiere a la fase de inicio. cuando va produciendo versiones más complejas del software por cada entrega. se puede decir que se está trabajando en base a un modelo incremental. ( ) La forma de organizar las actividades estructurales dentro del modelo general del proceso de software se conoce como flujo del proceso. ( ) En los procesos ágiles.PRIMER BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software Autoevaluación 3 Lea detenidamente cada una de las preguntas planteadas en la siguiente tabla y determine si la proposición es verdadera o falsa. es menor al costo del cambio con el uso de procesos ágiles. ( ) Cuando un software va cambiando. ( ) Si un cliente nos pide modificar cierta funcionalidad de un software. 3. 6. ( ) El prototipo sirve como la primera versión del sistema. 5. 7. 4. ( ) El diseño dentro del XP sigue rigurosamente el principio MS (mantenerlo sencillo). 9. 1. las personas y el equipo de trabajo deben adaptarse a las necesidades del proceso. será conveniente utilizar un modelo de cascada para esta implementación. 2. ( ) El número de actividades estructurales dentro del modelo general de proceso se encuentra definida y no permite realizar una variación. es decir. ( ) “Las primeras conversaciones con los gerentes de una organización para el desarrollo del software donde se propone una arquitectura aproximada de lo que se va a desarrollar”. ubique la información necesaria en el texto o en la guía didáctica y luego fundamente su respuesta. 8. ( ) El costo del cambio con procesos convencionales. Ir a solucionario 41 .

.

Arquitectura de software. Desarrollo de del RUP 2003 para software con el aplicarla a proyectos proceso unificado reales. organiza.5. 4.6. 6. • Habilidades para buscar. Lectura del material impreso en la guía didáctica. Analiza las necesidades de conocimiento necesarias para resolver un problema. Breve taxonomía la arquitectura del de estilos sistema. Características del proceso de principales del RUP desarrollo unificado.8.1.5: del texto básico señalados en la guía 12 horas de didáctica. INDICADORES DE APRENDIZAJE • • CONTENIDOS UNIDADES/TEMAS 4. dirige y controla sistemas y servicios informáticos en contextos empresariales o institucionales. • Organiza iteraciones considerando los niveles de riesgo de los casos de uso. • Compromiso con la calidad. • 5. análisis y síntesis. Desarrollo de los ejercicios propuestos en la guía.2. Planificación para el trabajo del alumno COMPETENCIAS ESPECÍFICAS Planea. Competencias genéricas • Capacidad de abstracción. Mejores prácticas Identifica los de la ingeniería del artefactos clave software de cada fase 4. software 5.1. CRONOGRAMA ORIENTATIVO Tiempo Estimado Semana 1. Desarrollo de la autoevaluación. Modelado de Realiza la requerimientos especificación correcta de los casos 5.2: 8 horas de autoestudio y 8 horas de interacción.4. Modelado basado en de diagramas los clases requerimientos de 5.3. Modelado UML para casos de uso Modela a través 5. Desarrollo de la evaluación a distancia. procesar y analizar información procedentes de fuentes diversas.2. Navegando por el proceso unificado de Extrae información desarrollo de la herramienta 4.7. autoestudio y 12 horas de Instalar la herramienta interacción. Actividades en el EVA. Rational Rose. Revisar recursos OCW. Actividades del EVA Lectura de los apartados Semana 3. 5. Modelado basado en escenarios de uso. • Conocimiento sobre el área de estudio y la profesión. arquitectónicos 5.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE SEGUNDO BIMESTRE 6.4. Géneros y estilos Organiza los arquitectónicos componentes para 5.3.4.5. Desarrollo de la autoevaluación y desarrollo de la evaluación a distancia. 43 .6. Diseño arquitectónico • • ACTIVIDADES DE APRENDIZAJE Instalación del RUP 2003.

Calidad del software 6. SEGUNDO BIMESTRE CONTENIDOS UNIDADES/TEMAS ACTIVIDADES DE APRENDIZAJE 6. CRONOGRAMA ORIENTATIVO Tiempo Estimado Semana 6: 4 horas de autoestudio y 4 horas de interacción Semanas 7 y 8 8 horas de Desarrollo del autoestudio cuestionario de repaso a través del EVA.2. Unidades de la 4 a la 6 Repaso general de la materia. Cómo lograr la calidad del software Lectura de los apartados del texto básico señalados en la guía didáctica.Guía didáctica: Fundamentos de Ingeniería de Software COMPETENCIAS ESPECÍFICAS INDICADORES DE APRENDIZAJE • Aplica criterios de calidad a los diferentes componentes y artefactos del ciclo de vida del software. Conceptos de calidad 6.3. 8 horas de interacción 44 .4. Dilema de la calidad del software 6.1. Desarrollo de la autoevaluación y actividades en el EVA.

Ob. James Rumbaugh e Ivar Jacobson. Cit. es así como tres visionarios Gary Booch. lo que los llevó a crear el denominado Proceso Unificado de Desarrollo Rational (RUP). En sus inicios el desarrollo de software era una práctica propia de los programadores. que más allá de los antecedentes históricos. pero no da la estructura del proceso que guíe a los equipos del proyecto cuando aplican la tecnología”7. es importante tenerlas en cuenta al momento de abordar un proyecto de software y no considerar al proceso de desarrollo como un mero formulismo que incluye la aplicación de plantillas para las diferentes partes del proyecto. (2010). por lo tanto. en este sentido trataremos dos apartados importantes que son: las mejores prácticas de la ingeniería del software y las características que lo hace diferentes de los otros procesos de desarrollo. no había un estándar en cuanto a modelos y representaciones de software. 45 . 4.7. P. nos interesa conocer las bases que lo sostienen. A inicios de los 90. Revisemos en este momento los orígenes y fundamentos del proceso unificado de desarrollo.SEGUNDO BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software 6. unen sus esfuerzos y logran crear el Lenguaje Unificado de Modelado (UML) el cual “brinda la tecnología necesaria para apoyar la práctica de la ingeniería de software orientada a objetos. 23. sin embargo colocaremos las referencias necesarias para que pueda ampliar la información. por lo que será desarrollado en su totalidad en la presente guía didáctica. que hoy en día es uno de los procesos más ampliamente utilizados en la práctica de la ingeniería del software y para una gran cantidad de proyectos. se trata del proceso unificado de desarrollo que se caracteriza por su versatilidad y adaptabilidad a diferentes tipos de proyectos. quienes gracias a su gran capacidad e ingenio podían crear aplicaciones complejas. Orientaciones específicas para el aprendizaje por competencias UNIDAD 4: APLICACIÓN DE UN MODELO DE PROCESOS RUP La presente unidad pretende enseñarle un modelo de desarrollo de software que podrá aplicar en proyectos reales. 7 Pressman R.1. sin embargo a medida que estas aplicaciones se incluían en el ámbito empresarial se volvieron mucho más complejas y los métodos de desarrollo utilizados hasta entonces se volvieron insuficientes. Mejores prácticas de la ingeniería del software El RUP se fundamenta en las mejores prácticas de la ingeniería del software que se han originado como soluciones a los principales problemas que debe enfrentar el proceso de desarrollo. Importante: El contenido del presente capítulo no se encuentra en el texto básico.

y una pobre gestión a lo largo del ciclo de desarrollo. (2003).1. Requerimientos Análisis y diseño Planificación Implementación Gestión de la configuración Pruebas Evaluación Liberación Figura 4. (2003). se enfoca en tres objetivos generales: 1. se caracteriza por sus fases organizadas secuencialmente.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE 4. Module 1: Best practices of software engineering. y atribuye como causa más común de dichos fallos a una incorrecta definición de los requerimientos en las fases iniciales del proyecto. visto en la unidad 2 de la presente guía didáctica. 3. P. 4. personas y resultados esperados para esa iteración. 46 .1. se libera y termina. Esta práctica.1 se aprecia esta estrategia que es usada por el RUP y algunos otros procesos ágiles de desarrollo de software.1.1. Práctica 1: Desarrollo iterativo El proceso de desarrollo denominado ciclo de vida clásico. cuyo esquema de operación es el siguiente: cada ciclo (iteración) inicia con una fase de planificación donde se establecen alcances. Para evitar este problema. esta práctica propone el uso de modelos iterativos e incrementales que permite el desarrollo en ciclos cortos denominados iteraciones que arrojan resultados a corto plazo y realizan entregas parciales hasta completar el proyecto. IBM Corp. organizar y dar seguimiento a los requerimientos del sistema. recursos. de esta fase pasamos a la fase de evaluación y de haberse completado el desarrollo. documentar. de no ser este el caso pasa a una nueva fase de evaluación. por tanto. Citado por IBM Corp. planificación dando inicio a la siguiente iteración. 8. Etapas de un proceso iterativo8 En la figura 4. P. mucha redundancia de trabajo. tiempo en el cual cambiaron las necesidades organizacionales. y. La administración de requerimientos es la práctica sistemática para encontrar. Module 1: Best practices of software engineering. por tanto el producto de software se vuelve obsoleto antes de entrar a producción. aparte de que resulta en proyectos de desarrollo que arrojan resultados a largo plazo. luego de realizar el estudio de necesidades que derivan en los requerimientos. 8 9 Asegurarse de que se resuelve el problema correcto y se construye el sistema adecuado. la tasa de éxito de los proyectos de desarrollo de software ha ido disminuyendo progresivamente. prOcede a la fase de implementación que inicia con el análisis y diseño y culmina con la implementación. dificultades al momento de medir el avance del proyecto.2 Práctica 2: gestionar los requerimientos De acuerdo al reporte conocido como CHAOS Report9 . lo cual genera algunos problemas como: retrasos en la identificación de los riesgos.

Module 1: Best practices of software engineering. 4. se considera fundamental asegurar a la trazabilidad de los requerimientos a lo largo de todo el ciclo de vida del software. lo cual es definido por el estándar IEEE para la ingeniería de software como “El grado en el cuál una relación puede ser establecida entre dos o más productos del proceso de desarrollo. asegura que todo lo implementado y modelado responda a las necesidades del usuario. 11 IBM Corp.3. Guía didáctica: Fundamentos de Ingeniería de Software Tener un método organizado para levantar. y estas a su vez han sido representadas en los modelos del sistema y es lo que finalmente se implementa y. Mantener un sistema de control de cambios en los requerimientos. 3. como se muestra en la figura 4. a su vez. documentar y gestionar los requerimientos cambiantes de las aplicaciones.2) de los requerimientos permite asegurar que todas las necesidades de los usuarios han sido consideradas en los documentos de especificación.SEGUNDO BIMESTRE 2. la trazabilidad (figura 4. 15.3. pueden estar organizadas en capas. Figura 4. En este sentido.3 Arquitectura de componentes11 10 Citado por Westfall L.1. (2006). P. Modelo de trazabilidad de los requerimientos de software. Bidirectional Requirements Traceability. en sentido contrario.2. especialmente productos que tienen entre sí relaciones como predecesorsucesor o superior-subordinado”10. (2003). 47 . A más de estas características. Figura 4. Práctica 3: utilizar la arquitectura basada en componentes El estilo de arquitectura basada en componentes es ampliamente utilizado en todas las ramas de la ingeniería y establece el principio por el cual todo el sistema se construye en piezas reutilizables denominadas componentes las cuales. organizar.

facilita las actividades de planificación. Según el estándar ISO 9126. asignación de recursos y la liberación del producto y a la vez reduce la complejidad inherente al sistema mediante la descomposición en partes más pequeñas y manejables. Figura 4. por tanto propone el aseguramiento de la calidad como estrategia para prevenir los cambios o errores al final del proyecto. una abstracción semánticamente cerrada del sistema”.4 se muestran varios de los modelos que se pueden desarrollar con UML. 4. por tanto. la cual se encuentra desarrollada en la tercera parte del texto básico: “Administración de la calidad”.1. El modelado visual se ve soportado en su totalidad por UML y permite: visualizar. 48 .4. facilidad de recibir mantenimiento y portabilidad.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE Esta práctica favorece la reutilización tanto de los componentes como de la arquitectura en sí. Modelos visuales de un sistema con UML12 4. construir y documentar los artefactos de un sistema con gran cantidad de software. La práctica sugiere que las correcciones o problemas identificados en etapas tempranas del proyecto son mucho menos costosas que las identificadas mientras se acerca el cierre del proyecto. Module 1: Best practices of software engineering. En la figura 4.1. los atributos de calidad que deberían medirse en el desarrollo de software son: funcionalidad. Práctica 4: modelar visualmente Booch et Al (2006:6) definen a un modelo como “Una simplificación de la realidad” y además consideran que “Todos los sistemas pueden ser descritos desde diferentes perspectivas utilizando diferentes modelos.4. especificar. realizaremos el estudio de lo relacionado con la calidad. P. (2003). sin embargo no tenemos una disciplina tan madura que nos permita asegurar la calidad durante todo el proceso de desarrollo. 20.5 Práctica 5: verificación continua de la calidad La calidad del software es un factor que ha afectado considerablemente la confianza en los equipos de desarrollo. En la unidad 6. y cada modelo es. eficiencia. 12 IBM Corp. usabilidad. confiabilidad. Hemos mencionado anteriormente que los proyectos de software se caracterizan por su complejidad.

Utilice la siguiente tabla. Causas principales Gestionar los requerimientos Utilizar la arquitectura basada en componentes Modelar visualmente Verificación continua de la calidad Gestionar los cambios 2.1 Una vez que ha completado el estudio de las mejores prácticas de la ingeniería de software. sin embargo.SEGUNDO BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software 4. 1.6. la decisión más inteligente que se puede tomar es administrarlos utilizando herramientas que permitan hacer una gestión eficiente de los mismos. en este momento le pedimos que realice un análisis inverso y establezca cuáles considera que son estas causas. 49 . Utilice un mapa mental similar al siguiente. Al inicio de la unidad se planteó que las mejores prácticas de la ingeniería del software surgieron como respuesta a los problemas que había con los proyectos de desarrollo. Una vez que ha establecido las causas que han sido consideradas para ser resueltas con las mejores prácticas del RUP. los requerimientos de cambio son cada vez más rápidos y. lo ideal sería que no hubiesen cambios durante el desarrollo o una vez puesto en producción el sistema. Ejercicio 4.1. le invitamos a que reflexione sobre ellas y desarrolle el siguiente ejercicio. Mejor práctica Desarrollo iterativo. por lo tanto. describa las características que deberían tener este proceso de desarrollo que le permitiría atacar esos problemas. eso no sucede en el mundo real. Práctica 6: gestionar los cambios Los cambios en el software son muy comunes debido a las condiciones cambiantes que afectan a las organizaciones.

Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE IMPORTANTE No avance si no desarrolló el ejercicio.2. P. Este cambio de concepción no solo afecta a la etapa en donde se identifican las necesidades. el estudio del RUP debe comenzar con el conocimiento de sus características más importantes. en los modelos de software estas capas se conocen como modelos: estático. 13 Jacobson et Al (2000): Ob. Dirigido por casos de uso Los casos de uso representan una forma particular de ver el sistema. 5. a su vez.2. Iterativo e incremental El desarrollo de proyectos de desarrollo de software en los modelos tradicionales (no iterativos) tiene un problema bastante complejo de manejar. Continuemos conociendo otro de los cimientos del RUP. 4. la implementación y las pruebas. Características principales del RUP Basado en las mejores prácticas de la ingeniería del software que resuelven los problemas mayores comunes a los proyectos de desarrollo de software. 50 . muchas condiciones han cambiado y por tanto los requerimientos también cambiaron. se agregaron y simplemente ya no son necesarios. deben esforzarse por entender las necesidades de cada uno de los usuarios. es importante hacerlo puesto que le permitirá generar ideas acerca de los problemas que debe resolver un proceso de desarrollo y naturalmente la curiosidad por conocer cómo es un proceso de desarrollo de software que está basado en esas mejores prácticas. en ese sentido suele suceder que una vez pasada la fase de levantamiento de información y mientras se está trabajando en el diseño. se tiene etapas secuenciales que deben cumplirse antes de pasar a la siguiente.2. aparte de que es muy vertiginoso el cambio en el contexto organizacional. todos orientados por los casos de uso y otros aspectos propios del entorno organizacional. esto significa que los miembros del equipo en lugar de pensar en las “características deseables” del sistema. con lo cual podemos decir que los casos de uso guían el proceso de desarrollo. Centrado en la arquitectura De manera similar a como sucede con los planos en la industria de la construcción de viviendas. además de guiar la arquitectura y.3. 4. dinámico y de implantación. por el contrario implica que a partir de los casos de uso realizamos el diseño. la arquitectura del software representa desde diferentes capas cómo se construirá el producto de software.2. puesto que si se sigue el ciclo de vida clásico. que en este caso son las características. Cit. Cuatro son las características que sus creadores Jacobson et Al (2000:5) atribuyen al proceso unificado y que las vamos a resumir en las siguientes líneas: 4. sin embargo en la práctica las necesidades de los usuarios varían mucho o son difíciles de obtener a la primera. esto es con los ojos del usuario. esta arquitectura incide en la selección de los casos de uso.1. implementación y pruebas.2. 4. por tanto ayudan a responder la pregunta: “¿qué debe hacer el sistema? La estrategia de casos de uso puede describirse añadiendo tres palabras al final de esta pregunta ¿… para cada usuario?”13.

Figura 4. en los proyectos. el cual que viene en el disco adjunto a su guía didáctica. Como solución a esta situación el RUP y otra gama de procesos de desarrollo conocidos como ágiles. aseguramiento de calidad entre otros. se la identifica como riesgosa. P.5. como se aprecia en la figura 4. 51 . Cit.2 Elabore un breve ensayo con las respuestas a estas preguntas y adjúntelo en su trabajo a distancia. Cit. SCRUM y otros. 86. y el propósito del RUP es identificar y reducir los riesgos lo más temprano posible en el proyecto. planificación y gestión del proyecto. estos niveles empiezan a disminuir mucho más tarde en el proyecto. y en cada iteración se propone entregar parte de la solución a los usuarios. Barry Bohem. Diferencia de los niveles de riesgo entre un proceso de desarrollo iterativo y el modelo en cascada15. Bien. escribió que “cree una aproximación al proceso de desarrollo de software dirigida por los riesgos en lugar de un proceso fundamentalmente dirigido por los documentos o dirigido por el código”14. en su computador. en tanto que en el segundo. han optado por la estrategia de trabajar en ciclos cortos de desarrollo que en RUP se conocen como iteraciones. es momento de trabajar con él. durante las cuales el equipo de desarrollo cumple todas las actividades que ahora se conocen como disciplinas e incluyen: análisis del negocio. 14 Citado por Jacobson et Al (2000) Ob. y esto es precisamente lo que RUP busca. en relación a lo que necesita una disciplina de software. ¿Qué le parecen las características del RUP? ¿Cree que estas realmente cumplen con las características sugeridas en las mejores prácticas? ¿Qué tan lejos o qué tan cerca estuvieron sus respuestas de las características aquí planteadas? Ejercicio 4. para ello es necesario instalar el RUP. 86. sin embargo a medida que avanzan estos niveles empiezan a disminuir de manera temprana en el primero. análisis de requerimientos. reducir los niveles de riesgo lo más pronto posible. ahora que ya conoce algunas de las características del RUP. de modo que a medida que se avanza en el proceso el sistema se adapta a los cambios que se suceden en el tiempo con una arquitectura estable y funcionalidades probadas por los usuarios. P.5. con este producto se trabajará en el resto del presente capítulo. Las instrucciones para su instalación las encontrará en el EVA. 15 Jacobson et Al(2000) Ob. lo que significa también que los costos provocados por efecto de los riesgos serán mucho más altos que en el anterior. en los niveles de riesgo en un proceso iterativo e incremental y un modelo en cascada son similares.SEGUNDO BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software A esta situación. entre ellos XP.

en la parte derecha que es la más amplia es donde se muestra el contenido. espere que se inicie la aplicación y. es posible que le solicite autorización para ejecutar un control Activex y un applet denominado ruppresenter. dependiendo de las configuraciones de seguridad. Vamos a reconocer estos elementos navegando por el proceso de desarrollo. las cuales están íntimamente integradas para asegurar el cumplimiento de las mejores prácticas. Figura 4. Navegando por el proceso unificado de desarrollo El proceso unificado de desarrollo como todos los procesos se compone de 3 elementos básicos: fases.6. disciplinas e iteraciones. para ello le invitamos a que ingrese al RUP que instaló en su computador. el contenido del paquete se encuentra en idioma inglés. 4. Iniciado el comando se levantará su navegador Web.7). pero conscientes de que esto podría ser un problema. Una vez que ha ingresado familiarícese con la aplicación que tiene en pantalla (ver figura 4. 52 . en este caso debe responder NO para que se ejecute la aplicación. como se muestra en la figura 4.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE IMPORTANTE Como ya lo habrá notado. Inicio de aplicación de RUP 2003. lo cual debe permitirlo siempre.3. por lo tanto. en la parte superior del árbol de navegación encontrará los botones de control para cada una de las vistas del RUP. tenga en cuenta que para ejecutar el applet la pregunta que hace es: “Desea impedir que se ejecute el applet” y la opción SI está predeterminada y recomendada. vamos a tratar de orientarle en el desarrollo del contenido. en la parte izquierda tiene un árbol de navegación el cual le permitirá realizar un recorrido por cada uno de los componentes del proceso unificado de desarrollo. vaya a Inicio|Todos los Programas|Rational Software|Rational Unfified Process. es conveniente que tenga un dominio básico del ingles técnico.6. en la parte superior del árbol de contenido encontrará el árbol de ruta en donde puede saber dónde se encuentra ubicado y haciendo click en él se puede regresar. sin embargo será necesario que se valga de otros medios para comprender el contenido de la herramienta para que le saque el máximo provecho.

Ahora bien. en donde encontrará sus descripciones. Ejercicio 4. Fases Fase (Phase) Descripción 53 . una vez que esté familiarizado.7. Cuando visite cada disciplina tendrá un diagrama de las actividades que implica. deberá darle un vistazo general a cada diagrama e ingresar a estas actividades. Al seguir las instrucciones dadas aprenderá a navegar por toda la aplicación. anotándolo en la columna correspondiente de la tabla. Para ello debe empezar con el árbol de navegación en donde encontrará todas las opciones del programa. en la ventana de contenido. Identifique y liste las fases (phases) y las disciplinas (disciplines) y anótelas en las siguientes tablas junto con su descripción. a. para obtener la descripción de la misma. Todo el contenido debe estar en español. y. allí encontrará. Luego haga lo propio con las disciplinas.SEGUNDO BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software Figura 4. haciendo clic en cada una de ellas.3 Ahora que conoce algo de la herramienta. desarrolle las siguientes actividades: Navegue por la herramienta para encontrar la siguiente información: 1. Ventana de inicio del RUP. Para hacerlo seleccione. entre ellas debe buscar la opción que dice “Navigating the process” que se encuentra bajo la vista “Getting Started”. la opción “overview” (vista general). para seguir avanzando. le invito a que siga las indicaciones que aparecen en la sección “Getting Started”. en el árbol de navegación. el gráfico del proceso unificado de desarrollo. luego ingrese en cada una de las fases y establezca el propósito de cada una de ellas. es preciso que aprenda a navegar por la aplicación.

Disciplinas Disciplinas Descripción Estamos seguros que logró cumplir con la tarea. Luego haga lo mismo con “Template: Visión (Informal)” y obtendrá plantillas más livianas para proyectos pequeños. y de esta forma ha obtenido una plantilla en formato Word que podría usar en sus proyectos. Finalmente regrese y haga clic “Template: Vision” y seleccione todo el contenido de esa página (ir al menú del navegador. 3. Ahora le invitamos a ver cómo puede obtener información adicional. haga clic en “CREG-Vision–Inception” y revise el contenido del documento de visión para ese proyecto ejemplo. 6. luego haga click en el documento “Whitepaper: The Ten Essentials of RUP”. como decíamos antes. ingrese a la opción Editar y luego seleccionar todo) luego copie (Ctrl + C) este contenido en un documento en Word. Ahora seleccione la vista “Team” (Equipo). para ello ubíquese en la sección “Process essentials” el árbol de navegación en la vista “Getting Started”. Ahora ingrese al artefacto “Visión” haciendo clic en el mismo. ahora en la tabla que aparece hay artifacts (documentación) ordenados por importancia. en la tabla resultante. y ahora haga clic en donde dice “Lifecycle objectives milestone”.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE b. 54 . es posible que el idioma le haya significado ocupar un poco más de tiempo. léalo y elabore un breve resumen de su contenido. 2. y. luego seleccione “Rup Lifecycle” (ciclo de vida del RUP). Conforme se familiarice con este entorno le resultará más fácil sacarle provecho. pero eso le beneficiará mucho más adelante. en la ventana de contenido haga click en “Inception” (inicio o conceptualización) e identifique cuáles son los roles que intervienen en esta fase y lístelo a continuación. Regrese nuevamente a RUP LIFEYCYCLE. 4. Indique ¿cuál es el de mayor importancia y cuál es el de menor importancia? 5.

La herramienta del RUP que usted acaba de utilizar tiene abundante información sobre procesos. a pesar de que en los ejercicios del apartado 4. además se puede apreciar la cantidad de esfuerzo requerido por cada una de las disciplinas a lo largo del ciclo de vida. Frente a procesos de desarrollo tradicionales. P. las traducciones no son totalmente efectivas. pero usted puede explorarlas y sacarles provecho.SEGUNDO BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software Si instala en su navegador la barra de herramientas Google puede traducir todo el contenido a español. Iniciamos nuestro estudio revisando la estructura general del RUP. por tanto en la fase de inicio (inception) también puede haber algo de implementación de código. sino que lo use en la práctica. sin embargo tienen un nivel aceptable como para que pueda desarrollar sus actividades.1 tuvo la oportunidad de conocer algunos elementos. 4. El proceso unificado de desarrollo16. Desarrollo de software con el Proceso Unificado Hasta ahora hemos hecho un breve recorrido por las mejores prácticas y características del RUP. Le invitamos. todas las disciplinas se ejecutan con diferente nivel de esfuerzo mientras avanzan las fases. Lo que sí es necesario acotar es que debido a la terminología técnica.4. vamos a tratar de enfocarnos en aspectos clave para poder usarlo en proyectos reales. lo cual nos ayuda a comprenderlo. pero para poder usarlo es necesario conocerlo. a que la use no solamente como un recurso académico para aprobar el curso. para ello centremos nuestra atención en la figura 4. la ingeniería del software es mucho más amplia de lo que pretendemos cubrir con la presente asignatura. sin embargo dejamos algunas bases y herramientas que estamos seguros le serán de mucha utilidad al momento de trabajar en proyectos reales. Hay muchas opciones que no hemos explorado. y podrá obtener incluso las plantillas para los documentos Word en español.8. Estimado estudiante. 55 . Ed. las disciplinas y las iteraciones del RUP. sin embargo este se acentúa conforme se acerca a la fase de construcción. herramientas y plantillas (templates) que puede utilizar para trabajar en sus proyectos e incluso puede personalizarlas para acoplarlas a los diferentes tamaños y tipos de proyectos. 16 Booch et Al (2006).8 donde podemos apreciar las fases. Figura 4. y el RUP es una de ellas. 490. por lo tanto. técnicas. que usted ya tuvo la oportunidad de revisar. Cit.

y en el árbol de navegación ingrese al “Overview”. Jacobson. Puesto que usted dispone del RUP2003 y ha tenido la oportunidad de obtener algunos elementos del mismo. 56 . 99. 4. y pensamos que la mejor manera de hacerlo es mostrarle los elementos que a continuación desarrollamos como resumen de lo más importante de cada una de las fases del proceso unificado de desarrollo. que resumiendo serían: de la fase de inicio el hito principal es el alcance del producto.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE Puesto que usted ya tuvo la oportunidad de investigar el propósito de cada fase. puede complementar la información aquí brindada navegando en el mismo. que usted lo tiene disponible e instalado en su máquina y el curso Rational Unified Process Made Easy v 1. en la figura 4.4. Estimado estudiante: tenga en cuenta que las siguientes secciones de este capítulo se basan en los materiales siguientes: RUP2003. Ed. no consideramos necesario redundar en el tema. La fase de inicio Como habíamos mencionado antes. et Al (2000:99). y en el diagrama general del RUP.0 de IBM Rational. 17 Jacobson et Al (2000). Figura 4. procesos. Nuestro afán es que usted se lleve una idea muy clara de lo que implica el proceso de desarrollo de software.1. Hitos principales del proceso unificado de desarrollo17. de la fase de elaboración el hito es la arquitectura estable. Cit.9. para ello debe cumplir con una serie de flujos de trabajo desarrollado por diferentes actores del proyecto. plantean los siguientes objetivos para cada una de las fases. podemos decir que el proceso de construcción del software con el proceso unificado de desarrollo consiste en el desarrollo del siguiente proceso. actores y plantillas para ir descubriendo todo lo que implica el contenido. I. P. sin embargo queremos hacer hincapié en la visión general del proceso y en los hitos de cada una de las fases que propone el RUP. a los cuales tenemos acceso por el convenio académico. por lo tanto le proponemos que conforme va leyendo estos apartados. al que lo revisaremos a través de cada una de sus fases. en la fase de inicio se busca establecer el alcance del proyecto. A nivel general. ingrese al RUP. haga click en cada una de las fases.9. de la fase de construcción el hito es tener una versión estable del producto y el objetivo de la fase de transición es obtener el producto correctamente entregado a los usuarios.

Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE OBJETIVOS DE LA FASE DE INICIO 1. 3. previa entrega a los usuarios. este es uno de los roles técnicos de alta importancia para el proyecto. define las características de diseño del sistema. las restricciones y los criterios de éxito del proyecto. es por tanto quien organiza las actividades. Establecer al menos una solución potencial: esto es identificar la arquitectura candidata. Actividades de la fase de inicio 1. delimitando el alcance y las funcionalidades del sistema. y el valor que le agrega a los usuarios el proyecto. Definición del alcance del proyecto La definición del alcance del proyecto implica capturar la información de contexto del proyecto. para ello se obtiene el caso de negocio. entrenamiento y apoyo en los procesos a los miembros del equipo y apoyo en la planificación de actividades al gerente del proyecto. costos y riesgos asociados al proyecto. Este rol es uno de los más importantes. el aseguramiento de calidad interviene desde etapas tempranas del proyecto todos los artefactos que se van generando en el proyecto. • Analista de sistemas (System Analyst): es el rol que coordina el levantamiento de requisitos y el modelado de casos de uso. 57 . en el tiempo y costes previstos con los niveles de calidad acordados. plan del proyecto los análisis costo/beneficio. 2. gestión de recursos. Este rol puede ser asumido por el gerente de proyecto en equipos pequeños. 2. puesto que el alcance y requerimientos del sistema son elementos críticos para garantizar el éxito de un proyecto. Obtener una visión clara del cronograma. personalización de los mismos. • Ingeniero de procesos (Process Engineer): es el rol responsable de definir todos los procesos que se usarán en el proyecto. lo que desea. • Equipo de aseguramiento de calidad (Testers Roles): a diferencia del control de calidad en el que se validan los productos de software. los requerimientos de alto nivel. plan de desarrollo del proyecto y lista de riesgos. • Arquitecto de software (Software Architect). Desarrollo del caso de negocio Evaluar las alternativas para la gestión de riesgos. Obtener claridad en lo que se desea construir: ello significa obtener la visión del cliente. 4. Roles que intervienen: • Gerente del proyecto (Project Manager): es el responsable de que el proyecto se cumpla con el alcance definido. Identificar los requerimientos principales: casos de uso y requerimientos no funcionales.

identificada. Flujos de eventos en líneas generales para los casos de uso más importantes. las herramientas y la personalización del proceso de desarrollo. 58 . Plan de iteración para la primera iteración de la fase de elaboración Plan de iteraciones (Iteration Plan) aprobado. de forma que sean factibles las estimaciones de tiempo. costos y recursos. Lista de riesgos (Risk list) Lista de riesgos iniciales del proyecto. 4. el documento más importante es el documento de visión. los involucrados en el proyecto. identificados. la organización. Glosario Modelo de casos de uso Prototipos (opcional) Terminología importante del proyecto. Criterios de evaluación de la fase de inicio: • Los interesados en el proyecto están de acuerdo con la definición del alcance y las estimaciones de costo y cronograma. los artefactos esenciales de la fase de Inicio son los siguientes en orden de importancia: Artefacto (Artifact) Estado al cumplimiento del hito Documento de visión (Visión) Documenta los requerimientos centrales del proyecto. Definición de la arquitectura candidata Evaluar las ventajas y desventajas del diseño y las decisiones fabricar/comprar o reusar. (Software development plan) Adaptaciones y extensiones al RUP. documentadas y revisadas. Preparación del entorno del proyecto En esta actividad se busca establecer el contexto en el que se desarrollará el proyecto. además de realizar la evaluación financiera que permita determinar qué tan beneficioso resulta el proyecto frente a la inversión realizada. 3. Actores y casos de uso importantes. sus necesidades. Plan de desarrollo de software Etapas iniciales. Artefactos esenciales Según el RUP 2003. puesto que en él se definen cómo será el producto. Caso de negocio (Business Case) Definido y aprobado. Proceso de desarrollo (Development Típicamente incluye lineamientos específicos para el proyecto así process) como las plantillas y las decisiones de personalización. las características fundamentales y las principales restricciones. Uno o más prototipos conceptuales para dar soporte a la visión y al caso de negocio y enfocado en tratar riesgos específicos del proyecto. En este sentido y en función de las características del proyecto. duración y objetivos identificados. las restricciones del proyecto y los criterios de éxito del mismo.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE Uno de los elementos fundamentales del caso de negocio es la identificación de los procesos de negocio que se verán afectados (beneficiados) y las expectativas que se tiene respecto a los mismos.

desarrollar. • Aseguramiento de calidad (Resters): se encargan de verificar las estrategias de prueba. • Analista de sistemas (System Analyst): en esta fase administra los requerimientos y refina la definición del sistema. Roles que intervienen: • Gerente del proyecto (Project Manager): se encarga de realizar el monitoreo y control del proyecto y de la administración de iteraciones. pero recuerde que el proceso de desarrollo no implica únicamente el llenado de las plantillas. • Arquitecto de software (Software Architect): en esta fase define la arquitectura candidata y la refina hasta dejar estable. 4.. Diseñar. • Todos están de acuerdo en que las estimaciones de costo/cronograma. sino que implica llenar las plantillas con la información resultante del trabajo desarrollado.2 La fase de elaboración La segunda fase del proceso unificado de desarrollo tiene como hito el establecimiento de una arquitectura estable del sistema. 3.4. 2. riesgos y proceso de desarrollo son los apropiados.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE • Existe conformidad en que los requerimientos correctos han sido capturados y se ha logrado una comprensión compartida de los mismos. patrones. Mitigar riesgos con mayor criticidad. establecer la línea base del la estructura del sistema y ejecutar una prueba inicial de carga y rendimiento del sistema. • Desarrolladores (Developers): se encargan de construir y probar los componentes. los objetivos de esta fase son lo que se indican a continuación. validar y establecer la línea base de la arquitectura: tomar las decisiones cruciales de diseño. prioridades. y producir un cronograma y estimaciones de costo más precisas. • Se ha identificado todos los riesgos y existe una estrategia de mitigación para cada uno de ellos. 4. Obtener una comprensión detallada de los requerimientos: capturar al menos el 80% de los requerimientos. 59 . esto es comprar vs. Para trabajar obtenga las plantillas desde la herramienta. etc. Afinar el plan de desarrollo. implementar. En este punto puede abortarse el proyecto o reconsiderarse su enfoque si se falla en estos criterios. OBJETIVOS DE LA FASE DE ELABORACIÓN 1.

de modo que sirva para establecer cronogramas y costos realistas. Diseño de realizaciones de casos de uso para escenarios de arquitectura significativos y el comportamiento requerido ha sido ubicado en los elementos de diseño apropiados. 5. Plan de desarrollo de software Actualizado y expandido para cubrir las fases de construcción y transición. identificación de mecanismos y elementos de diseño (vista lógica) más la definición de la vista de procesos e implantación. Los componentes arquitectónicos se encuentran integrados y evaluados frente a los escenarios primarios. basado en la nueva información obtenida durante la fase. Nuevos riesgos relacionados con la arquitectura relacionados principalmente con requerimientos no funcionales. 4. Refinar la visión en base a la nueva información obtenida. 2. 3. Infraestructura de desarrollo El ambiente de desarrollo está listo e incluye todas las herramientas y soporte automático para el proceso. Documento de Visión Refinado. Modelo de implementación Estructura inicial creada y los componentes principales están prototipados. incluye descripciones detalladas de software los casos de uso arquitectónicos (vista de casos de uso). Incluye entidades. Modelo de diseño Definido y establecido como línea base. Los principales elementos de datos han sido definidos y revisados. Refinar la arquitectura y seleccionar componentes en base a las decisiones de comprar o desarrollar. Artefactos esenciales Artefacto (Artifact) Estado al cumplimiento del hito Prototipos Uno o más prototipos de la arquitectura se han creado para explorar las funcionalidades críticas y escenarios significativos. Proceso de desarrollo Se ha refinado el proceso de desarrollo. lograr una comprensión sólida de los casos de uso más críticos que afectan a las decisiones de planificación y arquitectura.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE Actividades de la fase de elaboración 1. Documento de arquitectura del Creado y establecido como línea base. Definir. Modelo de datos Establecido como línea base. Se han identificado los componentes y las decisiones de desarrollar/comprar/reusar están lo suficientemente claras para establecer con precisión los costos y cronograma de la fase de construcción. validar y establecer la línea base de la arquitectura de una manera rápida y práctica. 60 . tablas y relaciones. Refinar el plan de desarrollo del proyecto considerando: procesos. Crear una línea de base de los planes de iteración para la fase construcción. Lista de riesgos Actualizada y revisada. herramientas y soportes automáticos requeridos por parte de los miembros del equipo del proyecto. los lineamientos y las plantillas basadas en la experiencia obtenida en el proyecto hasta ahora. estableciendo una comprensión sólida de los casos de uso críticos que orientan la arquitectura y las decisiones de planificación.

Pueden requerirse si el sistema tiene una interfaz de usuario compleja. Modelo de análisis (opcional) Manuales de usuario Puede ser desarrollado como artefacto formal y evolucionar a la primera versión del modelo de diseño. de La composición y los mecanismos de los elementos del software de automatización de pruebas han sido establecidos como base. • La arquitectura es estable. En este punto puede abortarse el proyecto o reconsiderar su enfoque si se falla en este hito. Las pruebas han sido implementadas y ejecutadas para validar la estabilidad de la construcción de cada versión ejecutable creada durante la fase de elaboración. • Todos los interesados están de acuerdo en que la visión actual puede ser alcanzada si los planes se ejecutan como están para desarrollar el sistema completo en el contexto de la arquitectura actual. • Los planes de iteración para la fase de construcción se soportan en estimaciones confiables. Modelo de casos de uso (use case Aproximadamente el 80% de los casos de uso han sido identificados. model) evaluados y se ha desarrollado la mayoría de las descripciones de los mismos.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE Artefacto (Artifact) Estado al cumplimiento del hito Plan de iteraciones Plan completo de iteraciones para la fase de construcción. Los manuales de usuario y otros recursos de capacitación se han creado en sus versiones borrador basados en los casos de uso. Criterios de evaluación de la fase de elaboración: • La visión del producto es estable. 61 . Especificaciones suplementarias (Supplementary specifications) Suite de pruebas (Test Suite) Arquitectura pruebas del sistema Los requerimientos no funcionales han sido identificados y revisados. • Las técnicas de validación del software se han probado. • La comparación entre los recursos previstos y los recursos gastados muestran equivalencia o son aceptables. • Las pruebas y evaluaciones de los prototipos ejecutables han demostrado que los elementos de riesgo mayores han sido direccionados y efectivamente resueltos.

• Administrador de versiones es el encargado de producir las versiones que se liberarán. OBJETIVOS DE LA FASE DE CONSTRUCCIÓN 1. revisada y establecida como base. Esta fase es. en cierto sentido.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE 4. • Los testers son los encargados de probar y evaluar cada uno de los componentes construidos.4. esto significa optimizar los recursos y evitar retrasos innecesarios y la repetición del trabajo debido a los errores cometidos. control y optimización del proceso. Evaluar las versiones del producto contra los criterios de aceptación definidos en la visión. • Analista de sistemas es el encargado de administrar todos los requerimientos de cambio. Actividades de la fase de construcción: • • • Gestión de recursos. Completar el desarrollo de componentes y probarlos contra los criterios de evaluación definidos. Suite de pruebas Pruebas implementadas y ejecutadas para validar la estabilidad del componente para cada versión ejecutable creada durante la fase de construcción. el proceso de manufactura donde se pone énfasis en administrar los recursos y controlar las operaciones para optimizar los costos. Plan de iteraciones Plan de iteraciones para la fase de transición completado y revisado.3 La fase de construcción El objetivo de la fase de construcción es clarificar los requerimientos pendientes y completar el desarrollo del sistema conforme lo establecido en la línea base de la arquitectura. Minimizar los costos del desarrollo y alcanzar cierto grado de paralelismo en el trabajo de los equipos de desarrollo. Artefacto (Artifact) Estado al cumplimiento del hito La aplicación Es el sistema ejecutable listo para iniciar la fase de pruebas (versión beta). En proyectos más pequeños este puede ser embebido en el plan de desarrollo del software. Desarrollar de manera iterativa un producto completo que está listo para ser transferido a su comunidad de usuarios. Modelo de implementación Expandido del creado durante la fase de elaboración. todos los elementos de implantación creados al final de la fase de construcción. Plan de implantación Versión inicial desarrollada. 62 . cronogramas y calidad. esto es desarrollar la primera versión operacional del sistema y determinar si los lugares y los usuarios están todos listos para que la aplicación sea entregada. • Los desarrolladores son los encargados de construir los componentes. monitorear y controlar el proyecto y planificar las siguientes iteraciones. • Un documentador técnico en el encargado de desarrollar el material de soporte. Roles que intervienen: • Gerente del proyecto es el responsable de administrar las iteraciones. 2.

En este punto la retroalimentación de los usuarios debería enfocarse principalmente en el afinamiento del producto como configuración.4. incluyendo el caso de desarrollo (development case) y cualquier lineamiento específico del proyecto en plantillas que se hayan definido estan basados en la experiencia del proyecto y. etc. además. índices. Criterios de evaluación Los criterios de evaluación para la fase de construcción comprenden las respuestas a las siguientes preguntas: • ¿Es la versión de este producto estable y lo suficientemente madura para ser entregada a la comunidad de usuarios? • ¿Están todos los interesados listos para la transición a la comunidad de usuarios? • ¿Los costos actuales versus los planificados continúan siendo aceptables? 4. Especificaciones suplementarias (opcional) Actualizado con nuevos requerimientos en caso de que se hayan descubierto durante la fase de construcción. 63 . Modelo de datos Actualizado con todos los elementos necesarios para soportar la implementación de la persistencia (tablas. debido a que todos los incidentes estructurales han sido resueltos durante etapas anteriores. Infraestructura de desarrollo El entorno de desarrollo para la transición está listo. Esta fase puede subdividirse en varias iteraciones e incluye la verificación del producto preparándolo para ser liberado. Modelo de casos de uso (opcional) Actualizado con nuevos casos de uso si se hubieran descubierto durante la fase de construcción.). instalación e incidentes de usabilidad. Proceso de desarrollo El proceso de desarrollo. está lo suficientemente definido para proceder con la siguiente fase. incluyendo todas las herramientas y soporte para la automatización del proceso. mapeo de objetos a relacional.SEGUNDO BIMESTRE Artefacto (Artifact) Guía didáctica: Fundamentos de Ingeniería de Software Estado al cumplimiento del hito Modelo de diseño Actualizado con nuevos elementos de diseño identificados durante el desarrollo de todos los requerimientos.4 La fase de transición El enfoque de la fase de transición es asegurarse de que el software esté disponible para su comunidad de usuarios finales. hacer ajustes menores basados en la retroalimentación de los usuarios.

Mejorar el rendimiento de futuros proyectos mediante lecciones aprendidas. Conseguir el acuerdo de los interesados en que las líneas base de implantación se han completado y son consistentes con los criterios de evaluación del documento de visión. 3. 64 . • Completar el material de soporte para usuarios finales. esto es especialmente importante para productos comerciales. 4. administra las iteraciones. esto es corregir errores y realizar mejoras al rendimiento y a la usabilidad. Entrenar usuarios y personal de soporte para conseguir independencia del usuario. • Hacer que el producto esté disponible para los usuarios finales. • Afinar el producto basado en la retroalimentación de usuarios. 2. Prepararse para la distribución y la fuerza de ventas mediante el entrenamiento del personal. Preparar el entorno de implantación y dejar listas las bases de datos operacionales. • Obtener retroalimentación de parte de los usuarios. • Documentador técnico: se encarga de desarrollar materiales de soporte como manuales de usuario. esto implica comprar nuevo hardware. Actividades de la fase de transición: • Ejecutar planes de implantación. añadir espacio para el nuevo hardware y la migración de datos. • Probar los productos entregables en el sitio de desarrollo. • Crear una versión del producto. • Gerente de proyecto. 5. • Implementador. a cargo de ejecutar el plan de implantación. Probar la versión beta para validar que las expectativas del usuario han sido alcanzadas. • Testers se encargan de probar y evaluar los componentes implementados colaborando con la integración del sistema. 6. Roles que intervienen: • Gerente de implantación. se encarga de corregir errores en los componentes y de integrar el sistema.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE OBJETIVOS DE LA FASE DE TRANSICIÓN 1.

SEGUNDO BIMESTRE Artefacto (Artifact) Guía didáctica: Fundamentos de Ingeniería de Software Estado al cumplimiento del hito El producto Completado de acuerdo a los requerimientos y en condiciones de usabilidad para el cliente. Elementos de implementación La implementación se ha completado y será establecido como base y los elementos de implantación han sido incorporados en el producto final. operando y manteniendo al producto deben estar completos y en concordancia con los requerimientos. Material de soporte para usuarios finales Los materiales que asisten el aprendizaje del usuario final usando. Criterios de evaluación: Los criterios de evaluación primarios para la fase de transición tienen que ver con respuestas a las siguientes preguntas: • ¿Está el usuario satisfecho? • ¿Están los gastos de recursos versus los gastos planeados en condiciones aceptables? 65 . Suite de pruebas (opcional) La suite de pruebas desarrollada debería ser provista en la situación donde el cliente necesite ejecutar pruebas básicas en sitio.

Comunicación pobre entre usuarios y miembros del equipo. Disciplinas 66 Descripción A Modelado de negocio Escribir código B Requisitos Reglas de negocio C Análisis y diseño Configurar infraestructura D Implementación Organización de componentes E Pruebas Establecer cronogramas F Despliegue Identificar problemas G Gestión de la configuración Preparar espacios de trabajo H Gestión del proyecto Recoger necesidades I Entorno Validar escenarios .Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE Autoevaluación 4 Estimado estudiante. E Gestionar los cambios Arquitectura basada en componentes Ambigüedad en las especificaciones del sistema. cuyas respuestas no encontrará de manera directa en el material. 2. Escaso o nulo seguimiento de los requerimientos. para ello sírvase responder a las siguientes interrogantes. le invitamos a medir cuánto a asimilado de la presente unidad. Para asociarlas coloque las letras de las mejores prácticas en las filas correspondientes de los problemas. recuerde que la primera actividad que se planteó en esta unidad era establecer estos problemas. Calidad pobre de los productos de software. Muchos errores al finalizar el proyecto. ahora que ha comprendido cómo funciona el proceso unificado de desarrollo. 1. Asocie las buenas prácticas de la ingeniería de software. sino que le obligarán a realizar análisis y aplicación de los temas contemplados. con los problemas que motivaron su aparición. Riesgo alto durante la mayor parte del proyecto. Mejores prácticas A Problemas que resuelven Elemento de software difíciles de reutilizar. B F Largo tiempo para ver resultados. Estimaciones pobres del proyecto. C Desarrollo iterativo Verificación continua de la calidad Gestionar requerimientos D Modelar visualmente Requerimientos incorrectos en fases iniciales. Poca flexibilidad para cambios en el proyecto. Insistimos en la importancia de resolverlas como estrategia de aprendizaje. Incremento de costos en etapas finales del proyecto. si tiene alguna duda es momento de acudir a la tutoría. Asocie la disciplina del RUP con el producto de trabajo correspondiente. para ello coloque la letra de la disciplina en la columna de las descripciones.

b. Organice artefactos dados colocándolos en la fase del proceso unificado correspondiente: arquitectura de software. b. modelo de análisis. documento de visión. 7. 6. caso de negocio. Los testers El arquitecto de software El gerente de proyecto Los desarrolladores Especificaciones suplementarias Modelo de análisis Modelo de casos de uso Plan de iteraciones ¿Cuál de las fases del RUP se establece como concluida cuando el cliente y los usuarios están conformes con el producto? a. b. c. d. material de soporte para usuarios finales. 8. d. modelo de datos. Analizando los roles de las personas que forman parte de un proyecto de desarrollo de software según el RUP. ¿Cuál de los artefactos puede usarse para realizar la evaluación financiera del proyecto? a. d. Documento de visión Modelo de datos Análisis de stakeholders Especificación de casos de uso ¿Cuál de los artefactos especifica los requerimientos no funcionales? a. c. c. c. en los costos y alcance establecidos y con los niveles de calidad esperados? a. ¿cuál es el rol responsable de que el proyecto se termine a tiempo. El documento de visión El caso de negocio El modelo de costos El caso de uso ¿Cuál de los siguientes documentos captura y resume las necesidades de los usuarios? a. d. b. Fase de modelado Fase de construcción Fase de elaboración Fase de transición Ir a solucionario 67 . b.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE 3. d. producto. Fase Artefacto Inicio Elaboración Construcción Transición SELECCIONE LA ALTERNATIVA CORRECTA EN CADA UNA DE LAS SIGUIENTES PREGUNTAS: 4. modelo de diseño. 5. c.

el objetivo del modelo del análisis es describir los dominios de información. El modelo de clases se usa para representar la estructura del sistema y asociado a interacciones puede reflejar el comportamiento del sistema.1. Tabla 5. nos apoyaremos en una herramienta de modelado conocida como Rational Rose. El análisis de los requerimientos da como resultado la especificación de las características del software y cómo se ha de comportar muestra la interfaz y elementos del comportamiento esperado del sistema expresado en interacciones usuario-sistema. vamos a iniciar esta unidad estudiando cómo modelar los requerimientos. se considerará además cuestiones de diseño y arquitectura del sistema los cuales son la base para el inicio de la fase de construcción. en el cual manifestábamos que como una mejor práctica. “Modelado de los requerimientos: escenarios.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE UNIDAD 5: MODELADO DEL SOFTWARE: ANÁLISIS. que podríamos entenderlas como historias de usuario. para representar este modelo se usan diagramas de clases y diagrama de colaboración. El modelo cambia en forma dinámica a medida que se aprende más sobre el sistema por construir. pero ahora los vamos a revisar de una forma más clara. modelos orientados al flujo y modelos de comportamiento. informes y clases de análisis” del texto básico y veremos los diferentes enfoques para representar los requerimientos y los modelos asociados a los mismos. Realice una lectura del capítulo 6. Si se fija en la figura 6. 5. aquí podemos encontrar: modelado basado en escenarios. modelado de datos.1 Componentes del modelo de requisitos Requerimientos de software Modelo basado escenarios Modelo de clases 68 en Los escenarios reflejan diferentes situaciones que pueden darse durante la ejecución de un sistema. La figura 6. estamos hablando de un punto intermedio entre la descripción del sistema y el modelo de diseño.1. DISEÑO ARQUITECTURA Una vez que hemos conocido el proceso unificado de desarrollo. la técnica de modelado para estos escenarios y la más difundida por su versatilidad y simplicidad es la de los casos de uso.3 del texto básico notará 4 componentes del modelado de requerimientos que resumimos en la tabla 5. . Modelado de requerimientos El modelo de análisis es una forma de representar los requerimientos en cualquier momento.1 del texto básico nos muestra en dónde se encuentra el modelado del análisis. proponía el modelado visual de los componentes. modelos orientados a clases. En el capítulo 2 revisamos el resultado que se obtiene como acción de modelar los requerimientos.

estos se representan en los diagramas de estados y diagrama de secuencia.omg. 5. leer mensajes de texto. etc. Esto lo podemos lograr con las dos primeras tareas que se tienen que realizar en la obtención de requerimientos. html#EspCU. lo que algunos llaman caso preliminar de uso. objetivos operativos. que es lenguaje de modelado de componentes de software reconocido como un estándar por el Object Management Group18. prioridades. alcance. Ejercicio 5.upv. son la concepción e indagación. disponible en www. ¿cuáles son los requerimientos funcionales? y ¿qué cosas se manipulará en el sistema? Así debemos empezar a escribir el caso de uso de forma tal que se presenten las funciones o actividades que hace un determinado actor. En base a esto identificaremos participantes del proyecto. Para comprender lo que es un caso de uso. Como vemos los artefactos de trabajo con los que se modelarán los requerimientos son artefactos de UML. los cuales normalmente se usan en las técnicas de análisis estructurado.2. Cada vez que se mantiene conversaciones con el participante se van recabando los casos de uso. para luego pasar a un formato estructurado que puede ya existir con las modificaciones del caso según se necesite.dsic. enviar mensajes de texto. pensemos en aquellas cosas que podemos hacer con un sistema. contestar llamadas. Este es un ejemplo de modelado a partir de casos de uso de la Universidad Politécnica de Valencia.es/asignaturas/facultad/lsi/ejemplorup/Requisitos.1 Ingrese a la dirección siguiente y estudie los diferentes artefactos de la sección de requisitos http://users.org 69 . pueden representarse en base a dos componentes que son: los diagrama de flujo de datos y los modelos de datos. Naturalmente 18 Object Management Group. Estos modelos se enfocan en representar como fluyen los datos entre procesos del sistema. Esto lo puede lograr el equipo de software caracterizando adecuadamente los requerimientos y haciendo un análisis significativo. Modelado basado en escenarios El éxito consiste en saber cómo desean interactuar los usuarios finales con un sistema. piense por un momento en su teléfono celular como un sistema (en realidad lo es). los casos de uso para ese sistema sería las cosas que como usuario usted puede hacer como realizar llamadas. El primer escenario que podemos encontrar es desarrollar casos de uso. Primeramente los casos de uso pueden escribirse como una narración informal. ¿las recuerda?.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE Requerimientos de software Modelo comportamiento de Modelo de flujo El comportamiento entre componentes del sistema ayuda a establecer la manera de implementar eventos y los flujos de operaciones entre componentes. esto desde el punto de vista del usuario.

Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE estos casos de uso surgieron de los requerimientos y estos a su vez de las necesidades planteadas por los usuarios. RN02: Duración de la batería mínima de 30 horas en audio. Desarrollemos otro ejemplo sencillo. RN03: Interfaz sencilla para operación en movimiento. mp4. RF02 RF03 RF04 RN03 RN04 RN07 RN09 70 . Tabla 5. N1: Escuchar 30 horas de música al menos y que guarde aproximadamente 5000 canciones en dispositivo portátil. RN06: Pantalla de 4” a colores. RN09: Emisión señal FM. RN07: Pantalla táctil. “se desea construir un dispositivo de bolsillo que permita escuchar música bien sea a través de auriculares. reproducción aleatoria y reproducción secuencial. RN08: Soporte aplicaciones Java. con una duración de batería mínima de 30 horas y una capacidad de almacenamiento suficiente para 5.2. Permite organizar la música y los videos en el dispositivo en base a las preferencias del usuario. En la tabla 5. Tabla 5. Permite la selección y reproducción de los archivos de audio con opciones de control de volumen.000 canciones. RN04: Soporte para formato de audio mp3 y wav. RF06: Cargar archivos de video.3. Posibilidades de juegos. podemos apreciar este análisis que nos permite identificar requerimientos funcionales y no funcionales. vamos a comenzar traduciendo las necesidades a requerimientos. RF05 UC02: Reproducir música. reproducir videos con posibilidad de almacenar al menos 500 videos y posibilidades de juego”. N3: RF08: Cargar juegos. RF09: Ejecutar juego. esto lo podemos apreciar en la tabla 5. Para resolver este problema. RN05: Soporte para formato mpg.2 Mapeo de necesidades a requerimientos Necesidades Requerimientos funcionales Requerimientos no funcionales RF01: Cargar música de manera organizada RF02: Reproducir música a través de auriculares RF03 Reproducción secuencial y aleatoria RF04: Control de volumen RF05: Organizar listas de reproducción RN01: Dispositivo portátil peso máximo de 150 gramos. N2: Reproducir videos. Como siguiente paso definiremos los casos de uso necesarios para atender estos requerimientos. los cuales pueden ser funcionales o no funcionales. Mapeo de necesidades a requerimientos Nombre de caso de uso Descripción Requerimientos UC01: Organizar música. Guarde aproximadamente 500 videos.3. RF07: Reproducir formatos de video. parlantes o que transmita el audio en frecuencia FM.

Permite la comunicación con un ordenador para cargar los archivos de audio.1. video y aplicaciones en Java. representa una vista parcial de las funcionalidades disponibles en un iPod (reproductor de música y video). Ejecuta juegos implementados en lenguaje Java y permite la interacción del usuario con el mismo. y es importante analizar algunos aspectos. Conteste a las interrogantes siguientes: a. En base a esta información podemos diseñar el modelo de casos de uso que se aprecia en la figura 5.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE Nombre de caso de uso Descripción Requerimientos UC03: Reproducir video.1. Figura 5. El diagrama de casos de uso siguiente. para ello desarrolle las siguientes actividades: 1. RN05 UC04: Jugar. Modelo de casos de uso para el reproductor de música y video. En esta forma hemos establecido cómo podemos pasar de la captura de necesidades del cliente a la especificación de requerimientos y estos a su vez a casos de uso. Ejercicio 5. Permite la selección secuencial o en listas de los RF07 archivos de video en los formatos especificados. RF01 RF06 RF08 UC06: Crear listas de reproducción.2 Como habrá notado. hay algunos aspectos importantes al momento de mapear las necesidades a casos de uso. RF05 Permite agrupar canciones en base a las preferencias del usuario que le permititán reproducir sus canciones favoritas agrupadas conforme lo requiera el usuario. RF09 RN07 RN08 UC05: Sincronizar información. ¿Qué sucedió con los requerimientos funcionales? ¿Fueron resueltos todos en los casos de uso? 71 .

Ahora intente desarrollar un diagrama de canal que le permita registrar el proceso de matrícula en su centro universitario. y lo importante de ella es que nos permite asegurarnos que todas las funcionalidades del sistema atienden a necesidades de los usuarios. ¿se puede asegurar que todas las necesidades están contempladas en los casos de uso? d. 5. a esta característica la conocemos como trazabilidad de artefactos de software. SEGUNDO BIMESTRE b.3 Desarrolle un diagrama de actividades para una de las posibles funciones que se realizarían en alguno de los casos de uso del ejercicio sobre el reproductor multimedia. Esto lo puede determinar en la figura 6. Modelado basado en clases Los modelos de clases se usan para representar la estructura (conocida también como parte estática) del sistema. y todas la necesidades de los usuarios están resueltas en alguna de las funcionalidades.3. El ejercicio ahora consiste en diseñar este programa en base a las necesidades. ¿Cómo le pareció el ejercicio? Esperamos que lo haya completado. 5. reproductor fm. Ejercicio 5. salida de audio. ¿Se puede asegurar que todos los casos de uso se basan en requerimientos y estos a la vez en necesidades? Y viceversa. Uno de los primeros es el diagrama de actividades. y representa los objetos que formarán parte del sistema. luego la de casos de uso y completar con el diagrama para un sistema como lo es un teléfono celular. flechas para determinar el flujo y los rombos para determinar decisión. las operaciones que se aplicarán. Ahora luego de responder el primer bloque de preguntas queremos comentarle la importancia que tiene el poder hacer este seguimiento desde las necesidades hasta los casos de uso hacia adelante y hacia atrás. 72 .Guía didáctica: Fundamentos de Ingeniería de Software 2. ¿Cómo afectaron a los casos de uso los requerimientos no funcionales? ¿Cómo se atienden los requerimientos no funcionales que no pasaron directamente a los casos de uso? c.4. por favor no avance si no lo hizo. hacer las tablas de requerimientos. Modelado UML para casos de uso Vamos a revisar ahora algunos modelos UML que nos ayudarán a ver la información de un caso de uso en forma más clara. hemos colocado algunos actores entre los que podemos mencionar: usuario. las relaciones entre los objetos y la colaboración que tiene entre las clases. itunes. ¿Cuántos requerimientos fueron atendidos por cada caso de uso? ¿Cuántos casos de uso han sido considerados por cada requerimiento? Como habrá notado. en este caso itunes es una aplicación que permite cargar los archivos al reproductor. cuyos elementos los que vemos en la tabla son rectángulos redondeados para una función específica.5 del texto básico.

esta herramienta para fines educativos podrá utilizarla libremente. revise el apartado 6. además de dónde seleccionar la utilización de la herramienta. diagrama de secuencias y otros artefactos de software. Del análisis de los escenarios desarrollados.5. diagrama de actividades.SEGUNDO BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software El primer paso es identificar las clases. En la figura 5. para saber cómo. Esta clave será única por estudiante y para una sola computadora. Esa sería una primera aproximación de las clases. 73 . “Identificación de las clases de análisis”. esto debemos poderlo determinar. A continuación le mostramos la imagen principal de la herramienta: Figura 5. Debe familiarizarse con la misma y a su vez realizar los ejercicios y ejemplos que se listan en el texto con la ayuda de esta herramienta. • Debe contactarse con su profesor pues necesitará obtener una clave. las clases se determinan subrayando cada sustantivo o frase. Para el desarrollo de los diagramas que necesita se pueden emplear algunas herramientas. a continuación le presentamos algunas directrices para trabajar con Rational Rose. Su profesor le explicará los pasos a seguir. Tipos de diagramas en Rational Rose. Si la clase se requiere para implementar una solución o si solo es parte del espacio.2 puede ver dos tipos de diagramas que se están realizando. • Posterior a esto puede empezar a trabajar en esta herramienta la misma que le permitirá realizar diagramas de clases.2. para lo cual deberá seguir los siguientes pasos: • En el CD adjunto encontrará el instalador del mismo.1.

5. Cit.7. donde aprenderá cómo modelar la estructura del sistema y la relación que existe entre los datos y los componentes del sistema. Entonces revisemos el apartado 9.6.5. lo importante en este caso es conocer las características de los diferentes estilos y patrones de arquitecturas para poder adaptarlos a los diferentes contextos en donde se requiera la aplicación. de donde podemos encontrar esta taxonomía20: • Arquitectura centrada en datos.de/taxonomia/ 74 . Se trata de la ciencia de la clasificación. etc. p. luego haga una lista de software que conoce y clasifíquelos.1 del texto básico. Las figuras que se presentan en este apartado nos dan una idea de cada una de estas arquitecturas. Géneros y estilos arquitectónicos “El género arquitectónico es el que dicte el enfoque específico para la estructura que deba construirse”19. Breve taxonomía de estilos arquitectónicos A continuación revisaremos los estilos arquitectónicos que son base de muchos sistemas basados en computadores. 20 Taxonomía tiene su origen en un vocablo griego que significa “ordenación”. Arquitectura de software En el capítulo 9. mantenibilidad entre otros. 209. • Arquitectura de llamar y regresar. 19 Pressman R. esto será de gran utilidad cuando se traten temas de diseño. las cuales puede aplicarse igualmente a muchos tipos de escenarios.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE 5. http://definicion. usted encontrará información abundante sobre lo que es la arquitectura del software.3. En el ámbito de las aplicaciones corporativas podemos encontrar diferentes tipos de arquitecturas. En este capítulo del texto básico encontramos algunos géneros arquitectónicos para sistemas de software. Debe revisarlas y sacar los puntos principales de cada una de ellas. Muchos sistemas se desarrollan sin tener en consideración la arquitectura y terminan como aplicaciones con serios problemas de escalabilidad. C++ (herramientas). revise estos temas. este tema debe estar claramente comprendido para su uso en el desarrollo de proyectos de software. de esto se obtendrán muchas categorías dentro del dominio de software. estudie este capítulo en el texto. (2010). Ed. 5. “Diseño de la arquitectura” del texto básico. Por ejemplo: Windows (sistemas operativos). • Arquitectura de flujo de datos. • Arquitectura en capas. • Arquitectura orientada a objetos.

Diseño arquitectónico La definición del contexto donde se desarrollará el software es una tarea principal del diseño arquitectónico. Ahora ingrese al EVA para que responda el foro sobre Arquitectura de la Aplicación.5 del texto básico se presenta un DCA. 75 . Como actividad le recomendamos revisar un sistema donde usted puede determinar cuáles y cómo se relacionan o cómo interactúan los sistemas con el sistema principal. En la figura 9. Revise este apartado y encuentre la definición de arquetipo además de entender cómo se ejecuta el proceso para obtener una arquitectura completa. revise cada uno de los componentes que se muestran y asegúrese de comprender los conceptos de cada uno de ellos.SEGUNDO BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software 5. para ello es necesario desarrollar esta autoevaluación. Revise el apartado sobre refinamiento del sistema en el texto básico y analice el ejemplo de mapeo de arquitectura con el uso de flujo de datos. Como actividad recomendada debe descargar una herramienta de software de diseño arquitectónico en una versión de prueba para que analice su funcionamiento. el mismo que permite modelar la forma en que el software se relaciona con otras entidades. Considere por ejemplo los sistemas superiores que se encuentran en la parte superior del gráfico y su definición. La definición de arquetipos son “una clase o un patrón que representa una abstracción fundamental de importancia crítica para el diseño de una arquitectura para el sistema objetivo”. Representación del sistema en contexto En este apartado se tratará el tema de un diagrama de contexto arquitectónico (DCA). Recuerde que esta participación es calificada como parte de la evaluación a distancia. Ahora conviene comprobar cuánto hemos asimilado de los temas tratados. será muy importante que participe en dicho foro y aporte sobre los criterios que han realizado sus compañeros. Hemos concluido el estudio de esta unidad. Estos arquetipos son los bloques para la construcción de un diseño arquitectónico. definiendo entidades externas con las que interactúa el software y la naturaleza de dicha interacción.8.

4. Como estrategia le recomendamos que primero ubique el tema sobre el que le habla la pregunta. 8. estamos modelando el análisis. estos están dentro del tipo de modelos orientado a clases. ubique la información necesaria en el texto o en la guía didáctica y fundamente su respuesta. Ir a solucionario 76 . diríamos que estamos trabajando en la arquitectura del sistema. 6. ( ) Un sistema bancario donde se permita la realización de transacciones en línea podría considerarse con un género arquitectónico definido. debe existir una única relación en un solo sentido entre dos objetos. ( ) Un software que está diseñado para trabajar con una interfaz de escritorio puede ser una aplicación de tres capas. entonces. 5. 1. ( ) Al tener en cuenta la flexibilidad para un sistema software y considerarla como un requisito no funcional. ( ) Si se quiere tener un descripción completa de la funcionalidad a través de la especificación de un caso de uso las interacciones alternativas dentro de la misma son fundamentales. ( ) La elaboración de los casos de uso se encuentran dentro del modelado de requerimientos. este sistema contable debe ser considerado en la arquitectura. y al emprender el desarrollo de un sistema de registro de compra-venta (facturación) e inventarios el cual proporcionará información al primero. 7. ( ) De acuerdo al tipo de base de datos que vamos a utilizar. 10. o sea los requerimientos que se levanten deben considerar modelos no funcionales. podemos considerar cómo estará el acceso a los datos para el sistema.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE Autoevaluación 5 Lea detenidamente cada una de las preguntas planteadas en la siguiente tabla y determine si la proposición es verdadera o falsa. ( ) Al contar con un sistema contable dentro de la organización. ( ) Si estamos en la etapa de diseño y en base a los requerimientos. 3. se debe realizar una especificación de caso de uso para este requerimiento. 2. ( ) Con la ayuda de las flechas en una relación se puede determinar la dirección de la misma. ( ) Para el diseño de la arquitectura podemos encontrar elementos de modelado basado en escenarios y modelos basado en clases. 9.

es decir. entonces es por esta razón que comenzaremos hablar sobre la calidad del software. Etc. pues las metodologías y herramientas de la ingeniería de software tienen un único fin: producir software de alta calidad. • • • • • • Calidad. A lo largo de este capítulo vamos a realizar un estudio. entonces es inútil tenerlo aunque pudiera tener atributos de “calidad” como los tiempos de respuesta. la cual más allá de los conceptos y definiciones que encontrará más adelante. más aún con la difusión de las TI en el día a día de las organizaciones. seguridad. ejecutar y monitorear. estas frases están en el texto básico. Ahora revisemos este concepto de Pressman en 1992 dijo: “Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente”. y el razonamiento es bastante simple.1. interfaz amigable. 77 . 6. puede escribirse en tres palabras: “satisfacción del cliente”. sabes lo que es. Continúe con el estudio apoyándose en el subrayado de los temas correspondientes al capítulo 14 del texto básico para determinar frases relacionadas con calidad para que le permitan tener una mejor idea. se debe planificar. etc. llegar a un proceso de aseguramiento donde el principal beneficiario es el cliente. Como lo podemos notar debe haber una sincronización entre todas las actividades que se llevan a cabo para el desarrollo de productos software. Conceptos de calidad Vamos a empezar esta unidad obteniendo algunas frases que nos pueden ayudar a entender el concepto de calidad.SEGUNDO BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software UNIDAD 6: CALIDAD DEL SOFTWARE Al igual que en muchos otros ámbitos del quehacer humano. la calidad del software no solo se puede medir. y entender por qué tantas empresas y organizaciones invierten tanto en obtener calidad. Lo que el cliente está dispuesto a pagar. Algo que se reconoce de inmediato pero que no es posible definir explícitamente. pero no sabes qué es… Concepto complejo y de facetas múltiples.. entonces los requisitos del software son la base de las medidas de calidad del mismo. si el software no le sirve al usuario. Especificaciones originales del producto. facilidad de uso. el factor de la calidad ha cobrado importancia radical en el mundo del desarrollo de software. Han existido muchas aseveraciones de los costos que se hacen para corregir los programas defectuosos y también cuánto software es inútilmente desarrollado porque al final no cumple con las funcionalidades para lo que fue desarrollado. etc..

Ed. caso contrario puede apoyarse en una relectura o en una tutoría. ¿están estos relacionados con los factores que se persiguen para el desarrollo de software? 21 Pressman R. Revisemos algunas actividades para el aseguramiento de calidad del software dentro de las que podemos mencionar: • Métricas de software para el control del proyecto. (2010). A continuación revise los 6 factores de la calidad ISO 9126 en el mismo apartado del texto básico con la cual se pueden ir afianzando los temas sobre calidad del software aunque muchos de ellos no proporcionen medidas directas. entonces ¿cree que buscar la calidad del software está orientado a obtener mayores utilidades a través del producto software que se desarrolló? Cree que alguna actividad sombrilla está involucrada en el proceso de calidad del software. 78 . las mismas que se presentan en el texto básico. incluyendo pruebas y proceso de revisión. recuerde que esas dimensiones no fueron específicas para el software. ¿Cuáles cree que son esas actividades? Si respondió a estas interrogantes sin dudarlo. Realice un cuadro donde clasifique los mismos por la medida que nos proporcionan directa o indirecta. los cuales nos dan medidas directas e indirectas de la calidad. • Gestión de la configuración del software. Repase nuevamente estos puntos: proceso eficaz de software.2. pero las podemos adoptar. Calidad del software Tomemos la definición “proceso eficaz de software que se aplica de manera que crea un producto útil que proporciona valor medible a quienes lo producen y a quienes lo utilizan”21: En base a esta definición vamos a encontrar tres aspectos que hacen relación a esta definición y que se presentan en el texto básico como calidad del software. Revise estas dimensiones de la calidad.2. teniendo esto podríamos decir que estas dimensiones pueden considerarse de forma objetiva o no.Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE 6. 340. Conteste a las siguientes interrogantes: ¿cuál sería la diferencia o la similitud entre los factores de la calidad de McCall y los ISO 9126?. p.2 los factores que han sido propuestos por McCall. Hablaremos ahora sobre las 8 dimensiones de la calidad que son las planteadas por Garvin. Ahora revise en el apartado 14. Cit. producto útil y agregar valor para el producto y para el usuario. • Proceso de verificación y validación del software a lo largo del ciclo de vida de desarrollo. Entonces tiene clara la idea y podemos continuar.

3. se presentan cifras muy elevadas pero que al final nos reflejan en otros factores no solo económicos sino también operativos para la empresa.2. al estar presente en el proceso de calidad del software debe estar considerada en el proceso de aseguramiento de la calidad o al realizar control.1 “Software suficientemente bueno” y 14. Entonces ¿qué hacer. el efecto de las acciones de la administración que son tratadas en este apartado a las cuales se les debe poner la respectiva atención. Del primer apartado podremos ayudarle a su comprensión diciendo que de acuerdo al contexto donde se desarrolle este software conocido como suficientemente bueno depende su aplicación.. No será lo mismo utilizar este concepto en empresas grandes que en empresas pequeñas. Técnicas de administración de proyectos. esto se ve reflejado con la ayuda de 4 actividades que las encontraremos en el apartado 14. Existen temas como riesgos. pues tener una mala reputación es un costo externo que podría ser incalculable. Control de calidad. con la ayuda de un sinnúmero de actividades paralelas al desarrollo como la administración del proyecto y el seguir un proceso de desarrollo. “El costo de la calidad”. calidad y seguridad. ¿Cómo lograr la calidad del sotware? ¿Cómo se logra la calidad del software?. realmente será un software de muy mala calidad. pues se utilizarían demasiados recursos. La seguridad del software. procesos relacionados con esta actividad podemos mencionar muchos. Como podrá notar. Hablemos del segundo apartado y para ello podemos fijarnos en la figura 14. corregir las fallas en etapas iniciales es mucho menos costoso que hacerlo cuando el producto ya está implementado.4.3. negligencia y responsabilidad. Métodos de la ingeniería de software. Por ejemplo tomemos el tema de seguridad. son aquellos que ya revisamos en la unidad 3 de esta asignatura.2.pmi. serán las acciones de la IS las que permitan asegurar el cumplimiento del trabajo para el desarrollo del producto software. demasiado tiempo y al final un software muy costoso que quizá nadie compre o un software de tan mala calidad que todo lo invertido no se pueda recuperar porque nadie lo compra. 22 Project Management Institute. 6. por ejemplo tenemos especializaciones dentro del campo laboral en gerencia de proyectos del Project Management Institute (PMI)22. http:\\www. Dilema de la calidad del software ¿Por qué un dilema? Vamos a plantear dos cosas: un software bueno que cumpla todo será entonces muy caro.SEGUNDO BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software 6.3.? Para poder entender este dilema debemos entonces revisar los apartados del texto básico 14. un software que sea fácilmente vulnerable. tenemos las etapas de construcción de software. “Lograr la calidad del software” del texto básico en el cual podrá profundizar en los métodos de aseguramiento de calidad.4.org 79 . lo cual debe ser considerada desde la etapa de inicio de desarrollo del proyecto.

si se desea conocer más sobre estos temas. • La utilización de las dos anteriores (metodología y el medio de valoración) tienen que estar reconocidos por quienes están inmersos en el desarrollo. Hemos concluido el estudio de esta unidad. • PEMM (Performance Engineering Maturity Model). • ISO 9001 (International Standard Organization). Algunos autores relacionados con la ingeniería de software mencionar los pilares básicos para lograr una certificación. este campo es muy amplio y en el texto básico pueden profundizar este tema. • SP (Personal Software Process) /TSP (Team Software Process). para ello es necesario desarrollar esta autoevaluación. entre ellos: • Llevar una metodología correcta durante el proceso. Ahora nos conviene comprobar cuanto hemos asimilado de los temas tratados. 80 .Guía didáctica: Fundamentos de Ingeniería de Software SEGUNDO BIMESTRE Aseguramiento de la Calidad: conformar un equipo de ser posible que ayude a esta actividad dentro del desarrollo. • Tener un medio de valoración de la metodología que se está llevando. fácilmente encontrará documentación en Internet: • CMM (Capability Maturity Model). A continuación mencionaremos algunos modelos de calidad del software para su información. • SPICE (Software Process Improvement and Capability Determination).

se debe cuantificar este proceso al momento de realizar una estimación de costo del producto. 8. ( ) Se debe planificar un proceso de pruebas. Como estrategia le recomendamos que primero ubique el tema sobre el que le habla la pregunta. ( ) La eficiencia de un producto software está enfocada a poder utilizar el mismo en diferentes plataformas. 4. ubique la información necesaria en el texto o en la guía didáctica y fundamente su respuesta. ) La calidad del software se consigue por medio de la aplicación de métodos de ingeniería de software. 10. ( ) Un costo de falla interno lo podríamos adjudicar a la reputación que tendrá el equipo de analista ante el cliente. 3. 5. ( ) El software de alta calidad cumple con los requerimientos no funcionales con los que se espera cuente el mismo. 2. ( ) Revisar la codificación realizada en la interfaz corresponde al proceso de aseguramiento de calidad. 9. 7. ( ) Un costo externo de falla se lo podría mencionar al proceso de actualización de una versión a otra. ( ) Una característica de calidad del software podría estar incrustada en la forma como el usuario llega a una funcionalidad o la facilidad de utilización del mouse.SEGUNDO BIMESTRE Guía didáctica: Fundamentos de Ingeniería de Software Autoevaluación 6 Lea detenidamente cada una de las preguntas planteadas en la siguiente tabla y determine si son verdadersa o falsas. ( ) La eficiencia hace mención a los recursos. 6. ( ) Si al software se le realiza un mantenimiento o se lo corrige. se dice que no es un software de calidad. esta característica se considera como un factor de la calidad en sus diferentes formas. 1. ( Ir a solucionario 81 .

(V) 10.Guía didáctica: Fundamentos de Ingeniería de Software SOLUCIONARIO 7. (V) 7. (V) . (F) 8. (F) 9. (V) 6. (F) 4. (F) 5. (V) 2. (V) 3. Solucionario UNIDAD 1 82 Pregunta Respuesta 1.

(F) 11. (F) 6. (V) 8. (V) 3. c 83 . (F) 9. (F) 4. (F) 7. (F) 10.Guía didáctica: Fundamentos de Ingeniería de Software SOLUCIONARIO UNIDAD 2 Pregunta Respuesta 1. (V) 5. b 12. (V) 2. c 13.

Guía didáctica: Fundamentos de Ingeniería de Software SOLUCIONARIO UNIDAD 3 84 Pregunta Respuesta 1. (F) 5. (V) 4. (V) 7. (F) 3. (V) 8. (F) 9. (V) 2. (V) 6. (F) 10. (V) .

él tiene función de: organizar el equipo. Elaboración Arquitectura de software. Transición Producto. no es una alternativa válida. puesto que no es un artefacto. lo que nos deja como única alternativa al caso de negocio. H 6. F 4. por lo tanto. B 12. G 5. Modelo de análisis. E 10.Guía didáctica: Fundamentos de Ingeniería de Software SOLUCIONARIO UNIDAD 4 Pregunta 1 Respuestas Pregunta 2 Respuestas 1. D 3. E 11. pero no maneja costos y el modelo de casos de uso son funcionalidad. planificar iteraciones. A 3. 4. E 3. D 5. D 2. Construcción Modelo de diseño. C 4. A 2. Caso de negocio. el documento de visión especifica el alcance. 5. F 9. F 1. ( c ) Si revisa las responsabilidades del gerente de proyecto. C 6. gestión de riesgos. se dará cuenta de que el modelo de costos (c). monitoreo y control. Fase Artefacto Inicio Documento de visión. C 7. B 9. ( b ) Si revisa las alternativas. G 8. Material de soporte para usuarios finales. armar equipos de trabajo. B 7. él debe asegurarse de que se han solucionando todos los problemas para que el proyecto se cumpla en las condiciones estipuladas. 85 . Modelo de datos. A 8.

la opción (b) se valida con la consecución de una versión beta del sistema. ( d ) La opción (a) no corresponde a una fase. fase de transición.Guía didáctica: Fundamentos de Ingeniería de Software SOLUCIONARIO 6. ( a ) Los casos de uso contienen requerimientos funcionales. sin embargo no tienen directamente las necesidades. es una actividad. basados en los requerimientos obtenidos de las necesidades. no un documento. por tanto (d) es incorrecto. 86 . el modelo de análisis contiene los modelos de clases y el plan de iteraciones especifica cómo se llevará a cabo el proyecto en cada fase. la opción (c) se valida con la arquitectura del sistema. por lo tanto la única solución válida sería el documento de especificaciones suplementarias. por lo tanto incorrecto. el análisis de stakeholders (c). la única opción válida sería la opción d. 7. el modelo de datos es un artefacto técnico que no tienen que ver los usuarios y por tanto la única alternativa es el documento de visión (a) cuyo propósito es establecer las necesidades y el alcance del sistema. 8. ( a ) Las especificaciones de casos de uso representan interacciones sistema-usuario.

(F) 7. (V) 9. (V) 4. (V) 5. (F) 3.Guía didáctica: Fundamentos de Ingeniería de Software SOLUCIONARIO UNIDAD 5 Pregunta Respuesta 1. (V) 8. (V) 10. (V) 87 . (V) 2. (V) 6.

Guía didáctica: Fundamentos de Ingeniería de Software SOLUCIONARIO UNIDAD 6 Pregunta Respuesta 1. (V) PAE&DJH/ vtc/ 2011-06-21/ 84 kvv/2015-12-28 88 . (V) 2. (F) 10. (V) 6. (F) 4. (F) 3. (V) 7. (F) 9. (V) 5. (V) 8.