Ingenieria de Software

lOMoARcPSD|6168564
Ingeniería de Software
Ingenieria de Software (Universidad Siglo 21)
StuDocu no está patrocinado ni avalado por ningún colegio o universidad.

Descargado por Julian Nicolas Ottonello Constantinidis (ottocons90@gmail.com)
lOMoARcPSD|6168564
Unidad 1: Ingeniería de Software

1.1 Ingeniería de Software
1.1.1 Concepto de Ingeniería de Software

La Ingeniería de software es una disciplina, como expresa su nombre, de Ingeniería, la cual
comprende todos los aspectos de la producción de software, es decir, desde las etapas iniciales
de la especificación del sistema, lo que debe hacer, hasta su entrega y mantenimiento. El
mantenimiento del software se realiza después de haber sido entregado al cliente y éste lo está
utilizando.
Otra definición que podemos plantear es la de D. L. Parnas (Programming Methodology, 4th

Informatik Symposium, 1974), quien definió a la ingeniería en software como “multi-person
construction of multi-version software”, su traducción sería “varias personas en la construcción de
multiversión de software”.
Es lógico pensar que el software que se produce funciona correctamente y satisface las
necesidades del cliente, para que esto sea así es necesario que se cumplan varias etapas del
desarrollo del mismo y los recursos humanos involucrados deben ser capaces de hacerlo cumplir.
Para ello resulta necesario conocer conceptos fundamentales que hacen a la Ingeniería de
software.
Los ingenieros son los encargados de hacer que los software funcionen, para ello aplican teorías,
métodos y herramientas de forma selectiva, tratando de descubrir soluciones a los problemas
existentes o futuros, aún cuando no existan teorías o métodos aplicables a la resolución de dichos
problemas.
Todo proyecto tiene restricciones de tiempo, organizacionales y de presupuesto, por lo que el

ingeniero debe tener en cuenta en la resolución de los problemas estas restricciones. Son
entonces los encargados de llevar el proyecto adelante y que éste sea con éxito, para ello deberá
realizar la gestión integral del proyecto, el desarrollo de herramientas, teorías y/o métodos que
apoyen la producción de software.
El trabajo del ingeniero debe ser sistémico y organizado, como lo determina la Ingeniería, si quiere
obtener un software de alta calidad, pero a su vez necesita ser flexible a los cambios y tener un
enfoque más informal y creativo para algunos casos que lo requieran.
Para entender mejor la definición primero tiene que conocer el concepto de software.
¿Qué es software?
El software es más que programas; tiene una característica muy importante que hay que atender:
es un sistema.
Antes de mirar más profundamente el proceso de creación de software, será útil explorar algunos
aspectos del software mismo. Como dice el viejo adagio: “para derrotar a tu enemigo hay que
conocerlo”. (Freeman).
Lo importante es definir qué es software, cómo se piensa en él y qué papel cuenta en un contexto
mayor. Si nuestro concepto de software es sólo desde el punto de vista de una computadora, será
Materia: Ingeniería de Software -1-

Profesora: Lic. Adriana Pérez
lOMoARcPSD|6168564
sólo programas, líneas de código que se producen en un determinado tiempo; esto es un error, ya
que nos llevará a tener montañas de códigos que no se integrarán como sistema y que no
lograrán satisfacer las necesidades del cliente, aunque técnicamente sean correctos.
Software es un conjunto de programas que se ejecutan en un ordenador y la documentación

asociada, de este modo los “productos de software” pueden desarrollarse para un cliente en
particular o para un mercado particular o general.
Existen tres tipos básicos de software:

 System software
 Utilitarios
 Software de Aplicación
Cualquiera sea el tipo de software, requiere de información que lo acompañe para su correcto
entendimiento y uso para luego mantenerlo, caso contrario lo llevará a tener errores que no
podrán ser salvados en el tiempo.
El software tiene características que es importante conocer, veamos algunas de ellas.
Su Naturaleza y Cualidades:
 El software es fácilmente modificable, lo que implica que el código responde a una lógica y
normalmente es de quien lo construye, por lo que si cambia el actor es muy posible que
cambie el código.
 No es tangible, como otros productos. Al ser intangible no es fácil imaginarse el tamaño o
la forma del software, muchas veces se cree que realizar una aplicación o una nueva
funcionalidad es algo simple, pero la mayoría de las veces implica un gran trabajo difícil de
visualizar.
Clasificación de las Cualidades:

 Externas versus internas, se pueden considerar como externas la usabilidad del software
por los usuarios, mientras que la interna es técnica, la ven quienes codifican. Es posible
que un software esté muy bien diseñado y codificado pero al usuario le resulte difícil de
entender y usar, o totalmente al revés, el usuario solicita algo que mientras lo entienda y
sea fácil de usar no importa si técnicamente está bien realizado. Lo óptimo es que cumpla
con ambas condiciones.
 Cualidades de producto y proceso. El proceso de desarrollo de software dará un producto
final que se espera que sea de calidad y satisfaga las necesidades del cliente, para ello el
proyecto deberá ser exitoso y el proceso de software también.
Cualidades Representativas:
 Correctitud, confiabilidad y robustez
o Correctitud: un programa es “funcionalmente correcto” si se comporta acorde a la
especificación de la función que debería proveer.
o Confiabilidad: un programa es confiable si el usuario puede depender de él. El
software no debe causar daño físico o económico si falla.
o Robustez: un programa es robusto si se comporta “razonablemente”, aún en
situaciones que no fueron anticipadas en los requerimientos.
 Performance: afecta la usabilidad de un sistema
 Confiabilidad: El software no debería malgastar el uso de los recursos del sistema.
 Amigabilidad: esto ocurre si los seres humanos lo encuentran fácil de usar
 Verificabilidad: esto ocurre si sus propiedades pueden ser verificadas fácilmente

lOMoARcPSD|6168564
 Mantenibilidad: se refiere a modificaciones que se le hacen al software después de su

lanzamiento inicial. Es software debería evolucionar acompañando el cambio que puede
ser:
o Reparativo.
o Evolutivo
 Reusabilidad: software o componentes de él que permiten evolucionar a otra versión con
mínimas modificaciones
 Portabilidad: si corre en diferentes ambientes, plataformas, entendiendo por plataforma al
hardware y sistema operativo.
 Comprensible: si es fácil de entender por otros
 Interoperabilidad: si el software es capaz de convivir con otros
 Productividad: la eficiencia puesta en el proceso
 Entrega en fecha: entregar un producto en el tiempo previsto
 Visibilidad: si todos los pasos y su actual estado están documentados claramente.
Si el software es lo que se entrega al cliente, entonces se puede considerar un producto.
Software como producto
Desde los años ‟60 se comenzó a separar el concepto de software de hardware, fue entonces que
comenzó a constituirse como producto.
El software es tanto un producto como un objeto técnico, esto es: conocimiento empaquetado.
Software como conocimiento
Si los programas que se entregan al finalizar el proceso de desarrollo contienen conocimiento,

