Guia Didáctica

UNIVERSIDAD TCNICA PARTICULAR DE LOJA
La Universidad Catlica de Loja

MODALIDAD ABIERTA Y A DISTANCIA
Departamento de Ciencias de la Computacin y Electrnica

Seccin Ingeniera del Software y Gestin de Tecnologas de la
Informacin
Fundamentos de Ingeniera de
Software
Gua didctica
4 crditos
Titulacin
Informtica
Ciclo
Autores:
Ing. Marco Patricio Adab Espinoza

Ing. Danilo Rubn Jaramillo Hurtado
18505
Asesora virtual:
www.utpl.edu.ec
FUNDAMENTOS DE INGENIERA DEL SOFTWARE

Gua didctica
Marco Patricio Abad Espinoza

Danilo Rubn Jaramillo Hurtado
Corrector de estilo: Carlos Vacacela
UNIVERSIDAD TCNICA PARTICULAR DE LOJA
CC Ecuador 3.0 By NC ND
Diagramacin, diseo e impresin:
EDILOJA Ca. Ltda.
Telefax: 593-7-2611418
San Cayetano Alto s/n
www.ediloja.com.ec
[email protected]
Loja-Ecuador
Primera edicin
Novena reimpresin
ISBN fsico-978-9942-08-019-6
ISBN digital-978-9942-04-218-7
Esta versin 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 pblicamente la obra, mientras se reconozca la autora 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. Introduccin.................................................................................................................... 5
4. Bibliografa..................................................................................................................... 6
4.1. Bsica......................................................................................................................... 6
4.2. Complementaria......................................................................................................... 6
5. Orientaciones generales para el estudio........................................................... 8

6. Proceso de enseanza-aprendizaje para el logro de competencias..... 11
PRIMER BIMESTRE
6.1.
6.2.
6.3.
6.4.
Competencias genricas............................................................................................. 11
Planificacin para el trabajo del alumno.................................................................... 11
Sistema de evaluacin de la asignatura (primero y segundo bimestres).................. 13
Orientaciones especficas para el aprendizaje por competencias............................... 14
UNIDAD 1: INTRODUCCIN A LA INGENIERA 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 prctica de la ingeniera de software..................................................................... 18
Autoevaluacin 1.................................................................................................................. 20
UNIDAD 2: PROCESOS DE CONSTRUCCIN DEL SOFTWARE........................................................ 21

2.1. Ingeniera de requerimientos...................................................................................... 22
2.2. Preparar el camino a la obtencin.............................................................................. 24
2.3. Indagacin de los requerimientos............................................................................... 25
2.4. Desarrollo de casos de uso......................................................................................... 25
2.5. Elaboracin del modelo de los requerimientos........................................................... 27
2.6. Validacin de los requerimientos................................................................................ 27
2.7. Diseo en el contexto de la ingeniera del software.................................................. 28
2.8. El proceso de diseo................................................................................................... 29
2.9. Conceptos de diseo.................................................................................................. 29
2.10. Modelo del diseo...................................................................................................... 30
Autoevaluacin 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

Evaluacin 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. Programacin extrema............................................................................................... 38

3.8. Otros modelos giles.................................................................................................. 39
Autoevaluacin 3.................................................................................................................. 41
SEGUNDO BIMESTRE
6.5. Competencias genricas............................................................................................. 43
6.6. Planificacin para el trabajo del alumno.................................................................... 43
6.7. Orientaciones especficas para el aprendizaje por competencias............................... 45
UNIDAD 4: APLICACIN DE UN MODELO DE PROCESOS RUP..................................................... 45

4.1. Mejores prcticas de la ingeniera del software......................................................... 45
4.2. Caractersticas principales del RUP............................................................................. 50
4.3. Navegando por el proceso unificado de desarrollo..................................................... 52
4.4. Desarrollo de software con el Proceso Unificado...................................................... 55
Autoevaluacin 4.................................................................................................................. 66
UNIDAD 5: MODELADO DEL SOFTWARE: ANLISIS, DISEO 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. Gneros y estilos arquitectnicos............................................................................... 74
5.7. Breve taxonoma de estilos arquitectnicos............................................................... 74
5.8. Diseo arquitectnico................................................................................................. 75
Autoevaluacin 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. Cmo lograr la calidad del sotware?....................................................................... 79
Autoevaluacin 6.................................................................................................................. 81
7. Solucionario.................................................................................................................... 82
PRELIMINARES
Gua didctica: Fundamentos de Ingeniera de Software
3. Introduccin
La asignatura de Fundamentos de Ingeniera del Software es una asignatura troncal de carrera que se
imparte en el 5.o ciclo de la carrera de Ingeniera en Informtica que se oferta en la Escuela de Ciencias
de la Computacin; y, tiene una valoracin de 4 crditos acadmicos.
El software y los sistemas de informacin constituyen hoy en da algunos de los recursos ms importantes
de las organizaciones, y no solo en el contexto empresarial sino a todo nivel, generalmente se escucha
hablar de aplicaciones basadas en la Web, ubicuidad, aplicaciones mviles etc. Por lo tanto, no resulta
extrao pensar que su desarrollo debe ser considerado como una de las actividades que mayor
profesionalismo exige; no obstante, no siempre se lo mira as. La mayora de las personas consideran
que es una actividad en la cual un programador se sienta frente al computador y empieza a producir
el software, casi de manera automtica; sin embargo esto est muy lejos de la realidad; el desarrollo de
software hoy en da es una de las actividades ms complicadas y que ms herramientas necesita debido
a la complejidad de las aplicaciones que deben desarrollarse. A los profesionales que se dedican a esta
ardua labor de construir software se los conoce como ingenieros de software, y la presente asignatura
se enfoca precisamente, en presentar los fundamentos en los que se sustenta esta disciplina para
producir software de calidad. Naturalmente esta rea de conocimiento es demasiado amplia como para
ser abarcada en una sola asignatura, sin embargo, hemos hecho el esfuerzo de sintetizar los aspectos
ms importantes que le permitiran tener una idea completa de lo que se requiere para un desarrollo
profesional adecuado.
En este sentido, 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, los sistemas de informacin y la
terminologa bsica de la ingeniera del software; 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 mtodos de
desarrollo de software conocidos como ciclos de vida, con esto concluimos el primer bimestre.
El segundo bimestre est diseado para ensearle a organizar sus proyectos basados en el proceso de
desarrollo unificado y a personalizarlos si es necesario, de modo que pueda ajustarlo a sus necesidades;
no obstante, vale acotar que podra necesitar mucha ms informacin, por lo que adjuntamos un
disco con algunas herramientas adicionales para ayudarle en ese requerimiento; luego en la unidad 5
revisaremos algunos de los modelos importantes del proceso de construccin de software para culminar
en la unidad 6 estudiando algunos principios sobre la calidad del software.
Consideramos que el estudio de la presente asignatura le ser de mucha utilidad. Le manifestamos
nuestro deseo de que estos conocimientos les ayuden no solo a aprobar la asignatura sino les sirva en
la prctica.
Tenemos ms de 10 aos de experiencia en la ingeniera del software; somos sus tutores y estaremos con
ustedes para guiar el proceso de aprendizaje de esta asignatura.
Bienvenido al mundo de la ingeniera del software !
PRELIMINARES
4. Bibliografa
4.1. Bsica
Pressman, R. (2010). Ingeniera de software: un enfoque prctico. Mxico, McGraw-Hill Interamericana

de Editores.
El autor del texto, Roger Pressman, tiene mucha experiencia en el campo de la ingeniera del
software. El texto se ha seleccionado debido a que la forma como plantea los contenidos es
didctica y fcil de seguir, adems tiene ejercicios y autoevaluaciones que lo hacen ideal para un
estudiante a distancia.
Abad, M. y Jaramillo D, (2011): Gua didctica de Fundamentos de Ingeniera del Software. LojaEcuador: UTPL.
La presente gua de estudio est diseada para orientar el proceso de enseaza aprendizaje y se
complementa con actividades y ejercicios de autoevaluacin que le permitirn medir su grado de
avance. Sin las orientaciones dadas en esta gua el proceso ser complejo y extenso, por ello debe
comenzar su estudio a partir de la gua.
4.2. Complementaria
Jacobson I, Booch G, Rumbaugh J. (2000). El proceso unificado de desarrollo de software, Madrid,

Addison Wesley.
Este texto es de singular importancia para el estudio de la unidad 4 de la gua didctica, es escrito
por los autores del Proceso Unificado de Desarrollo y presenta amplia informacin para aplicar
de manera efectiva el proceso unificado de desarrollo a una amplia variedad de proyectos.
Recomendamos su lectura para afianzar las bases no solo del proceso unificado, sino tambin de
la ingeniera del software.
Booch G, Rumbaugh J., Jacobson I. (2006). El lenguaje unificado de modelado. Madrid, Addison
Wesley.
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 diseo. Es escrito por los propios autores del
Lenguaje Unificado de Modelado que calza perfectamente en el Proceso Unificado de Desarrollo.
Recomendamos su lectura sobre todo para fundamentar los principios del modelado de software.
IBM Corp. (2003). Essentials of Rational Unified Process: Course Material.

Este es un material oficial de entrenamiento de IBM Rational, al cual, como universidad, tenemos
acceso gracias a un convenio acadmico. El contenido es importante para aprender el RUP y sirve
de apoyo para la unidad 4.
PRELIMINARES
Direcciones electrnicas

Lpez, C. (2003). Desarrollo de un sistema para la gestin de artculos deportivos. [En lnea]. Valencia
Espaa. Disponible en http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Requisitos.
html#EspCU. [Consulta: 15-04-2010]
Ejemplo de desarrollo software utilizando la metodologa rup, el mismo que puede ser tomado
como referencia para la comprensin de los temas que se trabajan en esta asignatura.
UNIVERSIDAD DE SALAMANCA. (2007). Una aplicacin para jugar al hex. Salamanca: Espaa.
Disponible en http://hex.nosololinux.com/modulos/descargas/Anexo%202.pdf, [Consulta: 15-042010]
En esta direccin encuentra un ejemplo muy prctico de cmo trabajar con una documentacin
de especificacin de requisitos.
Cueva, J. Anlisis orientado a objetos. Oviedo. Espaa. Disponible en http://hex.nosololinux.com/

modulos/descargas/Anexo%202.pdf, [Consulta: 15-04-2010]
En esta direccin encontrar el documento que le ayudar a comprender el modelado visual con
UML, http://www.di.uniovi.es/~cernuda/pfc/aoo.pdf,
Recurso OCW

Fundamentos de Ingeniera del Software (2009). Universidad de Murcia. http://ocw.um.es/

ingenierias/fundamentos-de-ingenieria-del-software.
Curso de Ingeniera de software que le servir para complementar su estudio en los apartados de
conceptos, procesos de desarrollo y modelado de componentes de software.
Herramientas

Rational Rose, Enterprise Edition.
Rational Unified Process.
PRELIMINARES
5. Orientaciones generales para el estudio

Para el estudio de la presente asignatura el estudiante contar con las siguientes herramientas bsicas:
1.
La gua didctica: le orientar sobre cmo y qu temas estudiar, adems contiene ejercicios de
autoevaluacin que le permitirn medir su grado de comprensin y la necesidad de tutora por
parte del docente. Muchos estudiantes empiezan estudiando directamente el texto, pero como
ver ms adelante no es recomendable hacerlo.
2.
El texto bsico: le servir para desarrollar los contenidos principales conforme se lo indica en la
gua didctica. Vale acotar que no todos los captulos del texto se consideran para la asignatura
y tampoco cubren todos los contenidos, por lo que el estudio debe hacerse siguiendo las
instrucciones de la gua didctica.
3.
El Entorno Virtual de Aprendizaje: donde podr interactuar con sus profesores a travs de una
orientacin del trabajo semanal, uso de mensajera electrnica para resolver inquietudes, foros,
desarrollo de ejercicios prcticos, publicacin de recursos, todo este trabajo tendr una valoracin
de 2 puntos.
4.
La tutora personal: es un tiempo semanal que, como profesores, dedicamos para atender las
inquietudes en relacin a los contenidos o desarrollo de trabajos, para ello se publicar un horario
en el cual podrn asistir personalmente o contactarse va telefnica, el mismo se detalla en la
cartula de la evaluacin a distancia.
5.
Los trabajos a distancia: son actividades tericas y prcticas que acompaan a la gua didctica de
cada una de las materias, le permiten aplicar y reforzar los conocimientos adquiridos mediante su
desarrollo, y debe enviarlos a su profesor. La entrega de estos trabajos con su respectiva cartula
es obligatoria y no recuperable, lo cual significa que si no entrega alguno de estos no tendr
opcin a la evaluacin presencial; su valoracin es de 4 puntos que, sumados a la calificacin de
participacin en el EVA, totalizan 6 puntos.
6.
Adicionalmente usted cuenta con un DVD que contiene instaladores de dos productos de software
importantes para realizar sus prcticas. Se trata del Proceso Unificado de Desarrollo, edicin 2003,
es una aplicacin que se instala en la mquina y la herramienta Rational Rose Enterprise; le permitir
construir modelos en UML, ambos productos los puede usar legalmente con licencia conferida
por IBM Rational bajo el convenio acadmico. Los detalles del acuerdo se pueden visualizar en la
URL http://www.ibm.com/developerworks/university/membership/guidelines.html
En cuanto a la forma de trabajo, damos algunos lineamientos que le ayudarn a aprovechar su tiempo y
lograr mejores resultados:
1.
El tiempo que dedique a la lectura y desarrollo de los ejercicios es fundamental; por lo tanto,
dedique al menos 8 horas semanales. Utilice tcnicas de estudio como el subrayado, cuadros
sinpticos y sobre todo mapas conceptuales.
2.
Recuerde que cuenta con su profesor tutor para la comprensin de los temas. Por lo tanto,
la comunicacin con l ser fundamental, para ello debe familiarizarse con las formas de
PRELIMINARES
comunicacin que tiene, ya sea por telfono (consultar horario de tutora), email, chat, y otras
herramientas tecnolgicas. Recuerde adems que existe una variada informacin en Internet,
bibliotecas digitales y tambin la documentacin que su profesor le acerca a travs del EVA.
3.
En la gua didctica encontrar la planificacin del trabajo con las actividades sugeridas para cada
unidad, distribuidas en el tiempo, por lo tanto trate de cumplir con estas segn se lo indica.
4.
Las autoevaluaciones que se presentan al final de cada unidad as como las que constan en el texto
bsico le ayudarn a comprender de mejor manera cada uno de los temas, por lo que su desarrollo
es de suma importancia para afianzar el proceso de enseanza aprendizaje. Una vez resueltas las
autoevaluaciones de la gua didctica puede comparar sus respuestas con el solucionario que
consta al final de la gua. 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.
Como ayudas, a lo largo del presente documento encontrar los siguientes focalizadores:
Se usar para reflejar actividades de trabajo personal que incluye desarrollo de ejercicios,
o actividades en el computador.
Este focalizador se usar para llamar su atencin sobre aspectos generales

de la materia o consideraciones al respecto del origen del contenido y su
utilidad.
Utilizaremos este cono para darle orientaciones especficas o tcnicas respecto al

desarrollo de ejercicios, actividades o sobre algn contenido especfico de la asignatura.
Utilizaremos este focalizador para solicitarle el uso de un recurso OCW (Open Course
Ware) que son recursos educativos diseados por varias universidades y que estn
disponibles para su uso libre por parte de estudiantes y profesionales que deseen
estudiarlos. En el caso de la presente asignatura usaremos parte de este material, para
ello requiere acceso a Internet.
Cuando encuentre este cono se le solicitar que realice una actividad de autoevaluacin
que le permitirn medir su nivel de asimilacin, en este sentido intentamos que estas
autoevaluaciones tengan respuestas no triviales de modo que si usted tiene dudas,
acuda a la tutora o a algn otro medio que le permita solucionarla. Al final encontrar
un solucionario.
Este cono se usar para solicitarle la lectura de una seccin del texto bsico. Recuerde
que no debe leer todo el texto, sino solamente las partes indicadas en los lugares
donde encuentre este cono.
PRELIMINARES
La presencia de este cono, denota una actividad de reflexin en base a preguntas

planteadas cuya respuesta le permitir profundizar o comprender mejor un tema. Estas
preguntas no son evaluables, sin embargo le resultar til responderlas.
Utilizamos esta imagen para sugerir el desarrollo de algunas actividades que, si bien no
forman parte de la asignatura, puede ser interesante que ahonde en el tema.
Estrategias de evaluacin
El sistema de estudios de la Modalidad Abierta y a Distancia de la Universidad Tcnica Particular de
Loja contempla los siguientes parmetros de evaluacin, con la particularidad de que en la carrera de
Ingeniera en Informtica se incluye de manera obligatoria la participacin en el EVA.
La asignatura se encuentra dividida en dos bimestres, cada uno de los cuales se califica sobre 20 puntos,
en caso de que algn estudiante no obtenga una nota mnima de 14 puntos, deber presentarse a un
examen supletorio calificado sobre 20 que reemplaza la nota bimestral correspondiente. Los estudiantes
aprueban cuando han logrado un mnimo de 28 puntos.
En el presente cuadro constan los parmetros y puntajes que se tomarn en cuenta en el primero y
segundo bimestres.
Instrumento
Trabajo a distancia:
- Objetiva
- Ensayo
- Interaccin EVA
Evaluacin presencial
TOTAL
10
Puntaje
2 puntos
2 puntos
2 puntos
14 puntos
20 PUNTOS
PRIMER BIMESTRE
6. Proceso de enseanza-aprendizaje para el logro de competencias

PRIMER BIMESTRE
6.1. Competencias genricas

Capacidad de abstraccin, anlisis y sntesis.
Conocimiento sobre el rea de estudio y la profesin.
Habilidades para buscar, procesar y analizar informacin procedentes de fuentes diversas.
Compromiso con la calidad.
6.2. Planificacin para el trabajo del alumno

COMPETENCIAS
ESPECFICAS
Evala y asegura
la accesibilidad,
usabilidad y
seguridad de los
sistemas, aplicaciones
y servicios
informticos.
INDICADORES DE
APRENDIZAJE
CONTENIDOS
UNIDADES/TEMAS
ACTIVIDADES DE
APRENDIZAJE
CRONOGRAMA
ORIENTAIVO
Tiempo estimado
Reconoce los tipos de 1.1. La naturaleza del

aplicaciones y su uso
software
en el mundo real.
1.2. La naturaleza
Asocia los sistemas
nica de las
con su nivel de
webapps
importancia en la
organizacin.
1.3. El proceso del
software
Identifica los factores
que inciden en la
1.4. La prctica de
complejidad del
la Ingeniera de
software.
software.
Lectura del captulo 1

Semana 1:
del texto bsico como se
seala en la gua didctica
4 horas de autoestudio y
complementado con las
actividades de la unidad 1 de 4 horas de interaccin.
la gua didctica.
Reconoce los roles

que las personas
cumplen frente
a los proyectos
de desarrollo de
software.
Realizar la interaccin en el
EVA: foro.
Desarrollo de la primera
autoevaluacin.
Desarrollo de la evaluacin
a distancia preguntas de la
1 a 6.
Investigar los diferentes tipos

de aplicaciones y ejemplos
concretos de cada tipo
(ejercicio 1.1).
Descarga y lectura del
bloque 1 del recurso OCW.
11
COMPETENCIAS
ESPECFICAS
Definie
requerimientos,
disea, implementa,
integra, administra
y optimiza
soluciones software
centralizadas,
distribuidas o
soluciones Web.
INDICADORES DE
APRENDIZAJE
Identifica
requerimientos
y los clasifica en
funcionales y no
funcionales a partir
de planteamientos
iniciales.
Abstrae casos de
uso a partir de
requerimientos
definidos.
Reconoce los
componentes de un
caso de uso.
PRIMER BIMESTRE
CONTENIDOS
ACTIVIDADES DE
APRENDIZAJE
UNIDADES/TEMAS
CRONOGRAMA
ORIENTAIVO
Tiempo estimado
2.1. Ingeniera de
requerimientos.
2.2.
2.3.
2.4.
2.5.
2.6.
Modela componentes
de software a partir
del modelo de casos 2.7.
de uso.
2.8.
Lectura de los captulos 5 y 8 Semanas 2,3,4:

