Igenieria de Software

UNIVERSIDAD PARA EL DESARROLLO ANDINO
Anti hatun yachay wasi iskay simi yachachiypi umalliq
FACULTAD DE CIENCIAS E INGENIERÍA

ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA
MONOGRAFÍA
INGENIERÍA DE SOFTWARE
EXAMEN DE SUFICIENCIA PROFESIONAL

PARA OPTAR EL TÍTULO PROFESIONAL DE:
INGENIERO INFORMÁTICO
PRESENTADO POR:
BACH. JORGE LUIS PUENTE SULLCARAY
ASESOR:
ING. HASEM ENRIQUE CURI VILLANUEVA
LIRCAY – ANGARAES- HUANCAVELICA – PERÚ

2016
“A mi familia en general, porque me han
brindado su apoyo incondicional y por
compartir conmigo buenos y malos
momentos. Agradezco a Dios por
protegerme durante todo mi camino y darme
fuerzas para superar obstáculos y
dificultades a lo largo de toda mi vida.”
2
RESUMEN
En el presente trabajo monográfico que lleva por título “Ingeniería de
software” el cual es el resultado de muchas investigaciones a los principales
medios de información como son los libros, páginas de internet, artículos
electrónicos, revistas electrónicas, etc. Contiene tres capítulos, cuyas
descripciones genéricas son como sigue:
CAPITULO I. Se presenta una vista general sobre la definición de Ingeniería
de Software, su importancia, objetivo y así como el reto de la Ingeniería de
Software.
El CAPITULO II. En esta segunda parte de la monografía nos centraremos en
la definición de: producto de Software y también se determina las
características del Software así como los mitos del Software.
El CAPÍTULO III. En esta tercera parte de la monografía nos centraremos en
la definición de: Proceso de Software y también se determina las
características del Software así como los mitos del Software.
El CAPÍTULO VI. Se tiene un resumen de las Metodologías para el Desarrollo
de Software, considerando algunos modelos del proceso de desarrollo de
Software.
Es importante tomarse el tiempo necesario para conocer a nuestros clientes y
usuarios, así como su ambiente de trabajo. Esto, también ayuda a establecer
una buena relación de trabajo y comunicación entre el equipo de desarrollo y
los clientes.
3
Es necesario que los clientes y usuarios participen en la definición de sus
requerimientos, pues ellos son los que deciden nuestro destino en el
proyecto, deciden si les gustamos o no y además financian el proyecto.
Como final de todo eso podemos exponer que el objetivo principal de la
Ingeniería de Software es lograr todo tipo de productos en calidad de
uso y de ejecución y que cumplir todos los requerimientos de cliente o
usuario, demostrar todas habilidades conjuntamente.
CHINTISQA
4
Hukllamanta kay llamkaymi sutinta apan: “Inhiñiryapi Ukun churanchaynin”
kaymi ancha llapa maskariykunapa aypasqan, llapallan maykunapi tarisqa,
chaynam liwrukuna, intirnit rapi, kallpalliwan ruwasqa, wanku kallpalli,
achapiwan. Kanmi kimsa rakipaynin, chay qawachwan llapa imankunata:
I RAKIPAY. Qawarichinchik llapa imanata hawallamanta Inhiñiryapa uku
churanchayninta, imakuna lloqsisqa hinallataq qawachinchik imayna
paqarisqanta.
II RAKIPAY. Kay iskay ñeqen rakipaypim qawanchik imam inhiñirya ukun
churaychaynin kasqanta, imaynam puririn. Chaynallataq rikurun imaymana
puririyninkasqan chaynallataq imaynam miramurqa kasqanta.
III RAKIPAY. Imaymanaman huñusqam kachkan llapa maynin pusana ñan
chaynallataq imaynam chay ukun churanchaynin poqorichinapaq. Chaymi
mana pachawan yallichikunachu, qasillama llapa rantiqninchikkunata
suyana chaynallataq ñoqanchikmanta imapas orqoqta. Chaynataq maypim
llamkananchik kasqanta. Chaymi kaykuna anchata yanapan
llamkaqkunawan allin kananpaq.
VI RAKIPAY. Llapa rantiqninchikkunata suyana chaynallataq
ñoqanchikmanta imapas orqoqta. Chaynataq maypim llamkananchik
kasqanta. Chaymi kaykuna anchata yanapan llamkaqkunawan allin
kananpaq.
Allin punim rantiqkuna chaymanta hapiriqkuna munakuyninkupi
llakarinanku, paykunam imayna kananchikta yachanku, chaynallataq
5
niwanchik munawanchikchu icha manachu chyanallataq llakanapaq
qollqeta qowanchik.
Tukunapaq, llapa ima nisqanchiktam qawachinanchik inhiñirya ukun
churanchasqapi, chaymi rantinanchik, armananchik llapa ima ichaqa
allinninta hinaspa rantiqpa llapa munasqanta apamunanchik hinaspa
qawachinanchik kusqalla atiyninta.
SUMMARY
In this monographic work entitled "Software Engineering" which is the result
6
of many researches to the main information media such as books, websites,
electronic articles, electronic journals, etc. It contains three chapters, whose
generic descriptions are as follows:
CHAPTER I. An overview of the definition of Software Engineering, its
importance, objective and the challenge of Software Engineering.
CHAPTER II. In this second part of the monograph we will focus on the
definition of: Software product and also determines the characteristics of the
Software as well as the myths of the Software.
CHAPTER III. In this third part of the monograph we will focus on the
definition of: Software Process and also determine the characteristics of the
Software as well as the myths of the Software.
CHAPTER VI. There is a summary of the Methodologies for Software
Development, considering some models of the software development
process.
It is important to take the time to get to know our customers and users, as
well as their work environment. This also helps establish a good working
relationship and communication between the development team and the
clients.
It is necessary that the clients and users participate in the definition of their
requirements, because they are the ones who decide our destiny in the
project, decide whether they like it or not and also finance the project.
7
At the end of all this we can show that the main objective of Software
Engineering is to achieve all kinds of products in quality of use and
execution and that meet all the requirements of client or user, demonstrate
all skills together.
INTRODUCCIÓN
En esta investigación presentamos, todas las facetas de la Ingeniería del
software, las ideas relacionadas con el Producto software en sí: lo que se

8
ha dado en llamar Ingeniería del Producto Software. La Ingeniería de
Software es una disciplina que integra procesos, métodos y herramientas
para el desarrollo de Software. Varios son los modelos de procesos que se
han propuesto para la Ingeniería de Software, cada uno presenta
ventajas y desventajas, pero todos tienen en común fases genéricas que
permiten llevar a cabo el proceso de la Ingeniería de Software.
Se muestra todo que tuvo que ver con su historia , ya que es muy
importante saber su origen, evolución y conocer mucho más cada uno
de sus tipos y manera de aplicarlos, a si podremos diseñar, elaborar un
Software de calidad. Donde se da a conocer que se puede aplicar una
gran cantidad de disciplinas, técnicas y metodologías que hacen referencia
a todas las actividades relacionadas con la fabricación del Software y su
gestión, presentadas desde el punto de vista de la Ingeniería. Este
concepto abre un abanico muy amplio que es totalmente diversos para
nuestro conocimiento y aplicación.
La Ingeniería de Software, por lo tanto, incluye el análisis previo de la
situación, el diseño del proyecto, el desarrollo del Software, las pruebas
necesarias para confirmar su correcto funcionamiento y la implementación
del sistema.
ÍNDICE
PORTADA
DEDICATORIA…………………………………………………………………………….…………………ii
9
RESUMEN............................................................................................................................................ iii
CHINTISQA........................................................................................................................................... v
SUMMARY........................................................................................................................................... vii
INTRODUCCIÓN.................................................................................................................................. ix
ÍNDICE................................................................................................................................................... x
ÌNDICE DE ILUSTRACIONES............................................................................................................. xiii
CAPITULO I........................................................................................................................................... 9
INGENIERÍA DEL SOFTWARE............................................................................................................. 9
1.1. DEFINICIÓN DE INGENIERÍA DEL SOFTWARE............................................................9
1.2. HISTORIA DE LA INGENIERÍA DE SOFTWARE..........................................................10
1.3. OBJETIVOS DE LA INGENIERÍA DE SOFTWARE.......................................................12
1.4. RETOS FUNDAMENTALES QUE AFRONTA LA INGENIERÍA DEL SOFTWARE.........13
1.5. RESPONSABILIDAD PROFESIONAL Y ÉTICA............................................................14
1.6. ETAPAS DE LA INGENIERÍA DE SOFTWARE..............................................................16
1.6.1. ANÁLISIS DE REQUISITOS.....................................................................................16
1.6.2. ESPECIFICACIÓN.................................................................................................... 16
1.6.3. DISEÑO Y ARQUITECTURA....................................................................................17
1.6.4. PROGRAMACIÓN..................................................................................................... 17
1.6.5. PRUEBA.................................................................................................................... 17
1.6.6. MANTENIMIENTO.................................................................................................... 18
1.7. PRINCIPIOS DE LA INGENIERÍA DEL SOFTWARE.....................................................18
1.8. ESQUEMA DE LA INGENIERÍA DEL SOFTWARE........................................................22
1.9. IMPORTANCIA DE LA INGENIERÍA DEL SOFTWARE.................................................23
1.10. CAPAS DE LA INGENIERÍA DEL SOFTWARE.............................................................23
1.10.1. PROCESOS.......................................................................................................... 24
1.10.1.1. IMPORTANCIA DE UN PROCESO...................................................................25
1.10.2. MÉTODO.............................................................................................................. 27
1.10.3. HERRAMIENTAS.................................................................................................. 28
10
CAPITULO II........................................................................................................................................ 30
EL PRODUCTO................................................................................................................................... 30
2.1. DEFINICIÓN DEL PRODUCTO SOFTWARE................................................................30
2.2. LA EVOLUCIÓN DEL SOFTWARE................................................................................31
2.3. EL SOFTWARE............................................................................................................. 33
2.3.1. CARACTERÍSTICAS DEL SOFTWARE....................................................................33
2.3.2. APLICACIONES DEL SOFTWARE...........................................................................34
2.3.3. MITOS DEL SOFTWARE.......................................................................................... 35
2.3.4. ATRIBUTOS DE UN BUEN SOFTWARE..................................................................40
2.3.5. COMPONENTES DEL SOFTWARE.........................................................................41
CAPITULO III....................................................................................................................................... 43
EL PROCESO..................................................................................................................................... 43
3.1. DEFINICIÓN DEL PROCESO.......................................................................................43
3.2. EL PROCESO DEL SOFTWARE...................................................................................43
3.3. CICLOS DE VIDA DE DESARROLLO DEL SOFTWARE..............................................44
3.3.1. CICLO DE VIDA........................................................................................................ 44
3.3.2. TIPOS DE MODELO DE CICLO DE VIDA................................................................46
3.3.3. MODELOS DE CICLO DE VIDA...............................................................................46
3.3.1.1. MODELO EN CASCADA..................................................................................48
3.3.1.2. MODELO EN V................................................................................................. 52
3.3.1.3. MODELO ITERATIVO.......................................................................................55
3.3.1.4. MODELO DE DESARROLLO INCREMENTAL................................................57
3.3.1.5. MODELO EN ESPIRAL....................................................................................59
3.3.1.6. MODELO DE PROTOTIPOS............................................................................64
3.4. ISO/IEC 12207............................................................................................................... 67
3.4.1. PROCESOS PRINCIPALES DEL CICLO DE VIDA...................................................67
3.4.2. PROCESOS DE APOYO AL CICLO DE VIDA..........................................................68
3.4.3. PROCESOS ORGANIZATIVOS DEL CICLO DE VIDA.............................................68
11
CAPITULO VI...................................................................................................................................... 70
METODOLOGÍAS DE DESARROLLO DE SOFTWARE.....................................................................70
4.1. DESARROLLO DE SOFTWARE...................................................................................70
4.2. DEFINICIÓN DE METODOLOGÍA.................................................................................71
4.3. VENTAJAS DEL USO DE UNA METODOLOGÍA..........................................................72
4.4. METODOLOGÍAS TRADICIONALES VS. METODOLOGÍAS ÁGILES.........................73
4.4.1. METODOLOGÍA TRADICIONAL...............................................................................73
4.4.1.1. METODOLOGÍA RATIONAL UNIFIED PROCESS (RUP)................................74
4.4.1.2. METODOLOGÍA MICROSOFT SOLUTION FRAMEWORK (MSF)..................76
4.4.2.1. METODOLOGIA EXTREME PROGRAMMING (XP)........................................81
4.4.2.2. METODOLOGÍA AUP (AGIL UNIFIED PROCESS)..........................................84
4.4.2.3. METODOLOGÍA SCRUM.................................................................................85
4.4.2.4. METODOLOGÍA ICONIX..................................................................................88
RESUMEN Y OPINIÓN PERSONAL................................................................................................... 89
KIKIYKUPA RIMARIYNIYKU............................................................................................................... 90
SUMMARY AND PERSONAL OPINION.............................................................................................. 91
BIBLIOGRAFÍA.................................................................................................................................... 92
ANEXO................................................................................................................................................ 93
ÌNDICE DE ILUSTRACIONES
ILUSTRACIÓN 1: ESQUEMA DE LA INGENIERÍA DE SOFTWARE...............................................................22
ILUSTRACIÓN 2: CAPAS DE LA INGENIERÍA DE SOFTWARE....................................................................23
ILUSTRACIÓN 3: AUTOMATIZACIÓN DE TAREAS....................................................................................29
12
ILUSTRACIÓN 4: DEFINICIÓN DEL PRODUCTO SOFTWARE.....................................................................30
ILUSTRACIÓN 5: DEFINICIÓN DEL PRODUCTO SOFTWARE.....................................................................31
ILUSTRACIÓN 6: COMPONENTES DEL SOFTWARE.................................................................................42
ILUSTRACIÓN 7: EVALUACIÓN USO DE HERRAMIENTA DE RRHH I.........................................................42
ILUSTRACIÓN 9: EL PROCESO DE SOFTWARE.....................................................................................44
ILUSTRACIÓN 10: MODELO DE CICLO DE VIDA EN CASCADA.................................................................49
ILUSTRACIÓN 11: MODELO DE CICLO DE VIDA EN V.............................................................................53
ILUSTRACIÓN 12: MODELO DE CICLO DE VIDA ITERATIVO.....................................................................56
ILUSTRACIÓN 13: MODELO DE CICLO DE VIDA INCREMENTAL................................................................57
ILUSTRACIÓN 14: CICLO DE VIDA EN ESPIRAL......................................................................................62
ILUSTRACIÓN 15: MODELO DE CICLO DE VIDA DE PROTOTIPOS............................................................65
ILUSTRACIÓN 16: PROCESO UNIFICADO RATIONAL..............................................................................75
ILUSTRACIÓN 17: VENTAJAS Y DESVENTAJAS DEL MODELO (RUP)........................................................76
ILUSTRACIÓN 18: MICROSOFT SOLUTION FRAMEWORK (MSF).............................................................77
ILUSTRACIÓN 19: MODELO EXTREME PROGRAMIN..............................................................................81
ILUSTRACIÓN 20: VENTAJAS Y DESVENTAJAS DE METODOLOGIA (XP)...................................................84
ILUSTRACIÓN 21: AUP (AGIL UNIFIED PROCESS).................................................................................85
ILUSTRACIÓN 22: ESQUEMA DE TRABAJO SCRUM................................................................................87
ILUSTRACIÓN 23: ESQUEMA DE TRABAJO ICONIX.................................................................................88
13
CAPITULO I
INGENIERÍA DEL SOFTWARE
1.1. DEFINICIÓN DE INGENIERÍA DEL SOFTWARE
A nivel internacional, la Ingeniería de Software empieza a tomar un papel
fundamental y como un área de la Ingeniería.
“La Ingeniería de Software es una disciplina que integra métodos,
herramientas y procedimientos para el desarrollo de software de
computadora” [CITATION PRE93 \p 45-49 \l 3082 ].
A continuación se relacionan algunas definiciones de Ingeniería del
Software:
Otras definiciones:
1. (Zelkovitz, 1978). Ingeniería de Software
Ingeniería del Software es el estudio de los principios y metodologías
para el desarrollo y mantenimiento de sistemas de software.
2. (Bohem, 1976). Ingeniería de Software
Ingeniería del Software es la aplicación práctica del conocimiento
científico al diseño y construcción de programas de computadora y a la
documentación asociada requerida para desarrollar, operar (funcionar)
y mantenerlos. Se conoce también como desarrollo de software o
producción de software.
3. (Braude). Ingeniería de Software