entonces sus primeras versiones también contienen conocimiento, que en el punto de vista de
vista de software sólo como programas ejecutables lo perdemos. No perder este conocimiento es
uno de los pilares de la característica de “reusabilidad” del software.
Este conocimiento es de las personas que intervienen en el proyecto, cada uno aporta algo a un
todo, si este conocimiento no queda documentado se pierde en el tiempo, ya sea porque las
personas se van del proyecto o por olvido.
Como el software es maleable y responde a cambios, es importante pensarlo de otra forma, un

cambio en el software atiende a un cambio de diseño más que de código.
El proceso de producción de software atiende más al diseño e implementación que a la

manufactura del mismo.
Las visiones del producto de software atienden a distintos actores, cada uno espera algo distinto
de él:
 Usuario: que sea confiable, eficiente y fácil de usar.
 Productor: que sea verificable, mantenible, portable y extensible.
 Administrador del proyecto: productivo y fácil de controlar.
Es por ello que el software que se entrega es un producto compuesto por programas ejecutables y
documentación que lo acompaña.
Veamos las características que tiene el producto de software:

lOMoARcPSD|6168564
 Es un software más sofisticado

 Es usado por personas distintas al desarrollador
 Es extensivamente testeado antes de ser liberado
 Su costo de desarrollo es 3 veces mayor al de un programa
Recordemos también el concepto y alguitas características de sistema:

 Grupo de programas que trabajan juntos
 Su desarrollo es complicado debido a la complejidad de sus interfaces entre los
componentes
 Integración
 Su desarrollo cuesta 3 veces lo que cuesta desarrollar un programa
Si unimos todos los eslabones de esta cadena de conceptos, podemos identificar qué es un
“Sistema producto”:
 Tiene el “pulido” de un programa
 Múltiples partes de un sistema
 Su costo de desarrollo cuesta alrededor de 9 veces más que un simple programa
Otras de las diferencias importantes de entender son las relacionadas con la Ingeniería en
sistemas.
¿Cual es la diferencia entre Ingeniería en Software y el Profesional en Sistemas?
La Ingeniería en Sistema se ocupa de todos los aspectos del desarrollo de un sistema (aspectos
humanos, de software, de hardware, de procesos, otros), mientras que la Ingeniería en Software
es parte de ese proceso.
Así la Ingeniería de software debe cumplir con los siguientes principios, que son indispensables
para lograr un producto final de calidad:
 Rigor y formalidad
 Separación de intereses
 Modularidad
 Abstracción
 Anticipación al cambio
 Generalidad
 Incrementabilidad
El Rol del Ingeniero de Software. A veces se confunden los roles con los ingenieros de otras
disciplinas; si bien tienen algunas en común, es bueno identificar aquellas que hacen
específicamente al rol del Ingeniero en Software:
 Buen programador. Es necesario que reúna las características de un buen programador,
no es indispensable que sea en un lenguaje determinado, sino que haya adquirido las
herramientas necesarias para resolver un problema a través de la programación.
 Enfoques de diseño. Debe ser capaz de realizar buenos diseños de software.
 Niveles de abstracción, haber adquirido un nivel de abstracción que le permita ver la
solución de forma intangible.
 Saber modelar. Realizar un modelo conceptual es indispensable para luego poder
plasmarlo en el producto concreto.
 Habilidades de comunicación interpersonal. La comunicación y las buenas relaciones con
los integrantes del equipo son fundamentales para lograr un ambiente de trabajo
productivo.

lOMoARcPSD|6168564
 Ser capaz de planificar su trabajo y el de otros. Con desorganización no se produce

software de calidad, por lo que la planificación de las actividades es fundamental.
Como en todas las profesiones el Ingeniero de software de tener presente la ética y la

responsabilidad profesional:
 Responsabilidades que van más allá de la simple aplicación de habilidades técnicas.
 Los Ingenieros en Software se deben comportar en forma honesta y éticamente
responsables para ser respetados como profesionales.
 La conducta ética es más que el simple cumplimiento de la ley.
Temas de la responsabilidad profesional:

 Confidencialidad
 Competencia
 Derechos de propiedad Intelectual
 Malas practicas
Algunos dilemas éticos que se pueden presentar son:

 Desacuerdo con las políticas de la dirección.
 Su empleador actúa en forma no ética y libera software de características críticas sin
terminar las fases de testeo.
 Participación en el desarrollo de software militar y armamento nuclear
1.1.2 Problemas de la ingeniería de Software. La crisis de desarrollo

de software
Las economías de TODAS las naciones desarrolladas son dependientes del software, si
atendemos esta afirmación el software debe garantizar buenos negocios y nunca pérdida de
dinero.
La fabricación industrial, comercial y del sistema financiero está totalmente informatizada, por lo
que producir software costeable es fundamental para el funcionamiento de la economía nacional e
internacional.
Existieron factores que influyeron para que el software no fuese costeable:

 La evolución de la tecnología.
 El proceso de desarrollo
 La administración de proyectos
 El mantenimiento del software
La noción de Ingeniería del software fue introducida en 1968 en una conferencia para discutir lo
que se llamó “Crisis del software”, resultado de la introducción de nuevas tecnologías en hardware
basadas en circuitos integrados. Así, el software que se producía implicaba nuevos conocimientos
y nuevos lenguajes de programación con software de magnitudes mayores y más complejos que
los sistemas previos.
Durante años el desarrollo de Software ha sido un arte, una tarea artesanal basada en el
conocimiento de los desarrolladores de código y del cliente. Se suponía que el cliente sabía lo que
necesitaba y lo solicitaba, generalmente lo hacía directamente a los desarrolladores y en el mejor
de los casos al Gerente del área de Investigación y Desarrollo.

lOMoARcPSD|6168564
Este tipo de práctica sólo llevó a vivir “La crisis del software”, clientes insatisfechos y pérdida de
dinero para los dueños de las consultoras.
Esta forma de trabajar tiene un alto riesgo, cuando se carece de profesionalidad y calidad en el
producto final.
Para revertir esta situación en un principio se incorporó una persona como intermediario entre el
cliente y el desarrollador, el “Comercial” quien tenía la función de comunicar el requerimiento del
cliente a desarrollo, pero es evidente que entre lo que el cliente ve, necesita, piensa que ve o
piensa que necesita y lo que recepta el intermediario hay diferencias, de más está decir que la
diferencia se amplía cuando se transmite, lo que lleva inevitablemente a no cubrir las expectativas
del cliente.
¿Cuánto tiempo y dinero se pierde cada vez que se trata de resolver un error? Se cobra por
desarrollar un software y por mantenerlo pero no para solucionarlo, donde las horas de
recodificación son a cargo del dueño de la consultora de software.
Por otro lado:

¿Quién prueba el software? ¿El cliente? La respuesta debería ser no, ya que al cliente le debe
llegar el producto final funcionando correctamente, para lo cual se agrega el rol de Tester interno
en la empresa.
Con estas medidas podríamos solucionar en parte los problemas, es común escuchar expresiones
tales como, “El problema es el código”, “los que no saben son los desarrolladores”, pero la verdad
no es ésa.
Está comprobado que el mayor problema está en la captura del requerimiento, tarea que requiere
de conocimiento de negocio, de análisis y diseño de interfaz gráfica, porque es la persona
encargada de interpretar correctamente el problema, transmitirlo y documentarlo con la garantía
de que éste responde al requerimiento del cliente. Tan importante es esta tarea que hoy es tratada
como “Ingeniería de Requerimiento”.
La experiencia previa en la construcción de estos sistemas mostró que un enfoque informal para
el desarrollo del software no era bueno. Los grandes proyectos no se entregaban en término con
retrasos de años, costaban mucho más que lo presupuestado, totalmente irrealizables, difíciles de
mantener y con pobre desempeño.
Mientras el hardware mostraba avances tecnológicos que lo hacían superior y bajaban los costos,
el software sufría una evolución totalmente al revés.
Estaba claro que se necesitaba revertir esta situación y para ello había que fijar los lineamientos
para que la producción de software se convirtiera en una Ingeniería, nuevas técnicas y métodos
para controlar la complejidad inherente a los grandes sistemas.
Tomamos la definición de Ingeniería de software de Fairley (“Ingeniería de Software”, 1987): “La

Ingeniería de Software es la disciplina tecnológica y de administración que se ocupa de la
producción y evolución sistemática de productos de software que son desarrollados y modificados
dentro de los tiempos y costos estimados”.
En estos tiempos donde las empresas necesitan ser competitivas, responder al dinamismo de los
cambios en forma eficiente es sumamente importante, para ello se define un correcto proceso de
software, donde el cliente está al inicio y al final, desde el requerimiento hasta la entrega,

lOMoARcPSD|6168564
estableciendo las etapas mínimas que garantizan un producto de calidad y la satisfacción del
cliente.
Sabemos que no hay un “ideal” de la Ingeniería de software, debido a la gran diversidad de tipos
de sistemas y organizaciones que los usan, por lo que necesitamos tener diversos enfoques para
el desarrollo de software, no obstante, las nociones fundamentales de procesos y organización del
sistema constituyen la base de todas las técnicas y, a su vez, son la esencia de la Ingeniería de
software.
El desafío es ponerse en movimiento hacia el cambio en post de la mejora continua,

acompañando al crecimiento profesional y económico de todos.
1.1.3 Diferencias entre Ingeniería de Software y Ciencia de la

Computación.
Otra diferencia importante a destacar es el concepto de “Ciencia de la computación” con el de
“ingeniería de software”.
La Ciencia de la computación comprende la teoría y fundamentos, mientras que la ingeniería de

software comprende las formas prácticas para desarrollar y entregar un software requerido y útil
para el cliente.
La ingeniería de software, al atender el proceso de desarrollo de software, se diferencia de la

“ingeniería en sistemas”, ya que esta última se refiere a todos los aspectos del desarrollo de
sistemas informáticos, incluye hardware, software e ingeniería de procesos.
Concepto de sistema
El término Sistema es utilizado universalmente, aplicado a todas las disciplinas, en el caso de la

computación hablamos de Sistemas Operativos, sistemas informáticos, sistema educativo,
sistemas contables y financieros, entre otros. Si bien difieren unos de otros, todos entienden que
un sistema es más que una suma de partes.
Definición de Sommerville: “Un sistema es una colección de componentes interrelacionados que

trabajan conjuntamente para cumplir algún objetivo”.
Esta definición es tan amplia que puede incluir a sistemas tan simples como puede ser un velador
o un bolígrafo, hasta los sistemas muy complejos como podría ser un sistema de aviación o de
seguridad aérea, entre muchos otros casos posibles que incluyen diversas tecnologías, hardware
y software.
Los sistemas informáticos que incluyen software se dividen en dos categorías:

 Sistemas técnicos informáticos. Estos sistemas incluyen hardware y software pero no
incluyen procesos ni procedimientos. Como ejemplo de estos sistemas están los
electrodomésticos como lavarropas automáticos, microondas, como también los
televisores, los teléfonos móviles y las computadoras con sus componentes internos. Los
sistemas como herramientas informáticas tales como los procesadores de texto o las
planillas de cálculo también entran en esta categoría.
 Sistemas socio-técnicos. Estos sistemas comprenden uno o más sistemas técnicos pero
además incluyen el conocimiento necesario para su uso para lograr su funcionalidad.

lOMoARcPSD|6168564
Significa que estos sistemas incluyen los procesos y procedimientos operativos, las
personas que lo operan, las reglas internas, de negocio, como también las reglas externas
que rigen su uso y funcionamiento. Como ejemplo podemos citar un sistema de facturación
que incluye los procesos necesarios, las reglas impositivas que lo rigen y las reglas
internas de la organización.
Entre las características fundamentales de los sistemas socio-técnicos encontramos las

siguientes:
 Tienen propiedades emergentes, propiedades del sistema como un todo más que
asociadas con las partes del sistema, que dependen tanto de los componentes como de
las relaciones entre ellos. Estas propiedades pueden ser evaluadas luego de ser
implementado el sistema.
 Por lo general no son sistemas determinísticos. No siempre producen la misma salida con
una entrada específica, ya que el comportamiento del sistema depende de operadores
humanos, de su uso y tratamiento. Además, se debe contemplar la posibilidad de que el
sistema pueda proporcionar nuevas relaciones entre sus componentes.
 El grado de apoyo a los objetivos organizacionales no depende solamente del sistema. La
concreción de los objetivos dependen de la estabilidad de los mismos, conflictos entre
cómo son planteados e interpretados por las personas, así dependiendo de las personas
un sistema exitoso puede convertirse en un fracaso y no utilizarlo.
Teniendo en cuenta lo expresado anteriormente, las propiedades emergentes de un sistema se

dan en conjunto cuando el sistema ha sido implementado completamente e interactúan sus
componentes de forma integral.
Estas propiedades emergentes pueden considerarse como funcionales y no funcionales:

 Funcionales, cuando todos los componentes del sistemas trabajan conjuntamente para
lograr un objetivo común.
 No funcionales, se refieren al comportamiento de los sistemas en su entorno operativo.
Entre ellas encontramos, la fiabilidad, el rendimiento, la seguridad y la protección.
Entre estas propiedades no funcionales, la fiabilidad es quizás la más importante ya que se puede
aplicar a los cinco componentes principales de los sistemas socio-técnicos, fiabilidad del
hardware, del software, de las personas que lo operan, de los procesos definidos y de los datos
utilizados.
¿Cuáles son las diferencias entre el proceso de la ingeniería de sistemas y el proceso de

desarrollo de software?
 El desarrollo de sistemas tiene un alcance limitado para rehacer el trabajo. Cuando se han