del texto bsico y desarrollo
de las actividades de
12 horas de autoestudio
Preparar el
aprendizaje de la unidad 2 de y
camino.
la gua didctica.
12 horas de interaccin.
Indagacin de los Desarrollo de la
requerimientos. autoevaluacin
correspondiente a la unidad
Desarrollos de
2.
casos de uso.
Desarrollo de la evaluacin a
Elaboracin del distancia preguntas 7 a la 14.
modelo de los
requerimientos. Actividades en el EVA:
cuestionario.
Validacin de los
requerimientos. Desarrollar los ejercicios que
se proponen en la gua.
Diseo en el
contexto de la
Descarga y lectura del
ingeniera del
bloque 2 del recurso OCW.
software.
Iniciar el desarrollo de la
El proceso de
parte de ensayo del trabajo a
diseo.
distancia.
2.9. Conceptos de
diseo.
2.10. Modelo del
diseo.
Manejar
organizaciones
de tecnologa y
administracin de
Recursos de TI.
Identifica los
3.1 Un modelo
principios de
general de
cada modelo de
proceso.
desarrollo y los aplica
para organizar los
3.2 Evaluacin
proyectos.
y mejora de
procesos.
Aplica los principios
del desarrollo gil en 3.3. Modelos
el planteamiento de
prescriptivos.
soluciones a proyecto
de desarrollo de
3.4. Fases del proceso
software.
unificado.
3.5. Modelo proceso
personal y de
equipo.
Lectura de los captulos 2,3 Semanas 5,6:

del texto bsico conforme se
seala en la unidad 3 de la
8 horas de autoestudio.
gua didctica.
Desarrollo de
autoevaluacin.
Tareas en el EVA.
Termina el desarrollo del

trabajo a distancia.
3.6. Qu es un
proceso gil.
3.7. Programacin
extrema.
3.8. Otros modelos
giles.
Unidades de la 1 a la 3 Repaso general de la materia. Semanas 7 y 8
Desarrollo del cuestionario
de repaso en el EVA.
12
8 horas de autoestudio y
PRIMER BIMESTRE
6.3. Sistema de evaluacin de la asignatura (primero y segundo bimestres)

Formas de evaluacin
Interaccin en el EVA
Prueba objetiva y de
ensayo
Cumplimiento, puntualidad,
responsabilidad
Esfuerzo e inters en los trabajos
3. Coevaluacin
Parte de ensayo
Respeto a las personas y a las

normas de comunicacin
X
X
Creatividad e iniciativa
Habilidades
Evaluacin
presencial
Comportamiento tico
Competencia: criterio
Actitudes
Evaluacin a
distancia **
Parte objetiva
1. Autoevaluacin *
2. Heteroevaluacin
Contribucin en el trabajo
colaborativo y de equipo
Presentacin, orden y ortografa
Dominio del contenido
Investigacin (cita fuentes de

consulta)
Aporta con criterios y soluciones
Puntaje
10% 20% 30%
TOTAL
70%
14
20 puntos
Actividades
presenciales y en el
EVA
PORCENTAJE
Mximo 1 punto
(completa la
evaluacin a
distancia)
Anlisis 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 mnimo de 28/40 puntos, que equivale al 70%.
* Son estrategias de aprendizaje, no tienen calificacin; pero debe responderlas con el fin de autocomprobar su
proceso de aprendizaje.
** Recuerde que la evaluacin a distancia consta de dos partes: una objetiva y otra de ensayo, debe desarrollarla
y entregarla en su respectivo centro universitario.
Seor estudiante:
Tenga presente que la finalidad de la valoracin cualitativa es
principalmente formativa.
13
PRIMER BIMESTRE
6.4. Orientaciones especficas para el aprendizaje por competencias
UNIDAD 1: INTRODUCCIN A LA INGENIERA DEL SOFTWARE
El software en la actualidad es considerado como un elemento clave en las

organizaciones, industrias, instituciones, el hogar, etc., pues casi todos hemos trabajado
con un procesador de texto, una hoja electrnica y la mayora de pequeos negocios
cuentan ya con programas donde llevan el control de sus ventas, su contabilidad, etc.
La evolucin del software en los ltimos aos ha sido muy significativa convirtindose en la solucin
a mltiples problemas de procesamiento de informacin hasta ser considerada tambin como
herramienta especializada. Sin embargo, desarrollar software con la urgencia y calidad requeridas es
un problema difcil de resolver a pesar de las tecnologas y herramientas de las que se dispone.
En esta asignatura se expondrn algunas actividades que le ayudarn, como futuro ingeniero en
informtica, a desarrollar software de calidad y en los tiempos que se planifica.
Estimado estudiante: inicie entonces con el estudio de los conceptos generales de la

ingeniera del software (IS), que sern de mucha utilidad para comprender los apartados
siguientes, no avance si no logra comprender el contenido bsico de la asignatura.
La tabla 1.1 presenta una idea de las etapas que se pueden desarrollar para construir una aplicacin, as
como sus artefactos, los cuales pueden variar de acuerdo a la metodologa y al tipo de proyecto con el
que trabaje:
Tabla 1.1. Etapas y artefactos genricos para el desarrollo de aplicaciones de software
LEVANTAMIENTO
DE INFORMACIN
ANLISIS
DISEO
Encuestas.
Observacin
directa.
Requerimientos
modelados.
Requerimientos
Especificacin de Arquitectura.
casos de uso.
Scripts para creacin de
base de datos.
14
CONSTRUCCIN
Diagramas de flujo de datos. Lenguaje de

Diagramas entidad-relacin. programacin.
Diagrama de clases
Aplicacin
construida.
PRUEBAS E
IMPLEMENTACIN
Plan de pruebas.
Plan de
implementacin.
Instaladores.
Manuales tcnicos.
Manual de usuarios.
PRIMER BIMESTRE
1.1. La naturaleza del software

Revise el apartado 1.1 La naturaleza del software aplique la tcnica del subrayado,
puesto que beneficiar la comprensin de este tema.
Un concepto que se va a necesitar mucho en esta asignatura es el de software, entonces proceda a

responder la pregunta: qu es el software de computadoras?, ante esta interrogante, la respuesta es
la siguiente: software es realizado por un ingeniero de software, son programas que se ejecutan en
las computadoras, los cuales han tenido un proceso de desarrollo, pruebas y mantenimiento que le ha
permitido que sea utilizado por un usuario, que al final de todo, lo que necesita es que su tareas diarias
se las organice de mejor manera.
Se dice tambin que es la parte lgica de un sistema de computacin o la parte suave.
Con estos antescedentes se puede hablar de software de aplicaciones como Word, Excel, Autocad,
Photoshop, etc., sistema operativo Windows, Mac OS, Linux etc., software que permite desarrollar nuevo
software como java, .net, C++ , etc., de los expuestos, los ltimos son conocidos como lenguajes de alto
nivel, los desarrolladores los utilizan para realizar nuevo software, a la medida para un usuario final, como
ejemplo de este tipo de software se puede mencionar un sistema de facturacin para una farmacia.
Es conveniente que encuentre el concepto de software que se presenta en el
texto bsico, entenderlo, de ser posible compararlo con el de otros autores para
una mejor comprensin, puede buscar estos recursos tanto en el texto como
en Internet.
Ahora ya tiene claro la definicin de software y, mejor an, si asocia la palabra software con las funciones
del computador y los usos que se le pueden dar en los diferentes mbitos.
En el texto bsico se presentan tres caractersticas del software que lo hace diferente al
hardware, sera importante que realice la lectura detallada de las mismas.
Si ya realiz la lectura de estas caractersticas, es momento de hacer algo con esta

informacin. Conteste las siguientes preguntas: cules cree que podran 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 deca en un inicio que el software como tal existe en cualquier lugar y dispositivo imaginable, desde
el dispositivo ms simple como un reloj digital hasta los sistemas de lanzamientos de naves espaciales
de la NASA, se lo encuentra en celulares, hornos, microondas, televisores, juegos, vehculos, cajeros
automticos y todo lo que usted pueda imaginar, hoy en da, del mercado de las aplicaciones para
telfonos celulares se ha desarrollado a una escala increblemente alta, es posible encontrar en las tiendas
de aplicaciones mviles como Apple Store, OVI de Nokia, y cientos de tiendas ms de aplicaciones para
Android, en este mar de aplicaciones, surge la interrogante: qu dominios de aplicaciones se tiene que
construir?
15
PRIMER BIMESTRE
Ejercicio 1.1
1.
En base a la categorizacin de los dominios del software del texto bsico realice un cuadro
resumen de los dominios del software y luego clasifique los siguientes tipos de software:

Portal de bsquedas de informacin cientfica: isi of knowledge.

Lenguaje de programacin Java.

Sistema de facturacin utilizado por la tienda Supermaxi.
WEKA.
2.
De los problemas y puntos por evaluar que se encuentran al final del captulo realice el ejercicio
1.1 y 1.2.
Un tema que no se debe olvidar y por la naturaleza de las organizaciones es el 1.1.3
Software heredado, este tema se presenta en el texto bsico, el software heredado son
programas que fueron desarrollados tiempo atrs, son modificados continuamente y
a pesar de dar problemas de actualizacin, tambin son un apoyo para las funciones
bsicas del negocio, pues al estar ah, debe ser tomado en consideracin por los
equipos de desarrollo de cada una de las empresas.
Con estas explicaciones responda a las siguientes preguntas Qu tipos de cambios se

hacen a los sistemas heredados?, cuando encontramos sistemas heredados es mejor no
hacer nada y seguirlos manteniendo?
1.2. La naturaleza nica de las webapps

Se debe tener claro el trmino webapps y cmo se lo va a utilizar en esta asignatura, ser entonces:
una simple pgina Web? o un sitio donde puedan estar integradas todas las aplicaciones?, hemos
visto sitios de inters que permiten realizar bsqueda de automviles donde se pueden hacer pequeos
clculos para las compras o ingresar a la seccin electrnica de un banco, donde se puede realizar
muchas transacciones o pginas que permiten buscar informacin cientfica con tendencias y resultado
de investigaciones.
Las aplicaciones Web son una categora mencionada en el apartado de dominio del
software y que en los actuales momentos estn teniendo mucho auge. Este tipo de
aplicaciones presenta un grupo primordial de atributos que pueden ser revisados en
el apartado 1.2. Naturaleza de las WEBAPP del texto bsico donde se encontrar la
concurrencia, que hace referencia al nmero de usuarios conectados al mismo tiempo
a una aplicacin.
Utilice el siguiente cuadro para encontrar palabras clave por cada uno de estos atributos:
16
PRIMER BIMESTRE
Rendimiento
Uso intensivo de
redes
Concurrencias
Carga impredecible
Gran nmero de
usuarios a la vez
Disponibilidad
Orientadas a los
datos
Contenido sensible
Inmediatez
Seguridad
Esttica
Evolucin continua
Si termin de encontrar las palabras clave, ahora contine entonces con el siguiente apartado, que es de
gran importancia.
1.3. El proceso del software

Recuerde la definicin de ingeniera de software que se encuentra en el texto planteada por Fritz Bauer
es el establecimiento y uso de principios fundamentales de la ingeniera con objeto de desarrollar en
forma econmica software que sea confiable y que trabaje con eficiencia en mquinas reales.
Para comprender estos conceptos revise al inicio del apartado 1.3. Ingeniera del
software del texto bsico, las realidades que se deben aceptar para elaborar software,
y claro como un futuro profesional en el desarrollo de software debe tener claro estos
conceptos. Tambin aqu se mencionan cuatro temas:

Cmo el software est en el diario vivir de las personas?

Cmo las necesidades de los usuarios van aumentando cada da?
La importancia de software para la toma de decisiones.
El crecimiento de acceso de usuario a los sistemas.
Lea detenidamente cada uno de estos apartados que se presentan en el texto bsico.
Qu podemos concluir de esto? Se debe hacer ingeniera con el software en todas sus
formas y a travs de todos sus dominios? Cree que esta afirmacin es correcta o no?
Por qu?
Dentro de la ingeniera del software al proceso se lo define como conjunto de actividades, acciones
y tareas que se ejecutan cuando va a crearse algn producto del trabajo como lo expone el texto
bsico, de ah que la ingeniera de software se base en actividades estructuradas que van a ser aplicadas
a todos los proyectos software, con la finalidad de obtener productos de calidad. Una estructura general
podr constar de actividades las cuales las plasmamos en la figura 1.1 para que nos ayude a recordar:
Comunicacin
Planeacin
Modelado
Construccin
Despliegue
Figura 1.1. Actividades estructurales del proceso de software
17
PRIMER BIMESTRE
Esta estructura del proceso se encuentra en el texto bsico donde se detalla cada una de
estas cinco actividades, lalas y desarrolle la autoevaluacin. 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 vehculos, debe presentar un plan de desarrollo del mismo, en qu etapa o actividad
estructural estaremos entonces?, qu debe hacer adicionalmente en esta actividad?
De acuerdo al tipo de proyecto que estemos realizando estas actividades se podrn realizar en forma
interactiva de acuerdo al progreso del mismo, repitiendo estas tareas hasta llegar a la finalizacin del
proyecto. Tenemos que tener claro que cada iteracin contribuir para que el software vaya aumentando
sus funcionalidades y a la vez este proceso lo ir haciendo ms complejo.
Ya hemos visto y conocido las actividades estructurales del proceso de software, 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.- donde se evala el progreso
de desarrollo y permite tomar acciones para corregir en caso de que estas no se estn cumpliendo de
acuerdo a una planificacin inicial. Por ejemplo, si hace falta personal, si no hay informacin adecuada,
etc. una lnea de especializacin en esta rea es la PMO.
A continuacin revise las actividades sombrilla y familiarcese con cada una de ellas,.Estos
temas pueden ser ampliados ya que existe mucha documentacin en Internet.
Cada proyecto se diferencia de otro debido a su naturaleza, entonces la actividad de control y seguimiento
de proyectos diferenciar el tipo de proyecto o el proceso ser el mismo para cualquier proyecto. Cul
es su opinin?
1.4. La prctica de la ingeniera de software

Encontramos en el apartado 1.5. Prctica de la ingeniera del software del texto la
esencia plasmada en cuatro puntos que se muestran en la figura 2.1.
Entender el
problema
Planear la
solucin
Ejecutar el plan
Examinar la
exactitud del
resultado
Figura 2.1. Etapas del proceso de solucin de problemas.
18
PRIMER BIMESTRE
Hablaremos de la primera etapa: entender el problema. 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 solucin del problema, buscar y entender lo que realmente se
quiere conseguir y luego pasar a identificar una solucin del mismo.
Deber ahora usted revisar las otras etapas, no se olvide que cualquier inquietud debe ser conversada
con su tutor.
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.um.es/ingenierias/fundamentosde-ingenieria-del-software/material-de-clase, donde usted podr ir reafirmando sus
conocimientos sobre estos temas. Revise el tema 1 de este recurso.
Revise el apartado 1.5.2. Principios generales, y desarrolle un cuadro sinptico que

sintetice cada uno de los mitos del software, contrastndolos con lo que sucede en el
mundo real.
Los mitos del software son un tema muy interesante que le permitir entender y contraponer las
creencias errneas sobre el software y el proceso que se utiliza para obtenerlo. Le recomendamos que
haga una revisin de estos tanto en el mbito de la administracin, del cliente y profesional.
Antes de terminar con esta unidad queremos poner en consideracin 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, la de adaptar
un sistema de terceros, ampliar las funcionalidades o crear un producto
nuevo1.
En el texto bsico se va realizando un ejercicio prctico, el cual debe consideralo para la comprensin de
los temas. En varios apartados del texto se hace referencia a este ejercicio. En lo posible siga el desarrollo
de este ejercicio.
Hemos concluido el estudio de esta unidad, por lo que nos conviene comprobar cunto hemos asimilado
de los temas tratados, para lo cual es necesario desarrollar las autoevaluaciones de conocimiento.
Pressman R. (2010). Cit. Ed. p. 20
19
PRIMER BIMESTRE
Autoevaluacin 1
Lea detenidamente cada una de las preguntas planteadas en la siguiente tabla y

determine si la proposicin es verdadera o falsa. Como estrategia le recomendamos
que primero ubique el tema sobre el que le habla la pregunta, ubique la informacin
necesaria en el texto o en la gua didctica y fundamente su respuesta.
1.
Se puede decir que el software es un proceso dual, o sea que primeramente es un

producto y que luego es una herramienta para entregar otro producto.
2.
Cree que la siguiente afirmacin es una preocupacin sobre el desarrollo de software.

El control de avance del proyecto se ha vuelto muy complicado?
3.
Si tenemos un proyecto de software y un proyecto de manufacturacin podemos

realizar una administracin de los mismos, de igual manera.
4.
La robtica (los proyectos que se trabajan en esta rea) pueden ser consideraciones
como software de ingeniera y ciencias.
5.
La ingeniera de requisitos est orientada a trabajar de forma conjunta entre las

personas involucradas en el proyecto antes de empezar el desarrollo del mismo.
6.
La ingeniera de software es una tecnologa con varias capas.
7.
Las actividades sombrilla son complementadas por actividades estructurales del

proceso de software.
8.
Existen 4 etapas en la esencia de la prctica de la ingeniera del software para llegar a

la solucin. La aplicacin de las mismas puede variar en su orden.
9.
Los mitos del software que se presentan han desencadenado que administradores y
trabajadores se equivoquen aun cuando el conocimiento del software avanza.
10.
Cuando se ha resuelto un problema, los elementos que se obtuvieron pueden ser

reutilizados en otros proyectos similares?.
Ir a solucionario
20
PRIMER BIMESTRE
UNIDAD 2: PROCESOS DE CONSTRUCCIN DEL SOFTWARE

Cmo inicia un proyecto? Si bien un proyecto de software nace con la idea de solventar unas necesidades,
estas deben ser evaluadas a travs de un anlisis y un estudio que nos permita determinar la factibilidad
de ejecutar el mismo.
El proceso comienza con la recoleccin de informacin sobre el proyecto a desarrollar y determinar
cul es el nivel de comprometimiento que hay de los directivos de la organizacin, para lo cual nos
ayudaremos con tcnicas de recoleccin de informacin.
A partir de esto tendremos un listado de las necesidades para realizar un estudio de factibilidad del
proyecto que comprende los siguientes aspectos:

Econmico que busca establecer cules sern los beneficios frente a la inversin realizada. Para ello
se vale de tcnicas de evaluacin financiera de proyectos o modelos econmicos como anlisis
de valor ganado o la tasa interna de retorno.
Tcnico, en el cual se establece si la organizacin cuenta con la tecnologa (servidores, maquinas)
Legal, existen leyes o reglamentos que pudieran invalidar el proyecto o si se sustentan en el

reglamento interno de la organizacin, en este sentido hoy en da pesan mucho las normativas
ambientales.
Operativo, la empresa podr adoptar estos cambios.
Hasta ahora ya se ha realizado una inversin en un equipo para realizar el estudio de factibilidad, estos
gastos no deben ser un impedimento para que la empresa desista de realizar el proyecto por cualquiera
de los factores revisados. De no ser as se debe realizar una especificacin detallada de las alternativas
que se han seleccionado adems de tener una definicin de la planificacin inicial del proyecto.
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, o determinar un desarrollo
interno o externo del mismo.
La planificacin inicial podra identificar areas de riesgo, presupuestos, calendarios, planes de trabajo,
tcnicas de comunicacin entre los componentes del proyecto, forma de interactuar con el cliente.
Luego de haber realizado estas tareas, entonces nos centraremos en el proceso de obtencin de
requerimientos para iniciar el proyecto.
Comencemos el estudio de la presente unidad, con el tema PRINCIPIOS QUE GUAN
LA PRCTICA del captulo 4 del texto bsico, luego elabore un mapa conceptual sobre
estos principios.
21
PRIMER BIMESTRE
Ahora que ya conoce los principios empecemos el estudio con dos temas importantes,
el primero es la obtencin de los requerimientos (su modelado en la unidad 5) y el
proceso de diseo que se tiene que cumplir para la construccin del software.
2.1. Ingeniera de requerimientos

