Ingeniería de software

De Wikipedia, la enciclopedia libre

(Redirigido desde Desarrollo de software)

Saltar a navegación, búsqueda

Ingeniería de software es la disciplina o área de la informática que ofrece

métodos y técnicas para desarrollar y mantener software de calidad.

Esta ingeniería trata con áreas muy diversas de la informática y de las

Ciencias de la Computación, tales como construcción de compiladores,
Sistemas Operativos, o desarrollos Intranet/Internet, abordando todas las
fases del ciclo de vida del desarrollo de cualquier tipo de Sistema de
Información y aplicables a infinidad de áreas (negocios, investigación
científica, medicina, producción, logística, banca, control de tráfico,
meteorología, derecho, Internet Intranet, etc.).

Una definición precisa aún no ha sido contemplada en los diccionarios, sin

embargo se pueden citar las enunciadas por algunos de los más prestigiosos
autores:

1 - Ingeniería de Software es el estudio de los principios y metodologías

para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)

2 - Ingeniería de software es la aplicación práctica del conocimiento

científico al diseño y construcción de programas de computadora y a la
documentación asociada requerida para desarrollar, operar y mantenerlos.
Se conoce también como Desarrollo de Software o Producción de Software
( Bohem, 1976).

3 - Ingeniería de Software trata del establecimiento de los principios y

métodos de la ingeniería a fin de obtener software de modo rentable, que
sea fiable y trabaje en máquinas reales (Bauer, 1972).

4 - Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al

desarrollo, operación y mantenimiento del software; es decir, la aplicación
de la ingeniería al software (IEEE, 1993).

En el 2004, en los Estados Unidos, la Oficina de Estadísticas del Trabajo (U.

S. Bureau of Labor Statistics) contó 760.840 ingenieros de software de
computadora.[1] El término "ingeniero de software", sin embargo, se utiliza
en forma genérica en el ambiente empresarial, y no todos los ingenieros de
software poseen realmente títulos de Ingeniería de universidades
reconocidas.
Algunas autores consideran que Desarrollo de Software es un término más
apropiado que Ingeniería de Software (IS) para el proceso de crear software.
Personas como Pete McBreen (autor de "Software Craftmanship") cree que
el término IS implica niveles de rigor y prueba de procesos que no son
apropiados para todo tipo de desarrollo de software.

Indistintamente se utilizan los términos Ingeniería de Software o Ingeniería

del Software. En hispanoamérica el término usado normalmente es el
primero de ellos.

Implicaciones socioeconómicas [editar]La ingeniería de software afecta a la

economía y las sociedades de variadas formas.

Económicamente [editar]En los EEUU, el software contribuyó a 1/4 de todo

el incremento del PIB durante los 90's (alrededor de 90,000 millones de
dólares por año), y 1/6 de todo el crecimiento de productividad durante los
últimos años de la década (alrededor de 33,000 millones de dólares por
año). La ingeniería de software contribuyó a $1 billón de crecimiento
económico y productividad en esa década. Alrededor del globo, el software
contribuye al crecimiento económico en formas similares, aunque es difícil
de encontrar estadísticas fiables.

Socialmente [editar]La ingeniería de software cambia la cultura del mundo

debido al extendido uso de la computadora. El correo electrónico (E-mail), la
WWW y la mensajería instantánea permiten a la gente interactuar en
nuevas formas. 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 métodos de ingeniería de software incluyen a Linux, el software
del transbordador espacial, los cajeros automáticos y muchos otros.

La IS se puede considerar como la ingeniería aplicada al software, esto es,

por medios sistematizados y con herramientas preestablecidas, la aplicación
de ellos de la forma más eficiente para la obtención de resultados óptimos;
objetivos que siempre busca la ingeniería. No es sólo de la resolución de
problemas, sino más bien teniendo en cuenta las diferentes soluciones,
elegir la más apropiada.

Metodología [editar]Un objetivo de décadas ha sido el encontrar procesos y

metodologías, que sean sistemáticas, predecibles y repetibles, a fin de
mejorar la productividad en el desarrollo y la calidad del producto software.

Etapas del proceso [editar]La ingeniería de software requiere llevar a cabo

numerosas tareas, dentro de etapas como las siguientes:

Análisis de requisitos [editar]Extraer los requisitos de un producto de