tomado las decisiones en la Ingeniería del sistema se han planteado las etapas y las
acciones de cada una, donde cada etapa verifica con la anterior si el camino es el correcto,
por lo que pensar en cambios a la mitad del proceso traería costos y riesgos muy grandes.
Las etapas que se identifican en el proceso de Ingeniería de sistemas son las siguientes:
o Definición de requerimientos
o Diseño del sistema
o Desarrollo del subsistema
o Integración del sistema
o Instalación del sistema
o Evolución del sistema
o Desmantelamiento del sistema

lOMoARcPSD|6168564
 Alcance interdisciplinario. En la Ingeniería de sistemas se conjugan muchas Ingenierías,

como puede ser la electrónica con la mecánica y la de software.
El proceso de desarrollo de software involucra:
 procesos de negocio,
 procedimientos operativos que se deben tener en cuenta a la hora de diseñar los procesos
informatizados,
 las necesidades del cliente que se traducen en requerimientos funcionales para el
software,
 los requerimientos no funcionales, que hacen a la forma de presentación o performance
del software,
 los requerimientos candidatos, que son las funcionalidades que no se informatizarán en
este momento, pero que se tendrán en cuenta para el futuro,
 las etapas de captura de requerimiento, análisis, diseño, codificación, prueba, instalación y
mantenimiento.
 Las personas, cada una en el rol que se le requiere, tanto las internas como grupo de
trabajo del proceso de desarrollo como las externas como clientes y usuarios.
 Los cambios organizacionales, de procesos, de personas, tanto internos como externos.
1.2 Ciclo de Vida
1.2.1 Ciclo de Vida: Conceptos de Proceso de Desarrollo de Software.
Proceso de desarrollo de software
Se entiende por proceso de software al conjunto estructurado de actividades para desarrollar un

sistema de software.
Estas actividades varían dependiendo de la organización y el tipo de sistema que debe

desarrollarse.
Debe ser explícitamente modelado si va a ser administrado.
Person Materiales Energía Equipamiento Procedimiento
Requerimientos Productos y
Ideas Actividades servicios
Tiempo
Características del Proceso

 Comprensibilidad: Si el proceso está definido y es comprensible.
 Visibilidad: Si el progreso del proceso es visible externamente.
 Suportabilidad: Puede soportarse con herramientas CASE (Computer Aided Software
Engineering, en castellano Ingeniería de Software Asistida por Computadora)

lOMoARcPSD|6168564
 Aceptabilidad: Si el proceso es aceptable por los que deben utilizarlo

 Confiabilidad: Si los errores del proceso son descubiertos antes que resulten errores del
producto.
 Robustez: Puede el proceso continuar frente a problemas inesperados
 Mantenibilidad: Puede el proceso evolucionar para alcanzar las necesidades de cambio,
organizacionales.
 Rapidez: Cuán rápido puede producir el sistema.
Si bien no se puede tratar al proceso de software como una serie de actividades preestablecidas e
inmodificables, ya que cada producto de software final es único y atiende a características de
organización, cliente, proyecto y factores internos y externos, se identifican 4 actividades
fundamentales para todos los procesos, que son:
 Especificación del software. Se trata de definir las funcionalidades que deberá tener el
software y las restricciones en su operación.
 Diseño e implementación del software. Primero se diseña la solución y luego se produce el
software que cumpla con la especificación.
 Validación del software. Se valida con el cliente la funcionalidad del software asegurando
que realiza lo que el cliente desea y necesita.
 Evolución del software. Las organizaciones son sistemas dinámicos que se acomodan a
los cambios, el software debe evolucionar para cubrir las necesidades de cambio que
plantea el cliente.
Cada empresa adopta el proceso con las etapas que considera mejor según el equipo de gente
que dispone, siempre teniendo en cuenta estas 4 actividades fundamentales.
Todo proceso de construcción de software lleva un tiempo desde que es requerido por el cliente
hasta que se finaliza y se entrega el producto final, luego viene el mantenimiento del mismo. Este
tiempo es el “Ciclo de Vida”.
Como ciclo de vida, tiene un comienzo y puede tener un fin, de acuerdo al límite que se determine,
en ese tiempo es que se dan las actividades fundamentales que vimos anteriormente.
Como determinamos que no existe un proceso ideal, es que este proceso ha tomado distintas
formas en el tiempo, de acuerdo a la respuesta obtenida y la retroalimentación que se realiza del
mismo.
Existen modelos de procesos de desarrollo de software que han evolucionado en el tiempo y se

identifican con las características de la realidad de cada momento.
Dentro de una organización pueden existir sistemas que están funcionando y que quizás no
cumplan con todas las necesidades del cliente, pero que no se pueden dejar de usar. Las nuevas
funcionalidades tendrán que tener en cuenta estos sistemas para su integración. Estos sistemas
se consideran “Sistemas heredados”, en algunos casos no se pueden modificar, sólo utilizar, en
otros casos se puede modificar, pero si no poseen documentación es una tarea muy compleja.
Las nuevas funcionalidades o los sistemas completos se pueden desarrollar o adquirir, o sea que
en una organización pueden coexistir sistemas heredados, sistemas propios y sistemas
adquiridos; es necesaria la integración de las partes para alcanzar la funcionalidad, el objetivo y el
trabajo como sistema.
Materia: Ingeniería de Software - 10 -

lOMoARcPSD|6168564
1.2.2 Ciclo de Vida: Modelos

¿Qué es un modelo de procesos del software?
Comencemos con la definición de modelo según la Real Academia Española:
Modelo: Esquema teórico, generalmente en forma matemática, de un sistema o de una

realidad compleja, como la evolución económica de un país, que se elabora para facilitar
su comprensión y el estudio de su comportamiento.
Esta definición puede aplicarse al proceso de desarrollo de software; el modelo se plantea teórico,
para facilitar su comprensión y el estudio de su comportamiento.
Definición de modelo de procesos de software planteado por SOMMERVILLE, IAN (“Ingeniería del
Software”, pág. 25): “Un modelo de procesos es una descripción simplificada de un proceso del
software que presenta una visión de ese proceso.”
Esta definición la podemos interpretar como: La serie de pasos a través de los cuales el producto
progresa, teniendo en cuenta las personas involucradas en la ingeniería del software.
Un ciclo de vida de software es una representación de un proceso. Representa una descripción

del proceso desde una perspectiva particular.
En todos los casos los modelos especifican:

 Las fases de proceso. Por ejemplo: requerimientos, especificación, diseño.
 El orden en el cual se llevan a cabo.
¿Cuál es la importancia de los Modelos de Ciclos de Vida?
La importancia de los modelos de ciclos de vida es amplia, fundamentalmente ayudan al

seguimiento del proceso, organización y planificación. Veamos algunas de ellas:
 Proveer una guía para la administración de proyecto.

o ¿Cuáles de las tareas deben ser rastreadas?
o ¿Qué tipo de progreso se ha realizado?
o ¿Cuáles son las actividades que se deben realizar y en qué orden?
o ¿Cuándo interactuamos con el cliente?
o ¿Qué tenemos que tener en cuenta?
¿Cuál es la necesidad de modelos de ciclos de vida?
Para tener las ventajas descriptas anteriormente son necesarios los modelos de ciclos de vida, así
como conocerlos para poder elegir cuál es más conveniente utilizar, de acuerdo al caso a resolver
y a la situación.
 La necesidad de modelos de ciclos de vida.

