Ingeniera de software

software.[5][6][7] En Hispanoamrica los trminos ms

comnmente usados son los dos primeros.

Ingeniera de software es la aplicacin de un enfoque sistemtico, disciplinado y cuanticable al desarrollo, operacin y mantenimiento de software,[1] y el estudio de estos enfoques, es decir, la aplicacin de la ingeniera al software.[2] Integra matemticas, ciencias de la
computacin y prcticas cuyos orgenes se encuentran en
la ingeniera.[3]

La creacin del software es un proceso intrnsecamente

creativo y la ingeniera del software trata de sistematizar
este proceso con el n de acotar el riesgo del fracaso en
la consecucin del objetivo, por medio de diversas tcnicas que se han demostrado adecuadas sobre la base de la
Se citan las deniciones ms reconocidas, formuladas por experiencia previa.
prestigiosos autores:
La IS se puede considerar como la ingeniera aplicada al
software, esto es, por medios sistematizados y con herra Ingeniera de software es el estudio de los principios mientas preestablecidas, la aplicacin de ellos de la maney metodologas para el desarrollo y mantenimiento ra ms eciente para la obtencin de resultados ptimos;
de sistemas software (Zelkovitz, 1978).
objetivos que siempre busca la ingeniera. No es slo de la
resolucin de problemas, sino ms bien teniendo en cuen Ingeniera de software es la aplicacin prctica del ta las diferentes soluciones, elegir la ms apropiada.
conocimiento cientco al diseo y construccin de
programas de computadora y a la documentacin
asociada requerida para desarrollar, operar y mante- 1 Historia
nerlos. Se conoce tambin como desarrollo de software o produccin de software (Bohem, 1976).
Cuando aparecieron las primeras computadoras digitales
[8]
La ingeniera de software trata del establecimiento en la dcada de 1940, el desarrollo de software era algo
de los principios y mtodos de la ingeniera a n de tan nuevo que era casi imposible hacer predicciones de las
obtener software de modo rentable, que sea able y fechas estimadas de nalizacin del proyecto y muchos de
ellos sobrepasaban los presupuestos y tiempo estimados..
trabaje en mquinas reales (Bauer, 1972).
Los desarrolladores tenan que volver a escribir todos sus
La ingeniera de software es la aplicacin de programas para correr en mquinas nuevas que salan caun enfoque sistemtico, disciplinado y cuantica- da uno o dos aos, haciendo obsoletas las ya existentes.
ble al desarrollo, operacin, y mantenimiento del El trmino Ingeniera del software apareci por primera
software.[1]
vez en a nales de la dcada de 1950. La Ingeniera de
software fue estimulada por la crisis del software de las
dcadas de entre 1960 y 1980. La Ingeniera del software
viene a ayudar a identicar y corregir mediante principios y metodologas los procesos de desarrollo y mantenimiento de sistemas de software.

En 2004, la U. S. Bureau of Labor Statistics (Ocina de

Estadsticas del Trabajo de Estados Unidos) cont 760
840 ingenieros de software de computadora.[4] El trmino
ingeniero de software, sin embargo, se utiliza de manera genrica en el ambiente empresarial, y no todos los
que se desempean en el puesto de ingeniero de software
poseen realmente ttulos de ingeniera de universidades
reconocidas.

Aparte de la crisis del software de las dcadas de entre

1960 y 1980, la ingeniera de software se ve afectada
por accidentes que conllevaron a la muerte de tres personas; esto sucedi cuando la mquina de radioterapia
Therac-25 emite una sobredosis masiva de radiacin y
afecto contra la vida de estas personas.[9] Esto remarca
los riesgos de control por software,[10] afectando directamente al nombre de la ingeniera de software.

Algunos autores consideran que desarrollo de software

es un trmino ms apropiado que ingeniera de software para el proceso de crear software. Personas como Pete
McBreen (autor de Software Craftmanship) cree que el
trmino IS implica niveles de rigor y prueba de proce- A principios de los 1980,[11] la ingeniera del software ya
sos que no son apropiados para todo tipo de desarrollo de haba surgido como una genuina profesin, para estar al
software.
lado de las ciencias de la computacin y la ingeniera traIndistintamente se utilizan los trminos ingeniera de dicional. Antes de esto, las tareas eran corridas poniendo
software o ingeniera del software"; aunque menos co- tarjetas perforadas como entrada en el lector de tarjetas
mn tambin se suele referenciar como ingeniera en de la mquina y se esperaban los resultados devueltos por
1

RECURSOS

la impresora.

desarrolladores para crear nuevos sistemas de bloqueo o

que se
Debido a la necesidad de traducir frecuentemente el soft- seguridad de estas anomalas en la informtica ya [10]
volvan
sumamente
tediosas
y
difciles
de
arreglar
ware viejo para atender las necesidades de las nuevas mquinas, se desarrollaron lenguajes de orden superior. A Despus de una fuerte y creciente demanda surge la
medida que apareci el software libre, las organizaciones necesidad de crear soluciones de software a bajo costo,
de usuarios comnmente lo liberaban.
esto conlleva al uso de metodologas ms simples y
rpidas que desarrollan software funcional. Cabe sealar
Durante mucho tiempo, solucionar la crisis del software
fue de suma importancia para investigadores y empresas que los sistemas ms pequeos tenan un enfoque ms
simple y rpido para poder administrar el desarrollo de
que se dedicaban a producir herramientas de software.
clculos y algoritmos de software.
Para la dcada de 1980, el costo de propiedad y mantenimiento del software fue dos veces ms caro que el propio desarrollo del software, y durante la dcada de 1990,
el costo de propiedad y mantenimiento aument 30 % 2 Objetivos
con respecto a la dcada anterior. En 1995, muchos de
los proyectos de desarrollo estaban operacionales, pero
no eran considerados exitosos. El proyecto de software La ingeniera de software aplica diferentes normas y mmedio sobrepasaba en un 50 % la estimacin de tiempo todos que permiten obtener mejores resultados, en cuanpreviamente realizada, adems, el 75 % de todos los gran- to al desarrollo y uso del software, mediante la aplicacin
des productos de software que eran entregados al cliente correcta de estos procedimientos se puede llegar a cumtenan fallas tan graves, que no eran usados en lo absolu- plir de manera satisfactoria con los objetivos fundamento o simplemente no cumplan con los requerimientos del tales de la ingeniera de software.
cliente.[10]
Entre los objetivos de la ingeniera de software estn:
Algunos expertos argumentaron que la crisis del software
era debido a la falta de disciplina de los programadores.
Cada nueva tecnologa y prctica de la dcada de 1970 a
la de 1990 fue pregonada como la nica solucin a todos
los problemas y el caos que llev a la crisis del software.
Lo cierto es que la bsqueda de una nica clave para el
xito nunca funcion. El campo de la ingeniera de software parece un campo demasiado complejo y amplio para una nica solucin que sirva para mejorar la mayora
de los problemas, y cada problema representa slo una
pequea porcin de todos los problemas de software.
El auge del uso del Internet llev a un vertiginoso crecimiento en la demanda de sistemas internacionales de despliegue de informacin en la World Wide Web. Los desarrolladores se vieron en la tarea de manejar ilustraciones,
mapas, fotografas y animaciones, a un ritmo nunca antes
visto, con casi ningn mtodo para optimizar la visualizacin y almacenamiento de imgenes. Tambin fueron
necesarios sistemas para traducir el ujo de informacin
en mltiples idiomas extranjeros a lenguaje natural humano, con muchos sistemas de software diseados para
uso multilenguaje, basado en traductores humanos.