9
La ingeniería de software es el proceso de construir aplicaciones de
tamaño o alcance prácticos, en las que predomina el esfuerzo del
software y que satisfacen los requerimientos de funcionalidad y
desempeño.
4. (IEEE, 1993). Ingeniería de Software
La aplicación de un enfoque sistemático, disciplinado y cuantificable al
desarrollo, operación (funcionamiento) y mantenimiento del software;
es decir, la aplicación de ingeniería al software.
Resumiendo: La ingeniería de software es una aplicación práctica del
conocimiento científico para proveer metodologías y técnicas que ayuden
a desarrollar sistemas de software a tiempo, y a su vez que aseguren que
el desarrollador cumpla con las expectativas de calidad y permanezca
dentro del presupuesto.
1.2. HISTORIA DE LA INGENIERÍA DE SOFTWARE
El término ingeniería del software apareció por primera vez en la
conferencia de ingeniería de software de la OTAN en 1968 y fue
mencionado para provocar el pensamiento sobre la crisis de software del
momento. Desde entonces, ha continuado como una profesión y campo
de estudio dedicado a la creación de software de alta calidad, barato, con
capacidad de mantenimiento y rápido de construir. Debido a que el campo
es todavía relativamente joven comparado con otros campos de la
ingeniería, hay todavía mucho trabajo y debate sobre qué es realmente la
ingeniería del software, y si se merece el título de ingeniería. Ha crecido
10
orgánicamente fuera de las limitaciones de ver el software sólo como
programación.
Mientras que el término ingeniería del software fue acuñado en una
conferencia en 1968, los problemas que intentaba tratar empezaron
mucho antes. La historia de la ingeniería del software está entrelazada
con las historias contrapuestas de hardware y software.
Cuando el ordenador digital moderno apareció por primera vez en 1941,
las instrucciones para hacerlo funcionar estaban conectadas dentro
de la máquina. Las personas relacionadas con la ingeniería
rápidamente se dieron cuenta de que este diseño no era flexible e idearon
la arquitectura de programa almacenado o arquitectura von Neumann. De
esta forma la primera división entre “hardware” y “software” empezó con
la abstracción usada para tratar la complejidad de la computación.
Los lenguajes de programación empezaron a aparecer en la década de
1950 y este fue otro paso importante en la abstracción. Los lenguajes
principales como Fortran, Algol y Cobol se lanzaron a finales de los 50s
para tratar con problemas científicos, algorítmicos y de negocio
respectivamente. Dijsktra escribió “Go to Statement Considered Harmful”
en 1968 y David Parnas introdujo el concepto clave de la modularidad y
encapsulación en 1972 para ayudar a los programadores a tratar con la
complejidad de los sistemas de software. Un sistema software para
gestionar el hardware, denominado sistema operativo también se
introdujo, más notablemente por Unix en 1969. En 1967, el lenguaje
Simula introdujo el paradigma de la programación orientada a objetos.
11
Estos avances en software se encontraron con más avances en el
hardware. A mediados de los 70s, la microcomputadora fue introducida,
haciendo económico a los aficionados a obtener una computadora y
escribir software para él. Esto sucesivamente condujo al famoso
ordenador personal o PC y Microsoft Windows. El ciclo de vida de
desarrollo de software o SDLC también empezó a aparecer como un
consenso para la construcción centralizada de software a mediados de
los 80s. A finales de los 70s y principios de los 80 se vieron varios
lenguajes de programación orientados a objetos inspirados en Simula,
incluyendo C++, Smalltalk y Objective C.
El software open source empezó a aparecer a principios de los 90s en la
forma de Linux y otros software introduciendo el bazaar” o el estilo
descentralizado de construcción de software. Después aparecieron
Internet y la World Wide Web a mediados de los 90s cambiando de
nuevo la ingeniería del software. Los sistemas distribuidos ganaron
dominio como forma de diseñar sistemas y el lenguaje de programación
Java se introdujo como otro paso en la abstracción, teniendo su propia
máquina virtual. Varios programadores colaboraron y escribieron el
manifiesto ágil que favoreció procesos más ligeros para crear software
más barato y en menos tiempo.
1.3. OBJETIVOS DE LA INGENIERÍA DE SOFTWARE
La definición que Fritz Bauer elaboró de Ingeniería de software en 1969,
incluye una clara definición de los objetivos de la disciplina:
12
“Ingeniería de Software es el establecimiento y uso de principios
robustos de ingeniería, orientados a obtener software que sea fiable
y funcione de manera eficiente sobre máquinas reales”.[CITATION Fri15
\p 95 \l 3082 ]
Como elemento aclaratorio, es favorable observar algunos objetivos
primordiales, definidos por James Martin, para la programación
estructurada. Tales objetivos pueden ser fácilmente atribuibles a la
ingeniería de software. Según este criterio, los objetivos primordiales de
la ingeniería de software por lo menos algunos son:
 Lograr programas de alta calidad de un comportamiento predecible.

 Lograr programas que sean fácilmente modificables (y mantenibles).
 Simplificar los programas y el proceso de desarrollo de programas.
 Lograr mejores predicciones y controles en el proceso de desarrollo.
 Acelerar el desarrollo de sistemas.
 Aminorar los costos del desarrollo de sistemas.
1.4. RETOS FUNDAMENTALES QUE AFRONTA LA INGENIERÍA DEL
SOFTWARE
Los retos o desafíos clave con los que se enfrenta la ingeniería del
software son:
a. Mantener y tratar con sistemas legados: Tratar con una mayor
diversidad de sistemas con mayores demandas de cómputo, y
menores tiempos de entrega.

b. Sistemas Legados: Sistemas antiguos que deben ser mantenidos y
mejorados.
c. Heterogeneidad: Desarrollando técnicas para construir software que
puedan utilizar plataformas y entornos de ejecución heterogéneos.

d. Entrega: Desarrollando técnicas que lleven a una entrega de
software más rápida.
13
e. Confianza: Desarrollando técnicas que demuestren que los usuarios
pueden tener confianza en el software.
1.5. RESPONSABILIDAD PROFESIONAL Y ÉTICA
La ingeniería del software se lleva a cabo dentro de un marco legal y
social que limita la libertad de los ingenieros. Los ingenieros de software
deben aceptar que su trabajo comprende responsabilidades más amplias
que simplemente la aplicación de habilidades técnicas. Deben
comportarse de una forma ética y moral responsable si es que desean ser
respetados como profesionales.
Estándares de comportamiento:
 Confidencialidad. Respetar la confidencialidad de sus empleadores o
clientes.
 Competencia. No deben falsificar su nivel de competencia, ni aceptar
conscientemente trabajos que están fuera de su capacidad.

 Desarrollo de propiedad intelectual. Se debe asegurar que la
propiedad intelectual de los empleadores y clientes está protegida.

 Uso inapropiado de las computadoras. El uso inapropiado de las
computadoras va desde los relativamente triviales (utilizar juegos en la
máquina de un empleado, por ejemplo) hasta los extremadamente
serios (difusión de virus).
Los ingenieros de software deben comprometerse consigo mismos para
hacer del análisis, la especificación, el diseño, el desarrollo, las pruebas
y el mantenimiento del software una profesión beneficiosa y respetada.
En concordancia con su compromiso con la salud, la seguridad y el
14
bienestar del público, los ingenieros de software deben adherirse a
los siguientes ocho principios:
1. Público: Los ingenieros deberán actuar en consonancia con el interés
público.
2. Cliente Y Empleador: Los ingenieros de software deberán actuar de
forma que respondan a los intereses de sus clientes y empleadores
siendo consecuentes con el interés público.

3. Producto: Los ingenieros de software deberán asegurar que sus
productos y las modificaciones asociadas cumplan los más altos
estándares profesionales posibles.

4. Juicio: Los ingenieros de software deberán mantener la integridad e
independencia en sus juicios profesionales.

5. Gestión: Los gerentes y líderes ingenieros de software deberán
suscribir y promocionar un enfoque ético en la gestión del desarrollo y
mantenimiento del software.

6. Profesión: Los ingenieros de software deberán mantener la integridad
y reputación de la profesión de acuerdo con el interés público.

7. Colegas: Los ingenieros de software deberán ser imparciales y apoyar
a sus colegas.
8. Personal: Durante toda su existencia, los ingenieros de software
deberán aprender lo concerniente a la práctica de su profesión y
promocionar un enfoque ético en la práctica de su profesión.
1.6. ETAPAS DE LA INGENIERÍA DE SOFTWARE
Como puede observarse, los objetivos se centran en la obtención de
mejores productos de software.
La única forma en que tal objetivo puede lograrse, es mediante el
estudio y mejoramiento de los procesos de desarrollo de software.
15
La ingeniería de software requiere llevar a cabo numerosas tareas, dentro
de etapas como las siguientes:
1.6.1. ANÁLISIS DE REQUISITOS
Extraer los requisitos de un producto software es la primera etapa
para crearlo. El resultado del análisis de requisitos con el cliente se
plasma en el documento .Especificación de Requisitos. Asimismo,
se define un diagrama de entidad/relación, en el que se plasman
las principales entidades que participarán en el desarrollo de
software.
IEEEStd. 830-1998 normaliza la creación de las especificaciones
de requisitos software.
1.6.2. ESPECIFICACIÓN
Es la tarea de escribir detalladamente el software a ser
desarrollado, en una forma matemáticamente rigurosa. En la
realidad, la mayoría de las buenas especificaciones han sido
escritas para entender y afinar aplicaciones que ya estaban
desarrolladas. Las especificaciones son más importantes para las
interfaces externas, que deben permanecer estables.
1.6.3. DISEÑO Y ARQUITECTURA
Se refiere a determinar cómo funcionará el software de forma
general sin entrar en detalles. Consisten en incorporar
consideraciones de la implementación tecnológica, como el
hardware, la red, etc. Se definen los casos de uso para cubrir las
funciones que realizará el sistema, y se transformarán las

16
entidades definidas en el análisis de requisitos en clases de
diseño, obteniendo un modelo cercano a la programación orientada
a objetos.
1.6.4. PROGRAMACIÓN
Reducir un diseño a código puede ser la parte más obvia del
trabajo de ingeniería del software, pero no necesariamente es la
que demanda mayor trabajo ni la más complicada. La complejidad
y la duración de esta etapa está íntimamente relacionada al o a los
lenguajes de programación utilizados, así como al diseño
previamente realizado.
1.6.5. PRUEBA
Consiste en comprobar que el software realice correctamente las
tareas indicadas en la especificación del problema. Una técnica de
prueba es probar por separado cada módulo del software y luego
probar lo de forma integral, para así llegar al objetivo. Se considera
una buena práctica que las pruebas sean efectuadas por alguien
distinto al desarrollador que la programó.
1.6.6. MANTENIMIENTO
Mantener y mejorar el software para solventar errores descubiertos
y tratar con nuevos requisitos. El mantenimiento puede ser de
cuatro tipos: perfectivo (mejorar la calidad interna de los sistemas),
evolutivo (incorporaciones, modificaciones y eliminaciones
necesarias en un producto software para cubrir la expansión o
17
cambio en las necesidades del usuario), adaptativo (modificaciones
que afectan a los entornos en los que el sistema opera, por
ejemplo, cambios de configuración del hardware, software de base,
gestores de base de datos, comunicaciones) y correctivo
(corrección de errores).
1.7. PRINCIPIOS DE LA INGENIERÍA DEL SOFTWARE
El diccionario define la palabra principio como “una ley importante o
suposición que subyace y se requiere en un sistema de pensamiento”.
En este libro se analizarán principios en muchos niveles distintos de
abstracción. Algunos se centran en la ingeniería de software como un
todo. “David Hooker propuso siete principios que se centran en la Práctica
de la ingeniería de software como un todo. Se reproducen en los
párrafos siguientes.”[CITATION PRE93 \p 16-18 \l 3082 ]
1. Primer principio: La razón de que exista todo: Un sistema de
software existe por una razón: dar valor a sus usuarios. Todas las
decisiones deben tomarse teniendo esto en mente. Antes de
especificar un requerimiento del sistema, antes de notar la
funcionalidad de una parte de él, antes de determinar las
plataformas del hardware o desarrollar procesos, plantéese preguntas
tales como: “¿Esto agrega valor real al sistema?” Si la respuesta es
“no”, entonces no lo haga. Todos los demás principios apoyan a éste.