La prctica de la ingeniera de software consta de principios, conceptos, mtodos y herramientas que las
personas dedicadas al desarrollo de software deben aplicar durante el ciclo de vida.
2
ENTENDER LOS REQUERIMIENTOS DE UN PROBLEMA ES UNA DE LAS

TAREAS MS DFICILES QUE ENFRENTA EL INGENIERIO DE SOFTWARE2.
Una mala prctica por parte de los programadores es el pretender escribir cdigo sin informacin ni
insumos suficientes para poder hacerlo, es un grave error querer construir algo luego de la primera
entrevista con un cliente o usuario.
Es importante entonces entender lo que el cliente desea antes de comenzar a disear (modelar el diseo)
o construir (etapa de codificacin con una herramienta de programacin) un software. En la figura 2.1
podemos ver a la ingeniera de requerimientos ayudando en la descripcin del sistema y tambin siendo
la base para el diseo del mismo.
Descripcin del
sistema
Modelado de
anlisis
Modelado del
diseo
Figura 2.1. Paso de necesidades al modelo de diseo.
Los grandes sistemas software constituyen actualmente un elemento

comn en nuestra sociedad, convirtindose da a da en imprescindibles
para la industria, el comercio y las personas. Siempre que vamos a
desarrollar una determinada aplicacin o un sistema para nuestros
clientes, ponemos en marcha principios, mtodos, tcnicas y herramientas que permiten
mantener y documentar las necesidades o requisitos generales para el desarrollo de
estas aplicaciones, a estos aspectos se les llama ingeniera de requisitos. Por tanto,
es importante describir y detallar en qu consiste la ingeniera del software para la
consolidacin de cualquiera de los proyectos que se emprenda.
Realice una lectura de cada una de las tareas de la ingeniera de requisitos, esto le
ayudar a comprender este tema, estas tareas las encuentra en el apartado 5.1.
Ingeniera de requerimientos, estas son: concepcin, indagacin, elaboracin,
negociacin, especificacin, validacin y administracin.
2
Pressman R. (2010). Cit. Ed. p. 101.
22
PRIMER BIMESTRE
Ahora bien, hablaremos de una de estas tareas, la de validacin; donde entendemos como validacin
de los requisitos al proceso de comprobacin si dichos requisitos son correctos. Esta etapa es de suma
importancia si no se quiere correr el riesgo de realizar una mala implementacin debido a que no se hizo
una buena especificacin. Todo esto se ver reflejado tanto en la calidad del software como en el costo,
puesto que se deber corregir el sistema.
De esta manera es fundamental que al terminar la etapa de modelado de requerimientos

se realice el proceso de comprobacin mediante una comparacin de las conversaciones
iniciales que se realizaron con las especificaciones que se obtuvieron.
Del resultado de este proceso podemos llegar a su validacin determinando si:

El modelo que se obtiene es lo que el cliente pide.

Las especificaciones nuevas que se han realizado satisfacen al cliente.
Cuando estamos hablando sobre la mala definicin de la frontera del sistema podra
decirnos a qu tarea nos referimos?.
En este apartado podemos revisar la siguiente direccin electrnica: http://hex.nosololinux.com/
modulos/descargas/Anexo%202.pdf, donde encontrar un documento de especificacin de
requerimientos que le ayudar a comprender cul es el proceso que se debe seguir en esta etapa.
Otra de las actividades es la administracin de los requerimientos para software, ya que estos cambian
constantemente y su modificacin ser a travs de toda la vida del sistema. Entonces se necesitar
administrar esto para lo cual existen herramientas automatizadas que nos permiten comprobar la
trazabilidad, como por ejemplo Requisite Pro. Al existir versiones de prueba de esta herramienta sera
recomendable que usted. las consiga desde Internet y las trabaje.
A continuacin se presenta tambin una plantilla que se puede utilizar para la especificacin de los
requisitos:
23
PRIMER BIMESTRE
Plantilla de IEEE para las especificaciones de requisitos de software.

Contenido
1. Introduccin
1.1. Propsito
1.2. Alcance
1.3. Definiciones, siglas y abreviaturas
1.4. Referencias
1.5. Vista panormica
2. Descripcin general
2.1. Perspectiva del producto
2.2. Funciones del producto
2.3. Caractersticas del usuario
2.4. Restricciones generales
2.5. Suposiciones y dependencias
3. Requisitos especficos
3.1. Requisitos funcionales
3.1.1. Requisito funcional 1
3.1.1.1. Introduccin
3.1.1.2. Entrada
3.1.1.3. Proceso
3.1.1.4. Salida
3.1.2. Requisito Funcional 2, etc.
3.2. Requisitos de la Interfaz Externos
3.2.1. Interfaces del usuario
3.2.2. Interfaces de hardware
3.2.3. Interfaces de software
3.2.4. Interfaces de comunicaciones
3.3. Requisitos de rendimiento
3.4. Atributos de calidad
3.5. Otros requisitos
3.6. La historia de la revisin
2.2. Preparar el camino a la obtencin

Revise el apartado 5.2. Establecer las bases del texto bsico, donde aprender los
fundamentos que sustentan el proceso de requerimientos.
Si vamos a trabajar el proceso de obtencin de requerimientos se debe:
1.
Establecer las bases, es decir difundir qu se va hacer a los miembros de la organizacin
2.
Hacer una lista de las personas que se beneficiarn de forma directa o indirecta, es decir todos
quienes participen, o sea posibles candidatos.
3.
Establecer un dilogo anterior para que las personas estn preparadas y de ser posible darles una
idea del tema que se va a tratar.
4.
Escuchar a todos y seleccionar los diferentes puntos de vista.
5.
Pedir la colaboracin de los participantes en el proyecto.
6.
Comenzar con preguntas de tipo general.
24
PRIMER BIMESTRE
Continuemos con el ejemplo de la empresa DANCAR que se encarga de la compra-venta

de vehculos, el mismo que cuenta con 3 sucursales en la ciudad y la contabilidad se la
lleva en cada una de ellas. Elabore una lista de cules seran los posibles participantes
en el proceso de obtencin de requerimientos, adems liste posibles preguntas que
usted realizara y qu estrategia utilizar.
2.3. Indagacin de los requerimientos

Podemos mencionar que en este proceso vamos a averiguar los posibles requerimientos, o sea vamos
a hacer un anlisis preliminar de los requerimientos. La indagacin de los requerimientos, combina
elementos de la solucin del problema, es recomendable la participacin del equipo de trabajo para
la correcta identificacin de las necesidades y de los elementos que permitan la solucin del problema.
Encontrar entonces los siguientes temas:

Recabacin de los requerimientos en forma colaborativa.

Despliegue de la funcin de calidad.
Escenarios de uso.
Indagacin de los productos de trabajo.
Siendo fases primordiales dentro del proceso de desarrollo de software estos temas
deben ser revisados en el apartado 5.3. Indagacin de los requerimientos del texto
bsico.
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.
Para mejorar la captura de requerimientos de forma colaborativa el documento que se analizar

en la reunin debe ser repartido con anterioridad.
Para una mayor explicacin sobre un servicio se puede escribir miniespecificaciones.
Existen tipos de requerimientos como son los requerimientos normales, formales y emocionantes.
Cada vez que se van recabando los requerimientos se tiene ms clara la visin de cmo sern las
caractersticas del sistema.
En funcin del tamao del sistema, los productos de trabajo generado durante la indagacin
varan.
2.4. Desarrollo de casos de uso

Un caso de uso describe el comportamiento del sistema en distintas condiciones. En los casos de uso se
narra una interaccin entre el usuario final y el sistema.
Lo primero que debemos hacer para escribir un caso de uso es identificar ACTORES
que estarn involucrados. Algunos tpicos a considerar:
25
PRIMER BIMESTRE
Los actores son personas que usan el producto software.

Los actores representan los papeles que desempean las personas.
Un actor es cualquier cosa que se comunique con el sistema.
Todo actor tiene uno o ms objetivos cuando utiliza el sistema.
Un actor no necesariamente es un usuario final.
Un usuario final puede tener varios papeles, un actor representa una
clase de entidades externas.
Revise las preguntas que se sugiere realizar para desarrollar casos de uso una vez que se identific un
actor.
A continuacin vamos a revisar un ejemplo de plantilla para la especificacin de caso de uso y una breve
descripcin de cada uno de sus componentes. Esta llamada especificacin de caso de uso variar en su
forma puesto que como se lo lleve determinar el equipo de trabajo.
<Identificador>
<nombre descriptivo>
Descripcin
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]
segn se describe en el siguiente caso de uso:
<precondicin del caso de uso>
Paso
Accin
1
{<accin a realizar>, realizar el caso de uso [caso de uso]}
2
<Situacin que produce una alternativa>
2a Si [Situacin que produce una alternativa] el sistema deber
2b Si [Situacin que produce una alternativa] el sistema deber
.
n
.
<postcondicin del caso de uso>
Paso
Accin
p
En el caso de que [situacin que provoca la excepcin] el sistema deber
Precondicin
Secuencia normal
Postcondicin
Excepciones
Rendimiento
Frecuencia
Importancia
Urgencia
Comentarios
26
q
El sistema deber realizar la/s accin /es descrita/s en {los pasos [primer paso] al
[ltimo paso], el paso [nmero de paso]} en un mximo de [cota de tiempo]
Este caso de uso se espera que se lleve a cabo una media de [nmero de veces] al
[unidad temporal]
{vital, importante, quedara bien}
{inmediatamente, hay presin, puede esperar}
<otras consideraciones en formato libre>
PRIMER BIMESTRE
En el Entorno Virtual de Aprendizaje encontrar una plantilla basada en RUP para la especificacin de
casos de uso que podra ayudarle para una mejor comprensin.
En el texto bsico en la pgina 115 tenemos un ejemplo de caso de uso, como se puede ver con el que
hemos planteado como ejemplo difieren en algunos aspectos, pues realmente no hay un solo modelo
de especificacin de casos de uso, es por eso que el que se adopta en el desarrollo de un proyecto
software ser el que el ingeniero seleccione o diseo.
Vamos a referirnos al siguiente proyecto que se presenta en la WEB http://users.dsic.upv.es/asignaturas/
facultad/lsi/ejemplorup/Requisitos.html#EspCU para que se familiarice con los diagramas de casos de
uso y la especificacin de casos de uso.
2.5. Elaboracin del modelo de los requerimientos

Como lo expresa el texto bsico el objetivo del modelo de anlisis es describir los dominios de
informacin, funcin y comportamiento que se requieren para un sistema basado en computadora.
El modelado del anlisis es una fotografa que nos permite ver los requerimientos en cualquier momento
dado.
A continuacin se debe revisar el apartado sobre 5.5.1 Elementos del modelado
de requerimientos pues nos permitir ver diferentes formas de concebir los
requerimientos adems de determinar cundo y en qu casos se utiliza cada uno de
ellos.
Hemos encontrado en este apartado algunos temas como diagramas de actividades, diagramas de
estados, diagramas de clases.
2.6. Validacin de los requerimientos

El apartado 5.7. Validacin de los requerimientos del texto bsico 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 informacin.
Al momento de revisar los requerimientos tenemos una serie de preguntas que deberamos hacernos
esto se encuentra plasmado en este apartado.
Si revis las preguntas, debe considerar que puede plantear otras nuevas, esto con la finalidad de
determinar que <<el modelo de requerimientos es un reflejo correcto de las necesidades>>.
Tomemos en consideracin que a mediados de los aos 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
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, estas estimaciones
siguen teniendo plena vigencia.
Sin embargo, los costos de correccin 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 anlisis. De aqu que es necesario
adelantar el proceso de prueba en las primeras etapas de desarrollo, claro est donde sea posible.
27
PRIMER BIMESTRE
La revisin de requisitos se realiza con un grupo de personas que lee, analiza y discute el documento de
especificacin. Entonces es importante que usted sepa seleccionar a las personas que han de trabajar en
este proceso de validacin.
Podemos realizar una comparacin entre el anlisis y la validacin, as, en el anlisis contaremos como
entrada requisitos incompletos mientras que en la validacin un conjunto comprobado de requisitos.
Adems en el anlisis veremos si los requisitos satisfacen las necesidades del cliente o si hemos levantado
los requisitos correctos mientras que en la validacin nos preguntamos si estn bien descritos o si el
documento describe el sistema. Como nos podemos dar cuenta la etapa de validacin permite tener una
definicin precisa de las necesidades de los usuarios.
Despus de realizar la especificacin las preguntas que se presentan en el apartado del texto deben
plantearse y responderse para garantizar que el modelo est correcto.
2.7. Diseo en el contexto de la ingeniera del software

La etapa de diseo de software agrupa varios componentes necesarios para llegar al desarrollo de un
sistema de alta calidad. Es una etapa fundamental en el proceso de desarrollo de software y se deben
tener claros los conceptos que se asocian a este tema.
Basndonos en lo que se expresa en el texto bsico: el diseo de software se ubica en el rea tcnica
de la ingeniera del software y se aplica sin importar el modelo del proceso que se utilice, nos estamos
dando cuenta de la importancia que tiene el diseo. Podemos entonces entender que, luego de haber
realizado un modelado de los requerimientos, tenemos que hacer el diseo para entrar recin al proceso
de construccin.
Descripcin del
sistema
Modelado de
anlisis
Modelado del
diseo
Figura 201. Transicin del modelo de anlisis al modelo de diseo.
EL MILAGRO MS COMN DE LA INGENIERA DE SOFTWARE ES LA TRANSICIN DEL ANLISIS AL

DISEO Y DE ESTE AL CDIGO. Richar Du.
Revise entonces el apartado 8.1. Diseo en el contexto de la ingeniera de software

del texto bsico.
El modelo de diseo empieza por el diseo de datos o clases, para seguir con el diseo de la arquitectura,
la interfaz y el diseo a nivel de componentes. Recordemos siempre que el modelo de diseo se basa
principalmente en el modelo de requerimientos.
Parte del diseo de clases puede llevarse a cabo junto con el diseo de la arquitectura del software.
Entonces el diseo de la arquitectura define la relacin entre los elementos principales de la aplicacin
software, el diseo de interfaz en cambio se encarga de determinar la comunicacin con los sistemas
que interactan y con las personas que lo utilizarn. A nivel de componentes el diseo transforma los
elementos estructurales de la arquitectura del software en una descripcin.
28
PRIMER BIMESTRE
En la figura 8.1 del texto bsico, se puede ver esta relacin que acabamos de mencionar as como los
elementos que participan en cada parte del modelo de diseo que se encuentra en la pirmide.
Ejercicio 2.1
Analice la figura 8.1 del texto bsico y determine la relacin entre los elementos del anlisis hacia el
modelo. Realice un cuadro donde refleje los elementos y las relaciones entre los dos modelos.
Si ya revis este apartado, entonces habr notado que la importancia del diseo, se resume en una
palabra: CALIDAD.
2.8. El proceso de diseo

Este tema se ubica en el apartado 8.2. El proceso del diseo del texto bsico, en el
que podemos encontrar la definicin de diseo, identifquela y determine cul es su
importancia
Claramente el diseo es el plano para la construccin que se har a partir de los requerimientos.
Encontramos 8 lineamientos de la CALIDAD del software. Como habr visto, esta palabra se asocia
mucho a esta etapa; pues el diseo es importante ya que permite, a un equipo de software, evaluar la
calidad esperada del mismo.
Si se ha revisado estos lineamientos se dar cuenta que es muy importante la aplicacin de principios de
diseo, aplicar una metodologa 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, 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.
El apartado de seguridad, dentro de qu atributo se encuentra?

Es importante considerar estos atributos de calidad puesto que al final nos servirn para realizar el
proceso de validacin del software.
2.9. Conceptos de diseo

Estudie ahora los conceptos asociados al diseo y revise detalladamente cada uno de ellos: abstraccin,
arquitectura, patrones, divisin de problemas, modularidad, ocultamiento de la informacin,
independencia funcional, refinamiento, aspectos, rediseo, conceptos de diseo orientado a objetos,
clases de diseo.
Vamos a trabajar con el ocultamiento de informacin, no olvide revisar detenidamente los otros
apartados. Ocultamiento: decisiones de diseo que se oculten a las dems. Se pretende de esta manera
que algunos mdulos sean accesibles solo a determinados mdulos y no a todos. Dentro de esto est
incluida la abstraccin (separar lo que se necesita del contexto general) ayudndonos a definir qu es
lo que se quiere que se vea y de lo que no se debe ver. Este tema de ocultamiento de modularidad est
presente sobre todo en los sistemas bancarios. Pues determinados usuarios ni siquiera deben saber que
existen ciertas funcionalidades.
29
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.
2.10. Modelo del diseo

El apartado 8.4. El modelo de diseo estudia el diseo desde 2 dimensiones: al igual
que un plano cartesiano, en el eje de las x est la dimensin del proceso (tareas del
proceso de software), y en el eje de las y est la dimensin de abstraccin (modelos),
observe que el modelo de anlisis y el modelo a diseo, estn separados con una lnea
entrecortada.
Si nos fijamos en la tercera columna de la figura 8.4 del texto bsico, en el modelo de anlisis encontramos
diagramas de secuencia y en el de diseo tambin, pues bien, como el de diseo es ms aproximado a
la solucin (de aqu pasaremos a la construccin), podemos ver que se ha realizado un refinamiento de
este diagrama.
Entonces revise cada uno de los elementos columnas que se presentan, aqu encontramos los de
arquitectura, interfaz, componentes y despliegue, es de importancia que revise la teora, el grfico y los
elementos que se muestran. De ser posible realice un cuadro sinptico donde resuma los conceptos que
encuentra.
Revise el OCW http://ocw.um.es/ingenierias/fundamentos-de-ingenieria-delsoftware/material-de-clase,, bloque nmero 2, aqu podr reforzar los conocimientos
sobre los temas de requerimientos y diseo.
Hemos concluido el estudio de esta unidad, por lo que nos conviene comprobar
cunto hemos asimilado de los temas tratados para lo cual es necesario desarrollar
esta autoevaluacin.
30
PRIMER BIMESTRE
Autoevaluacin 2

determine si la afirmacin es verdadera o falsa. Como estrategia le recomendamos
1.
Con tareas de ingeniera de requerimientos, se puede saber cmo interactuarn los

usuarios finales con el software?
2.
El producto final de la ingeniera de requisitos es obtener un modelo de especificacin

de requisitos.
3.
Existen problemas en la obtencin de requerimientos debido a que estos cambian,

este problema se puede superar con una buena negociacin de requerimientos.
4.
La validacin de los requisitos se lo hace a la especificacin de los mismos a fin de que

estos contemplen ciertos atributos de calidad.
5.
Las herramientas de administracin de requerimientos permiten realizar una efectiva

negociacin entre todos los participantes del proyecto.
6.
En un software bancario el proceso de realizar transacciones lo realizamos a travs de

dispositivos tctiles, este sera un requerimiento esperado?
7.
Para obtencin de requerimientos podemos usar prototipos.
8.
Un diagrama de estados se encuentra dentro de los modelos de requerimientos en

sus elementos basados en escenarios.
9.
La prioridad de los requerimientos es presentada por parte del cliente.
10.
Los requerimientos se realizan a fin de llegar a la construccin del sistema.
SELECCIONE EL LITERAL CORRECTO

1.
Un requerimiento de confiabilidad del sistema que, en muchos

casos, no es mencionado por el cliente se categoriza como:
a) normal.
b) esperado.
c) emocionante.
2.
La obtencin de un documento escrito donde se haga constar

los requerimientos est dentro de la tarea de:
a) concepcin.
b) elaboracin.
c) especificacin.
3.
Si los clientes y usuarios piden ms de lo que se puede alcanzar

se debe llegar a una tarea de:
a) indagacin.
b) validacin.
c) negociacin.
Ir a solucionario
31
PRIMER BIMESTRE
UNIDAD 3: CICLOS DE VIDA DEL SOFTWARE