Mejorar el diseo de aplicaciones o software de tal

modo que se adapten de mejor manera a las necesidades de las organizaciones o nalidades para las
cuales fueron creadas.
Promover mayor calidad al desarrollar aplicaciones
complejas.
Brindar mayor exactitud en los costos de proyectos
y tiempo de desarrollo de los mismos.
Aumentar la eciencia de los sistemas al introducir
procesos que permitan medir mediante normas especcas, la calidad del software desarrollado, buscando siempre la mejor calidad posible segn las necesidades y resultados que se quieren generar.
Una mejor organizacin de equipos de trabajo, en el
rea de desarrollo y mantenimiento de software.
Detectar a travs de pruebas, posibles mejoras para un mejor funcionamiento del software
desarrollado.[12]

La ingeniera de software contribuyo alrededor de 90,000

millones de dlares por ao ya que entra en juego el In- 3 Recursos
ternet; esto hace que los desarrolladores tuviesen que manejar imgenes mapas y animaciones para optimizar la
visualizacin/almacenamiento de imgenes (como el uso 3.1 Recurso humano
de imgenes en miniatura). El uso de los navegadores y
utilizacin de lenguaje HTML cambia drsticamente la Son todas aquellas personas que intervienen en la planicacin de cualquier instancias de software (por ejemplo:
visin y recepcin de la informacin.
gestor, ingeniero de software experimentado, etc.), El nLas amplias conexiones de red crea la proliferacin de mero de personas requerido para un proyecto de software
virus informticos y la basura en los correos electrnicos slo puede ser determinado despus de hacer una estima(E-mail) esto pone en una carrera contra el tiempo los cin del esfuerzo de desarrollo...

5.2

3.2

BPMN (notacin para el modelado de procesos de negocios)

Recursos de software reutilizables

Las siglas UML signican lenguaje unicado de modelado esto quiere decir que no pretende denir un modelo
Son aquellos componentes de un software que son usa- estndar de desarrollo, sino nicamente un lenguaje de
dos en otras aplicaciones de la misma ndole, ya sea para modelado.[14]
reducir costos o tiempo.
Un lenguaje de modelado consiste de vistas, elementos de
modelo y un conjunto de reglas: sintcticas, semnticas y
pragmticas que indican cmo utilizar los elementos.
3.3 Recursos de entorno
Es el entorno de las aplicaciones (software y hardware) el
hardware proporciona el medio fsico para desarrollar las 5.2
aplicaciones (software), este recurso es indispensable.[13]

BPMN (notacin para el modelado de

procesos de negocios)

El objetivo de la notacin para el modelado de procesos de negocios es proporcionar de una manera fcil de
4 Implicaciones socioeconmicas
denir y analizar los procesos de negocios pblicos y privados simulando un diagrama de ujo. La notacin ha
4.1 Econmicamente
sido diseada especcamente para coordinar la secuencia de los procesos y los mensajes que uyen entre los
En los Estados Unidos, el software contribuy a una oc- participantes del mismo, con un conjunto de actividades
tava parte de todo el incremento del PIB durante la d- relacionadas. Caractersticas bsicas de los elementos de
cada de 1990 (alrededor de 90,000 millones de dlares BPMN
por ao), y un noveno de todo el crecimiento de productividad durante los ltimos aos de la dcada (alrededor
Objetos de ujo: eventos, actividades, rombos de
de 33.000 millones de dlares estadounidenses por ao).
control de ujo (gateways).
La ingeniera de software contribuy a US$ 1 billn de
crecimiento econmico y productividad en esa dcada.
Objetos de conexin: ujo de secuencia, ujo de
Alrededor del globo, el software contribuye al crecimienmensaje, asociacin.
to econmico de maneras similares, aunque es difcil de
[cita requerida]
encontrar estadsticas ables.
Swimlanes (carriles de piscina): pool, lane.
Adems, con la industria del lenguaje est hallando cada
vez ms campos de aplicacin a escala global.
Artefactos: objetos de datos, grupo, anotacin.[14]

4.2

Socialmente

La ingeniera de software cambia la cultura del mundo

debido al extendido uso de la computadora. El correo
electrnico (e-mail), la WWW y la mensajera instantnea permiten a la gente interactuar de nuevas maneras.
El software baja el costo y mejora la calidad de los servicios de salud, los departamentos de bomberos, las dependencias gubernamentales y otros servicios sociales. Los
proyectos exitosos donde se han usado mtodos de ingeniera de software incluyen a GNU/Linux, el software del
transbordador espacial, los cajeros automticos y muchos
otros.

5
5.1

Notaciones

5.3 Diagrama de ujo de datos (DFD)

Un diagrama de ujo de datos permite representar el movimiento de datos a travs de un sistema por medio de
modelos que describen los ujos de datos, los procesos
que tranforman o cambian los datos, los destinos de datos y los almacenamientos de datos a la cual tiene acceso
el sistema.
Su inventor fue Larry Constantine, basado en el modelo
de computacin de Martin y Estrin: ujo grco de datos.
Con los diagramas de ujo de datos determina la manera
en que cualquier sistema puede desarrollarse, ayuda en la
identicacin de los datos de la transaccin en el modelo
de datos y proporciona al usuario una idea fsica de cmo
resultarn los datos a ltima instancia.[14]

LUM (lenguaje unicado de modela6

do) o UML

Es un lenguaje de modelado muy reconocido y utilizado actualmente que se utiliza para describir o especicar
mtodos. Tambin es aplicable en el desarrollo de software.

Herramientas CASE

Son herramientas computacionales (software) que estn

destinadas a asistir en los procesos de ciclo de vida de un
software, facilitan la produccin del software, varias se
basan principalmente en la idea de un modelo grco.[15]

Metodologa

Un objetivo de dcadas ha sido el encontrar procesos y

metodologas, que sean sistemticas, predecibles y repetibles, a n de mejorar la productividad en el desarrollo y
la calidad del producto software, en pocas palabras, determina los pasos a seguir y como realizarlos para nalizar
una tarea.

7.1

METODOLOGA

7.1.2 Anlisis de requisitos

Extraer los requisitos de un producto software es la primera etapa para crearlo. Durante la fase de anlisis, el
cliente plantea las necesidades que se presenta e intenta
explicar lo que debera hacer el software o producto nal para satisfacer dicha necesidad mientras que el desarrollador acta como interrogador, como la persona que
resuelve problemas. Con este anlisis, el ingeniero de sistemas puede elegir la funcin que debe realizar el software y establecer o indicar cual es la interfaz ms adecuada
para el mismo.[16]

Etapas del proceso