2. Segundo principio: MSE (Mantenlo sencillo, estúpido…): El diseño
de software no es un proceso caprichoso. Hay muchos factores por
considerar en cualquier actividad de diseño. Todo diseño debe ser tan
18
simple como sea posible, pero no más. Esto facilita conseguir un
sistema que sea comprendido más fácilmente y que sea susceptible de
recibir mantenimiento, lo que no quiere decir que en nombre de la
simplicidad deban descartarse características o hasta rasgos internos.
En realidad, los diseños más elegantes por lo general son los más
simples. Simple tampoco significa “rápido y sucio”. La verdad es que
con frecuencia se requiere mucha reflexión y trabajo con iteraciones
múltiples para poder simplificar. La recompensa es un software más
fácil de mantener y menos propenso al error.

3. Tercer principio: Mantener la visión: Una visión clara es esencial
para el éxito de un proyecto de software. Sin ella, casi infaliblemente
el proyecto terminará siendo un ser “con dos [o más mentes]”.
Comprometer la visión de la arquitectura de un sistema de software
debilita y, finalmente hará que colapsen incluso los sistemas bien
diseñados. Tener un arquitecto que pueda para mantener la visión y
que obligue a su cumplimiento garantiza un proyecto de software muy
exitoso.
4. Cuarto principio: Otros consumirán lo que usted produce: Rara
vez se construye en el vacío un sistema de software con fortaleza
industrial. En un modo u otro, alguien más lo usará, mantendrá,
documentará o, de alguna forma, dependerá de su capacidad para
entender el sistema. Así que siempre establezca especificaciones,
diseñe e implemente con la seguridad de que alguien más tendrá que
entender lo que usted haga. Elabore especificaciones con la mirada
puesta en los usuarios. Diseñe con los implementadores en mente.
19
Codifique pensando en aquellos que deben dar mantenimiento y
ampliar el sistema. Alguien debe depurar el código que usted escriba, y
eso lo hace usuario de su código. Hacer su trabajo más fácil agrega
valor al sistema.
5. Quinto principio: Ábrase al futuro: Un sistema con larga vida útil
tiene más valor. En los ambientes de cómputo actuales, donde las
especificaciones cambian de un momento a otro y las plataformas de
hardware quedan obsoletas con sólo unos meses de edad, es común
que la vida útil del software se mida en meses y no en años. Sin
embargo, los sistemas de software con verdadera “fortaleza industrial”
deben durar mucho más tiempo. Para tener éxito en esto, los sistemas
deben ser fáciles de adaptar a ésos y otros cambios.

Nunca diseñe sobre algo iniciado. Siempre pregunte: “¿qué pasa
si…?” y prepárese para todas las respuestas posibles mediante la
creación de sistemas que resuelvan el problema general, no sólo uno
específico
6. Sexto principio: Planee por anticipado la reutilización: La
reutilización ahorra tiempo y esfuerzo. Al desarrollar un sistema de
software, lograr un alto nivel de reutilización es quizá la meta más
difícil de lograr. La reutilización del código y de los diseños se ha
reconocido como uno de los mayores beneficios de usar tecnologías
orientadas a objetos. Sin embargo, la recuperación de esta inversión
no es automática. Para reforzar las posibilidades de la reutilización
que da la programación orientada a objetos [o la convencional], se
requiere reflexión y planeación.
20
Hay muchas técnicas para incluir la reutilización en cada nivel del
proceso de desarrollo del sistema… La planeación anticipada en
busca de la reutilización disminuye el costo e incrementa el valor tanto
de los componentes reutilizables como de los sistemas en los que se
incorpora.
7. Séptimo principio: ¡Piense!: Este último principio es tal vez el que
más se pasa por alto. Pensar en todo con claridad antes de
emprender la acción casi siempre produce mejores resultados. Cuando
se piensa en algo es más probable que se haga bien.

Un efecto colateral de pensar es aprender a reconocer cuando no se
sabe algo, punto en el que se puede investigar la respuesta. Cuando
en un sistema se han puesto pensamientos claros, el valor se
manifiesta. La aplicación de los primeros seis principios requiere
pensar con intensidad, por lo que las recompensas potenciales son
enormes.
Si todo ingeniero y equipo de software tan sólo siguiera los siete
principios de Hooker, se eliminarían muchas de las dificultades que se
experimentan al construir sistemas complejos basados en
computadora.
1.8. ESQUEMA DE LA INGENIERÍA DEL SOFTWARE
Es muy simple el esquema que consiste en desarrollar un programa
sencillo que resuelve una tarea bien determinada. Lo normal es que se
evolucione al desarrollo de un:
 Sistema software: integra varios programas, o

 Producto software: programa usado en diferentes
aplicaciones/entornos
21
Ambos desarrollos "dan lugar a la Ingeniería del Software": Programas
integrados que pueden trabajar en varios entornos.
Ilustración 1: Esquema de la Ingeniería de Software
(Interfaces + Integración)
UN
PROGRAMA UN
SISTEMA
(Algoritmos y DE
Estructuras de SOFTWARE
Datos)
UN PROYECTO
UN SOFTWARE
PRODUCTO
SOFTWARE
(Ingeniería de Software)
Fuente: Elaboración propia
1.9. IMPORTANCIA DE LA INGENIERÍA DEL SOFTWARE
“La ingeniería de software es muy importante ya que con ella se puede
analizar, diseñar, programar y aplicar un software de manera correcta y
organizada, cumpliendo con todas las especificaciones del cliente y el
usuario final.”[CITATION htt16 \l 3082 ].
1.10. CAPAS DE LA INGENIERÍA DEL SOFTWARE
El enfoque de ingeniería del software cuenta con un compromiso
organizacional con la calidad porque no es posible incorporar la ingeniería

22
del software en una organización que no está centrada en conseguir
calidad.
La ingeniería del software es una tecnología multicapa. Se puede ver
como un conjunto de componentes estratificados, que reposan sobre ese
enfoque de calidad.
Ilustración 2: Capas de la Ingeniería de Software
Herramientas
Métodos
Procesos
Un enfoque de Calidad
Fuente: Elaboración propia.
Estos componentes que forman parte de la ingeniería del software son:
 Procesos: un marco de trabajo que ayuda al jefe de proyecto a
controlar la gestión del proyecto y las actividades de ingeniería.

 Métodos: las actividades técnicas requeridas para la creación de
productos de trabajo.
• Herramientas: la ayuda automatizada para los procesos y métodos.
• Enfoque de calidad: Gestión total de calidad. Cultura continua de
mejoras de procesos.
1.10.1. PROCESOS
El fundamento de la ingeniería del software es la capa de
proceso. El proceso define un marco de trabajo para un conjunto
de áreas clave de proceso que se deben establecer para la

23
entrega efectiva de la tecnología de la ingeniería del software.
Por lo tanto, las áreas claves del proceso forman la base del
control de gestión de proyectos del software y establecen el
contexto en el que se aplican los métodos técnicos, se obtienen
productos de trabajo (modelos, documentos, datos, informes,
formularios, etc.), se establecen hitos, se asegura la calidad y el
cambio se gestiona adecuadamente. El proceso de la ingeniería
del software es la unión que mantiene juntas las capas de
tecnologías y que permite un desarrollo racional y oportuno de
la ingeniería del software.
La capa de proceso:
 Permite al jefe de proyecto planificar una ejecución exitosa del
proyecto. La capa de proceso proporciona una hoja de ruta del
trabajo de ingeniería del software. Ayuda al jefe de proyecto en
la creación de un plan de trabajo viable que aísle tareas de
trabajo, responsabilidades, los productos de trabajo
producidos, y los mecanismos usados para asegurar calidad
en dichos productos de trabajos.

 Proporciona a las personas involucradas el contexto de su
trabajo.
La capa de proceso es, por lo tanto, el fundamento de la
ingeniería del software y da soporte a las capas de métodos y
herramientas.
1.10.1.1. IMPORTANCIA DE UN PROCESO.
Un proceso es útil porque proporciona claridad en
24
cómo ha de realizarse el trabajo. Cualquier conjunto
de actividades humanas complejas se puede convertir
en caótico si no hay guías para que las personas
puedan realizar las actividades. Un proceso definido
responde a las siguientes cuestiones:
 ¿Quién se comunica con quién?

 ¿Cómo se coordinan las actividades
interdependientes?
 ¿Quién es responsable de qué trabajo?
 ¿Quién produce qué productos de trabajo, y cómo
se evalúan?
Un proceso:
 Identifica todas las actividades y tareas de la
ingeniería del software

 Define el flujo de trabajo entre las actividades y
tareas
 Identifica los productos de trabajo que se producen
 Especifica los puntos de control de calidad
requeridos.
Algunas personas ven el desarrollo de software con
una perspectiva que requiere habilidades artísticas y
de artesanía y que es inherentemente caótico. Se
resisten a la idea de usar un proceso definido porque lo
ven como incómodo y burocrático y por lo tanto dificulta
la creatividad.
Una buena ingeniería de software hace que el proceso
de software sea más visible, predecible y más útil para
25
aquellos que construyen software.
La capa de proceso abarca las siguientes cuestiones:
 El marco de trabajo de proceso común (CPF)

 Actividades y tareas de la ingeniería de software
 Puntos de control de calidad
 Definiciones de productos de trabajo
 Gestión de proyectos
 Aseguramiento de la calidad del software
 Gestión de la configuración del software
 Monitorización de proyectos
 Medidas y métricas
1.10.2. MÉTODO
La capa de proceso identifica las tareas de ingeniería que se
deben realizar para construir software de alta calidad.
La siguiente capa, la capa de métodos se centra en las
actividades técnicas que se deben realizar para conseguir las
tareas de ingeniería. Proporciona el “cómo” y cubre las
actividades de ingeniería fundamentales.
Los métodos abarcan una gran gama de tareas que incluyen
análisis de requisitos, diseño, construcción de programas,
pruebas y mantenimiento.
La capa de métodos contiene los métodos definidos para
realizar esas actividades de forma eficiente. Se centra en
cómo se han de realizar las actividades técnicas. Las
personas involucradas usan los métodos para realizar las
actividades de ingeniería fundamentales necesarias para
construir el software.
Las actividades técnicas fundamentales para construir software

26
son:
 Análisis: el análisis es el fundamento de todos los trabajos de
ingeniería que siguen. Durante el análisis, se crea el modelo de
lo que es requerido por el software.

 Diseño: las actividades de diseño siguen el análisis y traducen
el modelo del análisis en cómo el producto proporciona estas
funciones por medio del software.

 Codificación: una vez que el diseño es completo, la
codificación traduce el modelo de diseño en una forma
ejecutable.
 Pruebas: el proceso de pruebas ayuda a destapar errores en
el código y el diseño subyacente.
1.10.3. HERRAMIENTAS
La capa de herramientas proporciona soporte a las capas de
proceso y métodos centrándose en el significado de la
automatización de algunas de las actividades manuales. Las
herramientas se pueden utilizar para automatizar las siguientes
actividades:
 Actividades de gestión de proyectos.

 Métodos técnicos usados en la ingeniería del software.
 Soporte de sistemas general.
 Marcos de trabajo para otras herramientas.
La automatización ayuda a eliminar el tedio del trabajo, reduce las
posibilidades de errores, y hace más fácil usar buenas prácticas
de ingeniería del software.
Existen una gran variedad de herramientas para múltiples
actividades. Entre ellas se pueden destacar las siguientes:
27
 Herramientas de gestión de proyectos
 Herramientas de control de cambios
 Herramientas de análisis y diseño
 Herramientas de generación de código
 Herramientas de pruebas
 Herramientas de reingeniería
Estas herramientas soportan las capas de proceso y de métodos
en varias actividades.
Un ejemplo claro, que n la jefa de RRHH habla con un usuario de
la herramienta.
Ilustración 3: Automatización de Tareas
El uso de una buena Nos va a facilitar

herramienta de muchas de las tareas,
gestión de RRHH nos ahora que nuestra
permitirá plantilla se ha visto
automatizar muchas incrementada.
tareas.
28
CAPITULO II
EL PRODUCTO
2.1. DEFINICIÓN DEL PRODUCTO SOFTWARE
El software es el producto que diseñan y construyen los ingenieros del
software de cualquier tamaño y arquitectura.
“Los productos software pueden desarrollarse para un cliente
particular o se pueden desarrollar para un mercado general. Por lo
tanto, los productos software pueden ser:”[CITATION PRE93 \p 51 \l 3082
]
 Genéricos: Desarrollados para ser vendidos a un ámbito de clientes
diferentes.
 Hechos a medida (personalizados): Desarrollados para un cliente
individual de acuerdo a su especificación.
Ilustración 4: Definición del Producto Software
Afecta
Afecta las
las actividades
actividades cotidianas
cotidianas
Porque
El
El
Software
Software es
es Afecta
Afecta cualquier
cualquier aspecto
aspecto de
de nuestras
nuestras vidas
vidas
importante
importante
Está
Está muy
muy extendido
extendido en
en el
el comercio
comercio
29
Ilustración 5: Definición del Producto Software
El producto
obtenido (software)
Desde
El punto de vista El punto de

del Ingeniero del vista del
Software Usuario
es
es
El conjunto de La información
programas, documentos resultante que hace el
y los datos que mundo mejor.
configuran el software de
computadora.
2.2. LA EVOLUCIÓN DEL SOFTWARE
A continuación describiremos la evolución del Software dentro del
contexto de las áreas de aplicación de los sistemas basados en
computadoras.[CITATION PRE93 \p 188 \l 3082 ]
Los primeros años (1950 - 1965):
 El software estaba en su infancia.

 El software era un añadido.
 Existían pocos métodos para la programación.
 No se tenía una planificación para el desarrollo del software.
 Los programadores trataban de hacer las cosas bien.
 El software se diseñaba a medida.