Esperamos que los temas que se trataron en la unidad anterior estn comprendidos a plenitud, si no
sucedi as, es momento de acudir a la tutora, tenga en cuenta que la presente unidad se enfoca en
el estudio de los ciclos de vida del software, en s es estudiar cmo se construye software, pero lo ms
importante es que aprender a diferenciar los modelos prescriptivos de los modelos giles diferenciando
sus fortalezas y debilidades.
3.1. 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, revisemos el captulo 2. Modelos de proceso donde
encontrar una amplia variedad de procesos de desarrollo y con esta informacin
realice su propia definicin sobre este tema.
En la figura 2.1 del texto bsico se muestra la estructura general para el proceso de software donde se
consideran ya algunos de los puntos estudiados anteriormente como las actividades sombrillas.
Tambin podemos notar que existen varias actividades estructurales, o sea que no solamente pueden
estar las cinco que revisamos en la unidad I, y dentro de cada actividad hay un conjunto de tareas que
nos permitirn cumplir con dicha actividad, recuerde lo que presentamos en un ejemplo anterior, las
tareas dependiendo de la naturaleza del proyecto software difieren.
Otro tema que encontramos en este apartado es flujo de procesos, podemos distinguir en la figura 2.2
del texto bsico los diferentes tipos y como lo puede notar las actividades del modelo de proceso3 casi
siempre son las mismas (ocasionalmente pueden variar), vara ms bien la interaccin de las mismas,
claro est, depender del tipo de solucin que se desee desarrollar as como de los recursos con los que
se cuenta.
Una actividad que le podra ayudar para la comprensin de este tema, es la de realizar una comparacin
entre cada uno de los flujos de proceso, identificando las similitudes y diferencias que usted observa en
la grfica. Esta es una buena prctica, no olvide realizarla.
En el apartado 2.1. Un modelo general de proceso, revise los temas Definicin de
actividad estructural, Identificacin de un conjunto de tareas, Patrones del proceso
que se presentan en el texto bsico. En uno de estos apartados se hace referencia a lo
que se conoce como Ingeniera de requisitos.
Ejercicio 3.1
Como actividad identifique cules seran las ventajas de utilizar los patrones de proceso.
Ahora bien, volviendo al texto bsico, si nos fijamos en la figura 2.1 encontramos parte de su explicacin
en el apartado 2.1.2 y este se complementa con la descripcin del conjunto de tareas que se muestra a
continuacin de este apartado, como se ve, debe escogerse el conjunto de tareas que se adapte mejor a
las necesidades de cada proyecto dependiendo de las caractersticas del equipo de desarrollo.
3
Apartado 1.3 de la unidad I.
32
PRIMER BIMESTRE
El modelo general de procesos para la ingeniera de software ha de incluir un conjunto

de actividades estructurales, acciones y tareas. Estos modelos pueden referirse por un
flujo diferente de proceso de cmo estarn organizadas las actividades.
De acuerdo al desarrollo y la naturaleza del proyecto debemos definir el conjunto de actividades, as por
los dos proyectos en la etapa de obtencin de requerimientos podemos tener casi las mismas tareas,
pero la formalidad y profundidad de cada actividad variar:
Proyecto sencillo: Sistema de facturacin
para la empresa de Distribucin de Materiales
Elctricos.
Proyecto medio: sistema de Gestin Acadmico

para el Colegio La Dolorosa.
Seleccionar los participantes para el proyecto.
Elaborar una lista de todas las personas que

estarn involucradas.
Reuniones de trabajo informales.
Entrevista a cada participante (se ha de anticipar

la hora y los temas a tratar para que se preparen)
Determina qu
participante.
funciones
necesita
cada
Se obtienen y priorizan los requerimientos.
Lista inicial de
requerimientos.
funciones
necesidades
Luego de un proceso de reuniones, negociaciones

de los requerimientos y validacin de los mismos
se obtiene la lista final de requerimientos (se
puede dividir en subtareas).
Administraran los requerimientos.
3.2. Evaluacin y mejora de procesos

Por ms que un proyecto de software se desarrolle a travs de un proceso este no garantiza la entrega a
tiempo del mismo, y que adems satisfaga las necesidades de los usuarios y a la vez an que represente
utilidades para quien lo est haciendo.
El proceso entonces debe evaluarse garantizando que se cumplan con estndares esenciales para la
ingeniera del software.
Las mejores prcticas CMMI se publican en los documentos llamados modelos. En la actualidad hay tres
reas de inters cubiertas por los modelos de CMMI: desarrollo, adquisicin y servicios.

CMMI para el desarrollo (CMMI-DEV o CMMI for Development).

CMMI para la adquisicin (CMMI-ACQ o CMMI for Acquisition).
CMMI para servicios (CMMI-SVC o CMMI for Services).
Si le ha interesado este tema y quiere profundizar sus conocimientos podra revisar esta
direccin electrnica que le presentar un detalle completo: http://www.sei.cmu.edu/
cmmi/ The Carnegie Mellon Software Engineering Institute (SEI).
33
PRIMER BIMESTRE
3.3. Modelos prescriptivos

Estos modelos de proceso permiten poner orden en el desarrollo de software. Son conocidos tambin
como modelos tradicionales, en la figura 3.1 podemos apreciar algunos de estos modelos.
Figura 3.1. Modelos prescriptivos de desarrollo de software.
Revisaremos ahora de cada uno de ellos, determinando algunas caractersticas esenciales, debe realizar
una lectura detallada de cada uno y subrayar en el texto las partes ms importantes.
Algo que debe tener en cuenta es que la mayora de los procesos de software han
de incluir la actividades estructurales que hemos visto, sin embargo cada uno de los
modelos pone ms nfasis en determinada actividad, as como el proceso que se
realiza en cada uno podr variar.
Cascada
Conocido tambin como ciclo de vida clsico. Es un modelo secuencial que empieza con el levantamiento
de informacin y la identificacin de requerimientos, cumpliendo con las etapas para terminar con la
puesta en marcha del sistema.
Existe una variante que es el modelo en V, este modelo se lo puede observar en la figura 2.4 del texto
bsico, donde cada una de las etapas tiene una contraparte que nos ayuda al aseguramiento de la
calidad del producto final.
Incremental
Es un modelo para la produccin de software en incrementos. Por qu? Esto es necesario para poder
cumplir con cierta funcionalidad requerida y que luego se puede ir agregando componentes adicionales.
Observe la figura 3.2 en la cual hemos representado un sistema con sus componentes, se trata de un
sistema de gestin acadmica donde en el centro est el proceso central de matriculacin y expediente
acadmico, y en sus alrededores otras funcionalidades que poco a poco pueden irse terminando para
llegar a completar la solucin definitiva.
34
PRIMER BIMESTRE
Adems debemos tener claro que cada una de las funcionalidades se crearn en base a un nuevo modelo
de procesos.
Se dice que el primer entregable ser la solucin principal, donde se plasma la mayora de los
requerimientos bsicos y luego se van agregando caractersticas suplementarias al producto final.
Figura 3.2. Ejemplo de modelo incremental.
Evolutivo
El modelo espiral es un modelo definido inicialmente por Barry Boehm en 1988, propone un ciclo de
desarrollo que evoluciona con cada iteracin.
Concurrentes
Es conocido como de ingeniera concurrente, los modelos anteriormente revisados son representados a
travs de elementos iterativos y concurrentes.
Despus de haber realizado la lectura, es hora de verificar cunto entendi de este tema, llenemos
entonces el siguiente cuadro resumen:
Comunicacin
Planeacin
Modelado
Construccin
Despliegue
Cascada
Incremental
Evolutivo
Concurrente
Los modelos de procesos predictivos, como se lo menciona, han estado siendo aplicados por muchos
aos con la finalidad de organizar las actividades de desarrollo de software. Todos estos proponen un
flujo de proceso pero basados siempre en las mismas actividades como lo demuestra el cuadro anterior.
El apartado del texto bsico 2.4 relacionado con modelos de procesos especializado
debe ser parte de una lectura realizada por usted para una comprensin de este tema,
puesto que estos modelos no sern tratados en esta asignatura.
35
PRIMER BIMESTRE
3.4. Fases del proceso unificado

Hablaremos ahora acerca de Proceso Unificado de Desarrollo de Software (RUP)
Est basado en componentes e interfaces bien definidas; utiliza el UML (Lenguaje Unificado de Modelado)
principalmente dirigido por casos de uso, adems de estar centrado en la arquitectura es un modelo
iterativo e incremental. El trabajo se divide en miniproyectos, los cuales son una iteracin que resulta en
un incremento. En cada iteracin se persiguen unos objetivos concretos.
Las fases son: inicio, elaboracin, construccin y transicin.
A continuacin va a encontrar el detalle de 4 aspectos que se distinguen dentro del RUP, (y en la mayora
de procesos), estos pueden encontrarse en cualquier documento de RUP.

PERSONAS: pueden ser: arquitectos, desarrolladores, ingenieros de prueba, personal de gestin,

usuarios, clientes. El proceso de desarrollo afecta a las personas; las personas que participan
deben tener formacin, entrenamiento y experiencia; tienen un conjunto de responsabilidades y
ejecutan variedad de actividades.
PROYECTO: elemento organizativo de gestin, que construye el producto. El sistema evoluciona

con una serie de iteraciones. Cada iteracin implementa un conjunto de casos de uso.
PRODUCTO: estos son artefactos que se crean durante la vida del proyecto, pueden ser: modelos,
cdigo, documentacin, diagramas UML, prototipos, componentes, el plan de prueba. Artefactos
de ingeniera y de gestin.
PROCESOS: conjunto de actividades para crear el producto tambin se puede decir que es una
plantilla para crear proyectos. Se define en trminos de flujos de trabajo (conjunto de actividades).
Se identifican trabajadores y artefactos.
Este modelo se ampliar con ms detenimiento en la unidad 4 de esta gua como parte de la asignatura.
3.5. Modelo de proceso personal y de equipo

El mejor proceso del software es el que est cerca de las personas que harn el trabajo4, con esta frase
podemos darnos cuenta que se puede aplicar un proceso de desarrollo personal que debe cumplir las
etapas, aunque en cada una de ellas pueda omitirse o agregarse actividades que se considere.
Ejercicio 3.2
Realice la siguiente actividad. Analice las caractersticas del proceso personal de software
y de proceso del equipo de software, e identifique sus similitudes y diferencias, luego
antelas en la siguiente tabla.
Pressman R. (2010). Cit. Ed. p. 48.
36
PRIMER BIMESTRE

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 comprensin
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 ms 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 metodologas denominadas giles y son quienes
establecieron estos principios.
Figura 3.3 Manifiesto gil5

5
Beck Kent et Al (2001) Agile Manifesto [En lnea] EEUU:Utah. Disponible en http://agilemanifesto.org/ [Consulta 26 abril
2011]
37
PRIMER BIMESTRE
Luego de leer este manifiesto resultara sencillo encontrar las diferencias entre los
denominados modelos prescriptivos y los modelos giles. Lea pausadamente el
manifiesto y trate de identificar cules seran las caractersticas de los modelos
prescriptivos En este sentido seran las contrarias a este manifiesto.
Vamos a tratar de comprender este tema que se lo revisa en el captulo 3 del texto
bsico, ya que es de mucha importancia por la acogida que tienen en la actualidad este
tipo de metodologas.
Con esta parte de la ingeniera de software conocida como gil lo que se desea es llegar a cumplir con
las necesidades del cliente de forma correcta y adems 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 definicin que plantea, en el
texto bsico, Ivar Jacobson. Qu puntos ha considerado abstraer de este concepto?
Compare esto con lo propuesto en el apartado 3.3 del texto bsico donde podemos
encontrar la definicin de un proceso gil; despus de leer este apartado comprender
claramente. Ahora responda a la interrogante: cules son las caractersticas 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 bsico notar cmo los costos por los cambios disminuyen
significativamente con procesos giles durante el avance del desarrollo del software.
Quienes estn orientados hacia el desarrollo de los procesos agiles debern conocer
los principios de agilidad y polticas de desarrollo gil, estos temas se encuentran
en el texto bsico 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. Programacin extrema

Ms conocida como XP, calificado como el ms 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 informalizacin que nos lleva a procesos continuos,
nos consumir tiempo que se ver reflejado en recursos, entonces debemos utilizar los procesos giles.
Cundo los debemos utilizar? El personal est consciente de lo que implican los procesos?
Valores
Son un total de 5 valores:

Comunicacin entre los ingenieros de software y otros participantes.

Simplicidad, solo se debe realizar lo que se necesita.
38
PRIMER BIMESTRE
Retroalimentacin del software implementado, el cliente y otros miembros del equipo.

Disciplina, adhesin a las prcticas 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 bsico podemos observar claramente este
proceso empezando de una fase de planeacin, para pasar al diseo y luego a la codificacin 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 evolucin de software existen muchas maneras de describir el proceso de desarrollo y mtodos
para modelar; as mismo, en los modelos giles, existen muchos otros mtodos 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 bsico va haciendo
una descripcin de cada uno de estos.
Hablemos de uno de estos modelos
SCRUM
Scrum utiliza estas actividades: requerimientos, anlisis, diseo, evolucin y entrega. Cada una de estas
actividades ocurre con un patrn de proceso llamado sprint.
6
Beck Kent et Al (2001) Agile Manifiesto [En lnea] EEUU:Utah. Disponible en http://agilemanifesto.org/ [Consulta 26 abril
2011].
39
PRIMER BIMESTRE
Figura 3.5. Scrum. Fuente http://www.proyectosagiles.org/
Scrum acenta 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.
Atencin: Cules seran 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 interaccin a travs 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 nmero 3, para reforzar los conocimientos acerca de los modelos de procesos
de software.
Hemos concluido el estudio de esta unidad. Ahora nos conviene comprobar cunto hemos asimilado
de los temas tratados. Desarrolle la tercera autoevaluacin. Nuevamente reiteramos la importancia que
tiene el desarrollo de las preguntas de autoevaluacin.
40
PRIMER BIMESTRE
Autoevaluacin 3

necesaria en el texto o en la gua didctica y luego fundamente su respuesta.
1.
La forma de organizar las actividades estructurales dentro del modelo general del
proceso de software se conoce como flujo del proceso.
2.
El nmero de actividades estructurales dentro del modelo general de proceso se

encuentra definida y no permite realizar una variacin.
3.
Si un cliente nos pide modificar cierta funcionalidad de un software, ser conveniente

utilizar un modelo de cascada para esta implementacin.
4.
La primera entrega que se realiza en los procesos incrementales es el producto final

que se va a entregar con un porcentaje mnimo de actualizacin.
5.
Cuando un software va cambiando, es decir, cuando va produciendo versiones ms

complejas del software por cada entrega, se puede decir que se est trabajando en
base a un modelo incremental.
6.
El prototipo sirve como la primera versin del sistema.
7.
Las primeras conversaciones con los gerentes de una organizacin para el desarrollo
del software donde se propone una arquitectura aproximada de lo que se va a
desarrollar, en RUP se refiere a la fase de inicio.
8.
El costo del cambio con procesos convencionales, de acuerdo al avance de

programacin, es menor al costo del cambio con el uso de procesos giles.
9.
En los procesos giles, las personas y el equipo de trabajo deben adaptarse a las
necesidades del proceso.
10.
El diseo dentro del XP sigue rigurosamente el principio MS (mantenerlo sencillo).
Ir a solucionario
41
SEGUNDO BIMESTRE
SEGUNDO BIMESTRE
6.5. Competencias genricas

Capacidad de abstraccin, anlisis y sntesis.
Conocimiento sobre el rea de estudio y la profesin.
Habilidades para buscar, procesar y analizar informacin procedentes de fuentes diversas.
Compromiso con la calidad.
6.6. Planificacin para el trabajo del alumno

COMPETENCIAS
ESPECFICAS
Planea, organiza,
dirige y controla
sistemas y servicios
informticos
en contextos
empresariales o
institucionales.
Analiza las
necesidades de
conocimiento
necesarias para
resolver un
problema.
INDICADORES DE
APRENDIZAJE
CONTENIDOS
UNIDADES/TEMAS
4.1. Mejores prcticas

Identifica los
de la ingeniera del
artefactos clave
software
de cada fase
4.2. Caractersticas
del proceso de
principales del RUP
desarrollo unificado.
4.3. Navegando por el
proceso unificado de
Extrae informacin
desarrollo
de la herramienta
4.4. Desarrollo de
del RUP 2003 para
software con el
aplicarla a proyectos
proceso unificado
reales.
Organiza iteraciones
considerando los
niveles de riesgo de
los casos de uso.
5.1. Modelado de
Realiza la
requerimientos
especificacin
correcta de los casos 5.2. Modelado basado en
escenarios
de uso.
5.3. Modelado UML para
casos de uso
Modela a travs
5.4. Modelado basado en
de diagramas los
clases
requerimientos de
5.5. Arquitectura de
software.
software
5.6. Gneros y estilos
Organiza los
arquitectnicos
componentes para 5.7. Breve taxonoma
la arquitectura del
de estilos
sistema.
arquitectnicos
5.8. Diseo
arquitectnico
ACTIVIDADES DE
APRENDIZAJE
Instalacin del RUP

2003.
Lectura del material
impreso en la gua
didctica.
CRONOGRAMA
ORIENTATIVO
Tiempo Estimado
Semana 1,2:
8 horas de
autoestudio y
8 horas de
interaccin.
Desarrollo de los
ejercicios propuestos
en la gua.
Desarrollo de la
autoevaluacin y
desarrollo de la
evaluacin a distancia.
Actividades del EVA
Lectura de los apartados Semana 3,4,5:
del texto bsico
sealados en la gua
12 horas de
didctica.
autoestudio y
12 horas de
Instalar la herramienta interaccin.
Rational Rose.
Desarrollo de la
autoevaluacin.
Desarrollo de la
evaluacin a distancia.
Actividades en el EVA.
Revisar recursos OCW.
43
COMPETENCIAS
ESPECFICAS
INDICADORES DE
APRENDIZAJE
Aplica criterios
de calidad a
los diferentes
componentes y
artefactos del ciclo
de vida del software.
SEGUNDO BIMESTRE
CONTENIDOS
UNIDADES/TEMAS
ACTIVIDADES DE
APRENDIZAJE
6.1. Conceptos de
calidad
6.2. Calidad del software
6.3. Dilema de la calidad
del software
6.4. Cmo lograr la
calidad del software
Lectura de los apartados

del texto bsico
sealados en la gua
didctica.
Unidades de la 4 a la 6
Repaso general de la
materia.
Desarrollo de la
autoevaluacin y
actividades en el EVA.
CRONOGRAMA
ORIENTATIVO
Tiempo Estimado
Semana 6:
4 horas de
autoestudio y
4 horas de
interaccin
Semanas 7 y 8
8 horas de
Desarrollo del
autoestudio
cuestionario de repaso a
travs del EVA.
8 horas de
interaccin
44
SEGUNDO BIMESTRE
6.7. Orientaciones especficas para el aprendizaje por competencias
UNIDAD 4: APLICACIN DE UN MODELO DE PROCESOS RUP

La presente unidad pretende ensearle un modelo de desarrollo de software que podr aplicar en
proyectos reales, se trata del proceso unificado de desarrollo que se caracteriza por su versatilidad y
adaptabilidad a diferentes tipos de proyectos.
Importante:
El contenido del presente captulo no se encuentra en el texto bsico, por
lo que ser desarrollado en su totalidad en la presente gua didctica, sin
embargo colocaremos las referencias necesarias para que pueda ampliar
la informacin.
En sus inicios el desarrollo de software era una prctica propia de los programadores, quienes gracias
a su gran capacidad e ingenio podan crear aplicaciones complejas, sin embargo a medida que estas
aplicaciones se incluan en el mbito empresarial se volvieron mucho ms complejas y los mtodos de
desarrollo utilizados hasta entonces se volvieron insuficientes.
A inicios de los 90, no haba un estndar en cuanto a modelos y representaciones de software, es as
como tres visionarios Gary Booch, James Rumbaugh e Ivar Jacobson, unen sus esfuerzos y logran crear el
Lenguaje Unificado de Modelado (UML) el cual brinda la tecnologa necesaria para apoyar la prctica de
la ingeniera de software orientada a objetos, pero no da la estructura del proceso que gue a los equipos
del proyecto cuando aplican la tecnologa7, lo que los llev a crear el denominado Proceso Unificado
de Desarrollo Rational (RUP), que hoy en da es uno de los procesos ms ampliamente utilizados en la
prctica de la ingeniera del software y para una gran cantidad de proyectos.
Revisemos en este momento los orgenes y fundamentos del proceso unificado de
desarrollo, que ms all de los antecedentes histricos, nos interesa conocer las bases
que lo sostienen; en este sentido trataremos dos apartados importantes que son:
las mejores prcticas de la ingeniera del software y las caractersticas que lo hace
diferentes de los otros procesos de desarrollo.
4.1. Mejores prcticas de la ingeniera del software