software es la primera etapa para crearlo. Mientras que los clientes piensan
que ellos saben lo que el software tiene que hacer, se requiere de habilidad
y experiencia en la ingeniería de software para reconocer requisitos
incompletos, ambiguos o contradictorios. El resultado del análisis de
requisitos con el cliente se plasma en el documento ERS, Especificación de
Requerimientos del Sistema, cuya estructura puede venir definida por varios
estándares, tales como CMM-I. Asimismo, se define un diagrama de
Entidad/Relación, en el que se plasman las principales entidades que
participarán en el desarrollo del software.

La captura, análisis y especificación de requisitos (incluso pruebas de ellos),

es una parte crucial; de esta etapa depende en gran medida el logro de los
objetivos finales. Se han ideado modelos y diversos procesos de trabajo
para estos fines. Aunque aún no está formalizada, ya se habla de la
Ingeniería de Requisitos.

La IEEE Std. 830-1998 normaliza la creación de las Especificaciones de

Requisitos Software (Software Requirements Specification).

Especificación [editar]Es la tarea de describir detalladamente el software a

ser escrito, en una forma matemáticamente rigurosa. En la realidad, la
mayoría de las buenas especificaciones han sido escritas para entender y
afinar aplicaciones que ya estaban desarrolladas. Las especificaciones son
más importantes para las interfaces externas, que deben permanecer
estables.

Diseño y arquitectura [editar]Se refiere a determinar como funcionará de

forma general sin entrar en detalles. Consiste en incorporar consideraciones
de la implementación tecnológica, como el hardware, la red, etc. Se definen
los Casos de Uso para cubrir las funciones que realizará el sistema, y se
transforman las entidades definidas en el análisis de requisitos en clases de
diseño, obteniendo un modelo cercano a la programación orientada a
objetos.

Programación [editar]Reducir un diseño a código puede ser la parte más

obvia del trabajo de ingeniería de software, pero no necesariamente es la
que demanda mayor trabajo y ni la más complicada. La complejidad y la
duración de esta etapa está íntimamente relacionada al o a los lenguajes de
programación utilizados, así como al diseño previamente realizado.

Prueba [editar]Consiste en comprobar que el software realice

correctamente las tareas indicadas en la especificación del problema. Una
técnica de prueba es probar por separado cada módulo del software, y luego
probarlo de forma integral, para así llegar al objetivo. Se considera una
buena práctica 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 formas de organizar un área de pruebas, la primera es que
esté compuesta por personal inexperto y que desconozca el tema de
pruebas, de esta forma se evalúa que la documentación entregada sea de
calidad, que los procesos descritos son tan claros que cualquiera puede
entenderlos y el software hace las cosas tal y como están 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 aplicación y que pueden
poner atención en detalles que personal inexperto no consideraría.

Documentación [editar]Todo lo concerniente a la documentación del propio

desarrollo del software y de la gestión del proyecto, pasando por
modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales
técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad,
mantenimiento futuro y ampliaciones al sistema.

Mantenimiento [editar]Mantener y mejorar el software para enfrentar

errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo
incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la
ingeniería de software tiene que ver con dar mantenimiento. Una pequeña
parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte
consiste en extender el sistema para hacer nuevas cosas. De manera
similar, alrededor de 2/3 de toda la ingeniería civil, arquitectura y trabajo de
construcción es dar mantenimiento.

MODELOS DE DESARROLLO DE SOFTWARE

Desarrollo en cascada:

En Ingeniería de software el desarrollo en cascada, también llamado modelo

en cascada, es el enfoque metodológico que ordena rigurosamente las
etapas del ciclo de vida del software, de forma tal que el inicio de cada
etapa debe esperar a la finalización de la inmediatamente anterior.

Un ejemplo de una metodología de desarrollo en cascada es:

Análisis de requisitos, Diseño del Sistema, Diseño del Programa,

Codificación, Pruebas, Implantación, Mantenimiento.

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

conduce necesariamente al rediseño y nueva programación del código
afectado, aumentando los costes del desarrollo. La palabra cascada sugiere,
mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario
para introducir un cambio en las fases más avanzadas de un proyecto.

Si bien ha sido ampliamente criticado desde el ámbito académico y la

industria, sigue siendo el paradigma más seguido al día de hoy.

Desventajas:

En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea
una mala implementación del modelo, lo cual hace que lo lleve al fracaso.

Difícilmente un cliente va a establecer al principio todos los requerimientos

necesarios, por lo que provoca un gran atraso trabajando en este modelo,
ya que este es muy restrictivo y no permite movilizarse entre fases.
Los resultados y/o mejoras no son visibles, el producto se ve recién cuando
este esté finalizado, lo cual provoca una gran inseguridad por parte del
cliente que anda ansioso de ver avances en el producto. Esto también
implica toparse con requerimientos que no se habian tomado en cuenta, y
que surgieron al momento de la implementación, lo cual provocara que se
regrese nuevamente a la fase de requerimientos.

Ventajas :

Se tiene todo bien organizado y no se mezclan las fases.

Es perfecto para proyectos que son rígidos, y además donde se especifiquen

muy bien los requerimientos y se conozca muy bien la herramienta a
utilizar.

Desarrollo en espiral:

Este modelo fue propuesto por Boehm en 1988. Básicamente consiste en

una serie de ciclos que se repiten en forma de espiral, comenzando desde el
centro. Se suele interpretar como que dentro de cada ciclo de la espiral se
sigue un Modelo Cascada, pero no necesariamente debe ser así. Aunque el
Espiral puede verse como un modelo evolutivo que conjuga la naturaleza
iterativa del modelo MCP con los aspectos controlados y sistemáticos del
Modelo Cascada, con el agregado de gestión de riegos.

En cada vuelta o iteración hay que tener en cuenta [editar]Los Objetivos:

Que necesidad debe cubrir el producto.

Alternativas: Las diferentes formas de conseguir los objetivos de forma

exitosa, desde diferentes puntos de vista como pueden ser:

Características: experiencia del personal, requisitos a cumplir, etc.

Formas de gestión del sistema.

Riesgo asumido con cada alternativa.

Desarrollar y Verificar: Programar y probar el software.

Si el resultado no es el adecuado o se necesita implementar mejoras o

funcionalidades. Se planificaran los siguientes pasos y se comienza un
nuevo ciclo de la espiral. La espiral tiene una forma de caracola y se dice
que mantiene dos dimensiones, la radial y la angular:

Angular: Indica el avance del proyecto software dentro de un ciclo.

Radial: Indica el aumento del coste del proyecto, ya que con cada nueva
iteración se pasa más tiempo desarrollando.

Este sistema es muy utilizado en proyectos grandes y complejos como

puede ser, por ejemplo, la creación de un Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice
que uno de los aspectos fundamentales de su éxito radica en que el equipo
que lo aplique tenga la necesaria experiencia y habilidad para detectar y
catalogar correctamente los riesgos.

Ventajas

El análisis del riesgo se hace de forma explícita y clara. Une los mejores
elementos de los restantes modelos.

Reduce riesgos del proyecto

Incorpora objetivos de calidad

Integra el desarrollo con el mantenimiento, etc.

Además es posible tener en cuenta mejoras y nuevos requerimientos sin

romper con la metodología, ya que este ciclo de vida no es rígido ni estático.

Desventajas:

Genera mucho tiempo en el desarrollo del sistema

Modelo costoso

Requiere experiencia en la identificación de riesgos

Modelo de prototipos

En Ingeniería de software el desarrollo con prototipación, también llamado

modelo de prototipos que pertenece a los modelos de desarrollo evolutivo,
se inicia con la definición de los objetivos globales para el software, luego se
identifican los requisitos conocidos y las áreas del esquema en donde es
necesaria más definición. Entonces se plantea con rapidez una iteración de
construcción de prototipos y se presenta el modelado (en forma de un
diseño rápido).

El diseño rápido se centra en una representación de aquellos aspectos del

software que serán visibles para el cliente o el usuario final (por ejemplo, la
configuración de la interfaz con el usuario y el formato de los despliegues de
salida). El diseño rápido conduce a la construcción de un prototipo, el cual
es evaluado por el cliente o el usuario para una retroalimentación; gracias a
ésta se refinan los requisitos del software que se desarrollará. La iteración
ocurre cuando el prototipo se ajusta para satisfacer las necesidades del
cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo
que se debe hacer y el cliente vea resultados a corto plazo.

Modelo por etapas

