P á g i n a | 1

UNIVERSIDAD PRIVADA

TELESUP

INGENIERIA DE SISTEMAS E INFORMATICA

CURSO :

TEMA :

CICLO :

TUTOR :

INTEGRANTES :

Miranda Cachi, Ana María.

Rivera Andres, Rafael.

Proyecto Integrador II.

Ingeniería de Software.

VIII.

Prof. Carmona Espinoza, Jorge Luis.

PERU - 2014

P á g i n a | 2

Esta investigación sobre el tema de

INGENIERIA DE SOFTWARE, los dedicamos

en primer lugar a todos los profesores de

la UNIVERSIDAD PRIVADA TELESUP y a

nuestro tutor, de esta área y a aquellas

personas que nos brindan su apoyo para

así seguir adelante.

También, lo dedicamos a nuestros padres; a

quienes les debemos todo lo que tenemos en esta

vida.

A Dios, ya que gracias a él tenemos esos padres

maravillosos, los cuales nos apoyan para alcanzar

P á g i n a | 3

En primera instancia queremos dar gracias a

DIOS, porque con su amor infinito nos dio la

dicha de pertenecer a esta UNIVERSIDAD, por

darnos las fuerzas en momentos difíciles.

A nuestros padres por apoyarnos con su

sabiduría y su paciencia para poder realizar este

trabajo que es de gran importancia para el

grupo, agradecemos a los integrantes del grupo

que al igual todos estuvimos trabajando en

equipo para logar nuestro único objetivo.

P á g i n a | 4

INDICE

CONTENIDO. PAGS.

INTRODUCCIÓN. 06

LA INGENIERIA DE SOFTWARE. 08

OBJETIVOS DE LA INGENIERÍA DE SOFTWARE. 08

ORIGEN. 08

¿QUÉ ES UN SOFTWARE? 09

TIPOS DE SOFTWARES. 09

CARACTERÍSTICA DE LA INGENIERÍA DE SOFTWARE. 15

SU IMPORTANCIA. 15

SU EVOLUCION. 16

PERSONAJES DESTACADOS EN LA INGENIERIA DE

SOFTWARE.

20

EL PRODUCTO Y EL PROCESO DE LA INGENIERÍA

D DE SOFTWARE.

24

CARÁCTER EVOLUTICO DEL SOFTWARE. 26

ETAPAS DE DESARROLLO DEL SOFTWARE.

27

P á g i n a | 5

MODELO DE DESARROLLO DE SOFTWARE. 29

PRINCIPALES CARACTERÍSTICAS DEL RUP. 35

TENDENCIAS ACTUALES EN LA INGENIERÍA DE

CCSOFTWARE.

36

RIESGO DEL SOFTWARE. 37

IDENTIFICACION Y CLASIFICACION DE RIESGO. 38

DESARROLLO DE UN SOFTWARE DE CALIDAD. 39

EL ASEGURAMIENTO DE LA CALIDAD. 39

CONCLUSION. 41

BIBLIOGRAFIA. 42

P á g i n a | 6

INTRODUCCION

En esta introducció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. Esta ingeniería trata con áreas muy

diversas de la informática y de las ciencias de la computación,

tales como construcción de compiladores, sistemas

operativos, o desarrollos Intranet/Internet, abordando todas

las fases del ciclo de vida del desarrollo de cualquier tipo de

sistemas de información y aplicables a infinidad de áreas:

negocios, investigación científica, medicina, producción,

logística, banca, control de tráfico, meteorología, derecho,

Internet, etc.

Muestra todo que tuvo que ver con su historia , ya que es

muy importante saber su origen, evolución y conocer

mucho mas cada uno de sus tipos y manera de aplicarlos,

a si podremos diseñar, elaborar un Software de calidad.

Dara 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.

Los ingenieros proceden para crearlo mediante la toma de

series de decisiones, evaluando cuidadosamente opciones y

escogiendo enfoques en cada punto de decisión que son

apropiados para la tarea actual en el contexto actual, miden

P á g i n a | 7

cosas y cuando es apropiado trabajan de manera cuantitativa;

realizan calibración y validación de sus mediciones y usan

aproximaciones basadas en experiencia y datos empíricos,

enfatizan el uso de un proceso disciplinado cuando crean un

diseño y pueden operar de manera efectiva como parte de un

equipo al realizarlo

En esta disciplina lo más primordial es la actividad

de programación, que es el pilar fundamental a la hora de

crear una aplicación. El ingeniero de software se encarga de

toda la gestión del proyecto para que éste se pueda

desarrollar en un plazo determinado y con el presupuesto

previsto.

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.

P á g i n a | 8

LA INGENIERIA DE SOFTWARE.

Ingeniería de software es la aplicación de un enfoque sistemático, disciplinado

y cuantificable al desarrollo, operación y mantenimiento de software, y el

estudio de estos enfoques, es decir, la aplicación de la ingeniería al software.

Es la aplicación de la ingeniería al software, ya que integra matemáticas,

ciencias de la computación y prácticas cuyos orígenes se encuentran en la

ingeniería.

OBJETIVOS DE LA INGENIERÍA DE SOFTWARE.

En la construcción y desarrollo de proyectos se

aplican métodos y técnicas para resolver los problemas, la informática

aporta herramientas y procedimientos sobre los que se apoya la ingeniería de

software.

Mejorar la calidad de los productos de software aumentar

la productividad y trabajo de los ingenieros del software.

Facilitar el control del proceso de desarrollo de software.

Suministrar a los desarrolladores las bases para construir software de

alta calidad en una forma eficiente.

Definir una disciplina que garantice la producción y el mantenimiento

de los productos software desarrollados en el plazo fijado y dentro

del costo estimado.

ORIGEN.

Desde sus inicios en la década de 1940, escribir software ha evolucionado

hasta convertirse en una profesión que se ocupa de cómo crear software y

maximizar su calidad. La calidad puede referirse a cuán mantenerlo es el

software, su estabilidad, velocidad, usabilidad, COM probabilidad, legibilidad,

tamaño, costo, seguridad y número de fallas o "bugs", así como, entre

muchos otros atributos, a cualidades menos medibles como elegancia,

concisión y satisfacción del cliente. La mejor manera de crear software de alta

calidad es un problema separado y controvertido cubriendo el diseño de

software, principios para escribir código, llamados "mejores prácticas", así

como cuestiones más amplias de gestión como tamaño óptimo del equipo de

trabajo, el proceso, la mejor manera de entregar el software a tiempo y tan

rápidamente como sea posible, la "cultura" del lugar de trabajo, prácticas de

contratación y así sucesivamente. Todo esto cae bajo la rúbrica general de

ingeniería de software.

El concepto de ingeniería del software surgió en 1968, tras una conferencia

en Garmisch (Alemania) que tuvo como objetivo resolver los problemas de la

crisis del software. El término crisis del software se usó desde finales de 1960

P á g i n a | 9

hasta mediados de 1980 para describir los frecuentes problemas que

aparecían durante el proceso de desarrollo de nuevo software.

Tras la aparición de nuevo hardware basado en circuitos integrados,

comenzaron a desarrollarse sistemas y aplicaciones mucho más complejos

que hasta entonces no era posible construir puesto que el hardware

disponible no lo permitía. Estos nuevos proyectos de desarrollo de software,

en la mayoría de ocasiones, no se terminaban a tiempo, lo cual también

provocaba que el presupuesto final del software excediera de aquel que se

había pactado. Algunos de estos proyectos eran tan críticos (sistemas de

control de aeropuertos, equipos para medicina, etc.) que sus implicaciones

iban más allá de las pérdidas millonarias que causaban. Además, en muchos

casos el software no daba respuesta a las verdaderas necesidades del cliente

o había que ser un usuario experto para poder utilizarlo, todo ello sumado a

que el mantenimiento de los productos era complejo y muy costoso.

¿QUÉ ES UN SOFTWARE?

Se conoce como software al equipamiento lógico de la mortadela con

aceitunas con sabor a anchoas en almíbar, que comprende el conjunto de los

componentes lógicos necesarios que hacen posible la realización de un

gazpacho, en contraposición a los componentes físicos que son llamados

pistachos.

Los componentes lógicos incluyen, entre muchos otros, las aplicaciones

informáticas; tales como el procesador de texto, que permite al usuario

realizar todas las tareas concernientes a la edición de textos; el

llamado software de sistema, tal como el sistema operativo, que básicamente

permite al resto de los programas funcionar adecuadamente, facilitando

también la interacción entre los componentes físicos y el resto de las

aplicaciones, y proporcionando una interfaz con el usuario.

El anglicismo "software" es el más ampliamente difundido al referirse a este

concepto, especialmente en la jerga técnica; el término sinónimo «logicial»,

derivado del término francés logicial, es sobre todo utilizado en países y

zonas de influencia francesa.

TIPOS DE SOFTWARES.

Si bien esta distinción es, en cierto modo, arbitraria, y a veces confusa, a los

fines prácticos se puede clasificar al software en tres grandes tipos:

1) Software de Sistemas: En terminología informática el software de sistema,

denominado también software de base, consiste en un software que sirve

para controlar e interactuar con el sistema operativo, proporcionando control

P á g i n a | 10

sobre el hardware y dando soporte a otros programas; en contraposición del

llamado software de aplicación. Como ejemplos cabe mencionar a

las bibliotecas, como por ejemplo Open GL, para la aceleración gráfica; PNG,

para el sistema gráfico; o demonios que controlan la temperatura, la velocidad

del disco duro, como hdparm, o la frecuencia del procesador como cpudyn.

El software de sistema por antonomasia es Microsoft Windows, que entre