El RUP se fundamenta en las mejores prcticas de la ingeniera del software que se han originado como
soluciones a los principales problemas que debe enfrentar el proceso de desarrollo; por lo tanto, 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 aplicacin de plantillas para las diferentes
partes del proyecto.
Pressman R. (2010). Ob. Cit. P. 23.
45
SEGUNDO BIMESTRE
4.1.1. Prctica 1: Desarrollo iterativo

El proceso de desarrollo denominado ciclo de vida clsico, visto en la unidad 2 de la presente gua
didctica, se caracteriza por sus fases organizadas secuencialmente, lo cual genera algunos problemas
como: retrasos en la identificacin de los riesgos, dificultades al momento de medir el avance del
proyecto, mucha redundancia de trabajo, aparte de que resulta en proyectos de desarrollo que arrojan
resultados a largo plazo, tiempo en el cual cambiaron las necesidades organizacionales; y, por tanto el
producto de software se vuelve obsoleto antes de entrar a produccin.
Para evitar este problema, esta prctica 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.
Requerimientos
Anlisis y diseo
Planificacin
Implementacin
Gestin de la
configuracin
Pruebas
Evaluacin
Liberacin
Figura 4.1. Etapas de un proceso iterativo8
En la figura 4.1 se aprecia esta estrategia que es usada por el RUP y algunos otros procesos giles de
desarrollo de software, cuyo esquema de operacin es el siguiente: cada ciclo (iteracin) inicia con una
fase de planificacin donde se establecen alcances, recursos, personas y resultados esperados para esa
iteracin, luego de realizar el estudio de necesidades que derivan en los requerimientos; prOcede a la
fase de implementacin que inicia con el anlisis y diseo y culmina con la implementacin; de esta fase
pasamos a la fase de evaluacin y de haberse completado el desarrollo, se libera y termina; de no ser este
el caso pasa a una nueva fase de evaluacin, planificacin dando inicio a la siguiente iteracin.
4.1.2 Prctica 2: gestionar los requerimientos
De acuerdo al reporte conocido como CHAOS Report9 , la tasa de xito de los proyectos de desarrollo de
software ha ido disminuyendo progresivamente, y atribuye como causa ms comn de dichos fallos a
una incorrecta definicin de los requerimientos en las fases iniciales del proyecto, y una pobre gestin
a lo largo del ciclo de desarrollo.
La administracin de requerimientos es la prctica sistemtica para encontrar, documentar, organizar y
dar seguimiento a los requerimientos del sistema.
Esta prctica, por tanto, se enfoca en tres objetivos generales:
1.
8
9
Asegurarse de que se resuelve el problema correcto y se construye el sistema adecuado.

IBM Corp. (2003). Module 1: Best practices of software engineering. P. 3.
Citado por IBM Corp. (2003). Module 1: Best practices of software engineering. P. 8.
46
SEGUNDO BIMESTRE
2.
3.
Tener un mtodo organizado para levantar, organizar, documentar y gestionar los requerimientos
cambiantes de las aplicaciones.
Mantener un sistema de control de cambios en los requerimientos.
A ms de estas caractersticas, 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 estndar IEEE para la ingeniera
de software como El grado en el cul una relacin puede ser establecida entre dos o ms productos
del proceso de desarrollo, especialmente productos que tienen entre s relaciones como predecesorsucesor o superior-subordinado10.
En este sentido, la trazabilidad (figura 4.2) de los requerimientos permite asegurar que todas las
necesidades de los usuarios han sido consideradas en los documentos de especificacin, y estas a su vez
han sido representadas en los modelos del sistema y es lo que finalmente se implementa y, en sentido
contrario, asegura que todo lo implementado y modelado responda a las necesidades del usuario.
Figura 4.2. Modelo de trazabilidad de los requerimientos de software.
4.1.3. Prctica 3: utilizar la arquitectura basada en componentes

El estilo de arquitectura basada en componentes es ampliamente utilizado en todas las ramas de la
ingeniera y establece el principio por el cual todo el sistema se construye en piezas reutilizables
denominadas componentes las cuales, a su vez, pueden estar organizadas en capas, como se muestra
en la figura 4.3.
Figura 4.3 Arquitectura de componentes11

10 Citado por Westfall L. (2006). Bidirectional Requirements Traceability.
11 IBM Corp. (2003). Module 1: Best practices of software engineering. P. 15.
47
SEGUNDO BIMESTRE
Esta prctica favorece la reutilizacin tanto de los componentes como de la arquitectura en s, facilita
las actividades de planificacin, asignacin de recursos y la liberacin del producto y a la vez reduce la
complejidad inherente al sistema mediante la descomposicin en partes ms pequeas y manejables.
4.1.4. Prctica 4: modelar visualmente
Booch et Al (2006:6) definen a un modelo como Una simplificacin de la realidad y adems consideran
que Todos los sistemas pueden ser descritos desde diferentes perspectivas utilizando diferentes
modelos, y cada modelo es, por tanto, una abstraccin semnticamente cerrada del sistema.
El modelado visual se ve soportado en su totalidad por UML y permite: visualizar, especificar, construir
y documentar los artefactos de un sistema con gran cantidad de software. En la figura 4.4 se muestran
varios de los modelos que se pueden desarrollar con UML.
Figura 4.4. Modelos visuales de un sistema con UML12
4.1.5 Prctica 5: verificacin continua de la calidad

La calidad del software es un factor que ha afectado considerablemente la confianza en los equipos de
desarrollo. Hemos mencionado anteriormente que los proyectos de software se caracterizan por su
complejidad, sin embargo no tenemos una disciplina tan madura que nos permita asegurar la calidad
durante todo el proceso de desarrollo.
Segn el estndar ISO 9126, los atributos de calidad que deberan medirse en el desarrollo de software
son: funcionalidad, confiabilidad, usabilidad, eficiencia, facilidad de recibir mantenimiento y portabilidad.
La prctica 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, por tanto
propone el aseguramiento de la calidad como estrategia para prevenir los cambios o errores al final del
proyecto.
En la unidad 6, realizaremos el estudio de lo relacionado con la calidad, la cual se
encuentra desarrollada en la tercera parte del texto bsico: Administracin de la
calidad.
12 IBM Corp. (2003). Module 1: Best practices of software engineering. P. 20.
48
SEGUNDO BIMESTRE
4.1.6. Prctica 6: gestionar los cambios

Los cambios en el software son muy comunes debido a las condiciones cambiantes que afectan a
las organizaciones, lo ideal sera que no hubiesen cambios durante el desarrollo o una vez puesto en
produccin el sistema; sin embargo, eso no sucede en el mundo real, los requerimientos de cambio son
cada vez ms rpidos y, por lo tanto, la decisin ms inteligente que se puede tomar es administrarlos
utilizando herramientas que permitan hacer una gestin eficiente de los mismos.
Ejercicio 4.1
Una vez que ha completado el estudio de las mejores prcticas de la ingeniera de software,
le invitamos a que reflexione sobre ellas y desarrolle el siguiente ejercicio.
1.
Al inicio de la unidad se plante que las mejores prcticas de la ingeniera del software surgieron
como respuesta a los problemas que haba con los proyectos de desarrollo, en este momento le
pedimos que realice un anlisis inverso y establezca cules considera que son estas causas. Utilice
la siguiente tabla.
Mejor prctica
Desarrollo iterativo.
Causas principales
Gestionar los requerimientos

Utilizar la arquitectura basada
en componentes
Modelar visualmente
Verificacin continua de la
calidad
Gestionar los cambios
2.
Una vez que ha establecido las causas que han sido consideradas para ser resueltas con las mejores
prcticas del RUP, describa las caractersticas que deberan tener este proceso de desarrollo que le
permitira atacar esos problemas. Utilice un mapa mental similar al siguiente.
49
SEGUNDO BIMESTRE
IMPORTANTE
No avance si no desarroll el ejercicio, 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 cmo es
un proceso de desarrollo de software que est basado en esas mejores prcticas.
Continuemos conociendo otro de los cimientos del RUP, que en este caso son las caractersticas.
4.2. Caractersticas principales del RUP

Basado en las mejores prcticas de la ingeniera del software que resuelven los problemas mayores
comunes a los proyectos de desarrollo de software, el estudio del RUP debe comenzar con el conocimiento
de sus caractersticas ms importantes.
Cuatro son las caractersticas que sus creadores Jacobson et Al (2000:5) atribuyen al proceso unificado y
que las vamos a resumir en las siguientes lneas:
4.2.1. Dirigido por casos de uso
Los casos de uso representan una forma particular de ver el sistema, esto es con los ojos del usuario, por
tanto ayudan a responder la pregunta: qu debe hacer el sistema? La estrategia de casos de uso puede
describirse aadiendo tres palabras al final de esta pregunta para cada usuario?13, esto significa
que los miembros del equipo en lugar de pensar en las caractersticas deseables del sistema, deben
esforzarse por entender las necesidades de cada uno de los usuarios.
Este cambio de concepcin no solo afecta a la etapa en donde se identifican las necesidades, por el
contrario implica que a partir de los casos de uso realizamos el diseo, la implementacin y las pruebas,
con lo cual podemos decir que los casos de uso guan el proceso de desarrollo, adems de guiar la
arquitectura y, a su vez, esta arquitectura incide en la seleccin de los casos de uso.
4.2.2. Centrado en la arquitectura
De manera similar a como sucede con los planos en la industria de la construccin de viviendas, la
arquitectura del software representa desde diferentes capas cmo se construir el producto de software,
en los modelos de software estas capas se conocen como modelos: esttico, dinmico y de implantacin;
todos orientados por los casos de uso y otros aspectos propios del entorno organizacional.
4.2.3. Iterativo e incremental
El desarrollo de proyectos de desarrollo de software en los modelos tradicionales (no iterativos) tiene
un problema bastante complejo de manejar, puesto que si se sigue el ciclo de vida clsico, se tiene
etapas secuenciales que deben cumplirse antes de pasar a la siguiente, sin embargo en la prctica las
necesidades de los usuarios varan mucho o son difciles de obtener a la primera, aparte de que es muy
vertiginoso el cambio en el contexto organizacional, en ese sentido suele suceder que una vez pasada
la fase de levantamiento de informacin y mientras se est trabajando en el diseo, implementacin
y pruebas, muchas condiciones han cambiado y por tanto los requerimientos tambin cambiaron, se
agregaron y simplemente ya no son necesarios.
13 Jacobson et Al (2000): Ob. Cit. P. 5.
50
SEGUNDO BIMESTRE
A esta situacin, en los proyectos, se la identifica como riesgosa, y el propsito del RUP es identificar y
reducir los riesgos lo ms temprano posible en el proyecto. Barry Bohem, en relacin a lo que necesita una
disciplina de software, escribi que cree una aproximacin al proceso de desarrollo de software dirigida
por los riesgos en lugar de un proceso fundamentalmente dirigido por los documentos o dirigido por el
cdigo14, y esto es precisamente lo que RUP busca, reducir los niveles de riesgo lo ms pronto posible,
como se aprecia en la figura 4.5, en los niveles de riesgo en un proceso iterativo e incremental y un
modelo en cascada son similares, sin embargo a medida que avanzan estos niveles empiezan a disminuir
de manera temprana en el primero; en tanto que en el segundo, estos niveles empiezan a disminuir
mucho ms tarde en el proyecto, lo que significa tambin que los costos provocados por efecto de los
riesgos sern mucho ms altos que en el anterior.
Figura 4.5. Diferencia de los niveles de riesgo entre un proceso de desarrollo iterativo y el modelo en cascada15.
Como solucin a esta situacin el RUP y otra gama de procesos de desarrollo conocidos como giles,
entre ellos XP, SCRUM y otros, han optado por la estrategia de trabajar en ciclos cortos de desarrollo
que en RUP se conocen como iteraciones, durante las cuales el equipo de desarrollo cumple todas
las actividades que ahora se conocen como disciplinas e incluyen: anlisis del negocio, anlisis de
requerimientos, planificacin y gestin del proyecto, aseguramiento de calidad entre otros, y en cada
iteracin se propone entregar parte de la solucin a los usuarios, 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.
Qu le parecen las caractersticas del RUP? Cree que estas realmente cumplen con las
caractersticas sugeridas en las mejores prcticas? Qu tan lejos o qu tan cerca estuvieron
sus respuestas de las caractersticas aqu planteadas?
Ejercicio 4.2
Elabore un breve ensayo con las respuestas a estas preguntas y adjntelo en su trabajo
a distancia.
Bien, ahora que ya conoce algunas de las caractersticas del RUP, es momento de trabajar con l, para ello
es necesario instalar el RUP, en su computador, el cual que viene en el disco adjunto a su gua didctica.
Las instrucciones para su instalacin las encontrar en el EVA, con este producto se trabajar en el resto
del presente captulo.
14 Citado por Jacobson et Al (2000) Ob. Cit. P. 86.
15 Jacobson et Al(2000) Ob. Cit. P. 86.
51
SEGUNDO BIMESTRE
IMPORTANTE
Como ya lo habr notado, el contenido del paquete se encuentra en idioma ingls,
por lo tanto, es conveniente que tenga un dominio bsico del ingles tcnico, pero
conscientes de que esto podra ser un problema, vamos a tratar de orientarle
en el desarrollo del contenido, sin embargo ser necesario que se valga de otros medios para
comprender el contenido de la herramienta para que le saque el mximo provecho.
4.3. Navegando por el proceso unificado de desarrollo

El proceso unificado de desarrollo como todos los procesos se compone de 3 elementos bsicos: fases,
disciplinas e iteraciones, las cuales estn ntimamente integradas para asegurar el cumplimiento de las
mejores prcticas.
Vamos a reconocer estos elementos navegando por el proceso de desarrollo, para ello
le invitamos a que ingrese al RUP que instal en su computador, vaya a Inicio|Todos los
Programas|Rational Software|Rational Unfified Process, como se muestra en la figura 4.6.
Iniciado el comando se levantar su navegador Web, espere que se inicie la aplicacin y,
dependiendo de las configuraciones de seguridad, es posible que le solicite autorizacin para ejecutar
un control Activex y un applet denominado ruppresenter, lo cual debe permitirlo siempre, tenga en
cuenta que para ejecutar el applet la pregunta que hace es: Desea impedir que se ejecute el applet y
la opcin SI est predeterminada y recomendada, en este caso debe responder NO para que se ejecute
la aplicacin.
Figura 4.6. Inicio de aplicacin de RUP 2003.
Una vez que ha ingresado familiarcese con la aplicacin que tiene en pantalla (ver figura 4.7), en la parte
izquierda tiene un rbol de navegacin el cual le permitir realizar un recorrido por cada uno de los
componentes del proceso unificado de desarrollo; en la parte derecha que es la ms amplia es donde
se muestra el contenido, en la parte superior del rbol de navegacin encontrar los botones de control
para cada una de las vistas del RUP, en la parte superior del rbol de contenido encontrar el rbol de
ruta en donde puede saber dnde se encuentra ubicado y haciendo click en l se puede regresar.
52
SEGUNDO BIMESTRE
Figura 4.7. Ventana de inicio del RUP.
Ahora bien, para seguir avanzando, es preciso que aprenda a navegar por la aplicacin. Para ello debe
empezar con el rbol de navegacin en donde encontrar todas las opciones del programa, entre ellas
debe buscar la opcin que dice Navigating the process que se encuentra bajo la vista Getting Started.
Al seguir las instrucciones dadas aprender a navegar por toda la aplicacin.
Ejercicio 4.3
Ahora que conoce algo de la herramienta, le invito a que siga las indicaciones que aparecen
en la seccin Getting Started; y, una vez que est familiarizado, desarrolle las siguientes actividades:
Navegue por la herramienta para encontrar la siguiente informacin:
1.
Identifique y liste las fases (phases) y las disciplinas (disciplines) y antelas en las siguientes tablas
junto con su descripcin.
Para hacerlo seleccione, en el rbol de navegacin, la opcin overview (vista general); all encontrar, en la
ventana de contenido, el grfico del proceso unificado de desarrollo, luego ingrese en cada una de las
fases y establezca el propsito de cada una de ellas, anotndolo en la columna correspondiente de la
tabla. Todo el contenido debe estar en espaol. Luego haga lo propio con las disciplinas. Cuando visite
cada disciplina tendr un diagrama de las actividades que implica, para obtener la descripcin de la
misma, deber darle un vistazo general a cada diagrama e ingresar a estas actividades, haciendo clic en
cada una de ellas, en donde encontrar sus descripciones.
a. Fases
Fase (Phase)
Descripcin
53
SEGUNDO BIMESTRE
b. Disciplinas
Disciplinas
Descripcin
Estamos seguros que logr cumplir con la tarea. Conforme se familiarice con este entorno le resultar
ms fcil sacarle provecho; como decamos antes, es posible que el idioma le haya significado ocupar un
poco ms de tiempo, pero eso le beneficiar mucho ms adelante.
2.
Ahora le invitamos a ver cmo puede obtener informacin adicional, para ello ubquese en la
seccin Process essentials el rbol de navegacin en la vista Getting Started, luego haga click
en el documento Whitepaper: The Ten Essentials of RUP, lalo y elabore un breve resumen de su
contenido.
3.
Ahora seleccione la vista Team (Equipo), luego seleccione Rup Lifecycle (ciclo de vida del RUP),
en la ventana de contenido haga click en Inception (inicio o conceptualizacin) e identifique
cules son los roles que intervienen en esta fase y lstelo a continuacin.
4.
Regrese nuevamente a RUP LIFEYCYCLE, y ahora haga clic en donde dice Lifecycle objectives
milestone, ahora en la tabla que aparece hay artifacts (documentacin) ordenados por importancia.
Indique cul es el de mayor importancia y cul es el de menor importancia?
5.
Ahora ingrese al artefacto Visin haciendo clic en el mismo; y, en la tabla resultante, haga clic en
CREG-VisionInception y revise el contenido del documento de visin para ese proyecto ejemplo.
6.
Finalmente regrese y haga clic Template: Vision y seleccione todo el contenido de esa pgina (ir
al men del navegador, ingrese a la opcin Editar y luego seleccionar todo) luego copie (Ctrl + C)
este contenido en un documento en Word, y de esta forma ha obtenido una plantilla en formato
Word que podra usar en sus proyectos. Luego haga lo mismo con Template: Visin (Informal) y
obtendr plantillas ms livianas para proyectos pequeos.
54
SEGUNDO BIMESTRE
Si instala en su navegador la barra de herramientas Google puede traducir todo el

contenido a espaol, y podr obtener incluso las plantillas para los documentos Word
en espaol. Lo que s es necesario acotar es que debido a la terminologa tcnica, las
traducciones no son totalmente efectivas; sin embargo tienen un nivel aceptable como
para que pueda desarrollar sus actividades.
Estimado estudiante, la ingeniera del software es mucho ms amplia de lo
que pretendemos cubrir con la presente asignatura, sin embargo dejamos
algunas bases y herramientas que estamos seguros le sern de mucha
utilidad al momento de trabajar en proyectos reales, y el RUP es una de
ellas. Le invitamos, por lo tanto, a que la use no solamente como un recurso acadmico
para aprobar el curso, sino que lo use en la prctica. Hay muchas opciones que no
hemos explorado, pero usted puede explorarlas y sacarles provecho.
La herramienta del RUP que usted acaba de utilizar tiene abundante informacin sobre procesos,
tcnicas, herramientas y plantillas (templates) que puede utilizar para trabajar en sus proyectos e incluso
puede personalizarlas para acoplarlas a los diferentes tamaos y tipos de proyectos.
4.4. Desarrollo de software con el Proceso Unificado