El anlisis de requisitos puede parecer una tarea sencilla, pero no lo es debido a que muchas veces los clientes
piensan que saben todo lo que el software necesita para
La ingeniera de software requiere llevar a cabo numerosu buen funcionamiento, sin embargo se requiere la habisas tareas agrupadas en etapas, al conjunto de estas etapas
lidad y experiencia de algn especialista para reconocer
se le denomina ciclo de vida. Las etapas comunes a casi
requisitos incompletos, ambiguos o contradictorios. Estodos los modelos de ciclo de vida son las siguientes:
tos requisitos se determinan tomando en cuenta las necesidades del usuario nal, introduciendo tcnicas que nos
permitan mejorar la calidad de los sistemas sobre los que
se trabaja.[17]
7.1.1 Obtencin de los requisitos
El resultado del anlisis de requisitos con el cliente se
Se debe identicar sobre que se est trabajando, es decir,
el tema principal que motiva el inicio del estudio y creacin del nuevo software o modicacin de uno ya existente. A su vez identicar los recursos que se tienen, en
esto entra el conocer los recursos humanos y materiales
que participan en el desarrollo de las actividades. Es importante entender el contexto del negocio para identicar
adecuadamente los requisitos.

plasma en el documento ERS (especicacin de requisitos del sistema), cuya estructura puede venir denida por
varios estndares, tales como CMMI. Asimismo, se dene un diagrama de entidad/relacin, en el que se plasman
las principales entidades que participarn en el desarrollo
del software.

La captura, anlisis y especicacin de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa
depende en gran medida el logro de los objetivos nales.
Se tiene que tener dominio de la informacin de un Se han ideado modelos y diversos procesos metdicos de
problema, lo cual incluye los datos fuera del softwa- trabajo para estos nes. Aunque an no est formalizada,
re(usuarios nales, otros sistemas o dispositivos exter- ya se habla de la ingeniera de requisitos.
nos), los datos que salen del sistema (por la interfaz de La IEEE Std. 830-1998 normaliza la creacin de las esusuario, interfaces de red, reportes, grcas y otros me- pecicaciones de requisitos de software (Software Requidios) y los almacenamientos de datos que recaban y orga- rements Specication).
nizan objetos persistentes de datos (por ejemplo, aquellos
Finalidades del anlisis de requisitos:
que se conservan de manera permanente).
Tambin hay que ver los puntos crticos, lo que signica tener de una manera clara los aspectos que entorpecen
y limitan el buen funcionamiento de los procedimientos
actuales, los problemas ms comunes y relevantes que se
presentan, los motivos que crean insatisfaccin y aquellos que deben ser cubiertos a plenitud. Por ejemplo: El
contenido de los reportes generados, satisface realmente
las necesidades del usuario? Los tiempos de respuesta
ofrecidos, son oportunos?, etc.
Hay que denir las funciones que realizara el software ya
que estas ayudan al usuario nal y al funcionamiento del
mismo programa.

Brindar al usuario todo lo necesario para que pueda trabajar en conjunto con el software desarrollado
obteniendo los mejores resultados posibles.
Tener un control ms completo en la etapa creacin
del software, en cuanto a tiempo de desarrollo y costos.
Utilizacin de mtodos ms ecientes que permitan
el mejor aprovechamiento del software segn sea la
nalidad de uso del mismo.
Aumentar la calidad del software desarrollado al disminuir los riesgos de mal funcionamiento.[18]

Se tiene que tener en cuenta como ser el comportamiento

del software ante situaciones inesperadas como lo son por
ejemplo una gran cantidad de usuarios usando el software No siempre en la etapa de anlisis de requisitos las distintas metodologas de desarrollo llevan asociado un estuo una gran cantidad de datos entre otros.

7.1

Etapas del proceso

dio de viabilidad y/o estimacin de costes. El ms cono- Lo principal en este punto es poner en claro los aspectos
cido de los modelos de estimacin de coste del software lgicos y fsicos de las salidas, modelos de organizacin y
es el modelo COCOMO
representacin de datos, entradas y procesos que componen el sistema, considerando las bondades y limitaciones
de los recursos disponibles en la satisfaccin de las paci7.1.3 Limitaciones[14]
caciones brindadas para el anlisis.
Los software tienen la capacidad de emular inteligencia
creando un modelo de ciertas caractersticas de la inteligencia humana pero slo posee funciones predenidas
que abarcan un conjunto de soluciones que en algunos
campos llega a ser limitado. Aun cuando tiene la capacidad de imitar ciertos comportamientos humanos no es
capaz de emular el pensamiento humano porque acta bajo condiciones.
Otro aspecto limitante de los software proviene del proceso totalmente mecnico que requiere de un mayor esfuerzo y tiempos elevados de ejecucin lo que lleva a tener
que implementar el software en una mquina de mayor
capacidad.

Hay que tener en consideracin la arquitectura del sistema en la cual se va a trabajar, elaborar un plan de trabajo
viendo la prioridad de tiempo y recursos disponibles. En
los diseos de salidas entra los que es la interpretacin de
requerimientos lo cual es el dominio de informacin del
problema, las funciones visibles para el usuario, el comportamiento del sistema y un conjunto de clases de requerimientos que agrupa los objetos del negocio con los
mtodos que les dan servicio.