30
 El software era desarrollado y utilizado por la misma persona u
organización (entorno personalizado).

 El diseño de software era realizado en la mente de alguien y no existía
documentación.
La segunda era (1965 - 1975):
 Multiprogramación y sistemas multiusuario introducen nuevos
conceptos de interacción hombre-máquina.

 Sistemas de tiempo real que podían recoger, analizar y transformar
datos de múltiples fuentes.

 Avances en los dispositivos de almacenamiento en línea condujeron a
la primera generación de sistemas de gestión de Base de Datos.

 Software como producto y la llegada de las "casas de software"
produciéndose así una amplia distribución en el mercado.
La tercera era (1975 - 1985):
 Procesamiento Distribuido. Múltiple computadoras, cada una
ejecutando funciones concurrentes y comunicándose con alguna otra.

 Redes de área local y de área global. Comunicaciones digitales de alto
ancho de banda y la creciente demanda de acceso "instantáneo" a los
datos.
 Amplio uso de microprocesadores y computadoras personales
(hardware de bajo costo). Incorporación de "inteligencia" (autos, hornos
de microondas, robots industriales y equipos de diagnóstico de suero
sanguíneo). Impacto en el consumo.

 Planificación en el proceso del desarrollo de software.
La cuarta era (1985 -2000):
 Tecnología orientada a objetos

 Los sistemas expertos y la inteligencia artificial se han trasladado del
laboratorio a las aplicaciones prácticas.
31
Software para redes neuronales artificiales (simulación de procesamiento
de información al estilo de como lo hacen los humanos).
2.3. EL SOFTWARE
El software se ha convertido en el elemento clave de la evolución de los
sistemas y productos informáticos, y por tal razón no se puede tomar
como sólo el conjunto de programas, instrucciones y estructuras de datos.
“A continuación se presentan algunas características que permiten
visualizar lo que en realidad es el software”[CITATION PRE93 \p 3 \l
3082 ]
2.3.1. CARACTERÍSTICAS DEL SOFTWARE
a. El Software Se desarrolla, no se fabrica: Se utiliza un modelo
de proceso de desarrollo que comprende análisis, diseño,
desarrollo, implementación y evaluación para obtener un
producto de calidad.
b. El Software no se “estropea”, pero se deteriora: El software
durante su vida sufre cambios por lo que es probable que surjan
fallos y defectos que si no se corrigen permiten que el software
se vaya deteriorando.
c. El Software se construye a medida: A medida que el software
evoluciona se crean estándares de diseño. El software debe
diseñarse e implementarse para que pueda ser reutilizable.
2.3.2. APLICACIONES DEL SOFTWARE
El software tiene una gran amplitud de aplicaciones. A continuación
se relacionan:
32
a. Software de sistemas: Conjunto de programas creados como
herramienta para otros programas. Por ejemplo: compiladores,
Sistemas operativos.
b. Software de tiempo real: El software que coordina / analiza/
controla sucesos del mundo real conforme ocurren, se denomina
de tiempo real.
Ejemplos: procesamiento de transacciones en puntos de venta,
control de procesos de manufactura en tiempo real.

c. Software de gestión: Gestión de grandes cantidades de
información almacenadas, para facilitar la toma de decisiones.
Por ejemplo Bases de datos y aplicaciones de gestión de
empresa.
d. Software de ingeniería y científico: Utiliza algoritmos de
manejo de números, simulación de sistemas, utiliza software en
tiempo real. Por ejemplo: aplicaciones de astronomía,
vulcanología, fabricación automática.

e. Software empotrado: Reside en memoria de sólo lectura y
se utiliza para controlar productos y sistemas de los
mercados industriales. Por ejemplo, el control de las teclas de
un horno de microondas, funciones digitales en un automóvil.

f. Software de computadoras personales: Aplicaciones
orientadas a usuarios individuales o multiusuarios. Por
ejemplo: procesadores de texto, hojas de cálculo, juegos,
aplicaciones financieras, gestores de bases de datos.

g. Software basado en web: Las páginas web buscadas por un
explorador son software que incorpora instrucciones ejecutables
y datos.
33
h. Software de inteligencia artificial: Hace uso de algoritmos no
numéricos para resolver problemas complejos. Por ejemplo:
sistemas expertos, redes neuronales, robótica, prueba de
teoremas y juegos.
2.3.3. MITOS DEL SOFTWARE
Los mitos del software creencias erróneas sobre éste y sobre el
proceso que se utiliza para obtenerlo se remontan a los primeros
días de la computación. En la actualidad, la mayoría de
profesionales de la ingeniería de software reconocen los mitos
como lo que son: actitudes equivocadas que han ocasionado
serios problemas a los administradores y a los trabajadores por
igual.
Pueden afectar a:
 Gestores.
 Clientes.
 Programadores.
a. Mitos de gestión. Los gestores con responsabilidad sobre el
software, como los gestores en la mayoría de las disciplinas,
están normalmente bajo la presión de cumplir los presupuestos,
hacer que no se retrase el proyecto y mejorar la calidad. Igual
que se agarra al vacío una persona que se ahoga, un gestor de
software se agarra frecuentemente a un mito del software,
aunque tal creencia sólo disminuya la presión temporalmente.

 Mito. Tenemos ya un libro que está lleno de estándares y
procedimientos para construir software, ¿no le proporciona
ya a mi gente todo lo que necesita saber?.
34
 Realidad. Está muy bien que el libro exista, ¿pero se usa?
¿conocen los trabajadores su existencia?, ¿refleja las
prácticas modernas de desarrollo de software?, ¿es
completo?, ¿está diseñado para mejorar el tiempo de
entrega mientras mantiene un enfoque de calidad? En
muchos casos, la respuesta a todas estas preguntas es
«no».
 Mito. Mi gente dispone de las herramientas de desarrollo de
software más avanzadas, después de todo, les compramos
las computadoras más modernas.

 Realidad. Se necesita mucho más que el último modelo de
computadora grande o de PC para hacer desarrollo de
software de gran calidad. Las herramientas de ingeniería del
software asistida por computadora (CASE) son más
importantes que el hardware para conseguir buena calidad y
productividad, aunque la mayoría de los desarrolladores del
software todavía no las utilicen eficazmente.

 Mito. Si fallamos en la planificación, podemos añadir más
programadores y adelantar el tiempo perdido (el llamado
algunas veces «concepto de la horda Mongoliana»).

 Realidad. El desarrollo de software no es un proceso
mecánico como la fabricación. En palabras de Brooks:
«...añadir gente a un proyecto de software retrasado lo
retrasa aún más». Al principio, esta declaración puede
parecer un contrasentido. Sin embargo, cuando se añaden
nuevas personas, la necesidad de aprender y comunicarse
35
con el equipo puede y hace que se reduzca la cantidad de
tiempo gastado en el desarrollo productivo. Puede añadirse
gente, pero sólo de una manera planificada y bien
coordinada.
b. Mitos del cliente. Un cliente que solicita una aplicación de
software puede ser una persona del despacho de al lado, un
grupo técnico de la sala de abajo, el departamento de ventas o
una compañía exterior que solicita un software bajo contrato. En
muchos casos, el cliente cree en los mitos que existen sobre el
software, debido a que los gestores y desarrolladores del
software hacen muy poco para corregir la mala información. Los
mitos conducen a que el cliente se cree una falsa expectativa y,
finalmente, quede insatisfecho con el que desarrolla el software.

 Mito. Una declaración general de los objetivos es suficiente
para comenzar a escribir los programas–podemos dar los
detalles más adelante-.

 Realidad. Una mala definición inicial es la principal causa
del trabajo baldío en software. Es esencial una descripción
formal y detallada del ámbito de la información, funciones,
comportamiento, rendimiento, interfaces, ligaduras del
diseño y criterios de validación. Estas características pueden
determinarse sólo después de una exhaustiva comunicación
entre el cliente y el analista.

 Mito. Los requisitos del proyecto cambian continuamente,
pero los cambios pueden acomodarse fácilmente, ya que

 el software es flexible.
36
 Realidad. Es verdad que los requisitos del software
cambian, pero el impacto del cambio varía según el
momento en que se introduzca. Si se pone cuidado al dar la
definición inicial, los cambios solicitados al principio pueden
acomodarse fácilmente. El cliente puede revisar los
requisitos y recomendar las modificaciones con
relativamente poco impacto en el coste. Cuando los cambios
se solicitan durante el diseño del software, el impacto en el
coste crece rápidamente. Ya se han acordado los recursos a
utilizar y se ha establecido un marco de trabajo del diseño.
Los cambios pueden producir trastornos que requieran
recursos adicionales e importantes modificaciones del
diseño; es decir, coste adicional. Los cambios en la función,
rendimiento, interfaces u otras características, durante la
implementación (codificación y prueba) pueden tener un
impacto importante sobre el coste. Cuando se solicitan al
final de un proyecto, los cambios pueden producir un orden
de magnitud más caro que el mismo cambio pedido al
principio
c. Mitos de los desarrolladores. Los mitos en los que aún creen
muchos desarrolladores se han ido fomentando durante 50 años
de cultura informática. Durante los primeros días del desarrollo
del software, la programación se veía como un arte. Las viejas
formas y actitudes tardan en morir.
37
 Mito. Una vez que escribimos el programa y hacemos que
funcione, nuestro trabajo ha terminado.

 Realidad. Alguien dijo una vez: «cuanto más pronto se
comience a escribir código, más se tardará en terminarlo ».
Los datos industriales indican que entre el 60 y el 80 por
ciento de todo el esfuerzo dedicado a un programa se
realizará después de que se le haya entregado al cliente por
primera vez.
 Mito. Hasta que no tengo el programa «ejecutándose »,
realmente no tengo forma de comprobar su calidad.

 Realidad. Desde el principio del proyecto se puede aplicar
uno de los mecanismos más efectivos para garantizar la
calidad del software: la revisión técnica formal. La revisión
del software (descrito en el Capítulo 8) es un «filtro de
calidad» que se ha comprobado que es más efectivo que la
prueba, para encontrar ciertas clases de defectos en el
software.
 Mito. Lo único que se entrega al terminar el proyecto es el
programa funcionando.
 Realidad. Un programa que funciona es sólo una parte de
una configuración del software que incluye muchos
elementos. La documentación proporciona el fundamento
para un buen desarrollo y, lo que es más importante,
proporciona guías para la tarea de mantenimiento del
software. Muchos profesionales del software reconocen la
falacia de los mitos descritos anteriormente.
Lamentablemente, las actitudes y métodos habituales

38
fomentan una pobre gestión y malas prácticas técnicas,
incluso cuando la realidad dicta un método mejor. El
reconocimiento de las realidades del software es el primer
paso hacia la formulación de soluciones prácticas para su
desarrollo.
2.3.4. ATRIBUTOS DE UN BUEN SOFTWARE
El software debe proporcionar la funcionalidad y el rendimiento
requeridos a los usuarios y debe ser sostenible, fiable y aceptable.

 Mantenibilidad: (Capacidad de poder mantenerse): el software
debe evolucionar para cumplir con las necesidades de cambio.

 Fiabilidad: El software deber ser digno de confianza.
 Eficiencia: El software no debe hacer un uso derrochador
de los recursos del sistema.

 Aceptabilidad: El software debe ser aceptado por los usuarios
para los que se diseñó. Esto significa que ha de ser entendible,
usable y compatible con otros sistemas.
2.3.5. COMPONENTES DEL SOFTWARE
El software se puede definir como el conjunto de tres
componentes:[ CITATION www16 \l 3082 ]
1. Programas: Los programas son conjuntos de instrucciones que
proporcionan la funcionalidad deseada cuando son ejecutadas
por el ordenador. Tales como lenguaje ensamblador, Basic,
FORTRAN, COBOL, C.
2. Datos: Los programas proporcionan la funcionalidad requerida
manipulando datos. El diseño del programa asume la
39
disponibilidad de las estructuras de datos tales como bases de
datos y archivos que contienen datos.

3. Documentos: Además de los programas y los datos, Los
documentos también son requeridos por las personas
encargadas de mantener el software para entender el interior del
software y modificarlo, en el caso en que sea necesario.

4. Enfoque de calidad: Gestión total de calidad. Cultura continua
de mejoras de procesos.
Ilustración 6: Componentes del software
Es importante contar con una definición exhaustiva del software ya
que de otra manera se podrían olvidar algunos componentes. Una
percepción común es que el software sólo consiste en programas,
sin embargo, los programas no son los únicos componentes del
software.
Aquí se hizo un ejemplo piloto con la herramienta que les
proporcionó el proveedor con algunas de las personas del
departamento de RRHH.
Ilustración 7: Evaluación uso de herramienta de RRHH I.

El principal
¿Qué os parece la
problema con el que
herramienta de
nos hemos
gestión de RRHH
encontrado es que
que estamos
no nos han
probando?
proporcionado un
manual de usuario.
40
CAPITULO III
EL PROCESO
3.1. DEFINICIÓN DEL PROCESO
Es una serie de pasos a seguir para construir un producto o un sistema.
El proceso del software es importante porque proporciona estabilidad,
control y organización a una actividad que puede, si no se controla,
volverse caótica.[CITATION PRE93 \p 26 \l 3082 ]
3.2. EL PROCESO DEL SOFTWARE
Un proceso de software se puede caracterizar como se muestra en la
ilustración 10. Se establece un marco común del proceso definiendo un
pequeño número de actividades del marco de trabajo que son aplicables
a todos los proyectos del software, con independencia de su tamaño o
complejidad. Un número de conjuntos de tareas cada uno es una
colección de tareas de trabajo de ingeniería del software, hitos de
proyectos, productos de trabajo, y puntos de garantía de calidad que
41
permiten que las actividades del marco de trabajo se adapten a las
características del proyecto del software y a los requisitos del equipo del
proyecto. Finalmente, las actividades de protección tales como garantía
de calidad del software, gestión de configuración del software y medición
abarcan el modelo de procesos. Las actividades de protección son
independientes de cualquier actividad del marco de trabajo y aparecen
durante todo el proceso.
Ilustración 8: El Proceso de Software
Aplicables a todos los proyectos de