Hasta ahora hemos hecho un breve recorrido por las mejores prcticas y caractersticas del RUP, lo cual
nos ayuda a comprenderlo; pero para poder usarlo es necesario conocerlo; a pesar de que en los ejercicios
del apartado 4.1 tuvo la oportunidad de conocer algunos elementos, vamos a tratar de enfocarnos en
aspectos clave para poder usarlo en proyectos reales.
Iniciamos nuestro estudio revisando la estructura general del RUP, que usted ya tuvo la oportunidad
de revisar, para ello centremos nuestra atencin en la figura 4.8 donde podemos apreciar las fases, las
disciplinas y las iteraciones del RUP; adems 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,
todas las disciplinas se ejecutan con diferente nivel de esfuerzo mientras avanzan las fases, por tanto en
la fase de inicio (inception) tambin puede haber algo de implementacin de cdigo; sin embargo este
se acenta conforme se acerca a la fase de construccin.
Figura 4.8. El proceso unificado de desarrollo16.

16 Booch et Al (2006). Cit. Ed. P. 490.
55
SEGUNDO BIMESTRE
Puesto que usted ya tuvo la oportunidad de investigar el propsito de cada fase, no consideramos
necesario redundar en el tema; sin embargo queremos hacer hincapi en la visin general del proceso y
en los hitos de cada una de las fases que propone el RUP.
Jacobson, I. et Al (2000:99), en la figura 4.9, plantean los siguientes objetivos para cada una de las fases,
que resumiendo seran: de la fase de inicio el hito principal es el alcance del producto, de la fase de
elaboracin el hito es la arquitectura estable, de la fase de construccin el hito es tener una versin
estable del producto y el objetivo de la fase de transicin es obtener el producto correctamente
entregado a los usuarios.
A nivel general, podemos decir que el proceso de construccin del software con el proceso unificado de
desarrollo consiste en el desarrollo del siguiente proceso, al que lo revisaremos a travs de cada una de
sus fases.
Figura 4.9. Hitos principales del proceso unificado de desarrollo17.
Estimado estudiante: tenga en cuenta que las siguientes secciones de

este captulo se basan en los materiales siguientes: RUP2003, que usted
lo tiene disponible e instalado en su mquina y el curso Rational Unified
Process Made Easy v 1.0 de IBM Rational, a los cuales tenemos acceso por
el convenio acadmico.
Nuestro afn es que usted se lleve una idea muy clara de lo que implica el proceso de desarrollo de
software, y pensamos que la mejor manera de hacerlo es mostrarle los elementos que a continuacin
desarrollamos como resumen de lo ms importante de cada una de las fases del proceso unificado de
desarrollo.
Puesto que usted dispone del RUP2003 y ha tenido la oportunidad de obtener algunos
elementos del mismo, puede complementar la informacin aqu brindada navegando en
el mismo; por lo tanto le proponemos que conforme va leyendo estos apartados, ingrese
al RUP, y en el rbol de navegacin ingrese al Overview, y en el diagrama general del
RUP, haga click en cada una de las fases, procesos, actores y plantillas para ir descubriendo todo lo que
implica el contenido.
4.4.1. La fase de inicio
Como habamos mencionado antes, en la fase de inicio se busca establecer el alcance del proyecto, para
ello debe cumplir con una serie de flujos de trabajo desarrollado por diferentes actores del proyecto.
17 Jacobson et Al (2000). Cit. Ed. P. 99.
56
SEGUNDO BIMESTRE
OBJETIVOS DE LA FASE DE INICIO

1.
Obtener claridad en lo que se desea construir: ello significa obtener la visin del cliente, lo que
desea, y el valor que le agrega a los usuarios el proyecto.
2.
Identificar los requerimientos principales: casos de uso y requerimientos no funcionales.
3.
Establecer al menos una solucin potencial: esto es identificar la arquitectura candidata.
4.
Obtener una visin clara del cronograma, costos y riesgos asociados al proyecto, para ello se
obtiene el caso de negocio, plan de desarrollo del proyecto y lista de riesgos.
Roles que intervienen:

Gerente del proyecto (Project Manager): es el responsable de que el proyecto se cumpla con el
alcance definido, en el tiempo y costes previstos con los niveles de calidad acordados, es por tanto
quien organiza las actividades.
Ingeniero de procesos (Process Engineer): es el rol responsable de definir todos los procesos que
se usarn en el proyecto, personalizacin de los mismos, entrenamiento y apoyo en los procesos a
los miembros del equipo y apoyo en la planificacin de actividades al gerente del proyecto. Este
rol puede ser asumido por el gerente de proyecto en equipos pequeos.
Analista de sistemas (System Analyst): es el rol que coordina el levantamiento de requisitos y el

modelado de casos de uso, delimitando el alcance y las funcionalidades del sistema. Este rol es
uno de los ms importantes, puesto que el alcance y requerimientos del sistema son elementos
crticos para garantizar el xito de un proyecto.
Arquitecto de software (Software Architect), este es uno de los roles tcnicos de alta importancia
para el proyecto, define las caractersticas de diseo del sistema.
Equipo de aseguramiento de calidad (Testers Roles): a diferencia del control de calidad en el que
se validan los productos de software, previa entrega a los usuarios, el aseguramiento de calidad
interviene desde etapas tempranas del proyecto todos los artefactos que se van generando en el
proyecto.
Actividades de la fase de inicio

1.
Definicin del alcance del proyecto
La definicin del alcance del proyecto implica capturar la informacin de contexto del proyecto,
los requerimientos de alto nivel, las restricciones y los criterios de xito del proyecto.
2.
Desarrollo del caso de negocio
Evaluar las alternativas para la gestin de riesgos, gestin de recursos, plan del proyecto los anlisis
costo/beneficio.
57
SEGUNDO BIMESTRE
Uno de los elementos fundamentales del caso de negocio es la identificacin de los procesos
de negocio que se vern afectados (beneficiados) y las expectativas que se tiene respecto a los
mismos, adems de realizar la evaluacin financiera que permita determinar qu tan beneficioso
resulta el proyecto frente a la inversin realizada.
3.
Definicin de la arquitectura candidata
Evaluar las ventajas y desventajas del diseo y las decisiones fabricar/comprar o reusar, de forma
que sean factibles las estimaciones de tiempo, costos y recursos.
4.
Preparacin del entorno del proyecto
En esta actividad se busca establecer el contexto en el que se desarrollar el proyecto, la

organizacin, las herramientas y la personalizacin del proceso de desarrollo.
Artefactos esenciales
Segn el RUP 2003, los artefactos esenciales de la fase de Inicio son los siguientes en orden de importancia:
Artefacto (Artifact)
Estado al cumplimiento del hito
Documento de visin (Visin)
Documenta los requerimientos centrales del proyecto, las

caractersticas fundamentales y las principales restricciones.
Caso de negocio (Business Case)
Definido y aprobado.
Lista de riesgos (Risk list)
Lista de riesgos iniciales del proyecto, identificada.
Plan de desarrollo de software

Etapas iniciales, duracin y objetivos identificados.
(Software development plan)
Adaptaciones y extensiones al RUP, documentadas y revisadas.
Proceso de desarrollo (Development
Tpicamente incluye lineamientos especficos para el proyecto as
process)
como las plantillas y las decisiones de personalizacin.
Plan de iteracin para la primera iteracin de la fase de elaboracin
Plan de iteraciones (Iteration Plan)
aprobado.
Glosario
Modelo de casos de uso
Prototipos
(opcional)
Terminologa importante del proyecto.

Actores y casos de uso importantes, identificados.
Flujos de eventos en lneas generales para los casos de uso ms
importantes.
Uno o ms prototipos conceptuales para dar soporte a la visin y
al caso de negocio y enfocado en tratar riesgos especficos del
proyecto.
En este sentido y en funcin de las caractersticas del proyecto, el documento ms importante es el

documento de visin, puesto que en l se definen cmo ser el producto, los involucrados en el proyecto,
sus necesidades, las restricciones del proyecto y los criterios de xito del mismo.
Criterios de evaluacin de la fase de inicio:

Los interesados en el proyecto estn de acuerdo con la definicin del alcance y las estimaciones
de costo y cronograma.
58
SEGUNDO BIMESTRE
Existe conformidad en que los requerimientos correctos han sido capturados y se ha logrado una
comprensin compartida de los mismos.
Todos estn de acuerdo en que las estimaciones de costo/cronograma, prioridades, riesgos y

proceso de desarrollo son los apropiados.
Se ha identificado todos los riesgos y existe una estrategia de mitigacin para cada uno de ellos.
En este punto puede abortarse el proyecto o reconsiderarse su enfoque si se falla en estos criterios.
Para trabajar obtenga las plantillas desde la herramienta, pero recuerde que el proceso
de desarrollo no implica nicamente el llenado de las plantillas, sino que implica llenar
las plantillas con la informacin resultante del trabajo desarrollado.
4.4.2 La fase de elaboracin

La segunda fase del proceso unificado de desarrollo tiene como hito el establecimiento de una
arquitectura estable del sistema, los objetivos de esta fase son lo que se indican a continuacin.
OBJETIVOS DE LA FASE DE ELABORACIN

1.
Obtener una comprensin detallada de los requerimientos: capturar al menos el 80% de los
requerimientos.
2.
Disear, implementar, validar y establecer la lnea base de la arquitectura: tomar las decisiones
cruciales de diseo, esto es comprar vs. desarrollar, patrones, etc.; establecer la lnea base del
la estructura del sistema y ejecutar una prueba inicial de carga y rendimiento del sistema.
3.
Mitigar riesgos con mayor criticidad, y producir un cronograma y estimaciones de costo ms

precisas.
4.
Afinar el plan de desarrollo.

Gerente del proyecto (Project Manager): se encarga de realizar el monitoreo y control del proyecto
y de la administracin de iteraciones.
Analista de sistemas (System Analyst): en esta fase administra los requerimientos y refina la
definicin del sistema.
Arquitecto de software (Software Architect): en esta fase define la arquitectura candidata y la

refina hasta dejar estable.
Desarrolladores (Developers): se encargan de construir y probar los componentes.
Aseguramiento de calidad (Resters): se encargan de verificar las estrategias de prueba.
59
SEGUNDO BIMESTRE
Actividades de la fase de elaboracin

1.
Definir, validar y establecer la lnea base de la arquitectura de una manera rpida y prctica.
2.
Refinar la visin en base a la nueva informacin obtenida, lograr una comprensin slida de los
casos de uso ms crticos que afectan a las decisiones de planificacin y arquitectura.
3.
Crear una lnea de base de los planes de iteracin para la fase construccin.
4.
Refinar el plan de desarrollo del proyecto considerando: procesos, herramientas y soportes

automticos requeridos por parte de los miembros del equipo del proyecto.
5.
Refinar la arquitectura y seleccionar componentes en base a las decisiones de comprar o desarrollar,

de modo que sirva para establecer cronogramas y costos realistas.
Artefactos esenciales
Prototipos
Uno o ms prototipos de la arquitectura se han creado para explorar las

funcionalidades crticas y escenarios significativos.
Lista de riesgos
Actualizada y revisada. Nuevos riesgos relacionados con la arquitectura

relacionados principalmente con requerimientos no funcionales.
Proceso de desarrollo
Se ha refinado el proceso de desarrollo, los lineamientos y las plantillas

basadas en la experiencia obtenida en el proyecto hasta ahora.
Infraestructura de desarrollo
El ambiente de desarrollo est listo e incluye todas las herramientas y soporte

automtico para el proceso.
Documento de arquitectura del Creado y establecido como lnea base, incluye descripciones detalladas de
software
los casos de uso arquitectnicos (vista de casos de uso), identificacin de
mecanismos y elementos de diseo (vista lgica) ms la definicin de la vista
de procesos e implantacin.
Modelo de diseo
Definido y establecido como lnea base. Diseo de realizaciones de casos

de uso para escenarios de arquitectura significativos y el comportamiento
requerido ha sido ubicado en los elementos de diseo apropiados. Se han
identificado los componentes y las decisiones de desarrollar/comprar/reusar
estn lo suficientemente claras para establecer con precisin los costos y
cronograma de la fase de construccin.
Los componentes arquitectnicos se encuentran integrados y evaluados
frente a los escenarios primarios.
Modelo de datos
Establecido como lnea base. Los principales elementos de datos han sido
definidos y revisados. Incluye entidades, tablas y relaciones.
Modelo de implementacin
Estructura inicial creada y los componentes principales estn prototipados.
Documento de Visin
Refinado, basado en la nueva informacin obtenida durante la fase,

estableciendo una comprensin slida de los casos de uso crticos que
orientan la arquitectura y las decisiones de planificacin.
Plan de desarrollo de software
Actualizado y expandido para cubrir las fases de construccin y transicin.
60
SEGUNDO BIMESTRE
Plan de iteraciones
Plan completo de iteraciones para la fase de construccin.
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 mayora de las descripciones de los mismos.
Especificaciones suplementarias
(Supplementary specifications)
Suite de pruebas (Test Suite)
Arquitectura
pruebas
del
sistema
Los requerimientos no funcionales han sido identificados y revisados.

Las pruebas han sido implementadas y ejecutadas para validar la estabilidad
de la construccin de cada versin ejecutable creada durante la fase de
elaboracin.
de La composicin y los mecanismos de los elementos del software de

automatizacin de pruebas han sido establecidos como base.
Modelo de anlisis
(opcional)
Manuales de usuario
Puede ser desarrollado como artefacto formal y evolucionar a la primera

versin del modelo de diseo.
Los manuales de usuario y otros recursos de capacitacin se han creado en
sus versiones borrador basados en los casos de uso. Pueden requerirse si el
sistema tiene una interfaz de usuario compleja.
Criterios de evaluacin de la fase de elaboracin:

La visin del producto es estable.
La arquitectura es estable.
Las tcnicas de validacin del software se han probado.
Las pruebas y evaluaciones de los prototipos ejecutables han demostrado que los elementos de
riesgo mayores han sido direccionados y efectivamente resueltos.
Los planes de iteracin para la fase de construccin se soportan en estimaciones confiables.
Todos los interesados estn de acuerdo en que la visin actual puede ser alcanzada si los planes se
ejecutan como estn para desarrollar el sistema completo en el contexto de la arquitectura actual.
La comparacin entre los recursos previstos y los recursos gastados muestran equivalencia o son
aceptables.
En este punto puede abortarse el proyecto o reconsiderar su enfoque si se falla en este hito.
61
SEGUNDO BIMESTRE
4.4.3 La fase de construccin

El objetivo de la fase de construccin es clarificar los requerimientos pendientes y completar el desarrollo
del sistema conforme lo establecido en la lnea base de la arquitectura. Esta fase es, en cierto sentido, el
proceso de manufactura donde se pone nfasis en administrar los recursos y controlar las operaciones
para optimizar los costos, cronogramas y calidad.
OBJETIVOS DE LA FASE DE CONSTRUCCIN

1.
Minimizar los costos del desarrollo y alcanzar cierto grado de paralelismo en el trabajo de los
equipos de desarrollo; esto significa optimizar los recursos y evitar retrasos innecesarios y la
repeticin del trabajo debido a los errores cometidos.
2.
Desarrollar de manera iterativa un producto completo que est listo para ser transferido a
su comunidad de usuarios; esto es desarrollar la primera versin operacional del sistema y
determinar si los lugares y los usuarios estn todos listos para que la aplicacin sea entregada.

Gerente del proyecto es el responsable de administrar las iteraciones, monitorear y controlar el

proyecto y planificar las siguientes iteraciones.

Administrador de versiones es el encargado de producir las versiones que se liberarn.

Analista de sistemas es el encargado de administrar todos los requerimientos de cambio.

Los desarrolladores son los encargados de construir los componentes.

Los testers son los encargados de probar y evaluar cada uno de los componentes construidos.

Un documentador tcnico en el encargado de desarrollar el material de soporte.
Actividades de la fase de construccin:

Gestin de recursos, control y optimizacin del proceso.

Completar el desarrollo de componentes y probarlos contra los criterios de evaluacin definidos.
Evaluar las versiones del producto contra los criterios de aceptacin definidos en la visin.
La aplicacin
Es el sistema ejecutable listo para iniciar la fase de pruebas (versin

beta).
Plan de implantacin
Versin inicial desarrollada, revisada y establecida como base. En

proyectos ms pequeos este puede ser embebido en el plan de
desarrollo del software.
Modelo de implementacin
Expandido del creado durante la fase de elaboracin; todos los

elementos de implantacin creados al final de la fase de construccin.
Suite de pruebas
Pruebas implementadas y ejecutadas para validar la estabilidad del

componente para cada versin ejecutable creada durante la fase de
construccin.
Plan de iteraciones
Plan de iteraciones para la fase de transicin completado y revisado.
62
SEGUNDO BIMESTRE
Modelo de diseo
Actualizado con nuevos elementos de diseo identificados durante el

desarrollo de todos los requerimientos.
Proceso de desarrollo
El proceso de desarrollo, incluyendo el caso de desarrollo (development

case) y cualquier lineamiento especfico del proyecto en plantillas
que se hayan definido estan basados en la experiencia del proyecto
y, adems, est lo suficientemente definido para proceder con la
siguiente fase.
Infraestructura de desarrollo
El entorno de desarrollo para la transicin est listo, incluyendo todas

las herramientas y soporte para la automatizacin del proceso.
Modelo de datos
Actualizado con todos los elementos necesarios para soportar la

implementacin de la persistencia (tablas, ndices, mapeo de objetos
a relacional, etc.).
Especificaciones
suplementarias (opcional)
Actualizado con nuevos requerimientos en caso de que se hayan

descubierto durante la fase de construccin.

(opcional)
Actualizado con nuevos casos de uso si se hubieran descubierto

durante la fase de construccin.
Criterios de evaluacin
Los criterios de evaluacin para la fase de construccin comprenden las respuestas a las siguientes
preguntas:

Es la versin de este producto estable y lo suficientemente madura para ser entregada a la

comunidad de usuarios?
Estn todos los interesados listos para la transicin a la comunidad de usuarios?
Los costos actuales versus los planificados continan siendo aceptables?
4.4.4 La fase de transicin

El enfoque de la fase de transicin es asegurarse de que el software est disponible para su comunidad
de usuarios finales. Esta fase puede subdividirse en varias iteraciones e incluye la verificacin del
producto preparndolo para ser liberado, hacer ajustes menores basados en la retroalimentacin de
los usuarios. En este punto la retroalimentacin de los usuarios debera enfocarse principalmente en
el afinamiento del producto como configuracin, instalacin e incidentes de usabilidad, debido a que
todos los incidentes estructurales han sido resueltos durante etapas anteriores.
63
SEGUNDO BIMESTRE
OBJETIVOS DE LA FASE DE TRANSICIN

1.
Probar la versin beta para validar que las expectativas del usuario han sido alcanzadas, esto
es corregir errores y realizar mejoras al rendimiento y a la usabilidad.
2.
Entrenar usuarios y personal de soporte para conseguir independencia del usuario.
3.
Preparar el entorno de implantacin y dejar listas las bases de datos operacionales, esto
implica comprar nuevo hardware, aadir espacio para el nuevo hardware y la migracin de
datos.
4.
Prepararse para la distribucin y la fuerza de ventas mediante el entrenamiento del personal,

esto es especialmente importante para productos comerciales.
5.
Conseguir el acuerdo de los interesados en que las lneas base de implantacin se han
completado y son consistentes con los criterios de evaluacin del documento de visin.
6.
Mejorar el rendimiento de futuros proyectos mediante lecciones aprendidas.

Gerente de implantacin, a cargo de ejecutar el plan de implantacin.
Gerente de proyecto, administra las iteraciones.
Implementador, se encarga de corregir errores en los componentes y de integrar el sistema.
Testers se encargan de probar y evaluar los componentes implementados colaborando con la