El modelo de desarrollo de software por etapas es similar al Modelo de
prototipos ya que se muestra al cliente el software en diferentes estados
sucesivos de desarrollo, se diferencia en que las especificaciones no son
conocidas en detalle al inicio del proyecto y por tanto se van desarrollando
simultáneamente con las diferentes versiones del código.

Pueden distinguirse las siguientes fases:

Especificación conceptual

Análisis de requerimientos

Diseño inicial

Diseño detallado, codificación, depuración y liberación

Estas diferentes fases se van repitiendo en cada etapa del diseño.

Desarrollo iterativo y creciente

Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo

de software, creado en respuesta a las debilidades del modelo tradicional de
cascada.

Para apoyar el desarrollo de proyectos por medio de este modelo se han

creado frameworks (entornos de trabajo), de los cuales los dos más famosos
son el Rational Unified Process y el Dynamic Systems Development Method.
El desarrollo incremental e iterativo es también una parte esencial de un
tipo de programación conocido como Extreme Programming y los demás
frameworks de desarrollo rápido de software.

Ciclo de vida

La idea principal detrás de mejoramiento iterativo es desarrollar un sistema

de programas de manera incremental, permitiéndole al desarrollador sacar
ventaja de lo que se ha aprendido a lo largo del desarrollo anterior,
incrementando, versiones entregables del sistema. El aprendizaje viene de
dos vertientes: el desarrollo del sistema, y su uso (mientras sea posible). Los
pasos claves en el proceso eran comenzar con una implementación simple
de los requerimientos del sistema, e iterativamente mejorar la secuencia
evolutiva de

versiones hasta que el sistema completo esté implementado. En cada

iteración, se realizan cambios en el diseño y se agregan nuevas
funcionalidades y capacidades al sistema.

El proceso en sí mismo consiste de:

Etapa de inicialización
Se crea una versión del sistema. La meta de esta etapa es crear un producto
con el que el usuario pueda interactuar, y por ende retroalimentar el
proceso. Debe ofrecer una muestra de los aspectos claves del problema y
proveer una solución lo suficientemente simple para ser comprendida e
implementada fácilmente. Para guiar el proceso de iteración, una lista de
control de proyecto se crea, y esta lista contiene un historial de todas las
tareas que necesitan ser realizadas. Incluye cosas como nuevas
funcionalidades para ser implementadas, y areas de rediseño de la solución
ya existente. Esta lista de control se revisa periódica y constantemente
como resultado de la fase de análisis.

Etapa de iteración

Esta etapa involucra el rediseño e implementación de una tarea de la lista

de control de proyecto, y el análisis de la versión más reciente del sistema.
La meta del diseño e implementación de cualquier iteración es ser simple,
directa y modular, para poder soportar el rediseño de la etapa o como una
tarea añadida a la lista de control de proyecto. El código puede, en ciertos
casos, representar la mayor fuente de documentación del sistema. El
análisis de una iteración se basa en la retroalimentación del usuario y en el
análisis de las funcionalidades disponibles del programa. Involucra el
análisis de la estructura, modularidad, usabilidad, confiabilidad, eficiencia y
eficacia (alcanzar las metas). La lista de control del proyecto se modifica
bajo la luz de los resultados del análisis.

Las guías primarias que guían la implementación y el análisis incluyen:

Cualquier dificultad en el diseño, codificación y prueba de una modificación

debería apuntar a la necesidad de rediseñar o recodificar.

Las modificaciones deben ajustarse fácilmente a los módulos fáciles de

encontrar y a los aislados. Si no es así, entonces se requiere algún grado de
rediseño.

Las modificaciones a las tablas deben ser especialmente fáciles de realizar.

Si dicha modificación no ocurre rápidamente, se debe aplicar algo de
rediseño.

Las modificaciones deben ser más fáciles de hacer conforme avanzan las
iteraciones. Si no es así, hay un problema primordial usualmente encontrado
en un diseño débil o en la proliferación excesiva de parches al sistema.

Los parches normalmente deben permanecer solo por una o dos iteraciones.
Se hacen necesarios para evitar el rediseño durante una fase de
implementación.

La implementación existente debe ser analizada frecuentemente para

determinar que tan bien se ajusta a las metas del proyecto.