software, con independencia de su
tamaño o complejidad.
Marco de trabajo común del proceso

Actividades del marco de trabajo
Conjunto de tareas
Tareas
Hitos, entregas
Actividades
PuntosdeSQA
protección
Son independientes de Permiten que las actividades del marco de

cualquier actividad del marco trabajo se adapten a las características del
de trabajo y aparecen durante proyecto del software y a los requisitos del
todo el proceso. proyecto.
3.3. CICLOS DE VIDA DE DESARROLLO DEL SOFTWARE.
3.3.1. CICLO DE VIDA
El ciclo de vida es el conjunto de fases por las que pasa el
sistema que se está desarrollando desde que nace la idea inicial
42
hasta que el software es retirado o remplazado (muere). También
se denomina a veces paradigma.
Entre las funciones que debe tener un ciclo de vida se pueden
destacar:
 Determinar el orden de las fases del proceso de software

 Establecer los criterios de transición para pasar de una fase a
la siguiente
 Definir las entradas y salidas de cada fase
 Describir los estados por los que pasa el producto
 Describir las actividades a realizar para transformar el producto
 Definir un esquema que sirve como base para planificar,
organizar, coordinar, desarrollar…
Un ciclo de vida para un proyecto se compone de fases
sucesivas compuestas por tareas que se pueden planificar. Según
el modelo de ciclo de vida, la sucesión de fases puede ampliarse
con bucles de realimentación, de manera que lo que
conceptualmente se considera una misma fase se pueda ejecutar
más de una vez a lo largo de un proyecto, recibiendo en cada
pasada de ejecución aportaciones a los resultados intermedios
que se van produciendo (realimentación).
 Fases: una fase es un conjunto de actividades relacionadas
con un objetivo en el desarrollo del proyecto. Se construye
agrupando tareas (actividades elementales) que pueden
compartir un tramo determinado del tiempo de vida de un
proyecto. La agrupación temporal de tareas impone requisitos
temporales correspondientes a la asignación de recursos
(humanos, financieros o materiales).

43
 Entregables: son los productos intermedios que generan
las fases. Pueden ser materiales o inmateriales
(documentos, software). Los entregables permiten evaluar la
marcha del proyecto mediante comprobaciones de su
adecuación o no a los requisitos funcionales y de condiciones
de realización previamente establecidos.
3.3.2. TIPOS DE MODELO DE CICLO DE VIDA.
Las principales diferencias entre distintos modelos de ciclo de vida
están en:
 El alcance del ciclo dependiendo de hasta dónde llegue el
proyecto correspondiente.
 Un proyecto puede comprender un simple estudio de viabilidad
del desarrollo de un producto, o su desarrollo completo o en el
extremo, toda la historia del producto con su desarrollo,
fabricación y modificaciones posteriores hasta su retirada del
mercado.
 Las características (contenidos) de las fases en que dividen
el ciclo. Esto puede depender del propio tema al que se refiere
el proyecto, o de la organización.
 La estructura y la sucesión de las etapas, si hay
realimentación entre ellas, y si tenemos libertad de repetirlas
(iterar).
3.3.3. MODELOS DE CICLO DE VIDA.
La ingeniería del software establece y se vale de una serie de
modelos que establecen y muestran las distintas etapas y estados
44
por los que pasa un producto software, desde su concepción
inicial, pasando por su desarrollo, puesta en marcha y posterior
mantenimiento, hasta la retirada del producto. A estos modelos se
les denomina “Modelos de ciclo de vida del software”.
Los modelos de ciclo de vida del software describen las fases
del ciclo de software y el orden en que se ejecutan las fases.
Un modelo de ciclo de vida de software es una vista de las
actividades que ocurren durante el desarrollo de software, intenta
determinar el orden de las etapas involucradas y los criterios
de transición asociados entre estas etapas.
Un modelo de ciclo de vida del software:
 Describe las fases principales de desarrollo de software

 Define las fases primarias esperadas de ser ejecutadas
durante esas fases

 Ayuda a administrar el progreso del desarrollo
 Provee un espacio de trabajo para la definición de un proceso
detallado de desarrollo de software.
En cada una de las etapas de un modelo de ciclo de vida, se
pueden establecer una serie de objetivos, tareas y actividades que
lo caracterizan. Existen distintos modelos de ciclo de vida, y la
elección de un modelo para un determinado tipo de proyecto
es realmente importante; el orden es uno de estos puntos
importantes.
Existen varias alternativas de modelos de ciclo de vida. A
continuación se muestran algunos de los modelos tradicionales y
más utilizados.
45
3.3.1.1. MODELO EN CASCADA.
Es el enfoque metodológico que ordena rigurosamente las
etapas del ciclo de vida del software, de forma que el
inicio de cada etapa debe esperar a la finalización de la
inmediatamente anterior.
El modelo en cascada es un proceso de desarrollo
secuencial, en el que el desarrollo se ve fluyendo hacia
abajo (como una cascada) sobre las fases que componen
el ciclo de vida.
Se cree que el modelo en cascada fue el primer modelo
de proceso introducido y seguido ampliamente en la
ingeniería el software. La innovación estuvo en la primera
vez que la ingeniería del software fue dividida en fases
separadas.
La primera descripción formal del modelo en cascada se
cree que fue en un artículo publicado en 1970 por Winston
W. Royce, aunque Royce no usó el término cascada en
este artículo. Irónicamente, Royce estaba presentando
este modelo como un ejemplo de modelo que no
funcionaba, defectuoso.
En el modelo original de Royce, existían las siguientes
fases:
 Especificación de requisitos
46
 Diseño
 Construcción (Implementación o codificación)
 Integración
 Pruebas
 Instalación
 Mantenimiento
Para seguir el modelo en cascada, se avanza de una fase
a la siguiente en una forma puramente secuencial.
Ilustración 9: Modelo de ciclo de vida en cascada
A. VENTAJAS.
El modelo en cascada puede ser apropiado, en general,
para proyectos estables (especialmente los proyectos
con requisitos no cambiantes) y donde es posible y
probable que los diseñadores predigan totalmente áreas
de problema del sistema y produzcan un diseño
correcto antes de que empiece la implementación.
Funciona bien para proyectos pequeños donde los
requisitos están bien entendidos.

47
Es un modelo en el que todo está bien organizado y no
se mezclan las fases. Es simple y fácil de usar.
Debido a la rigidez del modelo es fácil de gestionar ya
que cada fase tiene entregables específicos y un
proceso de revisión. Las fases son procesadas y
completadas de una vez.

B. INCONVENIENTES.
En la vida real, un proyecto rara vez sigue una
secuencia lineal, esto crea una mala implementación del
modelo, lo cual hace que lo lleve al fracaso.
Difícilmente un cliente va a establecer al principio todos
los requisitos necesarios, por lo que provoca un gran
atraso trabajando en este modelo, ya que este es muy
restrictivo y no permite movilizarse entre fases.
Los resultados y/o mejoras no son visibles
progresivamente, el producto se ve cuando ya está
finalizado, lo cual provoca una gran inseguridad por
parte del cliente que quiere ir viendo los avances en
el producto. Esto también implica el tener que tratar
con requisitos que no se habían tomado en cuenta
desde el principio, y que surgieron al momento de la
implementación, lo cual provocará que haya que volver
de nuevo a la fase de requisitos.
Hay muchas personas que argumentan que es una
mala idea en la práctica, principalmente a causa de su
48
creencia de que es imposible, para un proyecto no
trivial, conseguir tener una fase del ciclo de vida del
producto software perfecta antes de moverse a las
siguientes fases. Por ejemplo, los clientes pueden no
ser conscientes exactamente de los requisitos que
quieren antes de ver un prototipo del trabajo; pueden
cambiar los requisitos constantemente, y los
diseñadores e implementadores pueden tener poco
control sobre esto. Si los clientes cambian sus
requisitos después de que el diseño está terminado,
este diseño deberá ser modificado para acomodarse a
los nuevos requisitos, invalidando una buena parte del
esfuerzo.
Muchas veces se considera un modelo pobre para
proyectos complejos, largos, orientados a objetos y por
supuesto en aquellos en los que los requisitos tengan un
riesgo de moderado a alto de cambiar. Genera altas
cantidades de riesgos e incertidumbres.
C. VARIANTES.
Existen muchas variantes de este modelo. En respuesta
a los problemas percibidos con el modelo en cascada
puro, se introdujeron muchos modelos de cascada
modificados. Estos modelos pueden solventar algunas o
todas las críticas del modelo en cascada puro.
49
De hecho muchos de los modelos utilizados tienen su
base en el modelo en cascada.
Uno de estos modelos modificados es el modelo
Sashimi.
El modelo sashimi (llamado así porque tiene fases
solapadas, como el pescado japonés sashimi) fue
creado originalmente por Peter DeGrace. A veces se
hace referencia a él como el modelo en cascada
con fases superpuestas o el modelo en
cascada con retroalimentación. Ya que las fases en el
modelo sashimi se superponen, lo que implica que se
puede actuar durante las etapas anteriores. Por
ejemplo, ya que las fases de diseño e implementación
se superpondrán en el modelo sashimi, los problemas
de implementación se pueden descubrir durante las
fases de diseño e implementación del proceso de
desarrollo.
3.3.1.2. MODELO EN V.
El modelo en v se desarrolló para terminar con algunos de
los problemas que se vieron utilizando el enfoque de
cascada tradicional. También muestra que las pruebas no
son sólo una actividad basada en la ejecución. Hay una
variedad de actividades que se han de realizar antes del fin
de la fase de codificación. Estas actividades deberían ser
50
llevadas a cabo en paralelo con las actividades de
desarrollo, y los técnicos de pruebas necesitan trabajar
con los desarrolladores y analistas de negocio de tal forma
que puedan realizar estas actividades y tareas y producir
una serie de entregables de pruebas. Los productos de
trabajo generados por los desarrolladores y analistas de
negocio durante el desarrollo son las bases de las
pruebas en uno o más niveles. El modelo en v es
un modelo que ilustra cómo las actividades de prueba
(verificación y validación) se pueden integrar en cada fase
del ciclo de vida. Dentro del modelo en v, las pruebas de
validación tienen lugar especialmente durante las etapas
tempranas, por ejemplo, revisando los requisitos de
usuario y después por ejemplo, durante las pruebas de
aceptación de usuario.
Ilustración 10: Modelo de ciclo de vida en V
51
Realmente las etapas individuales del proceso pueden ser
casi las mismas que las del modelo en cascada. Sin
embargo hay una gran diferencia. En vez de ir para abajo
de una forma lineal las fases del proceso vuelven hacia
arriba tras la fase de codificación, formando una v. La
razón de esto es que para cada una de las fases de
diseño se ha encontrado que hay un homólogo en las
fases de pruebas que se correlacionan.
A. VENTAJAS.
Las ventajas que se pueden destacar de este modelo
son las siguientes:
 Es un modelo simple y fácil de utilizar.

 En cada una de las fases hay entregables
específicos.
 Tiene una alta oportunidad de éxito sobre el
modelo en cascada debido al desarrollo de planes
de prueba en etapas tempranas del ciclo de vida.

 Es un modelo que suele funcionar bien para
proyectos pequeños donde los requisitos son
entendidos fácilmente.
B. INCONVENIENTES.
Entre los inconvenientes y las críticas que se le hacen
a este modelo están las siguientes:

 Es un modelo muy rígido, como el modelo en
cascada.
 Tiene poca flexibilidad y ajustar el alcance es difícil
52
y caro.
 El software se desarrolla durante la fase de
implementación, por lo que no se producen
prototipos del software.

 El modelo no proporciona caminos claros para
problemas encontrados durante las fases de
pruebas.
3.3.1.3. MODELO ITERATIVO.
Es un modelo derivado del ciclo de vida en cascada.
Este modelo busca reducir el riesgo que surge entre las
necesidades del usuario y el producto final por malos
entendidos durante la etapa de recogida de requisitos.
Consiste en la iteración de varios ciclos de vida en
cascada. Al final de cada iteración se le entrega al cliente
una versión mejorada o con mayores funcionalidades del
producto. El cliente es quien después de cada iteración
evalúa el producto y lo corrige o propone mejoras.
Estas iteraciones se repetirán hasta obtener un
producto que satisfaga las necesidades del cliente.
Este modelo se suele utilizar en proyectos en los que los
requisitos no están claros por parte del usuario, por lo
que se hace necesaria la creación de distintos
prototipos para presentarlos y conseguir la conformidad
del cliente.
Ilustración 11: Modelo de ciclo de vida iterativo

53
A. VENTAJAS.
Una de las principales ventajas que ofrece este modelo
es que no hace falta que los requisitos estén totalmente
definidos al inicio del desarrollo, sino que se pueden ir
refinando en cada una de las iteraciones.
Igual que otros modelos similares tiene las ventajas
propias de realizar el desarrollo en pequeños ciclos, lo
que permite gestionar mejor los riesgos, gestionar mejor
las entregas…
B. INCONVENIENTES.
La primera de las ventajas que ofrece este modelo, el
no ser necesario tener los requisitos definidos desde el
principio, puede verse también como un inconveniente
ya que pueden surgir problemas relacionados con la
arquitectura.
3.3.1.4. MODELO DE DESARROLLO INCREMENTAL.
54
El modelo incremental combina elementos del modelo en
cascada con la filosofía interactiva de construcción de
prototipos. Se basa en la filosofía de construir
incrementando las funcionalidades del programa. Este
modelo aplica secuencias lineales de forma escalonada
mientras progresa el tiempo en el calendario. Cada
secuencia lineal produce un incremento del software.
Ilustración 12: Modelo de ciclo de vida incremental
Cuando se utiliza un modelo incremental, el primer
incremento es a menudo un producto esencial, sólo con
los requisitos básicos. Este modelo se centra en la
entrega de un producto operativo con cada incremento.
Los primeros incrementos son versiones incompletas del
producto final, pero proporcionan al usuario la
funcionalidad que precisa y también una plataforma para la
evaluación.
A. VENTAJAS.
55
Entre las ventajas que puede proporcionar un modelo
de este tipo encontramos las siguientes:
 Mediante este modelo se genera software