La arquitectura de software consiste en el diseo de componentes de una aplicacin (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseo arquitectnico debe permitir visualizar la interaccin
entre las entidades del negocio y adems poder ser validado, por ejemplo por medio de diagramas de secuencia.
Un diseo arquitectnico describe en general el cmo se
7.1.4 Especicacin
construir una aplicacin de software. Para ello se docuLa especicacin de requisitos describe el comporta- menta utilizando diagramas, por ejemplo:
miento esperado en el software una vez desarrollado.
Gran parte del xito de un proyecto de software radicar
Diagramas de clases
en la identicacin de las necesidades del negocio (denidas por la alta direccin), as como la interaccin con
Diagramas de base de datos
los usuarios funcionales para la recoleccin, clasicacin,
identicacin, priorizacin y especicacin de los requi Diagrama de despliegue
sitos del software.
Diagrama de secuencia
Entre las tcnicas utilizadas para la especicacin de requisitos se encuentran:
Caso de uso
Historias de usuario

Siendo los dos primeros los mnimos necesarios para describir la arquitectura de un proyecto que iniciar a ser
codicado. Dependiendo del alcance del proyecto, complejidad y necesidades, el arquitecto elegir cuales de los
diagramas se requiere elaborar.

Siendo los primeros ms rigurosas y formales, los segun- Las herramientas para el diseo y modelado de software
das ms giles e informales.
se denominan CASE (Computer Aided Software Engineering) entre las cuales se encuentran:
7.1.5

Arquitectura

Enterprise Architect

La integracin de infraestructura, desarrollo de aplicacio Microsoft Visio for Enterprise Architects

nes, bases de datos y herramientas gerenciales, requieren
de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas
de hoy. El rol en el cual se delegan todas estas actividades 7.1.6 Programacin
es el del Arquitecto.
Implementar un diseo en cdigo puede ser la parte ms
El arquitecto de software es la persona que aade valor obvia del trabajo de ingeniera de software, pero no necea los procesos de negocios gracias a su valioso aporte de sariamente es la que demanda mayor trabajo y ni la ms
soluciones tecnolgicas.
complicada. La complejidad y la duracin de esta etaLa arquitectura de sistemas en general, es una actividad pa est ntimamente relacionada al o a los lenguajes de
de planeacin, ya sea a nivel de infraestructura de red y programacin utilizados, as como al diseo previamente
realizado.
hardware, o de software.

7.1.7

Desarrollo de la aplicacin

Para el desarrollo de la aplicacin es necesario considerar

cinco fases para tener una aplicacin o programa eciente, estas son:
Desarrollo de la infraestructura: Esta fase permite el desarrollo y la organizacin de los elementos
que formaran la infraestructura de la aplicacin, con
el propsito de nalizar la aplicacin ecientemente.
Adaptacin del paquete: El objetivo principal de
esta fase es entender de una manera detallada el funcionamiento del paquete, esto tiene como nalidad
garantizar que el paquete pueda ser utilizado en su
mximo rendimiento, tanto para negocios o recursos. Todos los elementos que componen el paquete
son inspeccionados de manera detallada para evitar
errores y entender mejor todas las caractersticas del
paquete.
Desarrollo de unidades de diseo de interactivas: En esta fase se realizan los procedimientos que
se ejecutan por un dilogo usuario-sistema. Los procedimientos de esta fase tienen como objetivo principal:
1. Establecer especcamente las acciones que debe
efectuar la unidad de diseo.

METODOLOGA

software, y luego probarlo de manera integral, para as

llegar al objetivo. Se considera una buena prctica el que
las pruebas sean efectuadas por alguien distinto al desarrollador que la program, idealmente un rea de pruebas;
sin perjuicio de lo anterior el programador debe hacer sus
propias pruebas. En general hay dos grandes maneras de
organizar un rea de pruebas, la primera es que est compuesta por personal inexperto y que desconozca el tema
de pruebas, de esta manera se evala que la documentacin entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el
software hace las cosas tal y como estn descritas. El segundo enfoque es tener un rea de pruebas conformada
por programadores con experiencia, personas que saben
sin mayores indicaciones en qu condiciones puede fallar
una aplicacin y que pueden poner atencin en detalles
que personal inexperto no considerara.
De acuerdo con Roger S. Pressman, el proceso de pruebas
se centra en los procesos lgicos internos del software,
asegurando que todas las sentencias se han comprobado,
y en los procesos externos funcionales, es decir, la realizacin de pruebas para la deteccin de errores. Se requiere
poder probar el software con sujetos reales que puedan
evaluar el comportamiento del software con el n de proporcionar realimentacin a los desarrolladores. Es importante que durante el proceso de desarrollo del software
no se pierda contacto con los interesados o solicitantes
del desarrollo de Software, de esta manera los objetivos
del proyecto se mantendrn vigentes y se tendr una idea
clara de los aspectos que tienen que probarse durante el
perodo de pruebas.[20]

2. La creacin de componentes para sus procedimientos.

3. Ejecutar pruebas unitarias y de integracin en la unidad de diseo.
Desarrollo de unidades de diseo batch: En esta
fase se utilizan una serie de combinacin de tcnicas,
como diagrama de ujo, diagramas de estructuras,
tablas de decisiones, etc. Cualquiera a utilizar ser
benecioso para plasmar de manera clara y objetiva
las especicaciones y que as el programador tenga
mayor comprensin a la hora de programar y probar
los programas que le corresponden.

7.1.9

Implementacin

Una Implementacin es la realizacin de una especicacin tcnica o algoritmos con un programa, componente
software, u otro sistema de cmputo. Muchas especicaciones son dadas segn a su especicacin o un estndar. Las especicaciones recomendadas segn el World
Wide Web Consortium, y las herramientas de desarrollo
del software contienen implementaciones de lenguajes de
programacin. El modelo de implementacin es una coleccin de componentes y los subsitemas que contienen.
Componentes tales como: cheros ejecutables, cheros
de cdigo fuente y todo otro tipo de cheros que sean necesarios para la implementacin y despliegue del sistema.

Desarrollo de unidades de diseo manuales:

En esta fase el objetivo central es proyectar todos
los procedimientos administrativos que desarrollarn en torno a la utilizacin de los componentes
7.1.10 Documentacin
computarizados.[19]

Es todo lo concerniente a la documentacin del propio

desarrollo del software y de la gestin del proyecto, pasando por modelaciones (UML), diagramas de casos de
Consiste en comprobar que el software realice correcta- uso, pruebas, manuales de usuario, manuales tcnicos,
mente las tareas indicadas en la especicacin del proble- etc; todo con el propsito de eventuales correcciones, usama. Una tcnica es probar por separado cada mdulo del bilidad, mantenimiento futuro y ampliaciones al sistema.
7.1.8

Pruebas de software

8.1

Modelo en cascada o clsico

7.1.11 Mantenimiento

evolucionar el software, desde la concepcin de una idea

hasta la entrega y el retiro del sistema y representa todas
Fase dedicada a mantener y mejorar el software para co- las actividades y artefactos (productos intermedios) nerregir errores descubiertos e incorporar nuevos requisi- cesarios para desarrollar una aplicacin,[23] entre ellos se
tos. Esto puede llevar ms tiempo incluso que el desarro- puede citar:
llo del software inicial. Alrededor de 2/3 del tiempo de
ciclo de vida de un proyecto[21] est dedicado a su mantenimiento. Una pequea parte de este trabajo consiste 8.1 Modelo en cascada o clsico
eliminar errores (bugs); siendo que la mayor parte reside
en extender el sistema para incorporarle nuevas funcio- En ingeniera de software el modelo en cascada tambin llamado desarrollo en cascada o ciclo de vida clsinalidades y hacer frente a su evolucin.
co se basa en un enfoque metodolgico que ordena rigurosamente las etapas del ciclo de vida del software, esto
7.2 Ventajas[22]
sugiere una aproximacin sistemtica secuencial hacia el
proceso de desarrollo del software, que se inicia con la es7.2.1 Desde el punto de vista de gestin
pecicacin de requisitos del cliente y contina con la planicacin, el modelado, la construccin y el despliegue
Facilitar la tarea de seguimiento del proyecto
para culminar en el soporte del software terminado.[24]
Optimizar el uso de recursos
Facilitar la comunicacin entre usuarios y desarro- 8.2 Modelo de prototipos
lladores
En ingeniera de software, el modelo de prototipos perte Facilitar la evaluacin de resultados y cumplimiento nece a los modelos de desarrollo evolutivo. Este permite
que todo el sistema, o algunos de sus partes, se construde objetivos
yan rpidamente para comprender con facilidad y aclarar
ciertos aspectos en los que se aseguren que el desarrolla7.2.2 Desde el punto de vista de los ingenieros de dor, el usuario, el cliente estn de acuerdo en lo que se
Software
necesita as como tambin la solucin que se propone para dicha necesidad y de esta manera minimizar el riesgo y
Ayudar a comprender el problema
la incertidumbre en el desarrollo, este modelo se encarga
del desarrollo de diseos para que estos sean analizados y
Permitir la reutilizacin
prescindir de ellos a medida que se adhieran nuevas especicaciones, es ideal para medir el alcance del producto,
Facilitar el mantenimiento del producto nal
pero no se asegura su uso real.
Optimizar el conjunto y cada una de las fases del
Este modelo principalmente se aplica cuando un cliente
proceso de desarrollo
dene un conjunto de objetivos generales para el software a desarrollarse sin delimitar detalladamente los requi7.2.3 Desde el punto de vista de cliente o usuario sitos de entrada procesamiento y salida, es decir cuando
nal
el responsable no est seguro de la ecacia de un algoritmo, de la adaptabilidad del sistema o de la manera en que
Garantizar el nivel de calidad del producto nal
interacta el hombre y la mquina.
Obtener el ciclo de vida adecuado para el proyecto
Conanza en los plazos del tiempo mostrados en la
denicin del proyecto

Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor manera
cul ser el resultado de la construccin cuando los requisitos estn satisfechos.[25]

Modelos y Ciclos de Vida del 8.3 Modelo en espiral

Desarrollo de Software
El modelo en espiral, que Barry Boehm propuso origi-

La ingeniera de software, con el n de ordenar el caos

que era anteriormente el desarrollo de software, dispone de varios modelos, paradigmas y losofas de desarrollo, estos los conocemos principalmente como modelos
o ciclos de vida del desarrollo de software, esto incluye
el proceso que se sigue para construir, entregar y hacer

nalmente en 1986, es un modelo de proceso de software

evolutivo que conjuga la naturaleza iterativa de la construccin de prototipos con los aspectos controlados y sistemticos del modelo en cascada, es decir, cuando se aplica este modelo, el software se desarrolla en una serie de
entregas evolutivas (ciclos o iteraciones), cada una de estas entregando prototipos ms completas que el anterior,

MODELOS Y CICLOS DE VIDA DEL DESARROLLO DE SOFTWARE

todo esto en funcin del anlisis de riesgo y las necesidades del cliente. Aunque el modelo espiral representa
ventajas por sobre el desarrollo lineal, el clculo de los
riesgos puede ser muy complicado y por lo cual su uso en
el mbito real es muy escaso.[26]

8.4

Modelo de desarrollo por etapas

Se debe tener en cuenta que el ujo del proceso de cualquier incremento puede incorporar el paradigma de construccin de prototipos, ya que como se mencion anteriormente, este tipo de modelo es iterativo por naturaleza, sin embargo se diferencia en que este busca la entrega
de un producto operacional con cada incremento que se
le realice al software.

Este desarrollo incremental es til principalmente cuando

Es un modelo en el que el software se muestra al cliente en el personal necesario para una implementacin completa
etapas renadas sucesivamente. Con esta metodologa se no est disponible.
desarrollan las capacidades ms importantes reduciendo
el tiempo necesario para la construccin de un producto;
8.5.1 Modelo estructurado
el modelo de entrega por etapas es til para el desarrollo de la herramienta debido a que su uso se recomienda
Este modelo como su nombre lo indica utiliza las
para problemas que pueden ser tratados descomponintcnicas del diseo estructurado o de la programacin
dolos en problemas ms pequeos y se caracteriza princiestructurada para su desarrollo, tambin se utiliza en la
palmente en que las especicaciones no son conocidas en
creacin de los algoritmos del programa. Este formato
detalle al inicio del proyecto y por tanto se van desarrofacilita la comprensin de la estructura de datos y su
llando simultneamente con las diferentes versiones del
control.[28] Entre las principales caractersticas de este
cdigo.
modelo se encuentan las siguientes:
En este modelo pueden distinguirse las siguientes fases:
Especicacin conceptual.
Anlisis de requisitos.
Diseo inicial.
Diseo detallado (codicacin, depuracin, prueba
y liberacin).
Cuando es por etapas, en el diseo global estas fases pueden repetirse segn la cantidad de etapas que sean requeridas.
Entre sus ventajas tenemos:
Deteccin de problemas antes y no hasta la nica
entrega nal del proyecto.
Eliminacin del tiempo en informes debido a que
cada versin es un avance.

Generalmente se puede diferenciar de una manera

ms clara los procesos y las estructuras de datos.
Existen mtodos que se enfocan principalmente en
ciertos datos.
La abstraccin del programa es de un nivel mucho
mayor.
Los procesos y estructuras de datos son representados jerrquicamente.[28]
Este modelo tambin presenta sus desventajas entre las
cuales podemos mencionar algunas:
Se poda encontrar datos repetidos en diferentes
partes del programa.[28]
Cuando el cdigo se hace muy extenso o grande su
manejo se complica demasiado.[29]

Estimacin de tiempo por versin, evitando errores

en la estimacin del proyecto general.
En el modelo estructurado las tcnicas que comnmente
se utilizan son:
Cumplimiento a la fecha por los desarrolladores.

8.5

Modelo Incremental o Iterativo

El modelo entidad-relacin, esta tcnica se relaciona

principalmente con los datos.

Desarrollo iterativo y creciente (o incremental) es un pro El diagrama de ujo de datos, esta es utilizada princeso de desarrollo de software, creado en respuesta a las
cipalmente para los procesos.[30]
debilidades del modelo tradicional de cascada, es decir,
este modelo aplica secuencias lineales como el modelo en
cascada, pero de una manera iterativa o escalada segn 8.5.2 Modelo orientado a objetos
como avance el proceso de desarrollo y con cada una de
estas secuencias lineales se producen incrementos (mejo- Estos modelos tienen sus races en la programacin orientada a objetos y como consecuencia de ella gira entorno al
ras) del software.[27]

8.8

Proceso unicado del desarrollo de software

concepto de clase, tambin lo hacen el anlisis de requisitos y el diseo. Esto adems de introducir nuevas tcnicas, tambin aprovecha las tcnicas y conceptos del desarrollo estructurado, como diagramas de estado y transiciones. El modelo orientado a objetos tiene dos caractersticas principales, las cuales ha favorecido su expansin:
Permite la reutilizacin de software en un grado signicativo.
Su simplicidad facilita el desarrollo de herramientas informticas de ayuda al desarrollo, el cual es fcilmente implementada en una notacin orientada a
objetos llamado UML.[31]

8.6

9
cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor,
el modelo de proceso concurrente dene actividades en
dos dimensiones: una divisin de sistemas y una divisin
de componentes. Los aspectos del nivel de sistemas se
afrontan mediante dos actividades: diseo y realizacin.
La concurrencia se logra de dos maneras:
Las actividades del sistema y de componente ocurren simultneamente y pueden modelarse con el enfoque orientado a objetos descrito anteriormente;
Una aplicacin cliente/servidor tpica se implementa
con muchos componentes, cada uno de los cuales se
pueden disear y realizar concurrentemente.

Modelo RAD (rapid application deveEn realidad, el modelo de desarrollo concurrente es aplilopment)

El RAD (rapid application development: desarrollo rpido de aplicaciones), es un modelo de proceso de software
incremental, desarrollado inicialmente por James Maslow en 1980, que resalta principalmente un ciclo corto de
desarrollo.

cable a todo tipo de desarrollo de software y proporciona

una imagen exacta del estado actual de un proyecto. En
vez de connar actividades de ingeniera de software a
una secuencia de sucesos, dene una red de actividades,
todas las actividades de la red existen simultneamente
con otras. Los sucesos generados dentro de una actividad
dada o algn otro lado de la red de actividad inicia las
transiciones entre los estados de una actividad.

Esta es una metodologa que posibilita la construccin de

sistemas computacionales que combinen tcnicas y utilidades CASE (Computer Aided Software Engineering),
la construccin de prototipos centrados en el usuario y el 8.8 Proceso unicado del desarrollo de
seguimiento lineal y sistemtico de objetivos, incremensoftware
tando la rapidez con la que se producen los sistemas mediante la utilizacin de un enfoque de desarrollo basado El proceso unicado es un proceso de software genrico
en componentes.[32]
que puede ser utilizado para una gran cantidad de tipos de
Si se entienden bien los requisitos y se limita el mbi- sistemas de software, para diferentes reas de aplicacin,
to del proyecto, el proceso RAD permite que un equipo diferentes tipos de organizaciones, diferentes niveles de
de desarrollo cree un producto completamente funcional competencia y diferentes tamaos de proyectos.
dentro de un periodo muy limitado de tiempo sin reducir Provee un enfoque disciplinado en la asignacin de taen lo ms mnimo la calidad del mismo.[33]
reas y responsabilidades dentro de una organizacin de
desarrollo. Su meta es asegurar la produccin de software de muy alta calidad que satisfaga las necesidades de
8.7 Modelo de desarrollo concurrente
los usuarios nales, dentro de un calendario y presupuesto predecible.[34]
El modelo de desarrollo concurrente es un modelo de tipo
de red donde todas las personas actan simultneamente El proceso unicado tiene dos dimensiones:
o al mismo tiempo. Este tipo de modelo se puede repre Un eje horizontal que representa el tiempo y muestra
sentar a manera de esquema como una serie de activilos aspectos del ciclo de vida del proceso a lo largo
dades tcnicas importantes, tareas y estados asociados a
de su desenvolvimiento
ellas.
El modelo de proceso concurrente dene una serie de
acontecimientos que dispararan transiciones de estado a
estado para cada una de las actividades de la ingeniera
del software. Por ejemplo, durante las primeras etapas del
diseo, no se contempla una inconsistencia del modelo de
anlisis. Esto genera la correccin del modelo de anlisis de sucesos, que disparara la actividad de anlisis del
estado hecho al estado cambios en espera. Este modelo de desarrollo se utiliza a menudo como el paradigma
de desarrollo de aplicaciones cliente/servidor. Un sistema

Un eje vertical que representa las disciplinas, las

cuales agrupan actividades de una manera lgica de
acuerdo a su naturaleza.
La primera dimensin representa el aspecto dinmico del
proceso conforme se va desarrollando, se expresa en trminos de fases, iteraciones e hitos (milestones).
La segunda dimensin representa el aspecto esttico del
proceso: cmo es descrito en trminos de componentes

10

11 PARTICIPANTES Y PAPELES

del proceso, disciplinas, actividades, ujos de trabajo, artefactos y roles.

10 Naturaleza de la Ingeniera de
Software

El renamiento ms conocido y documentado del proceso

unicado es el RUP (proceso unicado racional).
La ingeniera de software es una disciplina que est orienEl proceso unicado no es simplemente un proceso, sino tada a aplicar conceptos y mtodos de ingeniera al desaun marco de trabajo extensible que puede ser adaptado a rrollo de software de calidad.
organizaciones o proyectos especcos. De la misma manera, el proceso unicado de rational, tambin es un marco de trabajo extensible, por lo que muchas veces resulta 10.0.1 Matemticas
imposible decir si un renamiento particular del proceso
ha sido derivado del proceso unicado o del RUP. Por Los programas tienen muchas propiedades matemticas.
dicho motivo, los dos nombres suelen utilizarse para re- Por ejemplo la correccin y la complejidad de muchos algoritmos son conceptos matemticos que pueden ser riferirse a un mismo concepto.[35]
gurosamente probados. El uso de matemticas en la IS es
llamado mtodos formales.

Producto
10.0.2 Creacin

El software se ha convertido en algo muy necesario en

nuestra sociedad actual, es la mquina que conduce a la
toma de decisiones comerciales, sirve para la investigacin cientca moderna, es un factor clave que diferencia
productos y servicios modernos, etc. Esto se da porque el
software est inmerso en sistemas de todo tipo alrededor
de nosotros.

Los programas son construidos en una secuencia de pasos. El hecho de denir propiamente y llevar a cabo estos pasos, como en una lnea de ensamblaje, es necesario
para mejorar la productividad de los desarrolladores y la
calidad nal de los programas. Este punto de vista inspira
los diferentes procesos y metodologas que se encuentran
en la IS.

El software de computadora es el producto que disean

y construyen los ingenieros de software. Esto abarca programas que se ejecutan dentro de una computadora de 10.0.3 Gestin de Proyecto
cualquier tamao y arquitectura, despus de estar construido casi cualquier persona en el mundo industrializado, El desarrollo de software de gran porte requiere una adeya sea directa o indirectamente.
cuada gestin del proyecto. Hay presupuestos, establecimiento de tiempos de entrega, un equipo de profesionales
Los productos se pueden clasicar en:
que liderar. Recursos (espacio de ocina, insumos, equi Productos genricos: Son los producidos por una or- pamiento) por adquirir. Para su administracin se debe
tener una clara visin y capacitacin en gestin de proganizacin para ser vendidos al mercado.
yectos.
Productos hechos a medida: Sistemas que son desarrollados bajo pedido a un desarrollador especco.
Estos productos deben cumplir varias caractersticas al
ser entregados, estas son:

11 Participantes y papeles

Para el desarrollo de un sistema de software es necesaria

Mantenibles: El software debe poder evolucionar la colaboracin de muchas personas con diversas compemientras cumple con sus funciones.
tencias, capacidades e intereses. Al conjunto de personas
Conabilidad: No debe producir daos en caso de involucradas en el proyecto se les conoce como participantes.
errores.
Al conjunto de funciones y responsabilidades que hay
Eciencia: El software no debe desperdiciar los redentro del proyecto o sistema se le conoce como roles
cursos.
o papeles. Los roles estn asociados a las tareas que son
Utilizacin adecuada: Debe contar con una interfaz asignadas a los participantes, en consecuencia, una persode usuario adecuada y su documentacin.
na puede desempear uno o mltiples roles, as tambin
un mismo rol puede ser representado por un equipo.[36]
Lo que constituye el producto nal es diferente para el
ingeniero y los usuarios, para el ingeniero son los programas, datos y documentos que conguran el software pero 11.1 Cliente
para el usuario el producto nal es la informacin que de
cierto modo soluciona el problema planteado por el usua- Es frecuente el uso de los trminos usuarios, usuarios
nales y clientes como sinnimos, lo cual puede prorio.

11.5

Cdigo tico de un ingeniero de software

vocar confusin; estrictamente, el cliente (persona, empresa u organizacin) es quin especica los requisitos
del sistema,[37] en tanto que el usuario es quien utiliza u
opera nalmente el producto software, pudiendo ser o no
el cliente.

11.2

Desarrolladores

Esta clase de participantes estn relacionados con todas

las facetas del proceso de desarrollo del software. Su trabajo incluye la investigacin, diseo, implementacin,
pruebas y depuracin del software.[38]

11.3

Gestores

En el contexto de ingeniera de software, el gestor de

desarrollo de software es un participante, que reporta al
director ejecutivo de la empresa que presta el servicio de
desarrollo. Es responsable del manejo y coordinacin de
los recursos y procesos para la correcta entrega de productos de software, mientras participa en la denicin de
la estrategia para el equipo de desarrolladores, dando iniciativas que promuevan la visin de la empresa.[39]

11.4

Usuarios nales

El usuario nal es quien interacta con el producto de

software una vez es entregado.[40] Generalmente son los
usuarios los que conocen el problema, ya que da a da
operan los sistemas.

11.5

Cdigo tico de un ingeniero de software

Un ingeniero de software debe tener un cdigo donde asegura, en la medida posible, que los esfuerzos realizados
se utilizarn para realizar el bien y deben comprometerse
para que la ingeniera de software sea una profesin benca y respetada. Para el cumplimiento de esta norma,
se toman en cuenta ocho principios relacionados con la
conducta y las decisiones tomadas por el ingeniero; donde estos principios identican las relaciones ticamente
responsables de los individuos, grupos y organizaciones
donde participen. Los principios a los que deben sujetarse son sobre la sociedad, cliente y empresario, producto,
juicio, administracin, profesin, colegas y por ltimo el
personal.
Sociedad: Los ingenieros de software deben actuar
de manera congruente con el inters social, aceptando la responsabilidad total de su trabajo, moderando los intereses con el bienestar social, aprobando
el software solamente si se tiene una creencia bien
fundamentada, cooperando en los esfuerzos para solucionar asuntos importantes de inters social, ser

11
justo y veraz en todas las armaciones relativas al
software o documentos asociados.
Cliente y empresario: Se debe actuar de manera tal
que se llegue a conciliar los mejores intereses de los
clientes y empresarios, congruentemente con el inters social. Estos debern prestar servicios en sus
reas de competencia, siendo honestos y francos sobre las limitaciones, no utilizar un software que se
obtenga ilegalmente o sin tica, usar la propiedad
de los clientes o empresarios de manera autorizada,
mantener secreto cualquier documento de informacin condencial.
Producto: Hay que asegurarse que los productos y
sus modicaciones cumplan con los estndares profesionales ms altos posibles, procurando la alta calidad, costos aceptables y una agenda razonable asegurando que los costos y benecios sean claros y
aceptados por el empresario y el cliente. Asegurar
que las metas y objetivos de cualquier proyecto sean
adecuados y alcanzables.
Juicio: Se debe mantener una integridad e independencia en el juicio profesional, moderando todo juicio tcnico por la necesidad de apoyar y mantener
los valores humanos, mantener la objetividad profesional con respecto a cualquier software o documento relacionado, no involucrarse en prcticas nancieras fraudulentas.
Administracin: Se deber asegurar una buena administracin para cualquier proyecto en el cual se
trabaje, utilizando procedimientos efectivos para
promover la calidad y reducir riesgos, asegurndose tambin que se conozcan las polticas y procedimientos del empresario para proteger contraseas,
archivos e informacin condencial.
Profesin: Se debe incrementar la integridad y reputacin de la profesin en conjunto con el inters social, ayudando al desarrollo de un ambiente organizacional favorable para actuar, promoviendo el conocimiento pblico de la ingeniera de software, extendiendo el conocimiento de la ingeniera de software por medio de participaciones en organizaciones, reuniones y publicaciones profesionales.
Colegas: Cada ingeniero deber apoyar y ser justos
con los colegas, motivando a sus colegas sujetndose
al cdigo, ayudando tambin a su desarrollo profesional, reconocer los trabajos de otros y abstenerse
a atribuirse de mritos indebidos, revisar los trabajos de manera objetiva, sincera y propiamente documentada.
Personal: Los ingenieros de software participaran
toda su vida en el aprendizaje con la prctica y pro-

12

14
movern un enfoque tico de la profesin, mejorando su conocimiento de los avances en el anlisis, especicacin, diseo, desarrollo, mantenimiento, pruebas del software y documentos relacionados en conjunto con administracin del proceso de
desarrollo.[41]

REFERENCIAS

[3] ACM (2006). Computing Degrees & Careers. ACM.

Consultado el 23 de noviembre de 2010.
[4] Bureau of Labor Statistics, U.S. Department of Labor,
USDL 05-2145: Occupational Employment and Wages,
November 2004, Table 1.
[5] Universidad Siglo XXI,Argentina,

12
12.1

Educacin tica
Organizaciones

IEEE Computer Society

Association for Computing Machinery (ACM).
Software Engineering Institute (SEI).
British Computer Society (BCS).
RUSSOFT Association
Society of Software Engineers

13

Vase tambin

Anexo:Filosofas del desarrollo de software

[6] Universidad Autnoma de Guadalajara, Mxico,

[7] Tecnolgico de Antioqua, Colombia,
[8] Leondes (2002). intelligent systems: technology and applications. CRC Press. ISBN 978-0-8493-1121-5.
[9] An Investigation of Therac-25 Accidents
[10] Computer Risks
[11] Software engineering... has recently emerged as
a discipline in its own right. cita libro | apellidos=Sommerville|
nombre=Ian|
ttulo=Software
Engineering| editorial=Addison-Wesley| ao=1985|
ao-original=1982| isbn = 0-201-14229-5| postscript=
[12] Universidad Politcnica de Madrid. Objetivos de ingeniera del software.
[13] Pressman, Roger S. (2003). El proceso. Ingeniera del
software, un enfoque prctico. Mxico: Mc Graw Hill,
quinta edicin.

Ingeniera informtica

[14] Ingenieria de SoftwareUML, artculo en el sitio web Monografas.

Gestin de la conguracin

[15] Monograas.com Ingeniera del software

Proceso para el desarrollo de software

[16] [http://yaqui.mxl.uabc.mx/~{}molguin/as/IngReq.htm

Mantenimiento de software

[17] [http://www.slideshare.net/marfonline/
analisis-de-requerimientos-ingenieria-de-software

Fragilidad del software

Error de software
Usabilidad
MTRICA
Historia de la ingeniera del software
Crisis del software
No hay balas de plata

14

Referencias

[1] IEEE Standard Glossary of Software Engineering

Terminology, IEEE std 610.12-1990, 1990. ISBN
155937067X.
[2] SWEBOK executive editors, Alain Abran, James W.
Moore; editors, Pierre Bourque, Robert Dupuis. (2004).
Pierre Bourque and Robert Dupuis, ed. Guide to the Software Engineering Body of Knowledge - 2004 Version.
IEEE Computer Society. pp. 11. ISBN 0-7695-2330-7.

[18] [http://www.slideshare.net/marfonline/
analisis-de-requerimientos-ingenieria-de-software
[19] Unidad 2: Fundamentos de la ingeniera del software,
artculo en el sitio web Ing Software.
[20]
[21] Pressman, Roger S. (2003). El proceso. Ingeniera del
software, un enfoque prctico. Mxico: Mc Graw Hill,
quinta edicin.
[22] Metodologia de ingeniera de software, artculo en el sitio
web Slide Share.
[23] Ingeniera de software: ciclos de vida y metodologas, artculo publicado en el sitio web de la Facultad de Ingeniera de la Universidad de Los Andes.
[24] Pressman, Roger S.: Ingeniera del software: un enfoque
prctico. Sexta edicin, pg. 50-51.
[25] Lawrence Peleeger, Shari: Ingeniera de software: modelo
de prototipos. Universidad Estatal de Milagro.
[26] Pressman, Roger S.: Ingeniera del software: un enfoque
prctico. Sexta edicin, pg. 58-60.

13

[27] Pressman, Roger S.: Ingeniera del software: un enfoque

prctico. Sexta edicin, pg. 52-53.
[28] Diseo estructurado, artculo en el sitio web Slide Share.
[29] , cuadro comparativo de programacin estructurada y programacin orientada objeto .
[30] , Benet Campderrich Falgueras, Editorial UOC, 2002 320 pginas.
[31] Campderrich Falgueras, Benet (2002): Ingeniera de software. Barcelona: Editorial UOC, 2002. 320 pginas.
[32] , What is Rapid Application Development?
[33] Pressman, Roger S.: Ingeniera del software: un enfoque
prctico. Sexta edicin, pg. 53-54.
[34] Proceso unicado del desarrollo de software, artculo
en el sitio web Yaqui.
[35] Pressman, Roger S.: Ingeniera del software: un enfoque
prctico. Sexta edicin, pg. 67-72.
[36] Bernd Bruegge & Allen H.Dutoit. Object-Oriented Software Engineering, Prentice Hall, Pag. 11.
[37] Pressman, 2002, p. 39
[38] O*NET Code Connector - Software Developers, Systems Software - 15-1133.00. Onetcodeconnector.org.
Consultado el 4 de agosto de 2014.
[39] Software Development Manager Position Description.
interfacing.com. Consultado el 4 de agosto de 2014.
[40] Pressman, 2002, p. 39
[41] Ingeniera de Software Cdigo de tica y Prctica Profesional. SEERI, East Tennessee State University. 1999.

15

Bibliografa

Ingeniera de software (sexta edicin), Ian Sommerville. Addison Wesley. Sitio en Ingls
Pressman, Roger S.: Ingeniera del software: un enfoque prctico (informacin en ingls). McGraw Hill
Higher Education, sexta edicin, pg. 50-51.</ref>

16

Enlaces externos
Wikiversidad alberga proyectos de aprendizaje
sobre Ingeniera de software.Wikiversidad

Is software engineering actually engineering?, artculo publicado en The Iron Warrior, publicacin
de la University of Waterloo Engineering Society.

14

17 ORIGEN DEL TEXTO Y LAS IMGENES, COLABORADORES Y LICENCIAS

17
17.1

Origen del texto y las imgenes, colaboradores y licencias

Texto

Ingeniera de software Fuente: https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software?oldid=85618478 Colaboradores: Zeno

Gantner, 4lex, Caligari~eswiki, Soniautn, Sabbut, Moriel, Sauron, JorgeGG, Lourdes Cardenal, ManuelGR, Head, Lsanabria, Rosarino,
Dodo, Jonik, Jynus, Ascnder, Sms, Rsg, Cookie, Tano4595, Robotito, JavierCantero, Amana, Ograma, Rodrigouf, Cinabrium, Porao,
Loco085, Jabernal, Renabot, Richy, Robotkarel, Chlewey, Soulreaper, Petronas, Airunp, JMPerez, Edub, Taichi, Emijrp, Rembiapo pohyiete (bot), Magister Mathematicae, RobotQuistnix, Platonides, Chobot, Afpineda, Yrbot, Baito, BOT-Superzerocool, Adrruiz, Mortadelo2005, Martingala, GermanX, The Photographer, Tigerfenix, Ppja, Maldoror, Covi, BOTpolicia, CEM-bot, Jorgelrm, Laura Fiorucci,
Eneaslabra, Ignacio Icke, Osepu, Dou1985, Davius, Govelamo, Antur, Juan.palacio, Julian Mendez, Gafotas, Genaro Rafael, Fsd141,
Jonpagecr, Diosa, Bot que revierte, Eidansoft, Ninovolador, Botones, Isha, Arcibel, Migp~eswiki, JAnDbot, Jugones55, Antipatico, Xavigivax, Gsrdzl, Fugarte, Humberto, Netito777, Fixertool, Nioger, Plux, Developer, Manuel Trujillo Berges, Biasoli, Bucephala, VolkovBot,
Drever, Technopat, Jose gueredo, Galandil, Queninosta, Raystorm, MasterNoX, Belgrano, Matdrodes, Autonomia, Gmarinp, Muro Bot,
Jmvgpartner, SieBot, Ctrl Z, Carmin, Hompis, Bigsus-bot, Alben9586, Switcher6746, Navarroaxel, Greek, BuenaGente, Mafores, Fadesga,
Arnombela, Tirithel, Javierito92, Marcecoro, Antn Francho, Nicop, Brayan Jaimes, Eduardosalg, Qwertymith, Graimito, Leonpolanco,
Pan con queso, LordT, Furti, Poco a poco, Rge, Camilo, UA31, SergioN, Climens, Andres romeroc, AVBOT, Flakinho, Diegusjaimes,
Davidgutierrezalvarez, CarsracBot, Arjuno3, Saloca, Andreasmperu, Luckas-bot, Jaromero, Nallimbot, Sergiportero, Vic Fede, Dangelin5,
ArthurBot, Usuwiki, Txangu22, Jefrcast, Angelux3000, SuperBraulio13, Xqbot, Jkbw, FrescoBot, Josemariasaldana, Igna, Botarel, Kraixx,
Ochonueve98, Yabama, BOTirithel, Maria.Jose.Garcia.UEM, Brian26, Luysys, RedBot, Fidelleandro, Abece, Leugim1972, PatruBOT,
Dinamik-bot, Jpussacq, Axvolution, EmausBot, Burny~eswiki, Savh, ZroBot, Joinsolutions, Hdavila1, Grillitus, Cris Dav CDVS, Kasirbot, MerlIwBot, JABO, KLBot2, Ayaita, Thehelpfulbot, Iranvaur, AvocatoBot, Sebrev, MetroBot, Diegosangz, TQLEOFULL, Raes123,
Aine Takarai, Felener, Makecat-bot, Ralgisbot, Withsell, Legobot, Ssamuel, Addbot, Balles2601, MarielCB, Guilberth, Ricardo concepcion, DianaJMZr18, Isaacjuc, Bryanro, Franklin.ayarza, Starmird, FlareXIII, Abdiel Williams, LisleidysDominguez, Joseline Jaramillo,
Neogeo02, RicardoFong, Albert-507, Joxeph18, Javrro, Alecjz, Jarould, Lomejordejr, Miranda23~eswiki, BenjaBot, Jos Toms reyes
rodriguez, FidiasX y Annimos: 401

17.2

Imgenes

Archivo:Spanish_Language_Wiki.svg Fuente: https://upload.wikimedia.org/wikipedia/commons/2/2a/Spanish_Language_Wiki.svg

Licencia: CC BY-SA 3.0 Colaboradores: Derived from Wiki puzzle.svg by user:Kimbar Artista original: James.mcd.nz
Archivo:Wikiversity-logo-Snorky.svg Fuente: https://upload.wikimedia.org/wikipedia/commons/1/1b/Wikiversity-logo-en.svg Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Snorky

17.3

Licencia del contenido

Creative Commons Attribution-Share Alike 3.0