integracin del sistema.
Documentador tcnico: se encarga de desarrollar materiales de soporte como manuales de

usuario.
Actividades de la fase de transicin:

Ejecutar planes de implantacin.
Completar el material de soporte para usuarios finales.
Probar los productos entregables en el sitio de desarrollo.
Crear una versin del producto.
Obtener retroalimentacin de parte de los usuarios.
Afinar el producto basado en la retroalimentacin de usuarios.
Hacer que el producto est disponible para los usuarios finales.
64
SEGUNDO BIMESTRE

El producto
Completado de acuerdo a los requerimientos y en condiciones de

usabilidad para el cliente.
Material de soporte para

usuarios finales
Los materiales que asisten el aprendizaje del usuario final usando,

operando y manteniendo al producto deben estar completos y en
concordancia con los requerimientos.
Elementos de
implementacin
La implementacin se ha completado y ser establecido como base y

los elementos de implantacin han sido incorporados en el producto
final.
Suite de pruebas (opcional) La suite de pruebas desarrollada debera ser provista en la situacin
donde el cliente necesite ejecutar pruebas bsicas en sitio.
Criterios de evaluacin:
Los criterios de evaluacin primarios para la fase de transicin tienen que ver con respuestas a las
siguientes preguntas:

Est el usuario satisfecho?
Estn los gastos de recursos versus los gastos planeados en condiciones aceptables?
65
SEGUNDO BIMESTRE
Autoevaluacin 4
Estimado estudiante, ahora que ha comprendido cmo funciona el proceso unificado de

desarrollo, le invitamos a medir cunto a asimilado de la presente unidad, para ello srvase
responder a las siguientes interrogantes, cuyas respuestas no encontrar de manera
directa en el material, sino que le obligarn a realizar anlisis y aplicacin de los temas
contemplados. Insistimos en la importancia de resolverlas como estrategia de aprendizaje, si tiene
alguna duda es momento de acudir a la tutora.
1.
Asocie las buenas prcticas de la ingeniera de software, con los problemas que motivaron su
aparicin, recuerde que la primera actividad que se plante en esta unidad era establecer estos
problemas. Para asociarlas coloque las letras de las mejores prcticas en las filas correspondientes
de los problemas.
Mejores prcticas
A
Problemas que resuelven

Elemento de software difciles de reutilizar.
Desarrollo iterativo
Verificacin continua de la
calidad
Gestionar requerimientos
Modelar visualmente
Requerimientos incorrectos en fases iniciales.
Gestionar los cambios

Arquitectura basada en
componentes
Ambigedad en las especificaciones del sistema.
Largo tiempo para ver resultados.

Comunicacin pobre entre usuarios y miembros del equipo.
Escaso o nulo seguimiento de los requerimientos.

Calidad pobre de los productos de software.
Riesgo alto durante la mayor parte del proyecto.
Estimaciones pobres del proyecto.
Incremento de costos en etapas finales del proyecto.
Muchos errores al finalizar el proyecto.
Poca flexibilidad para cambios en el proyecto.
2.
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.
Disciplinas
66
Descripcin
Modelado de negocio
Escribir cdigo
Requisitos
Reglas de negocio
Anlisis y diseo
Configurar infraestructura
Implementacin
Organizacin de componentes
Pruebas
Establecer cronogramas
Despliegue
Identificar problemas
Gestin de la configuracin
Preparar espacios de trabajo
Gestin del proyecto
Recoger necesidades
Entorno
Validar escenarios
SEGUNDO BIMESTRE
3.
Organice artefactos dados colocndolos en la fase del proceso unificado correspondiente:

arquitectura de software, producto, documento de visin, modelo de anlisis, material de soporte
para usuarios finales, modelo de diseo, modelo de datos, caso de negocio.
Fase
Artefacto
Inicio
Elaboracin
Construccin
Transicin
SELECCIONE LA ALTERNATIVA CORRECTA EN CADA UNA DE LAS SIGUIENTES PREGUNTAS:

4.
Analizando los roles de las personas que forman parte de un proyecto de desarrollo de software
segn el RUP, cul es el rol responsable de que el proyecto se termine a tiempo, en los costos
y alcance establecidos y con los niveles de calidad esperados?
a.
b.
c.
d.
5.
Cul de los artefactos puede usarse para realizar la evaluacin financiera del proyecto?
a.
b.
c.
d.
6.
Documento de visin
Modelo de datos
Anlisis de stakeholders
Especificacin de casos de uso
Cul de los artefactos especifica los requerimientos no funcionales?

a.
b.
c.
d.
8.
El documento de visin
El caso de negocio
El modelo de costos
El caso de uso
Cul de los siguientes documentos captura y resume las necesidades de los usuarios?
a.
b.
c.
d.
7.
Los testers
El arquitecto de software
El gerente de proyecto
Los desarrolladores
Especificaciones suplementarias
Modelo de anlisis
Plan de iteraciones
Cul de las fases del RUP se establece como concluida cuando el cliente y los usuarios estn
conformes con el producto?
a.
b.
c.
d.
Fase de modelado
Fase de construccin
Fase de elaboracin
Fase de transicin
Ir a solucionario
67
SEGUNDO BIMESTRE
UNIDAD 5: MODELADO DEL SOFTWARE: ANLISIS, DISEO ARQUITECTURA

Una vez que hemos conocido el proceso unificado de desarrollo, en el cual manifestbamos que
como una mejor prctica, propona el modelado visual de los componentes, vamos a iniciar esta
unidad estudiando cmo modelar los requerimientos, se considerar adems cuestiones de diseo y
arquitectura del sistema los cuales son la base para el inicio de la fase de construccin, nos apoyaremos
en una herramienta de modelado conocida como Rational Rose.
5.1. Modelado de requerimientos

El modelo de anlisis es una forma de representar los requerimientos en cualquier
momento, el objetivo del modelo del anlisis es describir los dominios de informacin.
El modelo cambia en forma dinmica a medida que se aprende ms sobre el sistema
por construir.
El anlisis de los requerimientos da como resultado la especificacin de las caractersticas del software
y cmo se ha de comportar muestra la interfaz y elementos del comportamiento esperado del sistema
expresado en interacciones usuario-sistema.
La figura 6.1 del texto bsico nos muestra en dnde se encuentra el modelado del anlisis; estamos
hablando de un punto intermedio entre la descripcin del sistema y el modelo de diseo.
En el captulo 2 revisamos el resultado que se obtiene como accin de modelar los
requerimientos, pero ahora los vamos a revisar de una forma ms clara, aqu podemos
encontrar: modelado basado en escenarios, modelado de datos, modelos orientados a
clases, modelos orientados al flujo y modelos de comportamiento.
Realice una lectura del captulo 6. Modelado de los requerimientos: escenarios, informes y clases de
anlisis del texto bsico y veremos los diferentes enfoques para representar los requerimientos y los
modelos asociados a los mismos.
Si se fija en la figura 6.3 del texto bsico notar 4 componentes del modelado de requerimientos que
resumimos en la tabla 5.1.
Tabla 5.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 ejecucin de un sistema, la tcnica de modelado para estos escenarios y
la ms difundida por su versatilidad y simplicidad es la de los casos de uso,
que podramos entenderlas como historias de usuario.
El modelo de clases se usa para representar la estructura del sistema y
asociado a interacciones puede reflejar el comportamiento del sistema,
para representar este modelo se usan diagramas de clases y diagrama de
colaboracin.
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, estos se representan en los diagramas de estados y
diagrama de secuencia.
Estos modelos se enfocan en representar como fluyen los datos entre
procesos del sistema, los cuales normalmente se usan en las tcnicas de
anlisis estructurado, pueden representarse en base a dos componentes
que son: los diagrama de flujo de datos y los modelos de datos.
Como vemos los artefactos de trabajo con los que se modelarn los requerimientos son artefactos de
UML, que es lenguaje de modelado de componentes de software reconocido como un estndar por el
Object Management Group18.
5.2. Modelado basado en escenarios

El xito consiste en saber cmo desean interactuar los usuarios
finales con un sistema. Esto lo puede lograr el equipo de software
caracterizando adecuadamente los requerimientos y haciendo un
anlisis significativo.
El primer escenario que podemos encontrar es desarrollar casos de uso. Esto lo podemos lograr con las
dos primeras tareas que se tienen que realizar en la obtencin de requerimientos, las recuerda?, son la
concepcin e indagacin. En base a esto identificaremos participantes del proyecto, alcance, objetivos
operativos, prioridades, cules 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.
Primeramente los casos de uso pueden escribirse como una narracin informal, lo que algunos llaman
caso preliminar de uso, para luego pasar a un formato estructurado que puede ya existir con las
modificaciones del caso segn se necesite. Cada vez que se mantiene conversaciones con el participante
se van recabando los casos de uso.
Ejercicio 5.1
Ingrese a la direccin siguiente y estudie los diferentes artefactos de la seccin de
requisitos
http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Requisitos.
html#EspCU. Este es un ejemplo de modelado a partir de casos de uso de la Universidad Politcnica de
Valencia.
Para comprender lo que es un caso de uso, pensemos en aquellas cosas que podemos
hacer con un sistema, esto desde el punto de vista del usuario; piense por un momento
en su telfono celular como un sistema (en realidad lo es), los casos de uso para ese
sistema sera las cosas que como usuario usted puede hacer como realizar llamadas,
contestar llamadas, enviar mensajes de texto, leer mensajes de texto, etc. Naturalmente
18 Object Management Group, disponible en www.omg.org
69
SEGUNDO BIMESTRE
estos casos de uso surgieron de los requerimientos y estos a su vez de las necesidades planteadas por
los usuarios.
Desarrollemos otro ejemplo sencillo, se desea construir un dispositivo de bolsillo que permita escuchar
msica bien sea a travs de auriculares, parlantes o que transmita el audio en frecuencia FM, con una
duracin de batera mnima de 30 horas y una capacidad de almacenamiento suficiente para 5.000
canciones, reproducir videos con posibilidad de almacenar al menos 500 videos y posibilidades de juego.
Para resolver este problema, vamos a comenzar traduciendo las necesidades a requerimientos, los cuales
pueden ser funcionales o no funcionales. En la tabla 5.2. podemos apreciar este anlisis que nos permite
identificar requerimientos funcionales y no funcionales.
Tabla 5.2 Mapeo de necesidades a requerimientos
Necesidades
Requerimientos funcionales
Requerimientos no funcionales
RF01: Cargar msica de manera

organizada
RF02: Reproducir msica a travs
de auriculares
RF03 Reproduccin secuencial y
aleatoria
RF04: Control de volumen
RF05: Organizar listas de
reproduccin
RN01: Dispositivo porttil peso

mximo de 150 gramos.
RN02: Duracin de la batera mnima
de 30 horas en audio.
RN03: Interfaz sencilla para operacin
en movimiento.
RN04: Soporte para formato de audio
mp3 y wav.
RN09: Emisin seal FM.
N2: Reproducir
videos. Guarde
aproximadamente 500
videos.
RF06: Cargar archivos de video.

RF07: Reproducir formatos de
video.
RN05: Soporte para formato mpg,

mp4.
RN06: Pantalla de 4 a colores.
N3:
RF08: Cargar juegos.

RF09: Ejecutar juego.
RN07: Pantalla tctil.

RN08: Soporte aplicaciones Java.
N1:
Escuchar 30 horas
de msica al menos
y que guarde
aproximadamente
5000 canciones en
dispositivo porttil.
Posibilidades de juegos.
Como siguiente paso definiremos los casos de uso necesarios para atender estos requerimientos, esto lo
podemos apreciar en la tabla 5.3.
Tabla 5.3. Mapeo de necesidades a requerimientos
Nombre de caso de uso
Descripcin
Requerimientos
UC01: Organizar msica.
Permite organizar la msica y los videos en

el dispositivo en base a las preferencias del
usuario.
RF05
UC02: Reproducir msica.
Permite la seleccin y reproduccin de los

archivos de audio con opciones de control de
volumen, reproduccin aleatoria y reproduccin
secuencial.
RF02
RF03
RF04
RN03
RN04
RN07
RN09
70
SEGUNDO BIMESTRE
Nombre de caso de uso
Descripcin
Requerimientos
UC03: Reproducir video.
Permite la seleccin secuencial o en listas de los RF07

archivos de video en los formatos especificados. RN05
UC04: Jugar.
Ejecuta juegos implementados en lenguaje

Java y permite la interaccin del usuario con el
mismo.
RF09
RN07
RN08
UC05: Sincronizar informacin. Permite la comunicacin con un ordenador

para cargar los archivos de audio, video y
aplicaciones en Java.
RF01
RF06
RF08
UC06: Crear listas de

reproduccin.
RF05
Permite agrupar canciones en base a las

preferencias del usuario que le permititn
reproducir sus canciones favoritas agrupadas
conforme lo requiera el usuario.
En base a esta informacin podemos disear el modelo de casos de uso que se aprecia en la figura 5.1.
En esta forma hemos establecido cmo podemos pasar de la captura de necesidades del cliente a la
especificacin de requerimientos y estos a su vez a casos de uso.
El diagrama de casos de uso siguiente, representa una vista parcial de las funcionalidades disponibles en
un iPod (reproductor de msica y video).
Figura 5.1. Modelo de casos de uso para el reproductor de msica y video.
Ejercicio 5.2
Como habr notado, hay algunos aspectos importantes al momento de mapear las
necesidades a casos de uso, y es importante analizar algunos aspectos, para ello desarrolle
las siguientes actividades:
1.
Conteste a las interrogantes siguientes:

a.
Qu sucedi con los requerimientos funcionales? Fueron resueltos todos en los casos de
uso?
71
2.
SEGUNDO BIMESTRE
b.
Cmo afectaron a los casos de uso los requerimientos no funcionales? Cmo se atienden
los requerimientos no funcionales que no pasaron directamente a los casos de uso?
c.
Se puede asegurar que todos los casos de uso se basan en requerimientos y estos a la
vez en necesidades? Y viceversa, se puede asegurar que todas las necesidades estn
contempladas en los casos de uso?
d.
Cuntos requerimientos fueron atendidos por cada caso de uso? Cuntos casos de uso
han sido considerados por cada requerimiento?
Como habr notado, hemos colocado algunos actores entre los que podemos mencionar: usuario,
salida de audio, reproductor fm, itunes, en este caso itunes es una aplicacin que permite cargar
los archivos al reproductor. El ejercicio ahora consiste en disear este programa en base a las
necesidades, hacer las tablas de requerimientos, luego la de casos de uso y completar con el
diagrama para un sistema como lo es un telfono celular.
Cmo le pareci el ejercicio? Esperamos que lo haya completado, por favor no avance
si no lo hizo. 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 atrs, a esta caracterstica
la conocemos como trazabilidad de artefactos de software, y lo importante de ella es
que nos permite asegurarnos que todas las funcionalidades del sistema atienden a
necesidades de los usuarios, y todas la necesidades de los usuarios estn resueltas en
alguna de las funcionalidades.
5.3. Modelado UML para casos de uso

Vamos a revisar ahora algunos modelos UML que nos ayudarn a ver la informacin de un caso de uso
en forma ms clara.
Uno de los primeros es el diagrama de actividades, cuyos elementos los que vemos en la tabla son
rectngulos redondeados para una funcin especfica, flechas para determinar el flujo y los rombos para
determinar decisin.
Esto lo puede determinar en la figura 6.5 del texto bsico.
Ejercicio 5.3
Desarrolle un diagrama de actividades para una de las posibles funciones que se realizaran
en alguno de los casos de uso del ejercicio sobre el reproductor multimedia.
Ahora intente desarrollar un diagrama de canal que le permita registrar el proceso de matrcula en su
centro universitario.
5.4. Modelado basado en clases

Los modelos de clases se usan para representar la estructura (conocida tambin como
parte esttica) del sistema, y representa los objetos que formarn parte del sistema,
las operaciones que se aplicarn, las relaciones entre los objetos y la colaboracin que
tiene entre las clases.
72
SEGUNDO BIMESTRE
El primer paso es identificar las clases; para saber cmo, revise el apartado 6.5.1. Identificacin de las
clases de anlisis.
Del anlisis de los escenarios desarrollados, las clases se determinan subrayando cada sustantivo o frase.
Esa sera una primera aproximacin de las clases. Si la clase se requiere para implementar una solucin o
si solo es parte del espacio, esto debemos poderlo determinar.
Para el desarrollo de los diagramas que necesita se pueden emplear algunas herramientas, a continuacin
le presentamos algunas directrices para trabajar con Rational Rose, esta herramienta para fines educativos
podr utilizarla libremente, para lo cual deber seguir los siguientes pasos:

En el CD adjunto encontrar el instalador del mismo.
Debe contactarse con su profesor pues necesitar obtener una clave. Esta clave ser nica por
estudiante y para una sola computadora. Su profesor le explicar los pasos a seguir.
Posterior a esto puede empezar a trabajar en esta herramienta la misma que le permitir realizar
diagramas de clases, diagrama de actividades, diagrama de secuencias y otros artefactos de
software.
A continuacin le mostramos la imagen principal de la herramienta:
Figura 5.2. Tipos de diagramas en Rational Rose.
En la figura 5.2 puede ver dos tipos de diagramas que se estn realizando, adems de dnde seleccionar
la utilizacin de la herramienta.
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.
73
SEGUNDO BIMESTRE
5.5. Arquitectura de software

En el captulo 9. Diseo de la arquitectura del texto bsico, usted encontrar
informacin abundante sobre lo que es la arquitectura del software, estudie este
captulo en el texto, donde aprender cmo modelar la estructura del sistema y la
relacin que existe entre los datos y los componentes del sistema, este tema debe estar
claramente comprendido para su uso en el desarrollo de proyectos de software.
En el mbito de las aplicaciones corporativas podemos encontrar diferentes tipos de arquitecturas, las
cuales puede aplicarse igualmente a muchos tipos de escenarios, lo importante en este caso es conocer
las caractersticas de los diferentes estilos y patrones de arquitecturas para poder adaptarlos a los
diferentes contextos en donde se requiera la aplicacin.
Muchos sistemas se desarrollan sin tener en consideracin la arquitectura y terminan como aplicaciones
con serios problemas de escalabilidad, mantenibilidad entre otros.
5.6. Gneros y estilos arquitectnicos

El gnero arquitectnico es el que dicte el enfoque especfico para la estructura que deba construirse19,
de esto se obtendrn muchas categoras dentro del dominio de software. En este captulo del texto
bsico encontramos algunos gneros arquitectnicos para sistemas de software, revise estos temas,
luego haga una lista de software que conoce y clasifquelos.
Por ejemplo: Windows (sistemas operativos), C++ (herramientas), etc.
5.7. Breve taxonoma de estilos arquitectnicos

A continuacin revisaremos los estilos arquitectnicos que son base de muchos sistemas basados en
computadores.
Entonces revisemos el apartado 9.3.1 del texto bsico, de donde podemos encontrar esta taxonoma20:

Arquitectura centrada en datos.
Arquitectura de flujo de datos.
Arquitectura de llamar y regresar.
Arquitectura orientada a objetos.
Arquitectura en capas.
Las figuras que se presentan en este apartado nos dan una idea de cada una de estas arquitecturas. Debe
revisarlas y sacar los puntos principales de cada una de ellas, esto ser de gran utilidad cuando se traten
temas de diseo.
19 Pressman R. (2010). Cit. Ed. p. 209.

20 Taxonoma tiene su origen en un vocablo griego que significa ordenacin. Se trata de la ciencia de la clasificacin.
http://definicion.de/taxonomia/
74
SEGUNDO BIMESTRE
5.8. Diseo arquitectnico