o El carácter del desarrollo de software ha cambiado.
 Épocas tempranas: los programadores eran los usuarios finales.
 Diseños muy modestos, desconocimiento del potencial del software.
o Sistemas más complejos

lOMoARcPSD|6168564
 Más funcionalidad, más sofisticación  mayor complejidad, más

posibilidades de cometer errores.
 Usuarios heterogéneos.
Algunos factores que ayudaron a la necesidad de contar con modelos fueron:

 Normalmente, las especificaciones son incompletas y con anomalías.
 Muy difusa la distinción entre especificación, diseño y manufactura.
 No hay una realización física del sistema en las pruebas.
 Software no se consume, el mantenimiento no significa reemplazo.
Recordemos que el ciclo de vida de un proyecto comienza cuando el mismo forma parte de una
idea hasta la implementación en todos los usuarios que utilizarán el sistema y que un modelo de
ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de
desarrollo de software.
Existen muchos modelos, algunos se desprenden de otros, también depende de los autores de las
distintas bibliografías. Sommerville Ian (“Ingeniería del Software”, pág. 25), plantea que “la
mayoría de los modelos de procesos del software se basan en uno de los tres modelos generales
o paradigmas de desarrollo de software”:
 Enfoque en cascada. Totalmente secuencial, una etapa después de terminada la anterior.

Se termina, se firma y se sigue con la siguiente.
 Desarrollo iterativo. Entrelaza las actividades de especificación, desarrollo y validación.
Parte de especificaciones muy abstractas, se refina de acuerdo a las peticiones del cliente
para finalmente producir un sistema que satisfaga las necesidades de dicho cliente.
 Ingeniería del software basado en componentes (CBSE). Supone que las partes del
sistema existen, por lo tanto, el proceso de desarrollo se enfoca en la integración de las
partes más que en su desarrollo desde el principio.
1.2.3 Ciclos de vida secuenciales: El modelo en cascada

Modelo en cascada
Fue el primer ciclo de vida de software, definido por Winston Royce a fines del 70.
Es el más básico de todos los modelos y sirve como bloque de construcción para los demás
modelos de ciclo de vida, plantea una visión simple basada en el concepto que el desarrollo de
software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de
metas bien definidas y las actividades dentro de una fase contribuyen a la satisfacción de metas
de esa fase o quizás a una subsecuencia de metas de la fase. Existen fases discontinuas, las
cuales no se solapan. Este modelo está orientado a la documentación.
El modelo de ciclo de vida cascada, captura algunos principios básicos:

 Planear un proyecto antes de embarcarse en él.
 Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura
interna.
 Documentar los resultados de cada actividad.
 Diseñar un sistema antes de codificarlo.
 Testear un sistema después de construirlo.

lOMoARcPSD|6168564
Se realizan relevamientos de los siguientes aspectos:

 Técnicos: equipamiento, capacidad técnica de recursos
 Funcionales: extracción completa de los Requerimientos, el 100%.
 Del Negocio: los sectores involucrados
Su utilización es beneficiosa en:

 productos bien definidos
 con metodologías técnicas bien entendidas,
 una actualización de un mantenimiento existente
 el traslado de un producto a una nueva plataforma
 en un equipo de trabajo sin experiencia
En los primeros años tuvo mucha aceptación, luego se fueron realizando modificaciones tratando
de lograr adaptarlo a las necesidades.
Encontramos como ventajas sobresalientes, las siguientes:

 Provee información a través del ciclo de vida y la documentación de cada fase.
 Favorece el seguimiento del proceso ordenándolo, con actividades bien comprendidas
pero complejas.
A partir de los 90 ha sido sujeto a numerosas críticas, debido a que es restrictivo y rígido, lo cual
dificulta el desarrollo de proyectos de software moderno.
Algunas de sus desventajas son:

 Lleva mucho tiempo finalizarlo por ser tan secuencial
 No se puede comenzar hasta tener el total de los requerimientos antes de comenzar con el
diseño.
 Es rígido, ya que no permite volver hacia etapas anteriores para corregir errores
 No es aconsejable para desarrollos cortos porque posee una excesiva cantidad de
documentación
Especificación de
Requerimiento Definición
Análisis
Especific.
Diseño
Implementación y
Unidad de Testeo Desarrollo
Integración
Implementación Mantenimiento

lOMoARcPSD|6168564
Debido a las desventajas del modelo, muchos modelos nuevos de ciclo de vida han sido
propuestos, incluyendo modelos que pretenden desarrollar software más rápidamente, más
incrementalmente, de una forma más evolutiva o precediendo el desarrollo a escala total con
algún conjunto de prototipos rápidos.
Desarrollo evolutivo
El desarrollo evolutivo consiste en desarrollar una implementación inicial, entregada a los usuarios
para sus comentarios y refinándola a través de la retroalimentación y las versiones hasta lograr el
sistema adecuado.
Los requerimientos son cuidadosamente examinados y sólo aquellos que son bien comprendidos
son seleccionados para el primer incremento. Los desarrolladores construyen una implementación
parcial del sistema que recibe sólo estos requerimientos. El cliente lo usa, basado en la
retroalimentación y en los nuevos requerimientos se construye la nueva versión, así el proceso se
repite indefinidamente.
Note que el desarrollo evolutivo es 100% compatible con el modelo cascada.
Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos
(incremental) y comprender que nuevos requerimientos aparecerán cuando el sistema sea
desplegado o desarrollado.
Las actividades de especificación, de desarrollo y validación se entrelazan en vez de separarse,

con una rápida retroalimentación entre éstas.
Existen 2 tipos de desarrollo evolutivo:
 Desarrollo exploratorio, donde se trabaja con el cliente para explorar sus requerimientos y
entregar un sistema final, comenzando siempre por los requerimientos del sistema que se
entienden mejor. El sistema crece, evoluciona con lo que el cliente va proponiendo.
 Prototipos desechables, en este caso se centra en los requerimientos que no están muy
claros, por lo que el objetivo es comprender los requerimientos del cliente para poder
desarrollar una definición mejorada del sistema.
Visto desde la ingeniería de gestión, el modelo evolutivo tiene los siguientes problemas:
 Carencia de Visibilidad del Proceso
 Los sistemas frecuentemente son pobremente estructurados
 Puede requerirse habilidades Especiales (Ej. En lenguajes de prototipación rápida)
Es factible su aplicación:
 Para Sistemas interactivos de tamaño pequeño o mediano.
 Para partes de sistemas grandes (Ej. Interfaces de usuario).
 Para sistemas de ciclo de vida corto.
Veamos el modelo representado en el siguiente gráfico.

lOMoARcPSD|6168564
Ingeniería de software basada en componentes
Con los avances de la programación orientada a objetos, el conocimiento de sistemas que actúan
en forma similar se ha incorporado el concepto de componente reusable.
Este enfoque requiere de componentes de software reutilizables (cantidad que va creciendo) y de

