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.”
ii
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
iii
una buena relación de trabajo y comunicación entre el equipo de desarrollo y
los clientes.
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.
iv
CHINTISQA
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.
v
Allin punim rantiqkuna chaymanta hapiriqkuna munakuyninkupi llakarinanku,
paykunam imayna kananchikta yachanku, chaynallataq 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.
vi
SUMMARY
In this monographic work entitled "Software Engineering" which is the result
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
vii
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.
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.
viii
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
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.
ix
ÍNDICE
PORTADA
DEDICATORIA…………………………………………………………………………….…………………ii
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
ANÁLISIS DE REQUISITOS ......................................................................................16
ESPECIFICACIÓN .....................................................................................................16
DISEÑO Y ARQUITECTURA .....................................................................................17
PROGRAMACIÓN......................................................................................................17
PRUEBA .....................................................................................................................17
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

x
PROCESOS ...........................................................................................................24
1.10.1.1. IMPORTANCIA DE UN PROCESO...................................................................25
MÉTODO................................................................................................................27
HERRAMIENTAS ...................................................................................................28
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
CARACTERÍSTICAS DEL SOFTWARE ....................................................................33
APLICACIONES DEL SOFTWARE............................................................................34
MITOS DEL SOFTWARE ...........................................................................................35
ATRIBUTOS DE UN BUEN SOFTWARE ..................................................................40
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
CICLO DE VIDA .........................................................................................................44
TIPOS DE MODELO DE CICLO DE VIDA.................................................................46
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

xi
3.4. ISO/IEC 12207. ...............................................................................................................67
PROCESOS PRINCIPALES DEL CICLO DE VIDA. ..................................................67
PROCESOS DE APOYO AL CICLO DE VIDA. .........................................................68
PROCESOS ORGANIZATIVOS DEL CICLO DE VIDA. ............................................68
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
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
xii
Ì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
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
xiii
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” (Pressman, 2010, págs. 45-49).
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.
9
3. (Braude). Ingeniería de Software
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”. (Fritz , 2010, pág.
95)
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.
13
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.
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).

14
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
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.
15
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.
La ingeniería de software requiere llevar a cabo numerosas tareas, dentro
de etapas como las siguientes:
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.
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

16
especificaciones son más importantes para las interfaces externas,
que deben permanecer estables.
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 entidades
definidas en el análisis de requisitos en clases de diseño, obteniendo
un modelo cercano a la programación orientada a objetos.
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.
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
17
una buena práctica que las pruebas sean efectuadas por alguien
distinto al desarrollador que la programó.
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
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.” (Pressman, 2010, págs. 16-18)
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
18
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
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
19
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. 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
20
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.
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.
21
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
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
22
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.” (www.um.es/docencia/barzana, 2016).
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
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:
23
 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.
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 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

24
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
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

25
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
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
26
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
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.
27
 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.
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:
 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
28
 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 herramienta Nos va a facilitar muchas de las

de gestión de RRHH nos permitirá tareas, ahora que nuestra plantilla
automatizar muchas tareas. se ha visto incrementada.
29
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:” (Pressman, 2010, pág. 51)
 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 las actividades cotidianas
Porque
El
Software Afecta cualquier aspecto de nuestras vidas
es
importante
Está muy extendido en el comercio
30
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.
(Pressman, 2010, pág. 188)
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.
31
 El software se diseñaba a medida.
 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.
32
 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.
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” (Pressman, 2010, pág. 3)
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.
33
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.
APLICACIONES DEL SOFTWARE
El software tiene una gran amplitud de aplicaciones. A continuación
se relacionan:
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

34
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.
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.
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.
35
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?.
 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
36
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
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.
37
 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.
 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
38
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.
 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
39
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
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.
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.

40
 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.
COMPONENTES DEL SOFTWARE
El software se puede definir como el conjunto de tres componentes:
(www.inteco.es., 2016)
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
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.
41
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.
¿Qué os parece la herramienta El principal problema con el que

de gestión de RRHH que nos hemos encontrado es que no
estamos probando? nos han proporcionado un manual
de usuario.
42
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. (Pressman, 2010, pág. 26)
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 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.
43
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
Puntos SQA
Actividades de 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.
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
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
44
 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).
 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
45
los requisitos funcionales y de condiciones de realización
previamente establecidos.
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).
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
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
46
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.
47
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
 Diseño
 Construcción (Implementación o codificación)
 Integración
48
 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.
49
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
50
idea en la práctica, principalmente a causa de su 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.
51
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
llevadas a cabo en paralelo con las actividades de
desarrollo, y los técnicos de pruebas necesitan trabajar con