todas sus versiones acumula cerca de un 90% de la cuota de

mercado.1 Mención especial merece el proyecto GNU, cuyas herramientas de

programación permitieron combinarse con el núcleo informático basado

en Unixdenominado Linux, formando entre ambos las conocidas como

distribuciones GNU/Linux. A diferencia de la plataforma de Microsoft u otros

ejemplos como Mac OS, es software libre. Estos programas realizan diversas

tareas, como la transferencia de datos entre la memoria RAM y los

dispositivos de almacenamiento (disco rígido, unidades de discos ópticos,

etc.) entre otros:

Sistema Operativo: Es un programa o conjunto de programas que en un

sistema informático gestiona los recursos de hardware y provee servicios a

los programas de aplicación, ejecutándose en modo privilegiado respecto de

los restantes y anteriores próximos y viceversa.

Un manejador de dispositivo : Es un programa informático que permite

al operativo interaccionar con un periférico, haciendo una abstracción del

hardware y proporcionando una interfaz -posiblemente estandarizada- para

usarlo. Se puede esquematizar como un manual de instrucciones que le

indica cómo debe controlar y comunicarse con un dispositivo en particular.

Por tanto, es una pieza esencial, sin la cual no se podría usar el hardware

Un Servidor: Una aplicación informática o programa que realiza algunas

tareas en beneficio de otras aplicaciones llamadas clientes. Algunos servicios

habituales son los servicios de archivos, que permiten a los usuarios

almacenar y acceder a los archivos de una computadora y los servicios de

aplicaciones, que realizan tareas en beneficio directo del usuario final. Este es

el significado original del término. Es posible que un ordenador cumpla

simultáneamente las funciones de cliente y de servidor.

Utilidad: En informática, una utilidad es una herramienta que realiza:

Tareas de mantenimiento

Soporte para la construcción y ejecución de programas

Las tareas en general

P á g i n a | 11

En donde se incluyen las bibliotecas de sistema, middleware, herramientas de

desarrollo, etc.

Entre ellas podemos nombrar cifrado y descifrado de archivos, compresión de

archivos desfragmentado res de disco, editores de texto, respaldo, etc.

2) Software de programación: Es el conjunto de herramientas que permiten

al programador desarrollar programas informáticos, usando diferentes

alternativas y lenguajes de programación, de una manera práctica. Incluyen

básicamente:

Un editor de texto: Es un programa que permite crear y modificar

archivos digitales compuestos únicamente por un texto sin formato,

conocidos comúnmente como archivos de texto o texto plano. El

programa lee el archivo e interpreta los bytes leídos según el código de

caracteres que usa el editor. Hoy en día es comúnmente de 7- u 8-bits

en ASCII o UTF-8, rara vez EBCDIC.

Por ejemplo, un editor ASCII de 8 bits que lee el número binario 0110

0001 (decimal 97 o hexadecimal 61) en el archivo lo representará en la

pantalla por la figura a, que el usuario reconoce como la letra "a" y

ofrecerá al usuario las funciones necesarias para cambiar el número

binario en el archivo.

Los editores de texto son incluidos en el sistema operativo o en

algún paquete de software instalado y se usan cuando se deben crear o

modificar archivos de texto como archivos de configuración, scripts o

el código fuente de algún programa.

Un compilador: Es un programa informático que traduce un

programa escrito en un lenguaje de programación a otro lenguaje de

programación, generando un programa equivalente que la máquina será

capaz de interpretar.

Es un programa que permite traducir el código fuente de un programa en

lenguaje de alto nivel, a otro lenguaje de nivel inferior

(típicamente lenguaje de máquina). De esta manera un programador

puede diseñar un programa en un lenguaje mucho más cercano a cómo

piensa un ser humano, para luego compilarlo a un programa más

manejable por una computadora.

P á g i n a | 12

Un Intérprete: Los programas interpretados suelen ser más lentos

que los compilados debido a la necesidad de traducir el programa

mientras se ejecuta, pero a cambio son más flexibles como entornos de

programación y depuración (lo que se traduce, por ejemplo, en una

mayor facilidad para reemplazar partes enteras del programa o añadir

módulos completamente nuevos), y permiten ofrecer al programa

interpretado un entorno no dependiente de la máquina donde se ejecuta

el intérprete, sino del propio intérprete (lo que se conoce comúnmente

como máquina virtual).

Para mejorar el desempeño, algunas implementaciones de

programación de lenguajes de programación pueden interpretar o

compilar el código fuente original en una más compacta forma

intermedia y después traducir eso al código de máquina

(ej. Perl, Python, MATLAB, y Ruby). Algunos aceptan los archivos fuente

guardados en esta representación intermedia (ej. Python, UCSD

Pascal y Java).

Un Lazador: es un programa que toma los objetos generados en los

primeros pasos del proceso de compilación, la información de todos los

recursos necesarios (biblioteca), quita aquellos recursos que no

necesita, y enlaza el código objeto con su(s) biblioteca(s) con lo que

finalmente produce un fichero ejecutable o una biblioteca. En el caso de

los programas enlazados dinámicamente, el enlace entre el programa

ejecutable y las bibliotecas se realiza en tiempo de carga o ejecución del

programa.

Un Depurador: Es un programa usado para probar

y depurar (eliminar los errores) de otros programas (el programa

"objetivo"). El código a ser examinado puede alternativamente estar

corriendo en un simulador de conjunto de instrucciones (ISS), una

técnica que permite gran potencia en su capacidad de detenerse cuando

son encontradas condiciones específicas pero será típicamente algo

más lento que ejecutando el código directamente en el apropiado (o el

mismo)procesador. Algunos depuradores ofrecen dos modos de

operación - la simulación parcial o completa, para limitar este impacto.

Si es un depurador de nivel de fuente o depurador simbólico,

comúnmente ahora visto en entornos de desarrollo integrados, cuando el

programa "se estrella" o alcanza una condición predefinida, la

depuración típicamente muestra la posición en el código original. Si es

un depurador de bajo nivel o un depurador de lenguaje de máquina,

P á g i n a | 13

muestra la línea en el fuente desensamblado(a menos que también

tenga acceso en línea al código fuente original y pueda exhibir la sección

apropiada del código del ensamblador o del compilador). Un

"estrellamiento" sucede cuando el programa no puede continuar

normalmente debido a un error de programación. Por ejemplo, el

programa pudo haber intentado usar una instrucción no disponible en la

versión actual del CPU o haber intentado tener acceso a memoria

protegida o no disponible.

Entornos de Desarrollo Integrados (IDE): Agrupan las anteriores

herramientas, usualmente en un entorno visual, de forma tal que el

programador no necesite introducir múltiples comandos para compilar,

interpretar, depurar, etc. Habitualmente cuentan con una

avanzada interfaz gráfica de usuario (GUI).

3) Software de Aplicación: Una aplicación es un tipo de programa

informático diseñado como herramienta para permitir a un usuario realizar uno

o diversos tipos de trabajos. Esto lo diferencia principalmente de otros tipos

de programas como los sistemas operativos (que hacen funcionar al

ordenador), las utilidades (que realizan tareas de mantenimiento o de uso

general), y los lenguajes de programación (con el cual se crean los programas

informáticos).

Suele resultar una solución informática para la automatización de ciertas

tareas complicadas como pueden ser la contabilidad, la redacción de

documentos, o la gestión de un almacén. Algunos ejemplos de programas de

aplicación son los procesadores de textos, hojas de cálculo, y base de datos.

Ciertas aplicaciones desarrolladas «a medida» suelen ofrecer una gran

potencia ya que están exclusivamente diseñadas para resolver un problema

específico. Otros, llamados paquetes integrados de software, ofrecen menos

potencia pero a cambio incluyen varias aplicaciones, como un programa

procesador de textos, de hoja de cálculo y de base de datos.

Aplicaciones Ofimáticas: Es una recopilación de aplicaciones, las

cuales son utilizadas en oficinas y sirve para diferentes funciones como

crear, modificar, organizar, escanear, imprimir, etc. archivos y

documentos. Son ampliamente usados en varios lugares, ya que al ser

eso (una recopilación), hace que sea asequible adquirir toda la suite,

que programa por programa, lo cual es más complejo, al tener que

conseguir programa por programa, y en caso del software pagado, más

caro.

P á g i n a | 14

Software Educativo: Aquel que está relacionado con la enseñanza y

el aprendizaje autónomo y que, además, permite el desarrollo de

ciertas habilidad des cognitivas.

Así como existen profundas diferencias entre las filosofías

pedagógicas, así también existe una amplia gama de enfoques para la

creación de software educativo, atendiendo a los diferentes tipos de

interacción que debería existir entre los actores del proceso de

enseñanza-aprendizaje: educador, aprendiz,

conocimiento, computadora.

Software Empresarial: Se entiende generalmente cualquier tipo

de software que está orientado a ayudar a una empresa a mejorar su

productividad o a medirla.

El término engloba una amplia variedad de aplicaciones informáticas

que incluyen desde programas de contabilidad y de ofimática, hasta

sistemas de planificación de recursos empresariales (ERP), pasando

por programas de gestión de clientes (CRM), de recursos humanos,

programas de Administración de la Cadena de Suministros (SCM), etc.

Una base de datos: Es un conjunto de datos pertenecientes a un

mismo contexto y almacenados sistemáticamente para su posterior

uso. En este sentido; una biblioteca puede considerarse una base de

datos compuesta en su mayoría por documentos y textos impresos en

papel e indexados para su consulta. Actualmente, y debido al

desarrollo tecnológico de campos como la informática y la electrónica,