La definicin del contexto donde se desarrollar el software es una tarea principal del diseo
arquitectnico, definiendo entidades externas con las que interacta el software y la naturaleza de dicha
interaccin.
Revise este apartado y encuentre la definicin de arquetipo adems de entender cmo
se ejecuta el proceso para obtener una arquitectura completa.
Representacin del sistema en contexto
En este apartado se tratar el tema de un diagrama de contexto arquitectnico (DCA), el mismo que
permite modelar la forma en que el software se relaciona con otras entidades.
En la figura 9.5 del texto bsico se presenta un DCA, revise cada uno de los componentes que se muestran
y asegrese de comprender los conceptos de cada uno de ellos. Considere por ejemplo los sistemas
superiores que se encuentran en la parte superior del grfico y su definicin.
Como actividad le recomendamos revisar un sistema donde usted puede determinar cules y cmo se
relacionan o cmo interactan los sistemas con el sistema principal.
La definicin de arquetipos son una clase o un patrn que representa una abstraccin fundamental de
importancia crtica para el diseo de una arquitectura para el sistema objetivo. Estos arquetipos son los
bloques para la construccin de un diseo arquitectnico.
Como actividad recomendada debe descargar una herramienta de software de diseo arquitectnico
en una versin de prueba para que analice su funcionamiento.
Revise el apartado sobre refinamiento del sistema en el texto bsico y analice el
ejemplo de mapeo de arquitectura con el uso de flujo de datos.
Ahora ingrese al EVA para que responda el foro sobre Arquitectura de la Aplicacin, ser muy importante
que participe en dicho foro y aporte sobre los criterios que han realizado sus compaeros. Recuerde que
esta participacin es calificada como parte de la evaluacin a distancia.
Hemos concluido el estudio de esta unidad. Ahora conviene comprobar cunto hemos asimilado de los
temas tratados; para ello es necesario desarrollar esta autoevaluacin.
75
SEGUNDO BIMESTRE
Autoevaluacin 5

1.
La elaboracin de los casos de uso se encuentran dentro del modelado de

requerimientos, estos estn dentro del tipo de modelos orientado a clases.
2.
De acuerdo al tipo de base de datos que vamos a utilizar, estamos modelando el

anlisis, o sea los requerimientos que se levanten deben considerar modelos no
funcionales.
3.
Para el diseo de la arquitectura podemos encontrar elementos de modelado basado

en escenarios y modelos basado en clases.
4.
Si se quiere tener un descripcin completa de la funcionalidad a travs de la

especificacin de un caso de uso las interacciones alternativas dentro de la misma
son fundamentales.
5.
Al tener en cuenta la flexibilidad para un sistema software y considerarla como un

requisito no funcional, se debe realizar una especificacin de caso de uso para este
requerimiento.
6.
Con la ayuda de las flechas en una relacin se puede determinar la direccin de la

misma; entonces, debe existir una nica relacin en un solo sentido entre dos objetos.
7.
Si estamos en la etapa de diseo y en base a los requerimientos, podemos considerar

cmo estar el acceso a los datos para el sistema, diramos que estamos trabajando
en la arquitectura del sistema.
8.
Un sistema bancario donde se permita la realizacin de transacciones en lnea podra

considerarse con un gnero arquitectnico definido.
9.
Un software que est diseado para trabajar con una interfaz de escritorio puede ser
una aplicacin de tres capas.
10. (
Al contar con un sistema contable dentro de la organizacin, y al emprender el

desarrollo de un sistema de registro de compra-venta (facturacin) e inventarios el cual
proporcionar informacin al primero, este sistema contable debe ser considerado
en la arquitectura.
Ir a solucionario
76
SEGUNDO BIMESTRE
UNIDAD 6: CALIDAD DEL SOFTWARE

Al igual que en muchos otros mbitos del quehacer humano, el factor de la calidad ha cobrado
importancia radical en el mundo del desarrollo de software, ms an con la difusin de las TI en el da a
da de las organizaciones, la calidad del software no solo se puede medir, se debe planificar, ejecutar y
monitorear; es decir, llegar a un proceso de aseguramiento donde el principal beneficiario es el cliente.
A lo largo de este captulo vamos a realizar un estudio, pues las metodologas y herramientas de la
ingeniera de software tienen un nico fin: producir software de alta calidad, la cual ms all de los
conceptos y definiciones que encontrar ms adelante, puede escribirse en tres palabras: satisfaccin
del cliente, y el razonamiento es bastante simple, si el software no le sirve al usuario, entonces es intil
tenerlo aunque pudiera tener atributos de calidad como los tiempos de respuesta, interfaz amigable,
seguridad, facilidad de uso, etc.
6.1. Conceptos de calidad

Vamos a empezar esta unidad obteniendo algunas frases que nos pueden ayudar a entender el concepto
de calidad, estas frases estn en el texto bsico.

Calidad... sabes lo que es, pero no sabes qu es

Concepto complejo y de facetas mltiples.
Algo que se reconoce de inmediato pero que no es posible definir explcitamente.
Especificaciones originales del producto.
Lo que el cliente est dispuesto a pagar.
Etc. etc.
Contine con el estudio apoyndose en el subrayado de los temas correspondientes al captulo 14 del
texto bsico para determinar frases relacionadas con calidad para que le permitan tener una mejor idea,
y entender por qu tantas empresas y organizaciones invierten tanto en obtener calidad.
Han existido muchas aseveraciones de los costos que se hacen para corregir
los programas defectuosos y tambin cunto software es intilmente
desarrollado porque al final no cumple con las funcionalidades para lo que
fue desarrollado, entonces es por esta razn que comenzaremos hablar
sobre la calidad del software.
Ahora revisemos este concepto de Pressman en 1992 dijo: Concordancia con los
requisitos funcionales y de rendimiento explcitamente establecidos con los estndares
de desarrollo explcitamente documentados y con las caractersticas implcitas que se
espera de todo software desarrollado profesionalmente.
Como lo podemos notar debe haber una sincronizacin entre todas las actividades que se llevan a cabo
para el desarrollo de productos software, entonces los requisitos del software son la base de las medidas
de calidad del mismo.
77
SEGUNDO BIMESTRE
6.2. Calidad del software

Tomemos la definicin 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 utilizan21:
En base a esta definicin vamos a encontrar tres aspectos que hacen relacin a esta
definicin y que se presentan en el texto bsico como calidad del software.
Repase nuevamente estos puntos: proceso eficaz de software, producto til y agregar valor para el
producto y para el usuario, entonces cree que buscar la calidad del software est orientado a obtener
mayores utilidades a travs del producto software que se desarroll?
Cree que alguna actividad sombrilla est involucrada en el proceso de calidad del software.
Cules cree que son esas actividades?
Si respondi a estas interrogantes sin dudarlo. Entonces tiene clara la idea y podemos
continuar, caso contrario puede apoyarse en una relectura o en una tutora.
Hablaremos ahora sobre las 8 dimensiones de la calidad que son las planteadas por Garvin, las mismas
que se presentan en el texto bsico, recuerde que esas dimensiones no fueron especficas para el
software, pero las podemos adoptar.
Revise estas dimensiones de la calidad, teniendo esto podramos decir que estas dimensiones pueden
considerarse de forma objetiva o no.
Ahora revise en el apartado 14.2.2 los factores que han sido propuestos por McCall, los cuales nos dan
medidas directas e indirectas de la calidad.
Realice un cuadro donde clasifique los mismos por la medida que nos proporcionan
directa o indirecta.
A continuacin revise los 6 factores de la calidad ISO 9126 en el mismo apartado del texto bsico
con la cual se pueden ir afianzando los temas sobre calidad del software aunque muchos de ellos no
proporcionen medidas directas.
Revisemos algunas actividades para el aseguramiento de calidad del software dentro de las que podemos
mencionar:

Mtricas de software para el control del proyecto.
Proceso de verificacin y validacin del software a lo largo del ciclo de vida de desarrollo,
incluyendo pruebas y proceso de revisin.
Gestin de la configuracin del software.

Conteste a las siguientes interrogantes: cul sera la diferencia o la similitud entre los
factores de la calidad de McCall y los ISO 9126?, estn estos relacionados con los factores
que se persiguen para el desarrollo de software?
21 Pressman R. (2010). Cit. Ed. p. 340.
78
SEGUNDO BIMESTRE
6.3. 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, pues se utilizaran demasiados
recursos, 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. Entonces qu hacer..?
Para poder entender este dilema debemos entonces revisar los apartados del texto
bsico 14.3.1 Software suficientemente bueno y 14.3.2. El costo de la calidad.
Del primer apartado podremos ayudarle a su comprensin diciendo que de acuerdo al contexto donde
se desarrolle este software conocido como suficientemente bueno depende su aplicacin. No ser lo
mismo utilizar este concepto en empresas grandes que en empresas pequeas.
Hablemos del segundo apartado y para ello podemos fijarnos en la figura 14.2, tenemos las etapas de
construccin de software. Como podr notar, corregir las fallas en etapas iniciales es mucho menos
costoso que hacerlo cuando el producto ya est implementado, se presentan cifras muy elevadas pero
que al final nos reflejan en otros factores no solo econmicos sino tambin operativos para la empresa;
pues tener una mala reputacin es un costo externo que podra ser incalculable.
Existen temas como riesgos, negligencia y responsabilidad, calidad y seguridad, el efecto de las acciones
de la administracin que son tratadas en este apartado a las cuales se les debe poner la respectiva
atencin.
Por ejemplo tomemos el tema de seguridad, un software que sea fcilmente vulnerable,
realmente ser un software de muy mala calidad, lo cual debe ser considerada desde la
etapa de inicio de desarrollo del proyecto.
La seguridad del software, 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.
6.4. Cmo lograr la calidad del sotware?

Cmo se logra la calidad del software?, con la ayuda de un sinnmero de actividades paralelas al
desarrollo como la administracin del proyecto y el seguir un proceso de desarrollo, esto se ve reflejado
con la ayuda de 4 actividades que las encontraremos en el apartado 14.4. Lograr la calidad del software
del texto bsico en el cual podr profundizar en los mtodos de aseguramiento de calidad.
Mtodos de la ingeniera de software, son aquellos que ya revisamos en la unidad 3 de esta asignatura.
Tcnicas de administracin de proyectos, procesos relacionados con esta actividad podemos mencionar
muchos, por ejemplo tenemos especializaciones dentro del campo laboral en gerencia de proyectos del
Project Management Institute (PMI)22.
Control de calidad; sern las acciones de la IS las que permitan asegurar el cumplimiento del trabajo para
el desarrollo del producto software.
22 Project Management Institute, http:\\www.pmi.org
79
SEGUNDO BIMESTRE
Aseguramiento de la Calidad: conformar un equipo de ser posible que ayude a esta actividad dentro del
desarrollo, este campo es muy amplio y en el texto bsico pueden profundizar este tema.
Algunos autores relacionados con la ingeniera de software mencionar los pilares bsicos para lograr
una certificacin, entre ellos:

Llevar una metodologa correcta durante el proceso.
Tener un medio de valoracin de la metodologa que se est llevando.
La utilizacin de las dos anteriores (metodologa y el medio de valoracin) tienen que estar
reconocidos por quienes estn inmersos en el desarrollo.
A continuacin mencionaremos algunos modelos de calidad del software para su informacin, si se

desea conocer ms sobre estos temas, fcilmente encontrar documentacin en Internet:

CMM (Capability Maturity Model).
ISO 9001 (International Standard Organization).
SPICE (Software Process Improvement and Capability Determination).
SP (Personal Software Process) /TSP (Team Software Process).
PEMM (Performance Engineering Maturity Model).
Hemos concluido el estudio de esta unidad. Ahora nos conviene comprobar cuanto hemos asimilado de
los temas tratados, para ello es necesario desarrollar esta autoevaluacin.
80
SEGUNDO BIMESTRE
Autoevaluacin 6

determine si son verdadersa o falsas. Como estrategia le recomendamos que primero
ubique el tema sobre el que le habla la pregunta, ubique la informacin necesaria en el
texto o en la gua didctica y fundamente su respuesta.
1.
El software de alta calidad cumple con los requerimientos no funcionales con los que
se espera cuente el mismo.
2.
Si al software se le realiza un mantenimiento o se lo corrige, se dice que no es un

software de calidad.
3.
La eficiencia de un producto software est enfocada a poder utilizar el mismo en

diferentes plataformas.
4.
La eficiencia hace mencin a los recursos, esta caracterstica se considera como un

factor de la calidad en sus diferentes formas.
5.
Una caracterstica de calidad del software podra estar incrustada en la forma como el
usuario llega a una funcionalidad o la facilidad de utilizacin del mouse.
6.
Se debe planificar un proceso de pruebas, se debe cuantificar este proceso al

momento de realizar una estimacin de costo del producto.
7.
Un costo externo de falla se lo podra mencionar al proceso de actualizacin de una

versin a otra.
8.
Un costo de falla interno lo podramos adjudicar a la reputacin que tendr el equipo

de analista ante el cliente.
9.
Revisar la codificacin realizada en la interfaz corresponde al proceso de aseguramiento

de calidad.
La calidad del software se consigue por medio de la aplicacin de mtodos de

ingeniera de software.
10. (
Ir a solucionario
81
SOLUCIONARIO
7. Solucionario
UNIDAD 1
82
Pregunta
Respuesta
1.
(V)
2.
(V)
3.
(F)
4.
(F)
5.
(V)
6.
(V)
7.
(F)
8.
(F)
9.
(V)
10.
(V)
SOLUCIONARIO
UNIDAD 2
Pregunta
Respuesta
1.
(V)
2.
(V)
3.
(F)
4.
(V)
5.
(F)
6.
(F)
7.
(V)
8.
(F)
9.
(F)
10.
(F)
11.
12.
13.
83
SOLUCIONARIO
UNIDAD 3
84
Pregunta
Respuesta
1.
(V)
2.
(F)
3.
(V)
4.
(F)
5.
(V)
6.
(V)
7.
(V)
8.
(F)
9.
(F)
10.
(V)
SOLUCIONARIO
UNIDAD 4
Pregunta 1
Respuestas
Pregunta 2
Respuestas
1.
1.
2.
2.
3.
3.
4.
4.
5.
5.
6.
6.
7.
7.
8.
8.
9.
9.
10.
11.
12.
3.
Fase
Artefacto
Inicio
Documento de visin.
Caso de negocio.
Elaboracin
Arquitectura de software.
Modelo de anlisis.
Construccin
Modelo de diseo.
Modelo de datos.
Transicin
Producto.
Material de soporte para usuarios finales.
4.
( c )
Si revisa las responsabilidades del gerente de proyecto, l tiene funcin de: organizar
el equipo, planificar iteraciones, armar equipos de trabajo, monitoreo y control,
gestin de riesgos; por lo tanto, l debe asegurarse de que se han solucionando todos
los problemas para que el proyecto se cumpla en las condiciones estipuladas.
5.
( b )
Si revisa las alternativas, se dar cuenta de que el modelo de costos (c), no es una
alternativa vlida, puesto que no es un artefacto, el documento de visin especifica el
alcance, pero no maneja costos y el modelo de casos de uso son funcionalidad, lo que
nos deja como nica alternativa al caso de negocio.
85
SOLUCIONARIO
6.
( a )
Las especificaciones de casos de uso representan interacciones sistema-usuario,

basados en los requerimientos obtenidos de las necesidades, sin embargo no tienen
directamente las necesidades, por tanto (d) es incorrecto; el anlisis de stakeholders
(c), es una actividad, no un documento, por lo tanto incorrecto, el modelo de datos es
un artefacto tcnico que no tienen que ver los usuarios y por tanto la nica alternativa
es el documento de visin (a) cuyo propsito es establecer las necesidades y el alcance
del sistema.
7.
( a )
Los casos de uso contienen requerimientos funcionales, el modelo de anlisis

contiene los modelos de clases y el plan de iteraciones especifica cmo se llevar a
cabo el proyecto en cada fase, por lo tanto la nica solucin vlida sera el documento
de especificaciones suplementarias.
8.
( d )
La opcin (a) no corresponde a una fase, la opcin (b) se valida con la consecucin de
una versin beta del sistema, la opcin (c) se valida con la arquitectura del sistema, la
nica opcin vlida sera la opcin d, fase de transicin.
86
SOLUCIONARIO
UNIDAD 5
Pregunta
Respuesta
1.
(V)
2.
(F)
3.
(V)
4.
(V)
5.
(V)
6.
(F)
7.
(V)
8.
(V)
9.
(V)
10.
(V)
87
SOLUCIONARIO
UNIDAD 6
Pregunta
Respuesta
1.
(V)
2.
(F)
3.
(F)
4.
(V)
5.
(V)
6.
(V)
7.
(V)
8.
(F)
9.
(F)
10.
(V)
PAE&DJH/ vtc/ 2011-06-21/ 84

kvv/2015-12-28
88

Guia Didáctica

Cargado por

Copyright:

Formatos disponibles

Guia Didáctica

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guia Didáctica

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD TCNICA PARTICULAR DE LOJA

La Universidad Catlica de Loja

Departamento de Ciencias de la Computacin y Electrnica

Ing. Marco Patricio Adab Espinoza

FUNDAMENTOS DE INGENIERA DEL SOFTWARE

Marco Patricio Abad Espinoza

5. Orientaciones generales para el estudio........................................................... 8

UNIDAD 1: INTRODUCCIN A LA INGENIERA DEL SOFTWARE................................................... 14

UNIDAD 2: PROCESOS DE CONSTRUCCIN DEL SOFTWARE........................................................ 21

UNIDAD 3: CICLOS DE VIDA DEL SOFTWARE............................................................................. 32

Un modelo general de proceso.................................................................................. 32

3.7. Programacin extrema............................................................................................... 38

UNIDAD 4: APLICACIN DE UN MODELO DE PROCESOS RUP..................................................... 45

UNIDAD 5: MODELADO DEL SOFTWARE: ANLISIS, DISEO ARQUITECTURA............................... 68

UNIDAD 6: CALIDAD DEL SOFTWARE........................................................................................ 77

Gua didctica: Fundamentos de Ingeniera de Software

Bienvenido al mundo de la ingeniera del software !

Gua didctica: Fundamentos de Ingeniera de Software

Pressman, R. (2010). Ingeniera de software: un enfoque prctico. Mxico, McGraw-Hill Interamericana

Jacobson I, Booch G, Rumbaugh J. (2000). El proceso unificado de desarrollo de software, Madrid,

IBM Corp. (2003). Essentials of Rational Unified Process: Course Material.

Gua didctica: Fundamentos de Ingeniera de Software

Cueva, J. Anlisis orientado a objetos. Oviedo. Espaa. Disponible en http://hex.nosololinux.com/

Fundamentos de Ingeniera del Software (2009). Universidad de Murcia. http://ocw.um.es/

Rational Rose, Enterprise Edition.

Rational Unified Process.

Gua didctica: Fundamentos de Ingeniera de Software

5. Orientaciones generales para el estudio

Gua didctica: Fundamentos de Ingeniera de Software

Este focalizador se usar para llamar su atencin sobre aspectos generales

Utilizaremos este cono para darle orientaciones especficas o tcnicas respecto al

Gua didctica: Fundamentos de Ingeniera de Software

La presencia de este cono, denota una actividad de reflexin en base a preguntas

Gua didctica: Fundamentos de Ingeniera de Software

6. Proceso de enseanza-aprendizaje para el logro de competencias

Capacidad de abstraccin, anlisis y sntesis.

Conocimiento sobre el rea de estudio y la profesin.

Habilidades para buscar, procesar y analizar informacin procedentes de fuentes diversas.

Compromiso con la calidad.

6.2. Planificacin para el trabajo del alumno

Reconoce los tipos de 1.1. La naturaleza del

Lectura del captulo 1

Reconoce los roles

Investigar los diferentes tipos

Gua didctica: Fundamentos de Ingeniera de Software

Lectura de los captulos 5 y 8 Semanas 2,3,4:

Lectura de los captulos 2,3 Semanas 5,6:

Termina el desarrollo del

Gua didctica: Fundamentos de Ingeniera de Software

6.3. Sistema de evaluacin de la asignatura (primero y segundo bimestres)

Esfuerzo e inters en los trabajos

Respeto a las personas y a las

Presentacin, orden y ortografa

Dominio del contenido

Investigacin (cita fuentes de

Aporta con criterios y soluciones

10% 20% 30%

Emite juicios de valor

Gua didctica: Fundamentos de Ingeniera de Software