un marco de trabajo de integración de estos. Es posible que estos componentes sean sistemas
por sí mismos, subsistemas o módulos que tienen una funcionalidad específica.
Veamos la gráfica de este modelo.
Especificación Análisis de Modificación Diseño de sistemas

de Rqs. componentes de Rqs. con reutilización
Desarrollo e Validación
integración del sistema
Si bien las etapas de especificación de requerimientos y la de validación son similares a otros

procesos, las etapas intermedias son diferentes.
Desarrollemos estas etapas intermedias:
Análisis de componentes: teniendo la especificación de requerimientos se buscan los

componentes necesarios que cumplan con toda la funcionalidad o con parte de ella. En este caso
serán modificados, llevándolos al punto más general posible, para que se constituyan en librerías
de componentes capaces de ser reutilizados en más de un proyecto sin tener que modificarlos.
Modificación de requerimientos: si los componentes encontrados para los requerimientos no son
modificables, se pueden buscar soluciones alternativas, modificando en parte el requerimiento, sin
que deje de cumplir con la necesidad del cliente.

lOMoARcPSD|6168564
Diseño de sistemas con reutilización: esta etapa se relaciona con el marco de trabajo, son los
diseñadores los que tienen en cuenta los componentes que se reutilizan para organizar el marco
de trabajo que los satisfaga o bien diseñar nuevos componentes porque no se cuenta con los
necesarios.
Desarrollo e integración: estas etapas no son independientes, es necesaria su integración ya que

es parte del desarrollo tener en cuenta los componentes que existen, los que se adquieren
externamente y los que se desarrollan internamente para integrarlos en un todo.
Ventajas de la ingeniería de software basada en componentes:

 Reducir la cantidad de software a desarrollar
 Reducir costos
 Reducir riesgos.
 Permite una entrega más rápida
Riesgos del uso de este modelo:

 Si depende totalmente de los componentes a reutilizar puede ser que el producto no
cumpla con las necesidades del cliente.
 Las nuevas versiones de los componentes pierden la especificidad de la organización, se
plantean generales, por lo que requiere de la necesidad de relevar las reglas de negocio
de cada cliente.
Este modelo tiene mucho en común con el enfoque que está surgiendo en los últimos años para el
desarrollo de sistemas que se basan en la integración de servicios Web.
Modelo incremental
Si el desarrollo de sistema es complejo y es un proyecto a largo plazo, implica que tiene asociado
demasiados riesgos, como por ejemplo que no se termine, que no cumpla con las necesidades del
cliente que cambiaron desde que lo solicitó, que el costo sea muy elevado, entre otros.
Una forma de reducir estos riesgos es construir sólo una parte de sistema, organizando por
versiones lo que se incrementa.
En el modelo incremental requiere del 100% de los requerimientos al comienzo del ciclo de vida,
se toman subconjuntos de requerimientos y se desarrollan en versiones siempre incrementando el
producto de software. El documento de requerimientos es escrito al capturar todos los
requerimientos necesarios para el sistema completo, es el que sirve de guía para los incrementos.
Este modelo es compatible con el modelo cascada, no obstante el modelo incremental provee
algunos beneficios significativos para los proyectos:
 Construir un sistema pequeño es siempre menos riesgoso que construir un sistema
grande.
 Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los
requerimientos planeados para los niveles subsiguientes son correctos.
 Si un error importante es realizado, sólo la última iteración necesita ser descartada.
 Reduciendo el tiempo de desarrollo de un sistema, decrecen las probabilidades que esos
requerimientos de usuarios puedan cambiar durante el desarrollo.
 Si un error importante es realizado, el incremento previo puede ser usado.
 Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del
comienzo del próximo incremento.

lOMoARcPSD|6168564
Veamos su gráfica de organización de etapas:
Requisitos Requisitos
Diseño de
Diseño Arquitectura
Diseño
detallado
Codificación
y pruebas
Desarrollo unitarias
Pruebas de
integración
Pruebas de
sistema
Instalación y
capacitación
Implementación
Aceptación del
cliente
Tanto el modelo de desarrollo incremental como el modelo de desarrollo evolutivo construyen una
serie de grandes versiones sucesivas de un producto. La diferencia radica en el conocimiento de
los requerimientos, mientras que la aproximación incremental presupone que el conjunto completo
de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no
son completamente conocidos al inicio del proyecto.
Modelos que derivan de los anteriores
Modelo de Prototipado de Requerimientos
El prototipado de requerimientos tiene el propósito explícito de aprender sobre los requerimientos

del sistema, para ello se crea una implementación parcial del sistema.

lOMoARcPSD|6168564
Por lo general consiste en la entrega de prototipos de interfaz de usuario, construido de una

manera tan rápida como sea posible. Esto es dado a los usuarios, clientes o representantes de
ellos, quienes serán los que proveen la retroalimentación sobre lo que a ellos les gustó y no les
gustó acerca del prototipo proporcionado.
En los 90 fue usado frecuentemente, porque la especificación de requerimientos para sistemas

complejos tiende a ser relativamente dificultoso de cursar.
A diferencia del modelo evolutivo donde los requerimientos mejor entendidos están incorporados,
un prototipo generalmente se construye con los requerimientos entendidos más pobremente.
Veamos su gráfica:
Modelo Entrega por etapas
Es utilizado cuando la arquitectura es conocida.
Las ventajas son:

 Permite correcciones en el transcurso del proyecto
 Permite colocar en producción las funcionalidades de mayor peso
 Obtiene un producto en forma rápida
Las desventajas son:

 Se debe trabajar con una planificación cuidadosa
Permite independizar la administración del proyecto de la parte técnica, brindándole al usuario las
funcionalidades más significativas. Se debe tener mucho cuidado porque para implementar una
fase puede requerir de la finalización de otra.

lOMoARcPSD|6168564
Veamos su gráfica:
1.2.4. La naturaleza iterativa de los desarrollos.
Modelo Iterativo
Este modelo tiene como objetivo obtener un protocolo de desarrollo común para cualquier tipo de
aplicación de software, minimizando los procesos que tardan mucho tiempo, para entregar
avances o compilados por módulos acompañados de su documentación facilitando la
transferencia de conocimientos entre los integrantes del proyecto y del cliente.
Se asemeja al modelo de desarrollo por prototipos, la diferencia es que en el modelo iterativo los
prototipos son entregables y tienen versión.
Veamos su gráfica:

lOMoARcPSD|6168564
Modelo de espiral
Cada proyecto es organizado y explotado en miniproyectos, es conveniente para modelos del ciclo
meta-vida, o sea que transcurren en el tiempo.
Es un modelo incremental con versiones, en cada una se respetan las etapas, se documenta y va
incluyendo a los productos anteriores.
Normalmente es utilizado en:

 Sistemas de gran envergadura
 Proyectos con un numeroso grupo de integrantes.
 Problemas de Performance
 Existencia de requerimientos pobres, poco entendibles
 Arquitectura pobremente detallada