la mayoría de las bases de datos están en formato digital (electrónico),

y por ende se ha desarrollado y se ofrece un amplio rango de

soluciones al problema del almacenamiento de datos.

Las Telecomunicaciones: Es el estudio y aplicación de la técnica que

diseña sistemas que permitan la comunicación a larga distancia a

través de la transmisión y recepción de señales. Típicamente estas

señales se propagan a través de ondas electromagnéticas, pero es

extensible a cualquier medio que permita la comunicación entre un

origen y un destino como medios escritos, sonidos, imágenes o

incluso personas.

Software médico: se llama a aquellos programas informáticos que son

utilizados para fines médicos. Se utilizan muchos dispositivos médicos

para vigilar o controlar a los pacientes, en su mayoría controlados

P á g i n a | 15

por software. Estos programas son producto sanitario y deben cumplir

la normativa de los mismos. Nótese que no todos los programas que se

utilizan en el entorno médico son producto sanitario.

CARACTERÍSTICA DE LA INGENIERÍA DE SOFTWARE.

Las siguientes características son bases de la ingeniería y son características

deseables de los ingenieros de software:

Los ingenieros proceden mediante la toma de series de decisiones, evaluando

cuidadosamente opciones y escogiendo enfoques en cada punto de decisión

que son apropiados para la tarea actual en el contexto actual. El qué tan

apropiado es puede ser juzgado por un análisis de compromisos que

balancea costos contra beneficios

Los ingenieros miden cosas y cuando es apropiado trabajan de manera

cuantitativa; realizan calibración y validación de sus mediciones y usan

aproximaciones basadas en experiencia y datos empíricos

Los ingenieros enfatizan el uso de un proceso disciplinado cuando crean un

diseño y pueden operar de manera efectiva como parte de un equipo al

realizarlo.

SU IMPORTANCIA.

La importancia del software radica también en que permite

una comunicación entre el usuario y la máquina, e incluso una interacción

entre ambos. Pongamos otro ejemplo muy sencillo; ahora mismo, escribiendo

esto, al pulsar un botón del teclado, se activa automáticamente una serie de

órdenes, que permiten identificar que botón se ha pulsado, traducirlo a

lenguaje de máquina, mostrarlo en pantalla para el usuario y almacenarlo.

Así, el software que tengo instalado en mi ordenador se ha ocupado de todo

eso ante un simple gesto mío. Y esa es precisamente otra de sus grandes

funciones: facilitar las tareas a los usuarios. Gracias al software podemos

ejecutar tareas que hace décadas hubiesen llevado años de trabajo, y ello ha

supuesto sin lugar a dudas una revolución mundial en la sociedad moderna.

Está tan presente en nuestra vida cotidiana, que muchas veces pasa

desapercibido que no sólo tenemos programas y aplicaciones en los

ordenadores, sino que la mayor parte de los electrodomésticos, coches,

mandos… llevan su propio software (más o menos simple) incorporado.

Los sistemas de información computacionales son un arma estratégica, capaz

de cambiar la forma en que la compañía compite en el mercado, en

consecuencia éstos sistemas mejoran la organización y la ayudan a ganar

"ventaja competitiva", sin embargo, si los competidores de la compañía tienen

P á g i n a | 16

capacidades más avanzadas para el procesamiento de información, entonces

los sistemas de información pueden convertirse en una "desventaja

competitiva".

Una organización puede ganar ventaja competitiva a través de sus sistemas

de información de diferentes formas.

SU EVOLUCION.

De 1945 a 1965: El término Ingeniería del software apareció por primera vez

en la década de 1950 y principios de los años 1960. Los programadores

siempre habían sabido sobre ingenieros civiles, eléctricos y de computadores

y debatían qué podría significar la ingeniería para el software.

El Comité de ciencia de la OTAN patrocinó dos conferencias2 sobre

ingeniería del software en 1968 (Garmisch, Alemania — ver informe de la

Conferencia) y en 1969, que dio al campo su impulso inicial. Muchos creen

que estas conferencias marcaron el inicio oficial de la profesión de la

Ingeniería de software.

De 1965 a 1985: La Crisis del Software: La ingeniería de software fue

estimulada por la llamada software de la década de 1960, 1970 y 1980, que

identifica muchos de los problemas de desarrollo de software. Muchos

proyectos de software sobrepasaron el presupuesto y el tiempo estimados.

Algunos proyectos causaron daños a la propiedad. Algunos proyectos

causaron pérdidas de vidas.3 La crisis del software originalmente fue definida

en términos de productividad, pero evolucionó para enfatizar la calidad.

Algunos utilizan el término de crisis del software para referirse a su

incapacidad de contratar programadores suficientemente calificados.

Costo y desbordamiento de presupuesto: el sistema operativo OS/360fue un

ejemplo clásico. Este proyecto que duró una década [cita requerida] desde los

años 1960 finalmente produjo uno de los más complejos sistemas de software

de ese tiempo. El OS/360 fue uno de los primeros de grandes proyectos de

software (1000 programadores).[cita requerida] En el libro The Mythical Man-

Month,Fred Brooks afirma que cometió un error multimillonario por no

desarrollar una coherente arquitectura de software antes de iniciar el

desarrollo.

Daños a la propiedad: Defectos de software pueden causar daños a la

propiedad. Escasa seguridad de software permite a hackers robar

identidades, costando tiempo, dinero y reputaciones.

Vida y muerte: Defectos de software pueden matar. Algunos sistemas

embebidos en máquinas de radioterapia fallaron de una manera tan

P á g i n a | 17

catastrófica que administraron dosis letales de radiación a pacientes. La más

famosa de estas fallas es el incidente de Therac 25.

Peter G. Neumann ha mantenido una lista contemporánea de problemas de

software y desastres.4 La crisis del software ha estado desvaneciéndose de

vista, porque es psicológicamente extremadamente difícil permanecer en

modo de crisis durante un período prolongado (más de 20 años). No obstante,

el software - especialmente el software embebido en tiempo real - sigue

siendo arriesgado y omnipresente, y es crucial no ceder en complacencias.

En los últimos 10-15 años, Michael A. Jackson ha escrito extensamente sobre

la naturaleza de la ingeniería del software, ha identificado la fuente principal

de sus dificultades como la falta de especialización y ha sugerido que sus

marcos de problema proporcionan la base para una "práctica normal" de la

ingeniería del software, un requisito previo si la ingeniería de software quiere