Las facilidades para analizar el programa deben ser utilizadas cada vez para
ayudar en el análisis de implementaciones parciales.
La opinión del usuario debe ser solicitada y analizada para indicar
deficiencias en la implementación referida por él.

RUP

Un poco de historia
Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken
Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la
investigación. En 1995 Rational Software compró una compañía sueca llamada
Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de
uso a los métodos de desarrollo orientados a objetos. El Rational Unified Process fue el
resultado de una convergencia de Rational Approach y Objectory (el proceso de la
empresa Objectory AB). El primer resultado de esta fusión fue el Rational Objectory
Process, la primera versión de RUP, fue puesta en el mercado en 1998, siendo el
arquitecto en jefe Philippe Kruchten.

Proceso Unificado de Rational

El Proceso Unificado de Rational (Rational Unified Process en inglés, habitualmente
resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje
Unificado de Modelado UML, constituye la metodología estándar más utilizada para el
análisis, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologías adaptables al contexto y necesidades de cada organización.
También se conoce por este nombre al software desarrollado por Rational, hoy
propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y
descripciones de las diversas actividades. Está incluido en el Rational Method
Composer (RMC), que permite la personalización de acuerdo a necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el Proceso
Unificado, y una especificación más detallada, el Rational Unified Process, que se
vendiera como producto independiente.

MSF( Microsoft Solution framawork): Es una serie de modelos que puede adaptarse a
cualquier proyecto de tecnología de información. En el Modelo de Diseño de
Soluciones, los usuarios se ven involucrados en el proceso de diseño. Obteniendo de
ellos información sobre ciertos detalles, como de funcionalidad y otros requerimientos,
el equipo puede determinar como se va a usar la aplicación e incrementar su
productividad.
METRICA 3: Es una metodología de aplicación, desarrollo y mantenimiento de
sistemas de información. Con la métrica 3 es posible desarrollar proyectos orientados a
objetos y proyectos estructurados, en tanto que la tendencia de la ingeniería de software
actual lleva con claridad hacia los sistemas y herramienta cuya utilización esta basada
exclusivamente el modelo de la orientación a objetos.
MANIFIESTO AJIL
○ Nuestra mayor prioridad es satisfacer al cliente a través de la entrega
temprana y continua de software con valor.
 ○ Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Los
procesos ágiles aprovechan el cambio para proporcionar ventaja
competitiva al cliente.
○ Entregamos software frecuentemente, con una periodicidad desde un
par de semanas a un par de meses, con preferencia por los periodos
más cortos posibles.
○ Los responsables de negocio y los desarrolladores deben trabajar
juntos diariamente a lo largo del proyecto.
○ Construimos proyectos con profesionales motivados. Dándoles el
entorno y soporte que necesitan, y confiando en ellos para que realicen
el trabajo.
○ El método más eficiente y efectivo de comunicar la información a un
equipo de desarrollo y entre los miembros del mismo es la
conversación cara a cara.
○ Software que funciona es la principal medida de progreso.
○ Los procesos ágiles promueven el desarrollo sostenible. Esponsores,
desarrolladores y usuarios deben ser capaces de mantener un ritmo
constante de forma indefinida.
○ La atención continua a la excelencia técnica y los buenos diseños
mejoran la agilidad.
○ Simplicidad, el arte de maximizar la cantidad de trabajo no realizado,
es esencial.
○ Las mejores arquitecturas, requisitos y diseños surgen de equipos que
se autoorganizan.
○ A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo, entonces mejora y ajusta su comportamiento de acuerdo a sus
conclusiones.

EXTREME PROGRAMMING:
La programación extrema o eXtreme Programming (XP) es un enfoque de la
ingeniería de software formulado por Kent Beck, autor del primer libro sobre
la materia, Extreme Programming Explained: Embrace Change (1999). Es el
más destacado de los procesos ágiles de desarrollo de software. Al igual que
éstos, la programación extrema se diferencia de las metodologías
tradicionales principalmente en que pone más énfasis en la adaptabilidad
que en la previsibilidad. Los defensores de XP consideran que los cambios
de requisitos sobre la marcha son un aspecto natural, inevitable e incluso
deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a
los cambios de requisitos en cualquier punto de la vida del proyecto es una
aproximación mejor y más realista que intentar definir todos los requisitos al
comienzo del proyecto e invertir esfuerzos después en controlar los cambios
en los requisitos.