Una vez entendido el problema, continua como un proyecto en cascada
Algunas de las ventajas son:

 Altos costos significan pocos riesgos
 Para desarrollos rápidos
 Provee más controles que los sistemas tradicionales
 Se pueden „mostrar‟ avances del proyecto
 Netamente confiable
Las desventajas que se han manifestado son:

 La administración de los riesgos
 Ante un proyecto complejo, requiere una administración rigurosa (concientizada). Se deben
definir hitos de control de pase de una etapa a otra
 Difícil de ser construidos con tiempos predeterminados

lOMoARcPSD|6168564
Veamos su gráfica:
Modelo Iterativo e incremental
Se toman las características de ambos modelos, del iterativo y del incremental para lograr un
modelo con mejores aplicaciones.
Las ventajas, si bien son muchas y variadas, dependen del contexto en que se implemente el
proceso. Algunas de ellas son:
 Se divide en fases, workflows centrales e iteraciones.
 Resolución de problemas de alto riesgo en menores tiempos del proyecto.
 Visión de avance en el desarrollo desde las primeras etapas del desarrollo.
 Obtención del feedback del usuario lo antes posible, lo que permite orientar el desarrollo al
cumplimiento de sus necesidades y realizar las adaptaciones identificadas y necesarias
para cumplir con los objetivos planteados.
 Menor porcentaje de fallo del proyecto, mayor productividad del equipo y menor cantidad
de defectos.
 La complejidad del proyecto se maneja por partes.
 El aprendizaje y experiencia del equipo se da iteración tras iteración, mejora
exponencialmente el trabajo, aumenta la productividad y permite optimizar el proceso a
corto plazo.
 El trabajo iterativo deja una experiencia en el equipo que permite ir ajustando y mejorando
las planificaciones, logrando menores desvíos en la duración total del proyecto.
 Adoptar este modelo no presenta grandes inversiones.
Si bien no se han detectado desventajas en el tiempo que lleva implementándose, es importante

tener en cuenta algunos aspectos:
 Su uso no garantiza por si solo el éxito del proyecto ni de su uso.

lOMoARcPSD|6168564
 Existen costos ocultos en su implementación, por la necesidad de la planificación y la

necesidad de medir el impacto para no fracasar en el intento.
El modelo iterativo e incremental es utilizado por metodologías modernas y es adoptado por UML
(Lenguaje de modelado unificado). Su gráfica es la siguiente (fuente: Book Racional Modeler)
El gráfico del modelo iterativo e incremental presenta una tabla de dos entradas, las columnas
representan las “Fases” y las filas representan los “Flujos de trabajo”.
Las fases son cuatro: Inicio, Elaboración, Construcción y Transición.
Los flujos de trabajo representan las actividades y son 7: Requerimientos, Análisis y Diseño,
Implementación, Prueba, Administración de configuración, Administración del proyecto y Entorno.
Las tres últimas etapas se toman como acompañamiento de todo el proceso de desarrollo.
1.2.5. Ventajas y desventajas de c/u de los ciclos de vida

Hemos planteado hasta ahora cada modelo de ciclo de vida del proceso de desarrollo de software
y las ventajas y desventajas de sus usos.
Existen dos temas que son generales a todos los modelos, el costo de tiempo por etapas y los
riesgos.
Costo relativo a las fases
Si bien cada modelo tiene su organización y tiempos por fases, hay cálculos promedios que se
pueden tener en cuenta para los procesos.
Veamos su representación gráfica:

lOMoARcPSD|6168564
Integración
Test de (8%)
Mod.(7%)
C od. De
Módulos
(5%)
Diseño (6%) Manteni-
miento
Especifica- Requeri- (67%)
ción (5%) mientos
(2%)
Gestión de Riesgos
Tal vez la tarea principal del administrador es minimizar el riesgo

El riesgo inherente en un activad es una medida de la incertidumbre de la salida de esa actividad.
Las actividades de alto riesgo causan excesos en los costos y la planificación.
El riesgo está relacionado con la calidad y cantidad de información disponible.
Mientras menos información el riesgo es mayor.
Problemas de riesgos en los modelos
Cascada
 Alto riesgo en sistemas nuevos debido a problemas de especificación y diseño.
 Bajo riesgo para desarrollos bien conocidos y utilizando tecnología familiar.
Evolutivos
 Bajo riesgo para nuevas aplicaciones debido a que la especificación y la programación
están muy relacionados
 Alto riesgo debido a la carencia de visibilidad para el proceso.
Transformacional
 Alto riesgo debido a la necesidad de tecnología avanzada y habilidades en el personal
Vista integral de los modelos
Trataremos entonces en conjunto los modelos integrando las características de cada uno para
lograr una visión general y particular de ellos, que ayude a la toma de decisiones a la hora de
tener que elegir uno a implementar en un proyecto.
Ciclo de vida Cascada Codificación y Espiral Cascada Prototipación Entrega por Diseño por
Puro Arreglo Modificado Evolutiva Etapas Fases
Trabaja con requerimientos Justo a Pobre a

Pobre Pobre Excelente Excelente Pobre
pobremente entendidos excelente justo
Trabaja con arquitectura Justo a
Pobre Pobre Excelente Pobre a Justo Pobre Pobre
pobremente entendida excelente
Produce un sistema
Excelente Pobre Excelente Excelente Justo Excelente Justo
altamente confiable

lOMoARcPSD|6168564
Produce sistema con sobre - Justo a

Excelente Pobre a justo Excelente Excelente Excelente Excelente
crecimiento excelente
Justo a
Administración de riesgos Pobre Pobre Excelente Justo Justo Justo
excelente
Puede ajustarse a un
Justo Pobre Justo Justo Pobre Justo Excelente
calendario predefinido
Tiene bajo perfil Pobre Excelente Justo Excelente Justo Justo Justo
Permite correcciones de Pobre a Pobre a
Pobre Justo Justo Excelente Pobre
medio curso excelente justo
Provee visibilidad en el
Pobre Justo Excelente Justo Excelente Justo Justo
progreso (al cliente)
Provee visibilidad en el Justo a
Justo Pobre Excelente Justo Excelente Excelente
progreso (al administrador) excelente
Requiere poca
Pobre a
administración o Justo Excelente Pobre Pobre Justo Pobre
Justo
sofisticación de desarrollo
Resumen:
Los temas tratados en este módulo tienen que ver directamente con la Ingeniería de software y su
relación con la Ingeniería de sistemas y la Ciencia de la computación.
Dentro de los temas de la Ingeniería de software identificamos los conceptos de software,

producto, proceso de desarrollo de software, su ciclo de vida y los distintos modelos de desarrollo
de software y su ciclo de vida.
Tenga en cuenta los puntos clave que remarcamos a continuación (Sommerville, Ian, capítulo 1 y
3):
 La Ingeniería en Software es una Ingeniería que abarca todos los aspectos de la

producción de software.
 Los productos de Software consisten en el desarrollo de programas y toda la