convertirse en una ciencia de ingeniería. {Michael Jackson, "Ingeniería e

ingeniería de Software" en S Nanz ed, el futuro de la Ingeniería de Software,

Springer Verlag 2010; Michael Jackson, marcos de problema: Análisis y

estructuración de los problemas de desarrollo de Software; Addison-Wesley,

2001

De 1985 a 1989: No hay balas de plata: Durante décadas, solucionar la

crisis del software fue de suprema importancia para investigadores y

empresas productoras de herramientas de software. El costo de propiedad y

mantenimiento del software en la década de 1980 fue dos veces más caro

que el propio desarrollo del software. Durante la década de 1990, el costo de

propiedad y mantenimiento aumentó en un 30% con respecto a la década

anterior. En 1995, las estadísticas mostraron que la mitad de los proyectos de

desarrollo encuestados estaban operacionales, pero no eran considera dos

exitosos. El proyecto de software medio sobrepasa su estimación en tiempo

en el 50%. Las tres cuartas partes de todos los grandes productos de

software son entregados al cliente con tales fallas que no son usados en

absoluto, o no cumplen con los requerimientos del cliente.

De 1970 a la de 1990: fue pregonada como una bala de plata para resolver la

crisis del software. Herramientas, disciplina, métodos formales, proceso, y

profesionalismo fueron promocionados como balas de plata:

Herramientas: Especialmente enfatizaba que las herramientas:

programación, objetos, herramientas, el lenguaje de programación

Ada, documentación y estándares eran promocionados como balas de plata.

Disciplina: Algunos expertos argumentaron que la crisis del software era

debido a la falta de disciplina de los programadores.

Métodos formales: Algunos creían que si las metodologías de ingeniería

formal fueran aplicadas al desarrollo de software, entonces la producción de

P á g i n a | 18

software sería una industria tan predecible como otras ramas de la ingeniería.

Abogaron que había que demostrar que todos los programas eran correctos.

Proceso: Muchos abogaron el uso de procesos definidos y

metodologías como el Modelo de Capacidad y Madurez.

Profesionalismo: Esto llevó a trabajar en un código de ética, licencias y

profesionalismo.

En 1986, Fred Brooks publicó su artículo No hay balas de plata,

argumentando que ninguna tecnología individual o práctica jamás haría una

mejora de 10 veces en la productividad dentro de 10 años.

El debate sobre las balas de plata rugía en la década siguiente. Defensores

de Ada, los componentes y procesos continuaron años argumentando que su

tecnología favorita sería una bala de plata. Los escépticos no estuvieron de

acuerdo. Finalmente, casi todo el mundo aceptó que nunca se encontrará

ninguna bala de plata. Sin embargo, afirmaciones sobre balas de plata

saltarán de vez en cuando, aún hoy en día.

Algunos interpretan que no hay balas de plata significa que la ingeniería de

software ha fracasado. Sin embargo, con otras lecturas, Brooks va a decir,

"seguramente haremos progresos sustanciales en los próximos 40 años; un

orden de magnitud en más de 40 años es casi mágico... ".

La búsqueda de una única clave para el éxito nunca funcionó. Todas las

prácticas y tecnologías conocidas sólo han hecho mejoras incrementales en

productividad y calidad. A pesar de todo, tampoco hay balas de plata para

cualquier otra profesión. Otros interpretan no hay balas de plata como prueba

de que la ingeniería de software finalmente ha madurado y reconoce que los

proyectos de éxito son debido al duro trabajo.

Sin embargo, podría decirse también que, de hecho, en la actualidad hay una

gama de balas de plata, incluyendo metodologías livianas (ver gerencia),

calculadoras de hoja de cálculo, navegadores personalizados, motores de

búsqueda en sitio, generadores de reportes de base de datos, editores de

código y pruebas de diseño integrados, con memoria/diferencias/deshacer y

tiendas especializadas que generan software de nicho, como sitios Web de

información, a una fracción del costo de desarrollo de un sitio Web totalmente

personalizado. Sin embargo, el campo de la ingeniería del software aparece

demasiado complejo y diverso para una única "bala de plata" que sirva para

mejorar la mayoría de los problemas, y cada problema representa sólo una

pequeña porción de todos los problemas de software.

De 1990 a 1999 Prominencias de Internet: El auge de la Internet

condujo a un rápido crecimiento en la demanda de sistemas internacionales

de despliegue de información y e-mail en la World Wide Web. Los

P á g i n a | 19

programadores debían manejar ilustraciones, mapas, fotografías y otras

imágenes, más animación sencilla, a un ritmo nunca antes visto, con pocos

métodos conocidos para optimizar la visualización/almacenamiento de

imágenes (como el uso de imágenes en miniatura).

El crecimiento del uso del navegador, corriendo en el lenguaje HTM, cambió

la manera en que estaba organizada la visualización y la recuperación de la

información. Las amplias conexiones de red condujeron al crecimiento y la

prevención de virus informáticos internacionales en computadores con MS

Windows, y la gran proliferación de correo basura se convirtió en una cuestión

de diseño importante en sistemas de correo electrónico, inundando canales

de comunicación y requiriendo de precalificación semiautomatizada. Sistemas

de búsqueda de palabra clave evolucionaron en buscadores web, y muchos

sistemas de software tuvieron que ser rediseñados, para la búsqueda

internacional, dependiendo de las técnicas de posicionamiento en

buscadores (SEO). Fueron necesarios sistemas de traducción de lenguaje

natural humano para intentar traducir el flujo de información en múltiples

idiomas extranjeros, con muchos sistemas de software siendo diseñados para

uso multilenguaje, basado en conceptos de diseño de traductores humanos.

Típicas bases de usuarios de computadora con frecuencia pasaron de cientos

o miles de usuarios a muchos millones de usuarios internacionales.

De 2000 al presente “Metodología Ligeras”: Con la creciente demanda de

software en muchas organizaciones pequeñas, la necesidad de soluciones de

software de bajo costo llevó al crecimiento de metodologías más simples y

rápidas que desarrollaran software funcional, de los requisitos de

implementación, más rápidos y más fáciles. El uso de prototipos rápidos

evolucionó a metodologías ligeras completas como la programación

extrema (XP), que intentó simplificar muchas las áreas de la ingeniería de

software, incluyendo la recopilación de requerimientos y las pruebas de

confiabilidad para el creciente y gran número de pequeños sistemas de

software. Sistemas de software muy grandes todavía utilizan metodologías

muy documentadas, con muchos volúmenes en el conjunto de

documentación; Sin embargo, sistemas más pequeños tenían un enfoque

alternativo más simple y rápido para administrar el desarrollo y mantenimiento

de cálculos y algoritmos de software, almacenamiento y recuperación de

información y visualización.

P á g i n a | 20

PERSONAJES DESTACADOS EN LA INGENIERIA DE

SOFTWARE.

Charles William Bachman.

Nacido el 11 de diciembre de1924, Manhattan, Estado

de Kansas, Estados Unidos) es un

prominente informático, especialmente en el área de

las bases de datos.

Recibió el Premio Turing en 1973 por "sus

sobresalientes contribuciones a la tecnología de las

bases de datos". Fue elegido como miembro

distinguido de la British Computer Society en1977 por su

trabajo pionero en sistemas de bases de datos.

Bachman es un ganador inusual del Premio Turing, puesto que pasó toda su

carrera en la industria, en lugar de en la academia. Tras empezar su trabajo

en 1950 en Dow Chemical, ascendió a la posición de encargado de

procesamiento de datos antes de abandonar en 1960 para unirse a General,

donde desarrolló el IDS (Integrated Data Store), uno de los primeros sistemas

de gestión de bases de datos. Trabajando junto con Weyerhaeuser Lumber,

desarrolló el primer acceso concurrente a la base de datos IDS. Más tarde, aú

en General Electric, desarrolló el producto "data Basic", que ofrecía servicios

de bases de datos a los usuarios del lenguaje Basic de tiempo compartido.

En 1983 fundó Bachman Information Systems, que desarrolló una línea de

productos de ingeniería del software asistida por computadora (CASE). Su

pieza central era el BACHMAN/Data Analyst, que proporcionaba soporte

gráfico a la creación y mantenimiento de los diagramas de estructuras de

datos conocidos como diagramas de Bachman. Fue promocionado en un

programa de marketing de IBM sobre reusabilidad, y combinaba 1) ingeniería

inversa de bases de datos obsoletas, 2) modelado de datos, 3) conversión a

nuevas bases de datos y 4) optimización de diseños físicos de bases de

datos.

Es conocido por sus acaloradas discusiones con Edgar F. Codd, que apoyaba

el modelo relacional de bases de datos contra la opinión

de Bachman.

Frederick Phillips Brooks. Jr.

(nacido el 19 de abril de 1931) es un ingeniero de

software y científico de la computación, más conocido

por dirigir el desarrollo del sistema operativo OS/360, y

después escribir honestamente sobre el proceso en su

P á g i n a | 21

famoso libro The Mythical Man-Month (El mítico hombre-mes). "Es una

experiencia humillante el cometer un error de coste multimillonario, pero es

también muy memorable." Brooks recibió el Premio Turingen 1999 "por sus

contribuciones a arquitectura de computadores, sistemas operativos e

ingeniería del software."

Nacido en Durham,Carolina del Norte, asistió a la Universidad de Duke,

licenciándose en 1953. Se doctoró en matemática aplicada por la Universidad

de Harvard en 1956. Howard Aiken fue su director de tesis.

Brooks se incorporó a IBM en 1956, trabajando en Poughkeepsie y Yorktown,

Nueva York. Trabajó en la arquitectura del IBM 7030 (un supercomputador

científico de $10M para el Laboratorio Científico de Los Alamos) y los

computadores Harvest, para después dirigir el desarrollo de la familia de

computadores System/360 y el software que ejecutaban.

Fue en The Mythical Man-Month cuando Brooks hizo su famosa observación:

"Añadir personal a un proyecto retrasado lo retrasará aún más." Desde

entonces, esto se ha venido conociendo como la "Ley de Brooks." Además

de The Mythical Man-Month, Brooks es conocido por su ensayo No Silver

Bullet, sobre ingeniería del software.

En 1965, Brooks dejó IBM para fundar el Departamento de Ciencias de la

Computación en la Universidad de Carolina del Norte en Chapel Hill del que

fue decano durante 20 años. En 2004 estaba aún implicado en actividades

investigadoras, principalmente en realidad virtual y visualización científica. En

enero de 2005 impartió la clase magistral anual Alan Turing ante

la IEE/BCS en Londres, sobre "Colaboración y Tele colaboración en Diseño".

Brooks es cristiano practicante, muy activo en la comunidad evangélica.

El Dr. Peter Pin-Shan.

Es el creador del Modelo Entidad-Relación (Modelo ER).

En el año 1968, obtuvo el grado de licenciado en

Ciencias en la Universidad Nacional de Taiwán.

Posteriormente, en el año 1973, obtuvo el grado

académico de Doctor en Ciencias de la Computación y

Matemática Aplicada en la Universidad de Harvard.

Desde 1983, el Dr. Peter Chen disfruta del cargo de M. J.

Distinguished Chair Professor of Computer Science en la

Universidad del Estado de Luisiana.

El Modelo ER ha sido la base para diversas metodologías sobre análisis y

diseño de sistemas, herramientas de ingeniería de software asistida por

computador (CASE) y repositorios de sistemas. En este sentido, el Modelo ER

P á g i n a | 22

ha sido utilizado por el IBM Repository Manager/MVS y por el DEC CDD/Plus.

Los términos ―Modelo de Entidad-Relación (Modelo ER)‖, ―Diagrama de

Entidad-Relación (Diagrama ER)‖ y ―Peter Chen‖ son utilizados habitualmente

en diccionarios on-line, libros, artículos, páginas Web, textos de aprendizaje y

en especificaciones de productos comerciales.

El artículo original de Peter Chen1 sobre el Modelo ER es uno de los trabajos

más citados en el campo de las ciencias de la computación.2 Este artículo ha

sido recientemente galardonado como uno de los 38 artículos más influyentes

para las ciencias de la computación, según una encuesta3realizada a cerca de

1000 investigadores universitarios.

En 1998, Peter Chen fue admitido como socio en la Association for Computing

Machinery.

Hoy en día, es muy probable encontrar al menos un capítulo que hable sobre

el Modelo ER en libros de diseño de sistemas de información o de bases de

datos. También es muy probable ver que el Modelo ER se explica en clases

de Gestión de la Información. Por ejemplo, en la Universidad Estatal de

Louisiana el Modelo ER se enseña en el Departamento de Ciencias de la

Computación del Colegio de Ciencias Básicas, en el Departamento de

Sistemas de Información y Ciencias de la Decisión de la Escuela de