operativo de forma rápida y en etapas tempranas
del ciclo de vida del software.

 Es un modelo más flexible, por lo que se reduce el
coste en el cambio de alcance y requisitos.

 Es más fácil probar y depurar en una iteración más
pequeña.
 Es más fácil gestionar riesgos.
 Cada iteración es un hito gestionado fácilmente
B. INCONVENIENTES.
Para el uso de este modelo se requiere una experiencia
importante para definir los incrementos y distribuir en
ellos las tareas de forma proporcionada.
Entre los inconvenientes que aparecen en el uso de
este modelo podemos destacar los siguientes:
 Cada fase de una iteración es rígida y no se
superponen con otras.

 Pueden surgir problemas referidos a la arquitectura
del sistema porque no todos los requisitos se han
reunido, ya que se supone que todos ellos se han
definido al inicio.
3.3.1.5. MODELO EN ESPIRAL.
El desarrollo en espiral es un modelo de ciclo de vida
desarrollado por Barry Boehm en 1985, utilizado de forma
generalizada en la ingeniería del software. Las actividades
56
de este modelo se conforman en una espiral, cada bucle
representa un conjunto de actividades. Las actividades no
están fijadas a priori, sino que las siguientes se eligen en
función del análisis de riesgos, comenzando por el bucle
anterior.
Boehm, autor de diversos artículos de ingeniería del
software; modelos de estimación de esfuerzos y tiempo
que se consume en hacer productos software; y modelos
de ciclo de vida, ideó y promulgó un modelo desde un
enfoque distinto al tradicional en Cascada: el Modelo
Evolutivo Espiral. Su modelo de ciclo de vida en espiral
tiene en cuenta fuertemente el riesgo que aparece a la
hora de desarrollar software. Para ello, se comienza
mirando las posibles alternativas de desarrollo, se opta por
la de riesgos más asumibles y se hace un ciclo de la
espiral. Si el cliente quiere seguir haciendo mejoras en el
software, se vuelven a evaluar las nuevas alternativas y
riesgos y se realiza otra vuelta de la espiral, así hasta que
llegue un momento en el que el producto software
desarrollado sea aceptado y no necesite seguir
mejorándose con otro nuevo ciclo.

Este modelo de desarrollo combina las características del
modelo de prototipos y el modelo en cascada. El modelo
en espiral está pensado para proyectos largos, caros y
complicados.
Esto modelo no fue el primero en tratar el desarrollo
57
iterativo, pero fue el primer modelo en explicar las
iteraciones.
Este modelo fue propuesto por Boehm en 1988 en su
artículo “A Spiral Model of Software Development and
Enhancement”. Básicamente consiste en una serie de
ciclos que se repiten en forma de espiral, comenzando
desde el centro. Se suele interpretar como que dentro de
cada ciclo de la espiral se sigue un modelo en cascada,
pero no necesariamente ha de ser así.

Este sistema es muy utilizado en proyectos grandes y
complejos como puede ser, por ejemplo, la creación de un
sistema operativo.
Al ser un modelo de ciclo de vida orientado a la gestión de
riesgos se dice que uno de los aspectos fundamentales
de su éxito radica en que el equipo que lo aplique
tenga la necesaria experiencia y habilidad para detectar y
catalogar correctamente riesgos.
Tareas:
Para cada ciclo habrá cuatro actividades:
1. Determinar o fijar objetivos:

a) Fijar también los productos definidos a
obtener: requerimientos, especificación, manual de
usuario.
b) Fijar las restricciones.
c) Identificación de riesgos del proyecto y estrategias
alternativas para evitarlos d. Hay una cosa que
solo se hace una vez: planificación inicial o previa

2. Análisis del riesgo:
58
a) Se estudian todos los riesgos potenciales y se
seleccionan una o varias alternativas propuestas
para reducir o eliminar los riesgos

3. Desarrollar, verificar y validar (probar):
a) Tareas de la actividad propia y de prueba.
b) Análisis de alternativas e identificación de
resolución de riesgos
c) Dependiendo del resultado de la evaluación de
riesgos, se elige un modelo para el desarrollo, que
puede ser cualquiera de los otros existentes, como
formal, evolutivo, cascada, etc. Así, por ejemplo,
si los riesgos de la interfaz de usuario son
dominantes, un modelo de desarrollo apropiado
podría ser la construcción de prototipos evolutivos.

4. Planificar:
a) Revisamos todo lo que hemos hecho, evaluándolo
y con ello decidimos si continuamos con las fases
siguientes y planificamos la próxima actividad.
El proceso empieza en la posición central. Desde
allí se mueve en el sentido de las agujas del reloj.
Ilustración 13: Ciclo de vida en espiral
59
Las cuatro regiones del gráfico son:
 La tarea de planificación: para definir recursos,
responsabilidades, hitos y planificaciones.

 La tarea de determinación de objetivos: para definir
los requisitos y las restricciones para el producto y
definir las posibles alternativas.

 La tarea de análisis de riesgos: para evaluar riesgos
tanto técnicos como de gestión.

 La tarea de ingeniería: para diseñar e implementar
uno o más prototipos o ejemplos de la aplicación
A. VENTAJAS.
El análisis de riesgos se hace de forma explícita y clara.
Une los mejores elementos de los restantes modelos.
Entre ellos:
 Reduce riesgos del proyecto

 Incorpora objetivos de calidad
 Integra el desarrollo con el mantenimiento
Además es posible tener en cuenta mejoras y nuevos
requerimientos sin romper con el modelo, ya que el ciclo
de vida no es rígido ni estático.
Mediante este modelo se produce software en etapas
tempranas del ciclo de vida y suele ser adecuado para
proyectos largos de misión crítica.
B. INCONVENIENTES
60
Es un modelo que genera mucho trabajo adicional. Al
ser el análisis de riesgos una de las tareas principales
exige un alto nivel de experiencia y cierta habilidad en
los analistas de riesgos (es bastante difícil).
Esto puede llevar a que sea un modelo costoso.
Además, no es un modelo que funcione bien para
proyectos pequeños.
C. COMPARACIÓN CON OTROS MODELOS
La distinción más destacada entre el modelo en espiral
y otros modelos de software es la tarea explícita de
evaluación de riesgos. Aunque la gestión de riesgos es
parte de otros procesos también, no tiene una
representación propia en el modelo de proceso. Para
otros modelos la evaluación de riesgos es una subtarea,
por ejemplo, de la planificación y gestión global.
Además no hay fases fijadas para la especificación de
requisitos, diseño y pruebas en el modelo en espiral. Se
puede usar prototipado para encontrar y definir los
requisitos.
La diferencia entre este modelo y el modelo de ciclo
incremental es que en el incremental se parte de que no
hay incertidumbre en los requisitos iniciales; en este, en
cambio, se es consciente de que se comienza con un
alto grado de incertidumbre. En el incremental
61
suponemos que conocemos el problema y lo dividimos.
Este modelo gestiona la incertidumbre.
3.3.1.6. MODELO DE PROTOTIPOS.
Un cliente, a menudo, define un conjunto de objetivos
generales para el software, pero no identifica los requisitos
detallados de entrada, proceso o salida. En otros casos, el
responsable del desarrollo del software puede no estar
seguro de la eficiencia de un algoritmo, de la calidad de
adaptación de un sistema operativo, o de la forma en que
debería tomarse la interacción hombre-máquina.

El paradigma de construcción de prototipos comienza con
la recolección de requisitos. El desarrollador y el cliente
encuentran y definen los objetivos globales para el
software, identifican los requisitos conocidos y las áreas
del esquema en donde es obligatoria más definición.
Entonces aparece un diseño rápido. El diseño rápido se
centra en una representación de esos aspectos del
software que serán visibles para el usuario/cliente. El
prototipo lo evalúa el cliente/usuario y se utiliza para refinar
los requisitos del software a desarrollar. La iteración ocurre
cuando el prototipo se pone a punto para satisfacer las
necesidades del cliente, permitiendo al mismo tiempo que
el desarrollador comprenda mejor lo que se necesita hacer.
Ilustración 14: Modelo de ciclo de vida de
prototipos
62
A. VENTAJAS.
Entre las ventajas que ofrece este modelo se pueden
destacar las siguientes:
Ofrece visibilidad del producto desde el inicio del ciclo
de vida con el primer prototipo. Esto puede ayudar al
cliente a definir mejor los requisitos y a ver las
necesidades reales del producto. Permite introducir
cambios en las iteraciones siguientes del ciclo. Permite
la realimentación continua del cliente.
El prototipo es un documento vivo de buen
funcionamiento del producto final. El cliente reacciona
mucho mejor ante el prototipo, sobre el que puede
experimentar, que no sobre una especificación escrita.
Este modelo reduce el riesgo de construir productos
que no satisfagan las necesidades de los usuarios.
B. INCONVENIENTES.
63
Entre los inconvenientes que se han observado con
este modelo está el hecho de que puede ser un
desarrollo lento. Además se hacen fuertes inversiones
en un producto desechable ya que los prototipos se
descartan. Esto puede hacer que aumente el coste de
desarrollo del producto.
Con este modelo pueden surgir problemas con el
cliente que ve funcionando versiones del prototipo pero
puede desilusionarse porque el producto final aún no
ha sido construido.
3.4. ISO/IEC 12207.
Esta norma establece un marco de referencia común para los procesos
del ciclo de vida del software, con una terminología bien definida a la que
puede hacer referencia la industria del software. Contiene procesos,
actividades y tareas para aplicar durante la adquisición de un sistema
que contiene software, un producto software puro o un servicio software,
y durante el suministro, desarrollo, operación y mantenimiento de
productos software. El software incluye la parte software del firmware.
Esta norma incluye también un proceso que puede emplearse para
definir, controlar y mejorar los procesos del ciclo de vida del software.
La ISO 12207 define un modelo de ciclo de vida como un marco
de referencia que contiene los procesos, actividades y tareas
involucradas en el desarrollo, operación y mantenimiento de un
producto software, y que abarca toda la vida del sistema, desde la

64
definición de sus requisitos hasta el final del uso.
Esta norma agrupa las actividades que pueden llevarse a cabo durante
el ciclo de vida del software en cinco procesos principales, ocho
procesos de apoyo y cuatro procesos organizativos. Cada proceso del
ciclo de vida está dividido en un conjunto de actividades; cada actividad
se subdivide a su vez en un conjunto de tareas.
3.4.1. PROCESOS PRINCIPALES DEL CICLO DE VIDA.
Son cinco procesos que dan servicio a las partes principales
durante el ciclo de vida del software. Una parte principal es la que
inicia o lleva a cabo el desarrollo, operación y mantenimiento de
productos software. Los procesos principales son:
 Proceso de adquisición.
 Proceso de suministro.
 Proceso de desarrollo.
 Proceso de operación.
 Proceso de mantenimiento.
3.4.2. PROCESOS DE APOYO AL CICLO DE VIDA.
Son procesos que apoyan a otros procesos como parte esencial
de los mismos, con un propósito bien definido, y contribuyen al éxito
y calidad del proyecto software. Un proceso de apoyo se emplea y
ejecuta por otro proceso según sus necesidades.

Los procesos de apoyo son:
 Proceso de documentación.
 Proceso de gestión de la configuración.
 Proceso de verificación.
 Proceso de validación.
 Proceso de revisiones conjuntas.
 Proceso de auditoría
 Proceso de solución de problemas
65
3.4.3. PROCESOS ORGANIZATIVOS DEL CICLO DE VIDA.
Se emplean por una organización para establecer e implementar
una infraestructura construida por procesos y personal asociado al
ciclo de vida, y para mejorar continuamente esta estructura y
procesos.
 Proceso de gestión.
 Proceso de infraestructura.
 Proceso de mejora.
 Proceso de formación.
66
CAPITULO VI
METODOLOGÍAS DE DESARROLLO DE SOFTWARE
4.1. DESARROLLO DE SOFTWARE
“El desarrollo de software no es una tarea fácil. Prueba de ello es que
existen numerosas propuestas metodológicas que inciden en distintas
dimensiones del proceso de desarrollo.” [CITATION Ron \p 709 \l 3082 ]
Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor
al individuo, a la colaboración con el cliente y al desarrollo incremental del
software con iteraciones muy cortas. Este enfoque está mostrando su
efectividad en proyectos con requisitos muy cambiantes y cuando se
exige reducir drásticamente los tiempos de desarrollo pero manteniendo
una alta calidad. Las metodologías ágiles. Están revolucionando la
manera de producir software, y a la vez generando un amplio debate
entre sus seguidores y quien es por escepticismo o convencimiento no las
ven como alternativa para las metodologías tradicionales. Estas
propuestas han demostrado ser efectivas y necesarias en un gran
número de proyectos, pero también han presentado problemas en
muchos otros. Una posible mejora es incluir en los procesos de desarrollo
más actividades, más artefactos y más restricciones, basándose en los
puntos débiles detectados. Otra aproximación es centrarse en un objetivo

67
de décadas ha sido encontrar procesos y metodologías, que sean
sistemáticas, predecibles y repetibles, a fin de mejorar la productividad en
el desarrollo y la calidad del producto software.
La evolución de la disciplina de ingeniería del software ha traído consigo
propuestas diferentes para mejorar los resultados del proceso de
construcción. Las metodologías tradicionales haciendo énfasis en la
planificación y las metodologías ágiles haciendo énfasis en la
adaptabilidad del proceso, delinean las principales propuestas presentes.
4.2. DEFINICIÓN DE METODOLOGÍA
Una metodología para el desarrollo de software comprende los procesos
a seguir sistemáticamente para idear, implementar y mantener un
producto software desde que surge
La necesidad del producto hasta que cumplimos el objetivo por el cual fue
creado.
Una definición estándar de metodología puede ser el conjunto de
métodos que se utilizan en una determinada actividad con el fin de
formalizar la y optimizarla. Determina los pasosa seguir y cómo realizar
los para finalizar una tarea.
Si esto se aplica a la ingeniería del software, podemos destacar que una
metodología:
 Optimiza el proceso y el producto software.

 Métodos que guían en la planificación y en el desarrollo del software.
 Define qué hacer, cómo y cuándo durante todo el desarrollo y