documentación asociada a ellos. Los atributos esenciales son la mantenibilidad,
confiabilidad, eficiencia y usabilidad.
 El proceso de software consiste en actividades las cuales involucran el desarrollo de
productos de software. Las actividades básicas son especificación, desarrollo, validación y
evolución.
 Los métodos son formas organizadas de producir software. Ellos incluyen sugerencias
para el cumplimento del métodos, la notación a ser usada, las reglas de validación de
modelos y guías de diseño.
 Las herramientas CASE son sistemas de software los cuales son diseñados para auxiliar
en actividades de rutina en el proceso de desarrollo de software. Tales como edición de
diagramas, verificar la consistencia de diagramas y mantener un registro de los testeos
efectuados.
 Los ingenieros en Software tienen responsabilidades para con su profesión y para con la
sociedad. No están simplemente involucrados en aspectos técnicos
En cuanto a los sistemas y las Ingenierías puede destacar los siguientes puntos clave
(Sommerville, Ian, capítulo 2):

lOMoARcPSD|6168564
 Los sistemas socio-técnicos incluyen hardware, software, personas y procesos, se

encuentran dentro de las organizaciones y ayudan a cumplir un objetivo.
 Las propiedades emergentes de un sistema son las características que actúan como un
todo no por partes o componentes del sistema. Incluyen propiedades como el rendimiento,
fiabilidad, usabilidad, seguridad y protección. El éxito o fracaso de un sistema socio-técnico
dependen de las propiedades en la mayoría de los casos.
 Factores humanos y organizacionales influyen en el funcionamiento de los sistemas socio-
técnicos.
 Dentro de una organización pueden existir más de un tipo de sistemas, los heredados, los
propios y los adquiridos. Es posible que se planteen conflictos entre el proceso de
adquisición, el proceso de desarrollo y los procesos operativos internos.
 Los sistemas heredados son sistemas socio-técnicos.
En cuanto al proceso de software puede destacar lo siguiente:
 Proceso de Software
o Un conjunto coherente de actividades para especificar, diseñar, implementar y
testear un sistema de software.
 Modelos de Ciclo de Vida
o Cascada demasiado inflexible
 Orientado a documentos
o Modelos evolutivos y prototipos
 Dependen de las decisiones tomadas antes del entendimiento del problema
o Una buena solución es integrar protipado rápido y cascada
Puntos clave a tener en cuenta, Sommerville, Ian, (capítulo 4 – temas 4.1 y 4.2):
 Los procesos de software incluyen las actividades relacionadas con la producción de un

sistema de software. Los modelos del proceso del software son representaciones
abstractas de estos procesos.
 Todos los procesos del software incluyen las etapas de especificación, diseño,
implementación, validación y evolución del software.
 Los modelos genéricos del proceso describen la organización de los procesos del
software, como son el modelo en cascada, los evolutivos y la Ingeniería basada en
componentes.
 Los modelos de iteración presentan el proceso de software como un ciclo de actividades.
El modelo en espiral, es uno de los más utilizados.
 El modelo iterativo e incremental incluye las mejores prácticas del modelo iterativo y del
modelo incremental.


Ingenieria de Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingenieria de Software

Cargado por

Copyright:

Formatos disponibles

lOMoARcPSD|6168564

Ingenieria de Software (Universidad Siglo 21)

StuDocu no está patrocinado ni avalado por ningún colegio o universidad.

Unidad 1: Ingeniería de Software

1.1.1 Concepto de Ingeniería de Software

Otra definición que podemos plantear es la de D. L. Parnas (Programming Methodology, 4th

Todo proyecto tiene restricciones de tiempo, organizacionales y de presupuesto, por lo que el

Materia: Ingeniería de Software -1-

Software es un conjunto de programas que se ejecutan en un ordenador y la documentación

Existen tres tipos básicos de software:

El software tiene características que es importante conocer, veamos algunas de ellas.

Clasificación de las Cualidades:

Materia: Ingeniería de Software -2-

 Mantenibilidad: se refiere a modificaciones que se le hacen al software después de su

Si el software es lo que se entrega al cliente, entonces se puede considerar un producto.

Software como producto

Software como conocimiento

Si los programas que se entregan al finalizar el proceso de desarrollo contienen conocimiento,

Como el software es maleable y responde a cambios, es importante pensarlo de otra forma, un

El proceso de producción de software atiende más al diseño e implementación que a la

Veamos las características que tiene el producto de software:

Materia: Ingeniería de Software -3-

 Es un software más sofisticado

Recordemos también el concepto y alguitas características de sistema:

¿Cual es la diferencia entre Ingeniería en Software y el Profesional en Sistemas?

Materia: Ingeniería de Software -4-

 Ser capaz de planificar su trabajo y el de otros. Con desorganización no se produce

Como en todas las profesiones el Ingeniero de software de tener presente la ética y la

Temas de la responsabilidad profesional:

Algunos dilemas éticos que se pueden presentar son:

1.1.2 Problemas de la ingeniería de Software. La crisis de desarrollo

Existieron factores que influyeron para que el software no fuese costeable:

Materia: Ingeniería de Software -5-

Por otro lado:

Tomamos la definición de Ingeniería de software de Fairley (“Ingeniería de Software”, 1987): “La

Materia: Ingeniería de Software -6-

El desafío es ponerse en movimiento hacia el cambio en post de la mejora continua,

1.1.3 Diferencias entre Ingeniería de Software y Ciencia de la

La Ciencia de la computación comprende la teoría y fundamentos, mientras que la ingeniería de

La ingeniería de software, al atender el proceso de desarrollo de software, se diferencia de la

El término Sistema es utilizado universalmente, aplicado a todas las disciplinas, en el caso de la

Definición de Sommerville: “Un sistema es una colección de componentes interrelacionados que

Los sistemas informáticos que incluyen software se dividen en dos categorías:

Materia: Ingeniería de Software -7-

Entre las características fundamentales de los sistemas socio-técnicos encontramos las

Teniendo en cuenta lo expresado anteriormente, las propiedades emergentes de un sistema se

Estas propiedades emergentes pueden considerarse como funcionales y no funcionales:

¿Cuáles son las diferencias entre el proceso de la ingeniería de sistemas y el proceso de

Materia: Ingeniería de Software -8-

 Alcance interdisciplinario. En la Ingeniería de sistemas se conjugan muchas Ingenierías,

1.2 Ciclo de Vida

1.2.1 Ciclo de Vida: Conceptos de Proceso de Desarrollo de Software.

Proceso de desarrollo de software

Se entiende por proceso de software al conjunto estructurado de actividades para desarrollar un

Estas actividades varían dependiendo de la organización y el tipo de sistema que debe

Debe ser explícitamente modelado si va a ser administrado.

Person Materiales Energía Equipamiento Procedimiento

Características del Proceso

Materia: Ingeniería de Software -9-

 Aceptabilidad: Si el proceso es aceptable por los que deben utilizarlo

Existen modelos de procesos de desarrollo de software que han evolucionado en el tiempo y se

Materia: Ingeniería de Software - 10 -

1.2.2 Ciclo de Vida: Modelos