Negocios, y en el Departamento de Ingeniería Industrial y Sistemas de

Manufacturación del Colegio de Ingenieros. El Modelo ER también se enseña

en otras universidades, por ejemplo, en dos o tres cursos de la Escuela de

Administración de la Información en Berkeley, en los programas de Biología

Computacional y de Bioinformática de la Universidad de Pennsylvania,

también en la Universidad de Drexel, la Universidad de Virginia, y la

Universidad de Hong Kong. Estos son sólo algunos ejemplos, ya que

actualmente se enseña el Modelo ER en diversas instituciones de educación

superior.

El trabajo del Dr. Chen es una de las piedras angulares en la ingeniería del

software, y especialmente en la ingeniería del software asistida por

computador (Computer-Aided Software Engineering – CASE). A finales de la

década de 1980 y principios de la de 1990, el marco de trabajo de IBM para el

Ciclo de Desarrollo de Aplicaciones (Application Development Cycle –

AD/Cycle) y el repositorio DB2(RM/MVS) estaban basados en el Modelo ER.

Los sistemas de repositorios de otros vendedores, como el CDD+ de Digital,

también estaban basados en el Modelo ER. Además, el Dr. Chen, mediante

sus investigaciones y conferencias correspondientes a metodologías de

desarrollo de sistemas estructurados, ha tenido un impacto significativo en la

P á g i n a | 23

industria CASE. De hecho, el Modelo ER ha influido en la mayoría de

las herramientas CASE (CASE tools), incluyendo a ERWIN

David Lorge Pernas.

Es un profesional canadiense pionero en el campo

de la ingeniería del software de la cual ha sido un

ferviente defensor a lo largo de su carrera. Ha

recibido numerosos premios a lo largo de su carrera

y ha sido profesor en universidades de diferentes

países del mundo.

El desarrollo de software se realiza para

organizaciones que están en continuo movimiento:

puede cambiar el mercado, los procesos, los

usuarios, los responsables técnicos, etc…, a lo que

hay que sumar que se intentan abstraer procesos que se realizan en el

mundo real a un programa de ordenador y no es nada fácil ese proceso

porque los que definen el sistema no tienen claro, por regla general, lo que

quieren realmente (tienen una idea, pero hasta que no la ven reflejada, no

terminan por matizarla).

La naturaleza del software es adaptativa, mediante aproximaciones y

evoluciones se consiguen alcanzar productos que satisfacen las necesidades

del usuario, a través del feedback que se obtiene de los mismos una vez que

hacen uso del sistema. Los principios ágiles definen ese marco (que también

se tiene en cuenta en metodologías del proceso unificado como RUP), si bien,

nuestra propia experiencia personal nos dirigirá de alguna u otra forma y de

forma paulatina hacia enfoques iterativos e incrementales en lugar de ciclos

de vida clásico o en cascada.

Dave Parnas, sobre este tema realiza la siguiente reflexión (traducción libre):

―Por regla general, los sistemas software no funcionan adecuadamente hasta

que han sido utilizados y han fallado repetidamente en entornos reales‖.

Alan Curtis Kay.

Lleva más de cuarenta años en el negocio. Ha

trabajado en el sector privado en empresas como

Xerox, Atari, Apple, Walt Disney y HP y ha sido profesor

universitario (UCLA, MIT, etc…). Es considerado como

uno de los pioneros de la programación orientada a

objetos y uno de los padres de las arquitecturas

modernas de interfaces gráficas de usuario.

P á g i n a | 24

Que una persona con ese Currículum realice la siguiente reflexión es para

tenerlo muy en cuenta: ―La mayoría del software actual se parece mucho a las

pirámides egipcias con millones de ladrillos apilados uno encima de otro, sin

integridad estructura y realizados mediante fuerza bruta y miles de esclavos‖.

Es una crítica dura a gran parte del software que se realizaba hace unos años

y que todavía se realiza. La crisis del software es un término totalmente

vigente como también lo es que la ingeniería del software es parte del

antídoto para combatirlas.

Antes de desarrollar un software hay que tener una estrategia y unos

procesos que apoyándose en una metodología adecuada, en la experiencia y

habilidades del equipo de proyecto y en unas relaciones adecuadas con el

área usuaria permitan desarrollar un producto de calidad (y por tanto

mantenible) y con un esfuerzo adecuado a la naturaleza del trabajo a realizar.

EL PRODUCTO Y EL PROCESO DE LA INGENIERÍA DEL

SOFTWARE.

El producto: El software de computadora se ha convertido en el alma máter.

Es la máquina que conduce a la toma de decisiones comerciales. Sirve para

la investigación científica moderna y de resolución de problemas de

ingeniería. Es el factor clave que diferencia los productos y servicios

modernos. Está inmerso en sistemas de todo tipo: de transportes, médicos,

de telecomunicaciones, militares, procesos industriales, entretenimientos,

productos de oficina, la lista es casi interminable. El software es casi

ineludible en un mundo moderno. A medida que nos adentremos en el siglo

XXI, será el que nos conduzca a nuevos avances en todo, desde la educación

elemental a la ingeniería genética.

El software de computadora es el producto que diseñan y construyen los

ingenieros del software. Esto abarca programas que se ejecutan dentro de

una computadora de cualquier tamaño y arquitectura, documentos que

comprenden formularios virtuales e impresos y datos que combinan números

y texto y también incluyen representaciones de información de audio, vídeo e

imágenes.

Los ingenieros de software lo construyen, y virtualmente cualquier persona en

el mundo industrializado lo utiliza, bien directa o indirectamente. Es importante

porque afecta muy de cerca cualquier aspecto de la vida y está muy extendido

en el comercio y en las actividades cotidianas.

Los pasos son construir software de computadora como construimos

cualquier otro producto satisfactorio, aplicando un proceso que conduce a un

P á g i n a | 25

resultado de alta calidad, que satisface las necesidades de las personas que

usarán el producto. Debes aplicar un enfoque de ingeniería de software.

Desde el punto de vista de un ingeniero de software, el producto obtenido son

los programas, documentos y los datos que configuran el software de

computadora. Pero desde el punto de vista de los usuarios el producto

obtenido es la información resultante que de algún modo mejora el mundo de

los usuarios.

El proceso: Como el software, al igual que el capital, es el conocimiento

incorporado, y puesto que el conocimiento está inicialmente disperso, el

desarrollo del software implícito, latente e incompleto en gran medida, es un

proceso social de aprendizaje.

El proceso es un diálogo en el que se reúne el conocimiento y se incluye en el

software. El proceso proporciona una interacción entre los usuarios y los

diseñadores, entre los usuarios y las herramientas de desarrollo, y entre los

diseñadores y las herramientas de desarrollo [tecnología]. Es un proceso

interactivo donde la herramienta de desarrollo se usa como medio de

comunicación, con cada iteración del diálogo se obtiene mayor conocimiento

de las personas involucradas.

Cuando se trabaja para construir un producto o un sistema, es importante

seguir una serie de pasos predecibles, un mapa de carreteras que le ayude a

obtener el resultado oportuno de calidad. El mapa de carreteras a seguir es

llamado proceso del software.

Lo construyen los ingenieros del software y sus gestores adaptan el proceso a

sus necesidades y entonces lo siguen. Además las personas que han

solicitado el software tienen un papel a desempeñar en 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.

Los pasos son a un nivel detallado, el proceso que adoptemos depende del

software que estamos construyendo. Un proceso puede ser apropiado para

crear software de un sistema de aviación, mientras que un proceso diferente

por completo puede ser adecuado para la creación de un sitio web.

Desde el punto de vista de un ingeniero de software, los productos obtenidos

son programas, documentos y datos que se producen como consecuencia de

las actividades ingenieriles definidas por el proceso.

Hay una cantidad de mecanismos de evaluación del proceso de software que

permiten a las organizaciones determinar la madurez de su proceso. Sin

embargo, la calidad, oportunidad y viabilidad a largo plazo del producto que

se está construyendo, son los mejores indicadores de la eficiencia del proceso

que estamos utilizando.

P á g i n a | 26

CARÁCTER EVOLUTICO DEL SOFTWARE.

El software es el producto derivado del proceso de desarrollo, según la

ingeniería de software. Este producto es intrínsecamente evolutivo durante su

ciclo de vida. El software evoluciona, en general, generando versiones cada

vez más completas, complejas, mejoradas, optimizadas en algún aspecto,

adecuadas a nuevas plataformas (sean de hardware o sistemas operativos),

etc.

Cuando un sistema deja de evolucionar, eventualmente cumplirá con su ciclo

de vida, entrará en obsolescencia e inevitablemente, tarde o temprano, será

reemplazado por un producto nuevo.

El software evoluciona sencillamente porque se debe adaptar a los cambios

del entorno, sean funcionales (exigencias de usuarios), operativos, de

plataforma o arquitectura hardware.

La dinámica de evolución del software es el estudio de los cambios del

sistema. La mayor contribución en esta área fue realizada por Meir M.

Lehman y Belady, comenzando en los años 70 y 80. Su trabajo continuó en la

década de 1990, con Lehman y otros investigadores18 de relevancia en la

realimentación en los procesos de evolución (Lehman, 1996; Lehman et al.,

1998; lehman et al., 2001). A partir de esos estudios propusieron un conjunto

de leyes (conocidas como leyes de Lehman)9 respecto de los cambios

producidos en los sistemas. Estas leyes (en realidad son hipótesis) son

invariantes y ampliamente aplicables.

Lehman y Belady analizaron el crecimiento y la evolución de varios sistemas

software de gran porte; derivando finalmente, según sus medidas, las