mantenimiento de un proyecto.
68
Una metodología define una estrategia global para enfrentarse con el
proyecto. Entre los elementos que forman parte de una metodología se
pueden destacar:
 Fases: Tareas a realizar en cada fase.

 Productos: E/S de cada fase, documentos.
 Procedimientos y herramientas: Apoyo a la realización de cada
tarea.
 Criterios de evaluación: Del proceso y del producto. Saber si se han
logrado los objetivos.
El marco de trabajo de una metodología de desarrollo de software
consiste en:
 Una filosofía de desarrollo de software, con el enfoque o enfoques del
proceso de desarrollo de software.

 Múltiples herramientas, modelos y métodos para ayudar en el proceso
de desarrollo de software.
4.3. VENTAJAS DEL USO DE UNA METODOLOGÍA
Son muchas las ventajas que puede aportar el uso de una metodología. A
continuación se van a exponer algunas de ellas, clasificadas desde
distintos puntos de vista.
a. Desde el punto de vista de gestión:

 Facilitar la tarea de planificación.
 Facilitar la tarea del control y seguimiento de un proyecto.
 Mejorar la relación coste/beneficio.
 Optimizar el uso de recursos disponibles.
 Facilitar la evaluación de resultados y cumplimiento de los objetivos.
 Facilitar la comunicación efectiva entre usuarios y desarrolladores.
b. Desde el punto de vista de los ingenieros del software:
 Ayudará la comprensión del problema.
 Optimizar el conjunto y cada una de las fases del proceso de
desarrollo.
 Facilitar el mantenimiento del producto final.
69
 Permitir la reutilización de partes del producto.
c. Desde el punto de vista del cliente o usuario:
 Garantía de un determinado nivel de calidad en el producto final.
 Confianza en los plazos de tiempo fijados en la definición del
proyecto.
 Definir el ciclo de vida que más se adecue a las condiciones y
características del desarrollo.
4.4. METODOLOGÍAS TRADICIONALES VS. METODOLOGÍAS ÁGILES
4.4.1. METODOLOGÍA TRADICIONAL
Al inicio el desarrollo de software era artesanal en su totalidad, la
fuerte necesidad de mejorar el proceso y llevar los proyectos a la
meta deseada, tuvieron que importarse la concepción y
fundamentos de metodologías existentes en otras áreas y
adaptarlas al desarrollo de software. Esta nueva etapa de
adaptación contenía el desarrollo dividido en etapas de manera
secuencial que de algo mejoraba la necesidad latente en el campo
del software.
Entre las principales metodologías tradicionales tenemos los ya tan
conocidos RUP y MSF entre otros, que centran su atención en
llevar una documentación exhaustiva de todo el proyecto y centran
su atención en cumplir con un plan de proyecto, definido todo esto,
en la fase inicial del desarrollo del proyecto.
Otra de las características importantes dentro de este enfoque
tenemos los altos costos al implementar un cambio y al no ofrecer
una buena solución para proyectos donde el entorno es volátil.
70
Las metodologías tradicionales (formales) se focalizan en
documentación, planificación y procesos. (Plantillas, técnicas de
administración, revisiones, etc.), a continuación se detalla RUP uno
de los métodos más usados dentro de los métodos tradicionales
4.4.1.1. METODOLOGÍA RATIONAL UNIFIED PROCESS (RUP)
RUP es un proceso formal: Provee un acercamiento
disciplinado para asignar tareas y responsabilidades dentro
de una organización de desarrollo. Su objetivo es asegurar
la producción de software de alta calidad que satisfaga los
requerimientos de los usuarios finales (respetando
cronograma y presupuesto). Fue desarrollado por Rational
Software, y está integrado con toda la suite Rational de
herramientas. Puede ser adaptado y extendido para
satisfacer las necesidades de la organización que lo
adopte. (Customización). Es guiado por casos de uso y
centrado en la arquitectura, y utiliza UML como lenguaje de
notación.
RUP se divide en cuatro fases:
 Inicio (Define el alcance del proyecto)

 Elaboración (definición, análisis, diseño)
 Construcción (implementación)
 Transición (fin del proyecto y puesta en producción)
Ilustración 15: Proceso Unificado Rational
71
.
Fuente: https://es.wikipedia.org/wiki/Proceso Unificado
Racional
DESVENTAJAS
VENTAJAS
Ilustración 16: Ventajas y
 Evaluación en cada fase  La evaluación de riesgos
Desventajas del modelo que permite cambios de es compleja
objetivos  Excesiva flexibilidad para
(Rup)
 Funciona bien en algunos proyectos
proyectos de innovación.  Estamos poniendo a
 Es sencillo, ya que sigue nuestro cliente en una
los pasos intuitivos situación que puede ser
necesarios a la hora de muy incómoda para él.
desarrollar el software.  Nuestro cliente deberá ser 72
 Seguimiento detallado capaz de describir y
en cada una de las fases. entender a un gran nivel
de detalle para poder
acordar un alcance del
proyecto con él.
4.4.1.2. METODOLOGÍA MICROSOFT SOLUTION FRAMEWORK
(MSF)
“MSF es un compendio de las mejores prácticas en cuanto
a administración de proyectos se refiere. Más que una
metodología rígida de administración de
proyectos,”[ CITATION www161 \l 3082 ] MSF es una serie
de modelos que puede adaptarse a cualquier proyecto de
tecnología de información.
Todo proyecto es separado en cinco principales fases:
 Visión y Alcances.
 Planificación.
 Desarrollo.
 Estabilización.
 Implantación.
Ilustración 17: Microsoft Solution Framework (Msf)
73
Fuente: http://intuitive-bi.com.ar/nuestra-metodologia.html
a. Visión y Alcances:
La fase de visión y alcances trata uno de los requisitos
más fundamentales para el éxito del proyecto, la
unificación del equipo detrás de una visión común. El
equipo debe tener una visión clara de lo que quisiera
lograr para el cliente y ser capaz de indicarlo en
términos que motivarán a todo el equipo y al cliente. Se
definen los líderes y responsables del proyecto,
adicionalmente se identifican las metas y objetivos a
alcanzar; estas últimas se deben respetar durante la
ejecución del proyecto en su totalidad, y se realiza la
evaluación inicial de riesgos del proyecto.

b. Planificación:
Es en esta fase es cuando la mayor parte de la
planeación para el proyecto es terminada. El equipo
prepara las especificaciones funcionales, realiza el
74
proceso de diseño de la solución, y prepara los planes
de trabajo, estimaciones de costos y cronogramas de los
diferentes entregables del proyecto.
c. Desarrollo:
Durante esta fase el equipo realice la mayor parte de la
construcción de los componentes (tanto documentación
como código), sin embargo, se puede realizar algún
trabajo de desarrollo durante la etapa de estabilización
en respuesta a los resultados de las pruebas.
d. Estabilización:
En esta fase se conducen pruebas sobre la solución, las
pruebas de esta etapa enfatizan el uso y operación bajo
condiciones realistas.
e. Implantación:
Durante esta fase el equipo implanta la tecnología base
y los componentes relacionados, estabiliza la
instalación, traspasa el proyecto al personal soporte y
operaciones, y obtiene la aprobación final del cliente.
f. Modelo de roles:
El modelo de equipos de MSF (MSF team model) fue
desarrollado para compensar algunas de las
75
desventajas impuestas por las estructuras jerárquicas de
los equipos en los proyectos tradicionales.
4.4.2. METODOLOGÍAS ÁGILES
Luego de varias opiniones tanto a favor como en contra de las
metodologías tradicionales se genera un nuevo enfoque
denominado, métodos ágiles, que nace como respuesta a los
problemas detallados anteriormente y se basa en dos aspectos
puntuales, el retrasar las decisiones y la planificación adaptativa;
permitiendo potencia aún más el desarrollo de software a gran
escala.
Como resultado de esta nueva teoría se crea un Manifiesto Ágil
cuyas principales ideas son:
 Los individuos y las interacciones entre ellos son más importantes
que las herramientas y los procesos empleados.

 Es más importante crear un producto software que funcione que
escribir documentación exhaustiva.

 La colaboración con el cliente debe prevalecer sobre la
negociación de contratos.
 La capacidad de respuesta ante un cambio es más importante
que el seguimiento estricto de un plan.
Entre los principales métodos ágiles tenemos el XP (eXtreme
Programming), Scrum, Iconix, Cristal Methods, AUP entre otras.
Estas metodologías ponen de relevancia que la capacidad de
respuesta a un cambio es más importante que el seguimiento
estricto de un plan. Nos lo proponen porque para muchos clientes
76
esta flexibilidad será una ventaja competitiva y porque estar
preparados para el cambio significar reducir su coste.
Retrasar las decisiones y Planificación Adaptativa:
Es el eje en cual gira la metodología ágil, el retrasar las decisiones
tan como sea posible de manera responsable será ventajoso tanto
para el cliente como para la empresa, lo cual permite siempre
mantener una satisfacción en el cliente y por ende el éxito del
producto, las principales ventajas de retrasar las decisiones son:
 Reduce el número de decisiones de alta inversión que se toman.

 Reduce el número de cambios necesario en el proyecto.
 Reduce el coste del cambio.
La planificación adaptativa permite estar preparados para el cambio
ya que lo hemos introducido en nuestro proceso de desarrollo,
además hacer una planificación adaptativa consiste en tomar
decisiones a lo largo del proyecto, estaremos transformando el
proyecto en un conjunto de proyectos pequeños.
Esta planificación a corto plazo nos permitirá tener software
disponible para nuestros clientes y además ir aprendiendo del
feedback para hacer nuestra planificación más sensible, sea ante
inconvenientes que aceleren o retrasen nuestro producto. A
continuación se detalla el XP que es el más aceptado dentro del
desarrollo de SW.
4.4.2.1. METODOLOGIA EXTREME PROGRAMMING (XP)
77
Ilustración 18: Modelo Extreme Programin
Fuente:http://gmodulo.sourceforge.net/docs/html/manual/ch02
s04.html
Es la más destacada de los procesos ágiles de desarrollo
de software formulada por Kent Beck. La programación
extrema se diferencia de las metodologías tradicionales
principalmente en que pone más énfasis en la
adaptabilidad que en la previsibilidad.[CITATION PRE93 \p
70 \l 3082 ]
Los defensores de XP consideran que los cambios de
requisitos sobre la marcha son un aspecto natural,
inevitable e incluso deseable del desarrollo de proyectos.
Creen que ser capaz de adaptarse a los cambios de
requisitos en cualquier punto de la vida del proyecto es una
aproximación mejor y más realista que intentar definir
todos los requisitos al comienzo del proyecto e invertir
78
esfuerzos después en controlar los cambios en los
requisitos.
Las características fundamentales del método son:
 Desarrollo iterativo e incremental: pequeñas mejoras,
unas tras otras.

 Pruebas unitarias continuas, frecuentemente repetidas y
automatizadas, incluyendo pruebas de regresión. Se
aconseja escribir el código de la prueba antes de la
codificación.
 Programación por parejas: se recomienda que las tareas
de desarrollo se lleven a cabo por dos personas en un
mismo puesto. Se supone que la mayor calidad del
código escrito de esta manera -el código es revisado y
discutido mientras se escribe- es más importante que la
posible pérdida de productividad inmediata.

 Frecuente interacción del equipo de programación con el
cliente o usuario. Se recomienda que un representante
del cliente trabaje junto al equipo de desarrollo.

 Corrección de todos los errores antes de añadir nueva
funcionalidad. Hacer entregas frecuentes.

 Refactorización del código, es decir, reescribir ciertas
partes del código para aumentar su legibilidad y
Mantenibilidad pero sin modificar su comportamiento.
Las pruebas han de garantizar que en la refactorización
no se ha introducido ningún fallo.

 Propiedad del código compartida: en vez de dividir la
responsabilidad en el desarrollo de cada módulo en
79
grupos de trabajo distintos, este método promueve el
que todo el personal pueda corregir y extender cualquier
parte del proyecto. Las frecuentes pruebas de regresión
garantizan que los posibles errores serán detectados.

 Simplicidad en el código: es la mejor manera de que las
cosas funcionen. Cuando todo funcione se podrá añadir
funcionalidad si es necesario. La programación extrema
apuesta que en más sencillo hacer algo simple y tener
un poco de trabajo extra para cambiarlo si se requiere,
que realizar algo complicado y quizás nunca utilizarlo.
La simplicidad y la comunicación son extraordinariamente
complementarias. Con más comunicación resulta más fácil
identificar qué se debe y qué no se debe hacer. Mientras
más simple es el sistema, menos tendrá que comunicar
sobre este, lo que lleva a una comunicación más completa,
especialmente si se puede reducir el equipo de
programadores.
80
Ilustración 19: Ventajas y desventajas de metodologia (Xp)
VENTAJAS DESVENTAJAS
 Apropiado para  Es recomendable
entornos volátiles emplearlo solo en
 Estar preparados para proyectos a corto plazo.
el cambio, significa
reducir su coste.  Altas comisiones en
 Planificación más caso de fallar.
transparente para
nuestros clientes,
conocen las fechas
de entrega de
funcionalidades. Vital
para su negocio
 Permitirá definir en
cada iteración cuales
son los objetivos de
la siguiente
 Permite tener
realimentación de los
usuarios muy útil.
 La presión está a lo
largo de todo el
proyecto y no en una
entrega final.
4.4.2.2. METODOLOGÍA AUP (AGIL UNIFIED PROCESS)
El AUP es un acercamiento aerodinámico a desarrollo del
software basado en el Proceso Unificado Rational de IBM
(RUP), basado en disciplinas y entregables incrementales
con el tiempo.[CITATION PRE93 \p 149 \l 3082 ] El ciclo de
vida en proyectos grandes es serial mientras que en los
pequeños es iterativo.
81
Ilustración 20: Aup (Agil Unified Process)
Fuente: http://ingenieriadesoftware.mex.tl/63758_AUP.html
Las disciplinas de Aup son:
 Modelado
 Implementación
 Prueba
 Despliegue
 Administración de la configuración
 Administración o gerencia del Proyecto
 Entorno