52
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
Realmente las etapas individuales del proceso pueden ser
53
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.
54
 Tiene poca flexibilidad y ajustar el alcance es difícil
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.

55
Ilustración 11: Modelo de ciclo de vida iterativo
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.
56
3.3.1.4. MODELO DE DESARROLLO INCREMENTAL.
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.
57
A. VENTAJAS.
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.
58
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
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.

59
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
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:
60
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:
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
61
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
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
62
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
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
63
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 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

64
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
A. VENTAJAS.
Entre las ventajas que ofrece este modelo se pueden
65
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.
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.
66
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 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.
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
67
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.
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
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
68
de vida, y para mejorar continuamente esta estructura y procesos.
 Proceso de gestión.
 Proceso de infraestructura.
 Proceso de mejora.
 Proceso de formación.
69
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.” (Ron , 1998, pág. 709) 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 de décadas ha sido encontrar
procesos y metodologías, que sean sistemáticas, predecibles y repetibles,
70
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.
71
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.

72
 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.
 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
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.
73
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.
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.

74
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
Fuente: https://es.wikipedia.org/wiki/Proceso Unificado
Racional
75
Ilustración 16: Ventajas y Desventajas del modelo (Rup)
DESVENTAJAS
VENTAJAS
 Evaluación en cada fase  La evaluación de riesgos

que permite cambios de es compleja
objetivos  Excesiva flexibilidad para
 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á
 Seguimiento detallado ser 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,”
(www.gpicr.com/msf.aspx, 2016) 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.
76
 Estabilización.
 Implantación.
Ilustración 17: Microsoft Solution Framework (Msf)
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.
77
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 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.
78
f. Modelo de roles:
El modelo de equipos de MSF (MSF team model) fue
desarrollado para compensar algunas de las 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.
79
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 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
80
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)
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. (Pressman, 2010, pág. 70)
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
81
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 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
82
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
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.
83
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 caso
 Planificación más 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. (Pressman, 2010, pág. 149) El ciclo de vida
en proyectos grandes es serial mientras que en los
pequeños es iterativo.
84
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
85
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 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
86
desarrollo. Se busca que los equipos sean lo más efectivos
y productivos posible.
Ilustración 21: Esquema de trabajo Scrum
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.
87
4.4.2.4. METODOLOGÍA ICONIX
Ilustración 22: Esquema de trabajo Iconix
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.
88
RESUMEN Y OPINIÓN PERSONAL
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.

89
KIKIYKUPA RIMARIYNIYKU
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.
90
SUMMARY AND PERSONAL OPINION
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.
91
BIBLIOGRAFÍA
Boehm , B. (en 1986). Modelo espiral. Software Development.
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.
92
ANEXO
93
SISTEMA INTEGRADO DE ASEGURAMIENTO DEL SIS (www.sis.gob.pe/portal/index.html, s.f.)
Acceso al sistema
LINK: PAGINA WEB SIASIS.
http://www.sis.go
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.
94
PRODUCTOS DEL SEGURO INTEGRAL DE SALUD (www.sis.gob.pe/portal/index.html, s.f.)
95
PROCESO PARA SOLICITA AFILIACIÓN
Solicita
afiliación
Tiene DNI Tiene solo ESSALUD

Referir que su
atención debe ser en
Tiene ESSALUD
SI ESSALUD y SIS Dar de baja
NO
afiliación al
SIS
Tiene solo SIS Explicar los beneficios Entregar ficha

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
96
PROCESO DEL CIUDADNO QUE NO CUENTA CON NINGUN SEGURO DE SALUD
97
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
NO TIENE 45 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.
 Recién nacidos hijos asegurados del SIS.
 Gestantes y niños menores de 5 años.
Informar que debe

tramitar su DNI para
NO CUMPLE CON REQUISITOS la obtención de
seguro de salud
98
PROCESO DE AFILIACION DE GRUPO POBLACIONAL DETERMINADO POR
NORMA
99
PROCESOS DEL SEGURO INTEGRAL DE SALUD INDEPENDIENTE
100
PROCESOS DEL SEGURO INTEGRAL DE SALUD EMPRENDEDOR
101
PROCESOS DEL SEGURO INTEGRAL DE SALUD MICROEMPRESAS
102

Igenieria de Software

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Igenieria de Software

Cargado por

Copyright:

Formatos disponibles

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

Es necesario que los clientes y usuarios participen en la definición de sus

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.

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

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

paykunam imayna kananchikta yachanku, chaynallataq niwanchik

munawanchikchu icha manachu chyanallataq llakanapaq qollqeta

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

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.

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 execution