siguientes ocho leyes:

1. Cambio continuo: Un programa que se usa en un entorno real

necesariamente debe cambiar o se volverá progresivamente menos útil en

ese entorno.

2. Complejidad creciente: A medida que un programa en evolución cambia, su

estructura tiende a ser cada vez más compleja. Se deben dedicar recursos

extras para preservar y simplificar la estructura.

3. Evolución prolongada del programa: La evolución de los programas es un

proceso autor regulativo. Los atributos de los sistemas, tales como tamaño,

tiempo entre entregas y la cantidad de errores documentados son

aproximadamente invariantes para cada entrega del sistema.

P á g i n a | 27

4. Estabilidad organizacional: Durante el tiempo de vida de un programa, su

velocidad de desarrollo es aproximadamente constante e independiente de

los recursos dedicados al desarrollo del sistema.

5. Conservación de la familiaridad: Durante el tiempo de vida de un sistema, el

cambio incremental en cada entrega es aproximadamente constante.

6. Crecimiento continuado: La funcionalidad ofrecida por los sistemas tiene que

crecer continuamente para mantener la satisfacción de los usuarios.

7. Decremento de la calidad: La calidad de los sistemas software comenzará a

disminuir a menos que dichos sistemas se adapten a los cambios de su

entorno de funcionamiento.

8. Realimentación del sistema: Los procesos de evolución incorporan sistemas

de realimentación multivalente y multibucle y estos deben ser tratados como

sistemas de realimentación para lograr una mejora significativa del producto.

ETAPAS DE DESARROLLO DEL SOFTWARE.

El proceso requiere una metodología con 5 etapas:

1. Análisis de requerimientos: Se extraen los requisitos del producto de

software. En esta etapa la habilidad y experiencia en la ingeniería del software

es crítica para reconocer requisitos incompletos, ambiguos o contradictorios.

Usualmente el cliente/usuario tiene una visión incompleta/inexacta de lo que

necesita y es necesario ayudarle para obtener la visión completa de los

requerimientos. El contenido de comunicación en esta etapa es muy intenso

ya que el objetivo es eliminar la ambigüedad en la medida de lo posible.

2. Especificación: Es la tarea de describir detalladamente el software a ser

escrito, de una forma rigurosa. Se describe el comportamiento esperado del

software y su interacción con los usuarios y/o otros sistemas.

3. Diseño y arquitectura: Determinar cómo funcionará de forma general sin

entrar en detalles incorporando consideraciones de la implementación

tecnológica, como el hardware, la red, etc. Consiste en el diseño de los

componentes del sistema que dan respuesta a las funcionalidades descritas

en la segunda etapa también conocidas como las entidades de negocio.

Generalmente se realiza en base a diagramas que permitan describir las

interacciones entre las entidades y su secuenciado.

4. Programación: Se traduce el diseño a código. Es la parte más obvia del

trabajo de ingeniería de software y la primera en que se obtienen resultados

P á g i n a | 28

―tangibles‖. No necesariamente es la etapa más larga ni la más compleja

aunque una especificación o diseño incompletos/ambiguos pueden exigir que,

tareas propias de las etapas anteriores se tengan que realizarse en esta.

5. Prueba: Consiste en comprobar que el software responda/realice

correctamente las tareas indicadas en la especificación. Es una buena praxis

realizar pruebas a distintos niveles (por ejemplo primero a nivel unitario y

después de forma integrada de cada componente) y por equipos

diferenciados del de desarrollo (pruebas cruzadas entre los programadores o

realizadas por un área de test independiente).

6. Documentación: Realización del manual de usuario, y posiblemente un

manual técnico con el propósito de mantenimiento futuro y ampliaciones al

sistema. Las tareas de esta etapa se inician ya en la primera fase pero sólo

finalizan una vez terminadas las pruebas.

7. Mantenimiento: En esta etapa se realizan un mantenimiento correctivo

(resolver errores) y un mantenimiento evolutivo (mejorar la funcionalidades y/o

dar respuesta a nuevos requisitos).

¿Porque el Proceso en el Desarrollo de Software es

Importante Aplicarlo?

Imagínese que quiere usted comenzar la construcción de una vivienda y para

ello solicita presupuesto a dos constructores. El primero, un tanto charlatán,

le dice que usa una nueva tecnología de construcción con la que puede

hacerle su casa en dos meses, que puede comenzar mañana mismo y que

sólo le costará 60.000€. Este constructor dice tener personal de primera

calidad, que ha usado está tecnología para hacer varias obras

anteriormente. El segundo constructor, más sosegado, le dice que lo primero

P á g i n a | 29

que debe hacer es sentarse con usted para discutir qué tipo de vivienda le

gustaría construir y luego una vez que usted le haya transmitido sus requisitos

y necesidades, elaborarán juntos un proyecto inicial de lo que pretende hacer

para su revisión. Una vez usted apruebe este estudio preliminar, elaborarán

juntos el proyecto definitivo y planificarán los tiempos y costes del resto del

trabajo a realizar. Esta fase inicial tendrá un coste de 6.000€.

¿Con cuál de los constructores se sentiría usted mejor? El primero de ellos

quiere comenzar a construir su vivienda, no tiene demasiado interés en

el como, ya lo irá viendo. Ni en estimar el tiempo que le llevará. No cuenta

con ningún dato más que la inquietud transmitida por parte de su potencial

cliente, pero sin embargo se atreve a proporcionarle un presupuesto. El

segundo quiere entender que pretende usted construir, para ello creará un

modelo y posteriormente una vez que sabe lo que usted necesita, lo

construirá utilizando la metodología adecuada para planificar costes y

tiempos.

Obviamente, el segundo le ofrece una primera fase que es imprescindible

para que el proyecto tenga éxito. Lo primero es entender lo que usted

necesita, antes de hacer algo que luego no cumpla sus expectativas. Esto

último es lo que pasa en la mayoría de los desarrollos de aplicaciones que

resultan insatisfactorios después de haber empleado gran cantidad de tiempo

y recursos.

Es recomendable el uso de ingeniería para el desarrollo de software. Han de

planificarse cada una de las fases y etapas del desarrollo, como en cualquier

otro proyecto. Esto que parece tan lógico y tan trivial, es increíble como en la

mayoría de las ocasiones no es tenido en cuenta. Si usted quiere que su

proyecto tenga éxito trabaje con aquellos que usan la metodología adecuada,

y no con los que le ofrecen bajo coste sin ni siquiera plantear un análisis

previo. Añada la ingeniería de software al desarrollo de sus aplicaciones, lo

agradecerá

MODELO DE DESARROLLO DE SOFTWARE.

Existen varios modelos, paradigmas y filosofías de desarrollo, en los cuales

se apoya la ingeniería de software para la construcción del software, entre

ellos se puede citar:

a) Modelo en cascada: En Ingeniería de software el desarrollo en cascada,

también llamado modelo en cascada, es el enfoque metodológico que ordena

P á g i n a | 30

rigurosamente las etapas del proceso para el desarrollo de software, de tal

forma que el inicio de cada etapa debe esperar a la finalización de la etapa

anterior.

De esta forma, cualquier error de diseño detectado en la etapa de prueba

conduce necesariamente al rediseño y nueva programación del código

afectado, aumentando los costos del desarrollo. La palabra cascada sugiere,

mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para

introducir un cambio en las fases más avanzadas de un proyecto.

Análisis de requisitos.

En esta fase se analizan las necesidades de los usuarios finales del software

para determinar qué objetivos debe cubrir. De esta fase surge una memoria

llamada SRD (documento de especificación de requisitos), que contiene la

especificación completa de lo que debe hacer el sistema sin entrar en detalles

internos.

Es importante señalar que en esta etapa se debe consensuar todo lo que se

requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no

pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del

software.

Diseño del Sistema.

Descompone y organiza el sistema en elementos que puedan elaborarse por

separado, aprovechando las ventajas del desarrollo en equipo. Como

resultado surge el SDD (Documento de Diseño del Software), que contiene la

descripción de la estructura relacional global del sistema y la especificación

de lo que debe hacer cada una de sus partes, así como la manera en que se

combinan unas con otras.

Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño

detallado. El primero de ellos tiene como objetivo definir la estructura de la

solución (una vez que la fase de análisis ha descrito el problema)

identificando grandes módulos (conjuntos de funciones que van a estar

asociadas) y sus relaciones. Con ello se define la arquitectura de la solución

elegida. El segundo define los algoritmos empleados y la organización del

código para comenzar la implementación.

Diseño del Programa.

Es la fase en donde se realizan los algoritmos necesarios para el

cumplimiento de los requerimientos del usuario así como también los análisis

necesarios para saber que herramientas usar en la etapa de Codificación.

P á g i n a | 31

Codificación.

Es la fase en donde se implementa el código fuente, haciendo uso de

prototipos así como de pruebas y ensayos para corregir errores.

Dependiendo del lenguaje de programación y su versión se crean las

bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer

que la programación sea un proceso mucho más rápido.

Pruebas.

Los elementos, ya programados, se ensamblan para componer el sistema y

se comprueba que funciona correctamente y que cumple con los requisitos,

antes de ser entregado al usuario final.

Verificación.

Es la fase en donde el usuario final ejecuta el sistema, para ello el o los

programadores ya realizaron exhaustivas pruebas para comprobar que el

sistema no falle.

En la creación de desarrollo de cascada se implementa los códigos de

investigación y pruebas del mismo.

Mantenimiento.

Una de las etapas más críticas, ya que se destina un 75% de los recursos, es

el mantenimiento del Software ya que al utilizarlo como usuario final puede