4.4.2.3. METODOLOGÍA SCRUM
Scrum es un proceso ágil y liviano que sirve para
administrar y controlar el desarrollo de software. El
desarrollo se realiza en forma iterativa e incremental (una
iteración es un ciclo corto de construcción repetitivo). Cada
ciclo o iteración termina con una pieza de software
ejecutable que incorpora nueva funcionalidad. Las
iteraciones en general tienen una duración entre 2 y 4

82
semanas. Scrum se utiliza como marco para otras
prácticas de ingeniería de software como RUP o Extreme
Programming.
Scrum se focaliza en priorizar el trabajo en función del
valor que tenga para el negocio, maximizando la utilidad de
lo que se construye y el retorno de inversión. Está
diseñado especialmente para adaptarse a los cambios en
los requerimientos, por ejemplo en un mercado de alta
competitividad. Los requerimientos y las prioridades se
revisan y ajustan durante el proyecto en intervalos muy
cortos y regulares. De esta forma se puede adaptar en
tiempo real el producto que se está construyendo a las
necesidades del cliente. Se busca entregar software que
realmente resuelva las necesidades, aumentando la
satisfacción del cliente.
En Scrum, el equipo se focaliza en una única cosa:
construir software de calidad. Por el otro lado, la gestión de
un proyecto Scrum se focaliza en definir cuáles son las
características que debe tener el producto a construir (qué
construir, qué no y en qué orden) y en remover cualquier
obstáculo que pudiera entorpecer la tarea del equipo de
desarrollo. Se busca que los equipos sean lo más efectivos
y productivos posible.
Ilustración 21: Esquema de trabajo Scrum
83
Fuente: www.softeng.es /empresa /metodología scrum
Scrum tiene un conjunto de reglas muy pequeño y muy
simple y está basado en los principios de inspección
continua, adaptación, auto-gestión e innovación. El cliente
se entusiasma y se compromete con el proyecto dado que
ve crecer el producto iteración a iteración y encuentra las
herramientas para alinear el desarrollo con los objetivos de
negocio de su empresa.
Por otro lado, los desarrolladores encuentran un ámbito
propicio para desarrollar sus capacidades profesionales y
esto resulta en un incremento en la motivación de los
integrantes del equipo.
4.4.2.4. METODOLOGÍA ICONIX
Ilustración 22: Esquema de trabajo Iconix
84
Fuente: http://metodologiaiconix.blogspot.pe/
El proceso de ICONIX maneja casos de uso, como el RUP,
pero le falta mucho para llegar al nivel del RUP. También es
relativamente pequeño y firme, como XP, pero no desecha
el análisis y diseño que hace XP. Este proceso también
hace uso aerodinámico del UML mientras guarda un
enfoque afilado en el seguimiento de requisitos.
RESUMEN Y OPINIÓN PERSONAL
85
Esta investigación ayudará a generaciones futuras como base primordial
para el entendimiento de Ingeniería de Software.
Hoy en día todos comprendemos que las métricas de software cuestan
dinero y tiempo, y que deben ser usadas con moderación.
El desarrollo de Software es inherentemente diferente de las Ciencias
Naturales tales como la Física, por lo que sus Métricas son muchas menos
precisas para capturar lo que deben describir.
Muchos proyectos se han realizado sin demasiado control pero han
generado productos maravillosos tales como Google Earth o la Wikipedia.
Esto nos lleva a la desagradable conclusión que el control estricto es algo
que importa mucho en proyectos relativamente inútiles y mucho menos en
proyectos útiles. Sugiere que mientras más te enfoques en el control
aumenta la probabilidad de que estás trabajando en un proyecto que se
esfuerza por generar algo de valor relativamente menor.
Estoy llegando gradualmente a la conclusión que el momento de la
Ingeniería del Software vino y se marchó.
El desarrollo de software es y será siempre algo experimental. Lo
construcción real de software no es necesariamente experimental, pero sí lo
es su concepción. Allí deberíamos enfocar nuestros esfuerzos. Allí es donde
deberíamos haberlo hecho siempre.
KIKIYKUPA RIMARIYNIYKU
86
Kay maskariyqa llapa hamuq runakunatam yanapanqa, teqsin hina kaspa chay
inhiñirya ukun churanchaykunata.
Kunan punchaw hamutachwanmi kay ukun churanchaykuna tupuymi ancha
qoolqepaq chaynallata pachapaq chaymi allinllata hatallina.
Kay ukun churanchaykuna poqochinapaqmi hapipakuna mama pacha yachayta
imaynam pisica, ancha mana cheqan kasqanta qawaspa, chayna qawaspa
imayna kasqanta rimarinapaq.
Ancha llamkanapaq churanchaykunatam ruwarqaku mana allinta qawarispa,
ichaqa allin allintam orqoykunku chay Google Eart chaynallataq Wikipediata.
Kaymi apawanchik imayna mana allinta chaskinanchikpaq, chaymi ancha imapas
tukuyña qawayqa manam allinchu, apawanchil mana chaniyoq llamkay
churanchayman, allin imapas llamkanapaq chaymi maskariptinchik tarichwanchik
ancha llamakayninta hinaptin tarichwanchik anchata llamkachakan ichaqa
aschallata kallpata hatallin.
Chaymi ña hamutarini tukuyninpiqa kay inhiñirya Ukun churanchakuyqa
hamusqan hinallam ripukun.
SUMMARY AND PERSONAL OPINION
87
This research will help future generations as central to the understanding of
software engineering base.
Today we all understand that software metrics cost money and time, and
should be used sparingly.
Software development is inherently different from the natural sciences such
as physics, so your metrics are far less accurate to capture what to describe.
Many projects have been carried out without much control but have
generated wonderful products such as Google Earth or Wikipedia.
This brings us to the unpleasant conclusion that strict control is something
that matters a lot in relatively useless projects much less useful projects. He
suggests that the more you focus on the control increases the likelihood that
you are working on a project that strives to generate some relatively minor
value.
I am gradually coming to the conclusion that the time of Software
Engineering came and left.
Software development is and will always be something experimental. The
real building software is not necessarily experimental, but it is his conception.
There should focus our efforts. That's where we should have always done.
BIBLIOGRAFÍA
Boehm , B. (en 1986). Modelo espiral. Software Development.

88
C2.com/cgi/wiki. (10 de Abril de 2016). http://C2.com/cgi/wiki?
Sevenprinciplesofsoftwaredevelopment. Obtenido de http://C2.com/cgi/wiki?
Sevenprinciplesofsoftwaredevelopment.
datateca.unad.edu.co/. (16 de Abril de 2016). http://datateca.unad.edu.co/.
Obtenido de http://datateca.unad.edu.co/
Fritz , B. (2010). Ingenieria de Software. EE.UU.
Pires, Donald, “Manifiesto Ágil”, UCLA, (en línea). (2010 de Mayo de 2016).
www.manifiestoagile.com. Obtenido de http://www.manifiestoagile.com
Pressman, R. S. (2010). Ingeniería de Software un enfoque practico.
España: Séptima edición.
Ron , B. (1998). Software Engineering Methodology. Bogota: María Teresa
Zapata Terrazas.
www.gpicr.com/msf.aspx. (25 de Abril de 2016).
http://www.gpicr.com/msf.aspx. Obtenido de http://www.gpicr.com/msf.aspx
www.inteco.es. (15 de Mayo de 2016). http://www.inteco.es. Obtenido de
http://www.inteco.es.
www.sis.gob.pe/portal/index.html. (s.f.). www.sis.gob.pe/portal/index.html.
Obtenido de www.sis.gob.pe/portal/index.html
www.um.es/docencia/barzana. (Abril de 10 de 2016).
www.um.es/docencia/barzana/IAGP/IAGP2-Metodologias-de- desarrollo.html.
89
ANEXO
90
SISTEMA INTEGRADO DE ASEGURAMIENTO DEL SIS[ CITATION www \l 3082 ]
Acceso al sistema
LINK: PAGINA WEB
SIASIS.
Encontramos los FUAS

Información resumida de
observados que no
los
superaron el
productos del SIS
Las reglas de
consistencia.
Hacemos la consulta en línea del seguro y

De los acreditados para el intercambio
prestacional.
De los acreditados para el intercambio
prestacional.
91
PRODUCTOS DEL SEGURO INTEGRAL DE SALUD[ CITATION www \l 3082 ]
92
PROCESO PARA SOLICITA AFILIACIÓN
Solicita
afiliación
Tiene DNI
Tiene solo ESSALUD
Referir que su
atención debe ser en
Tiene
SI Dar de baja ESSALUD
NO ESSALUD y SIS
afiliación al
SIS
Tiene solo SIS Entregar ficha

Explicar los beneficios
que viene con su seguro impresa de estado
de seguro
Verificar tipo de
seguro de salud
o derecho a otro tipo
de seguro de salud
93
PROCESO DEL CIUDADNO QUE NO CUENTA CON NINGUN SEGURO DE SALUD
94
PROCESO DE REQUISITOS PARA SER AFILIADO AL SEGURO INTEGRAL DE SALUD
Afiliación temporal
CUMPLE CON REQUISITOS
de personas no
inscritas en el
RENIEC. (Validos 45
NO TIENE días)
DNI
 Personas en
situación de calle
acreditada por el
Ministerio de la
Mujer.
 Personas que
residan en centros
poblados
focalizados por el
MIDIS. Informar que debe
tramitar su DNI para
NO CUMPLE CON REQUISITOS la obtención de
seguro de salud
95
PROCESO DE AFILIACION DE GRUPO POBLACIONAL DETERMINADO POR
NORMA
96
PROCESOS DEL SEGURO INTEGRAL DE SALUD INDEPENDIENTE
97
PROCESOS DEL SEGURO INTEGRAL DE SALUD EMPRENDEDOR
98
PROCESOS DEL SEGURO INTEGRAL DE SALUD MICROEMPRESAS
99

Igenieria de Software

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Igenieria de Software

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD PARA EL DESARROLLO ANDINO

Anti hatun yachay wasi iskay simi yachachiypi umalliq

FACULTAD DE CIENCIAS E INGENIERÍA

EXAMEN DE SUFICIENCIA PROFESIONAL

LIRCAY – ANGARAES- HUANCAVELICA – PERÚ

En el presente trabajo monográfico que lleva por título “Ingeniería de

software” el cual es el resultado de muchas investigaciones a los principales

medios de información como son los libros, páginas de internet, artículos

electrónicos, revistas electrónicas, etc. Contiene tres capítulos, cuyas

descripciones genéricas son como sigue:

CAPITULO I. Se presenta una vista general sobre la definición de Ingeniería

de Software, su importancia, objetivo y así como el reto de la Ingeniería de

El CAPITULO II. En esta segunda parte de la monografía nos centraremos en

la definición de: producto de Software y también se determina las

características del Software así como los mitos del Software.

El CAPÍTULO III. En esta tercera parte de la monografía nos centraremos en

la definición de: Proceso de Software y también se determina las

características del Software así como los mitos del Software.

El CAPÍTULO VI. Se tiene un resumen de las Metodologías para el Desarrollo

de Software, considerando algunos modelos del proceso de desarrollo de

Es importante tomarse el tiempo necesario para conocer a nuestros clientes y

usuarios, así como su ambiente de trabajo. Esto, también ayuda a establecer

una buena relación de trabajo y comunicación entre el equipo de desarrollo y

requerimientos, pues ellos son los que deciden nuestro destino en el

proyecto, deciden si les gustamos o no y además financian el proyecto.

Como final de todo eso podemos exponer que el objetivo principal de la

Ingeniería de Software es lograr todo tipo de productos en calidad de

uso y de ejecución y que cumplir todos los requerimientos de cliente o

usuario, demostrar todas habilidades conjuntamente.

kaymi ancha llapa maskariykunapa aypasqan, llapallan maykunapi tarisqa,

chaynam liwrukuna, intirnit rapi, kallpalliwan ruwasqa, wanku kallpalli,

achapiwan. Kanmi kimsa rakipaynin, chay qawachwan llapa imankunata:

I RAKIPAY. Qawarichinchik llapa imanata hawallamanta Inhiñiryapa uku

churanchayninta, imakuna lloqsisqa hinallataq qawachinchik imayna

II RAKIPAY. Kay iskay ñeqen rakipaypim qawanchik imam inhiñirya ukun

churaychaynin kasqanta, imaynam puririn. Chaynallataq rikurun imaymana

puririyninkasqan chaynallataq imaynam miramurqa kasqanta.

III RAKIPAY. Imaymanaman huñusqam kachkan llapa maynin pusana ñan

chaynallataq imaynam chay ukun churanchaynin poqorichinapaq. Chaymi

mana pachawan yallichikunachu, qasillama llapa rantiqninchikkunata

suyana chaynallataq ñoqanchikmanta imapas orqoqta. Chaynataq maypim

llamkananchik kasqanta. Chaymi kaykuna anchata yanapan

llamkaqkunawan allin kananpaq.

VI RAKIPAY. Llapa rantiqninchikkunata suyana chaynallataq

ñoqanchikmanta imapas orqoqta. Chaynataq maypim llamkananchik

kasqanta. Chaymi kaykuna anchata yanapan llamkaqkunawan allin

Allin punim rantiqkuna chaymanta hapiriqkuna munakuyninkupi

llakarinanku, paykunam imayna kananchikta yachanku, chaynallataq

Tukunapaq, llapa ima nisqanchiktam qawachinanchik inhiñirya ukun

churanchasqapi, chaymi rantinanchik, armananchik llapa ima ichaqa

allinninta hinaspa rantiqpa llapa munasqanta apamunanchik hinaspa

qawachinanchik kusqalla atiyninta.

In this monographic work entitled "Software Engineering" which is the result

electronic articles, electronic journals, etc. It contains three chapters, whose

generic descriptions are as follows:

CHAPTER I. An overview of the definition of Software Engineering, its

importance, objective and the challenge of Software Engineering.

Software as well as the myths of the Software.

Software as well as the myths of the Software.

CHAPTER VI. There is a summary of the Methodologies for Software

Development, considering some models of the software development

relationship and communication between the development team and the

Engineering is to achieve all kinds of products in quality of use and