ser que no cumpla con todas nuestras expectativas.

P á g i n a | 32

b) Modelo De Espiral: La principal características del modelo en espiral es la

gestión de riesgos de forma periódica en el ciclo de desarrollo. Este modelo

fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de

las metodologías del modelo de cascada y del desarrollo rápido de

aplicaciones, pero dando énfasis en un área que para muchos no jugó el

papel que requiere en otros modelos: un análisis iterativo y concienzudo de

los riesgos, especialmente en el caso de sistema complejos de gran escala.

La espiral se visualiza como un proceso que pasa a través de algunas

iteraciones con el diagrama de los cuatro cuadrantes representativos de las

siguientes actividades:

Crear planes con el propósito de identificar los objetivos del software,

seleccionados para implementar el programa y clarificar las restricciones en el

desarrollo del software;

Análisis de riesgos: una evaluación analítica de programas seleccionados,

para evaluar cómo identificar y eliminar el riesgo;

La implementación del proyecto: implementación del desarrollo del software y

su pertinente verificación;

Modelo de espiral con énfasis en los riesgos, haciendo hincapié en las

condiciones de las opciones y limitaciones para facilitar la reutilización de

software, la calidad del software puede ayudar como una meta propia en la

integración en el desarrollo del producto. Sin embargo, el modelo en espiral

tiene algunas limitaciones, entre las que destacan:

El énfasis se sitúa en el análisis de riesgo, y por lo tanto requiere de clientes

que acepten este análisis y actúen en consecuencia. Para ello es necesaria

confianza en los desarrolladores así como la predisposición a gastar más para

solventar los temas, por lo cual este modelo se utiliza frecuentemente en

desarrollo interno de software a gran escala.

Si la implementación del riesgo de análisis afectará de forma esencial los

beneficios del proyecto, no debería utilizarse este modelo.

Los desarrolladores de software han de buscar de forma explícita riesgos y

analizarlos de forma exhaustiva para que este modelo funcione.

La primera fase es la búsqueda de un plan para conseguir los objetivos con

las limitaciones del proyecto para así buscar y eliminar todos los riesgos

potenciales por medio de un cuidadoso análisis, y si fuera necesario

incluyendo la fabricación de un prototipo. Si es imposible descartar algunos

riesgos, el cliente ha de decidir si es conveniente terminar el proyecto o seguir

adelante ignorando los riesgos. Por último, se evalúan los resultados y se

inicia el diseño de la siguiente fase.

P á g i n a | 33

El desarrollo iterativo recomienda la construcción de secciones reducidas de

software que irán ganando en tamaño para facilitar así la detección de

problemas de importancia antes de que sea demasiado tarde. Los procesos

iterativos pueden ayudar a desvelar metas del diseño en el caso de clientes

que no saben cómo definir lo que quieren.

c) Desarrollo ágil: El desarrollo ágil de software utiliza un desarrollo iterativo

como base para abogar por un punto de vista más ligero y más centrado en

las personas que en el caso de las soluciones tradicionales. Los procesos

ágiles utilizan retroalimentación en lugar de planificación, como principal

mecanismo de control. La retroalimentación se canaliza por medio de pruebas

periódicas y frecuentes versiones del software.

Hay muchas variantes de los procesos ágiles:

En el caso de la programación extrema (XP), las fases se realizan en pasos

muy cortos (o "continuos") con respecto al anterior. El primer paso

(intencionalmente incompleto) por los pasos puede ocurrir en un día o en una

semana, en lugar de los meses o años de cada paso completo en el modelo

en cascada. En primer lugar, se crean pruebas automatizadas para proveer

metas concretas al desarrollo. Después se programa el código, que será

completo cuando todas las pruebas se superan sin errores, y los

desarrolladores ya no sabrían cómo mejorar el conjunto de pruebas

necesario. El diseño y la arquitectura emergen a partir de la

refactorización del código, y se da después de programar. El diseño lo

realizan los propios desarrolladores del código. El sistema, incompleto, pero

funcional se despliega para su demostración a los usuarios (al menos uno de

los cuales pertenece al equipo de desarrollo). Llegado este punto, los

profesionales comienzan a escribir las pruebas para la siguiente parte del

sistema de más importancia.

P á g i n a | 34

d) Codificación y corrección: El desarrollo de codificación y corrección (en

inglés "Code and fix") es, más que una estrategia predeterminada, el

resultado de una falta de experiencia o presión que se ejerce sobre los

desarrolladores para cumplir con una fecha de entrega. Sin dedicar tiempo de

forma explícita para el diseño, los programadores comienzan de forma

inmediata a producir código. Antes o después comienza la fase de pruebas de

software (a menudo de forma tardía) y los inevitables errores que se

encuentran han de eliminarse antes de poder entregar el software.

e) Proceso Unificado de Rational: El Proceso Unificado de Rational (Rational

Unified Process en inglés, habitualmente resumido como RUP) es un proceso

de desarrollo de software desarrollado por la empresa Rational Software,

actualmente propiedad de IBM. Junto con el Lenguaje Unificado de

Modelado UML, constituye la metodología estándar más utilizada para el

P á g i n a | 35

análisis, diseño, implementación y documentación de sistemas orientados a

objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un

conjunto de metodologías adaptables al contexto y necesidades de cada

organización.

También se conoce por este nombre al software, también desarrollado por

Rational, que incluye información entrelazada de diversos artefactosy

descripciones de las diversas actividades. Está incluido en el Rational Method

Composer (RMC), que permite la personalización de acuerdo con las

necesidades.

Originalmente se diseñó un proceso genérico y de dominio público, el Proceso

Unificado, y una especificación más detallada, el Rational Unified Process,

que se vendiera como producto independiente.

PRINCIPALES CARACTERÍSTICAS DEL RUP.

Forma disciplinada de asignar tareas y responsabilidades (quién hace qué,

cuándo y cómo)

Pretende implementar las mejores prácticas en Ingeniería de Software

Desarrollo iterativo

Administración de requisitos

Uso de arquitectura basada en componentes

Control de cambios

Modelado visual del software

Verificación de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e

incremental, estar centrado en

la arquitectura y guiado por los

casos de uso. Incluye artefactos

(que son los productos

tangibles del proceso como por

ejemplo, el modelo de casos de

uso, el código fuente, etc.) y

roles (papel que desempeña

una persona en un determinado

momento, una persona puede

desempeñar distintos roles a lo

largo del proceso).

P á g i n a | 36

TENDENCIAS ACTUALES EN LA INGENIERÍA DE

SOFTWARE.

La ingeniería de software es una disciplina joven y aún está en desarrollo. Las

direcciones en que la ingeniería de software se está desarrollando incluyen:

Aspectos: Los aspectos ayudan a los ingenieros de software a lidiar con los

atributos de calidad al proporcionar herramientas para añadir o quitar código

repetitivo de muchas áreas en el código fuente. Los aspectos describen cómo

todos los objetos o funciones deben comportarse en circunstancias

particulares. Por ejemplo, los aspectos pueden agregar control

de depuración, registro o bloqueo en todos los objetos de un tipo particular.

Los investigadores actualmente están trabajando para comprender cómo

utilizar aspectos para diseñar el código de propósito general. Conceptos

relacionados incluyen programación generativa y plantillas.

Ágil: El desarrollo ágil de software guía a los proyectos de desarrollo de

software que evolucionan rápidamente con cambiantes expectativas y

mercados competitivos. Los proponentes de este método creen que procesos

pesados, dirigidos por documentos (como TickIT, CMM e ISO 9000) están

desapareciendo en importancia. Algunas personas creen que las empresas y

agencias exportan muchos de los puestos de trabajo que pueden ser guiados

por procesos pesados.[cita requerida] Conceptos relacionados incluyen la

programación extrema, scrum y lean software development.

Experimental: La ingeniería de software experimental es una rama de la

ingeniería de software interesada en la elaboración de experimentos sobre el

software, en la recolección de datos de los experimentos y en la elaboración

de leyes y teorías desde estos datos. Los proponentes de este método

defienden que la naturaleza del software es tal que podemos hacer avanzar el

conocimiento en software a través de sólo experimentos.[cita requerida]

Model-driven: El diseño manejado por modelos desarrolla modelos textuales

y gráficos como artefactos primarios de diseño. Hay disponibles herramientas

de desarrollo que usan transformación de modelo y generación de

código para generar fragmentos de código bien organizado que sirven como

base para producir aplicaciones completas.

Líneas de productos de software: las líneas una forma sistemática para

producir familias de sistemas de software, en lugar de crear una sucesión de

productos completamente individuales. Este método destaca una extensiva,

sistemática, reutilización de código formal, para intentar industrializar el

proceso de desarrollo de software.

El futuro de la Conferencia de ingeniería de Software (FOSE),5 celebrada en

ICSE 2000, documenta el estado del arte de SE en 2000 y lista muchos

P á g i n a | 37

problemas a resolver en la próxima década. El FOSE sigue la pista de las

conferencias ICSE 20006 y el ICSE 20077 y también ayudar a identificar el

estado del arte en ingeniería de software.

Estado del arte de la Ingeniería del Software: La Ingeniería

del Software es una disciplinado área de la Informática o Ciencias de

la Computación, que ofrece métodos y técnicas para desarrollar y mantener

software de calidad que resuelven problemas de todo tipo. Hoy día es cada

vez más frecuente la consideración de la Ingeniería del Software como una

nueva área de la ingeniería, y el ingeniero del software comienza a ser una

profesión implantada en el mundo laboral internacional, con derechos,

deberes y responsabilidades que cumplir, junto a una, ya, reconocida

consideración social en el mundo empresarial y, por suerte, para esas

personas con brillante futuro.

La Ingeniería del Software trata con áreas muy diversas de la Informática y de

las ciencias de la computación, tales como construcción de compiladores,

sistemas operativos o desarrollos de Intranet/Internet, abordando todas las

fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de

información y aplicables a una infinidad de áreas tales como: negocios,

investigación científica, medicina, producción, logística, banca, control de

tráfico, meteorología, el mundo del derecho, la red de redes Internet, redes

Intranet y Extranet, etc.

RIESGO DEL SOFTWARE.

Se trata en que amenazan al plan del proyecto, es decir, si los riesgos del proyecto se hacen realidad, es probable que la planificación temporal del proyecto se retrase y que los costos aumenten. Los riesgos del proyecto identifican:

Problemas potenciales de presupuesto Planificación temporal Personas (Asignación y organización) Recursos Cliente, requerimientos y su impacto en el proyecto software La complejidad del proyecto Tamaño y grado de incertidumbre estructural

Riesgos Técnicos.

Amenazan la calidad y la planificación temporal del sw que hay que producir. Si un riesgo se convierte en realidad, la implementación puede llegar a ser difícil o imposible. Los riesgos técnicos identifican problemas potenciales de:

Diseño Implementación De interfaz

P á g i n a | 38

Verificación Mantenimiento Las ambigüedades de especificaciones Tecnologías

Los riesgos técnicos ocurren porque el problema es más difícil de resolver de lo que pensábamos.

Riesgos del Negocio.

Amenazan la viabilidad del software a construir. Los riesgos del negocio a menudo ponen en peligro el proyecto o producto. Los candidatos para los cinco principales riesgos del negocio son:

Construir un producto o sistema excelente que no quiere nadie en realidad (Riesgo de Mercado).

Construir un producto que no encaja en la estrategia comercial general de la compañía (Riesgo Estratégico).

Construir un producto que el departamento de ventas no sabe cómo vender. Perder el apoyo de una gestión experta debida a cambios de enfoque o a

cambios de personal (Riesgo de Dirección). Perder presupuesto o personal asignado (Riesgo de Presupuesto).

Es extremadamente importante recalcar que no siempre funciona una categorización tan sencilla. Algunos riesgos pueden pertenecer a más de una categoría o simplemente imposibles de predecir.

IDENTIFICACION Y CLASIFICACION DE RIESGO.

La identificación del riesgo es un intento sistemático para especificar las amenazas al plan de proyecto (estimaciones, planificación temporal, cargo de recursos, etc.). Identificando los riesgos conocidos y predecibles, el gestor del proyecto da un paso adelante para evitarlos cuando sea posible y controlarlos cuando sea necesario.

Existen dos tipos diferenciados de riesgos para cada categoría:

1. Riesgos Genéricos: Son una amenaza potencial para todos los proyectos de software.

2. Riesgos específicos: Los riesgos específicos de producto sólo los pueden identificar los que tienen una clara visión de la tecnología, el personal y el entorno específico del proyecto en cuestión, entre los que están:

Tamaño del producto: Riesgos asociados con el tamaño general del software a construir o a modificar.

Impacto en el negocio: Riesgos asociados con las limitaciones impuestas por la gestión o por el mercado.

Características del cliente: Riesgos asociados con la sofisticación del cliente y la habilidad del desarrollador para comunicarse con el cliente en los momentos oportunos.

P á g i n a | 39

Definición del proceso: Riesgos asociados con el grado de definición del proceso del software y su seguimiento para la organización de desarrollo.

Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas que se van a emplear en la construcción del producto.

Tecnología a construir: Riesgos asociados con la complejidad del sistema a construir y la tecnología de punta que contiene el sistema.

Tamaño y experiencia de la plantilla: Riesgos asociados con la experiencia técnica y de proyectos de los ingenieros de sw que van a realizar el trabajo.

DESARROLLO DE UN SOFTWARE DE CALIDAD.

La obtención de un software con calidad implica la utilización de metodologías

o procedimientos estándares para el análisis, diseño, programación y prueba

del software que permitan uniformar la filosofía de trabajo, en aras de lograr

una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que

eleven la productividad, tanto para la labor de desarrollo como para el control

de la calidad del software.

EL ASEGURAMIENTO DE LA CALIDAD.

Ante todo se debe conocer:

Aseguramiento de la calidad: "Conjunto de acciones planificadas y

sistemáticas necesarias para proporcionar la confianza adecuada de que un

producto o servicio satisfará los requerimientos dados sobre calidad".

Aseguramiento de la calidad de software: Conjunto de actividades

planificadas y sistemáticas necesarias para aportar la confianza en que el

producto (software) satisfará los requisitos dados de calidad.

El aseguramiento de calidad del software se diseña para cada aplicación

antes de comenzar a desarrollarla. Hay quienes prefieren decir garantía de

calidad en vez de aseguramiento.

La garantía, puede confundir con garantía de productos, mientras que el

aseguramiento pretende dar confianza en que el producto tiene calidad.

El aseguramiento de calidad del software está presente en:

Métodos y herramientas de análisis, diseño, programación y prueba.

Inspecciones técnicas formales en todos los pasos del proceso de desarrollo

del software.

Estrategias de prueba multiescala.

Control de la documentación del software y de los cambios realizados.

Procedimientos para ajustarse a los estándares (y dejar claro cuando se está

fuera de ellos).

Mecanismos de medida (métricas).

Registro de auditorías y realización de informes.

P á g i n a | 40

Las actividades para el aseguramiento de calidad del software se

detallan en:

Métricas de software para el control del proyecto.

Verificación y validación del software a lo largo del ciclo de vida (Incluye las

pruebas y los procesos de revisión e inspección).

La gestión de la configuración del software.

Algunos métodos del aseguramiento:

Revisiones técnicas y de gestión (su objetivo es la evaluación).

Inspección (su objetivo es la verificación). ¿Estamos construyendo el producto

correcto?

Pruebas (su objetivo es la validación). ¿Estamos construyendo el producto

correctamente?

Auditorias (su objetivo es la confirmación del cumplimiento).

P á g i n a | 41

CONCLUSION.

Creo que tenemos a la mano muchas herramientas que podrán ser de

gran utilidad para formar un buen software u otro diseño que se basen

en los gráficos y diagramas, no tienen qué ser precisamente sobre la

informática. Cada día la tecnología va incrementando muy

velozmente, y cada vez habrá mejores y mayores opciones de

herramientas para satisfacer las necesidades personales y

empresariales que llegarán a ser inimaginables. Pero por ahora, hay

muy buenas opciones y que debemos tomarlas para mejorar el futuro

de nuestra profesión y de las empresas.

Es importante tomarse el tiempo necesario para conocer a nuestros

clientes y usuarios, así como su ambiente de trabajo. Esto, también

ayuda a establecer una buena relación de trabajo y comunicación

entre el equipo de desarrollo y los clientes. Es realmente 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.

Entregar software de calidad, a tiempo y dentro del presupuesto, hará

que nuestros clientes confíen y asegurará el crecimiento y madurez

de la relación de negocio.

No se puede medir la calidad del software de forma correcta debido a

su naturaleza, la certificación se da a los procesos, la correcta

consecución de los mismos garantizaría un buen software. No se

puede medir al software como tal, sino los atributos que la conforman,

tales métodos de medida deben ser exactos.

El usuario final mide la calidad del software según lo que tenga o no,

es en ese sentido que la calidad del software depende de quien la

juzgue. El hecho de que una empresa tenga certificación en calidad de

software no garantiza que su software sea de calidad.

Como final de todo eso podemos exponer que el objetivo principal

de la Ingeniería de Software es lograr todo tipos de productos en

calidad de uso y de ejecución y que cumplir todos los

requerimientos de cliente o usuario, demostrar todas habilidades

conjuntamente.

P á g i n a | 42

BIBLIOGRAFIA.

Escritas:

ACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James (2000) (en

español). El Proceso Unificado de Desarrollo de Software. Pearson

Addisson-Wesley.

Pressman, Roger S. (2003) (en Español). Ingeniería del Software, un

enfoque Práctico (Quinta edición edición). Mc Graw Hill. ISBN 84-481-

3214-9.

Weitzenfeld - «El Proceso para Desarrollo de Software» - 2002

Carlos Reynoso - «Métodos Heterodoxos en Desarrollo de Software» -

2004

Electrónicas:

http://es.wikipedia.org/wiki/Historia_de_la_ingenier%C3%ADa_del_soft

ware#La_ingenier.C3.ADa_de_software_hoy

http://histinf.blogs.upv.es/2010/12/28/ingenieria-del-software/

http://www.importancia.org/software.php

http://es.wikipedia.org/wiki/Software_de_programaci%C3%B3n#Clasific

aci.C3.B3n_del_software

http://es.wikipedia.org/wiki/Editor_de_texto

http://es.wikipedia.org/wiki/Software_de_aplicaci%C3%B3n

http://jummp.wordpress.com/tag/ingenieria-del-software/

http://es.wikipedia.org/wiki/Peter_Chen

http://jummp.wordpress.com/2011/08/05/desarrollo-de-software-david-

lorge-parnas-feedback-adaptacion-y-satisfaccion-del-usuario/

http://jummp.wordpress.com/2011/11/16/desarrollo-de-software-watts-

humphrey-problema-requisitos-comprension-usuarios/

http://proyectosguerrilla.com/blog/2013/02/las-cinco-etapas-en-la-

ingenieria-del-software/

http://es.wikipedia.org/wiki/Desarrollo_en_cascada