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.
Algunos 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.
La ingeniería
de software afecta a la economía y las sociedades de variadas formas.
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.
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.
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.
La ingeniería
de software requiere llevar a cabo numerosas tareas, dentro de etapas como las
siguientes:
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).
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.
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.
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.
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.
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.
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
La ingeniería
de software tiene varios modelos o paradigmas de desarrollo en los cuales se puede
apoyar para la realización de software, de los cuales podemos destacar a éstos
por ser los más utilizados y los más completos:
- Modelo
en cascada o Clásico (modelo tradicional)
- Modelo
en espiral (modelo evolutivo)
- Modelo
de prototipos
- Desarrollo
por etapas
- Desarrollo
iterativo y creciente o Iterativo e Incremental
- RAD (Rapid Application Development)
La Ingeniería
de Software tiene que ver con varios campos en diferentes formas:
Los programas
tienen muchas propiedades matemáticas. Por ejemplo la corrección y la complejidad de muchos
algoritmos son conceptos matemáticos que pueden ser rigurosamente probados. El
uso de matemáticas en la IS es llamado métodos formales.
Los programas
son construidos en una secuencia de pasos. El hecho de definir propiamente y
llevar a cabo estos pasos, como en una línea de ensamblaje, es necesario para
mejorar la productividad de los desarrolladores y la calidad final de los
programas. Este punto de vista inspira los diferentes procesos y metodologías
que encontramos en la IS.
El software
comercial (y mucho no comercial) requiere gestión de proyectos. Hay
presupuestos y establecimiento de tiempos. Gente para liderar. Recursos
(espacio de oficina, computadoras) por adquirir. Todo esto encaja
apropiadamente con la visión de la Gestión de Proyectos.
Los programas
contienen muchos elementos artísticos. Las interfaces de usuario, la
codificación, etc. Incluso la decisión para un nombre de una variable o una
clase. Donald Knuth es famoso
porque ha argumentado que la programación es un arte.
La
responsabilidad en la Ingeniería del Software es un concepto complejo,
sobretodo porque al estar los sistemas informáticos fuertemente caracterizados
por su complejidad, es difícil apreciar sus consecuencias.
En la
Ingeniería del Software la responsabilidad será compartida por un grupo grande
de personas, que comprende desde el ingeniero de requisitos, hasta el
arquitecto software, y contando con el diseñador, o el encargado de realizar
las pruebas. Por encima de todos ellos destaca el director del proyecto. El
software demanda una clara distribución de la responsabilidad entre los
diferentes roles que se dan en el proceso de producción.
El ingeniero
del Sofware tiene una responsabilidad moral y legal limitada a las
consecuencias directas.
Ciclo de vida del software
El término ciclo de vida del
software describe el desarrollo de software, desde la fase inicial hasta la
fase final. El propósito de este programa es definir las distintas fases
intermedias que se requieren para validar el desarrollo de la
aplicación, es decir, para garantizar que el software cumpla los requisitos
para la aplicación y verificación de los procedimientos de desarrollo:
se asegura de que los métodos utilizados son apropiados.
Estos programas se originan en el hecho
de que es muy costoso rectificar los errores que se detectan tarde dentro de la
fase de implementación. El ciclo de vida permite que los errores se detecten lo
antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos de implementación y en los
costos asociados.
El ciclo de vida básico de un software
consta de los siguientes procedimientos:
·
Definición de objetivos: definir el resultado del proyecto y
su papel en la estrategia global.
·
Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los
requisitos del cliente y examinar cualquier restricción que se pueda aplicar.
·
Diseño general: requisitos generales de la arquitectura de la
aplicación.
·
Diseño en detalle: definición precisa de cada
subconjunto de la aplicación.
·
Programación (programación e implementación): es la implementación de
un lenguaje de programación para crear las funciones definidas durante la etapa
de diseño.
·
Prueba de unidad: prueba individual de cada subconjunto
de la aplicación para garantizar que se implementaron de acuerdo con las
especificaciones.
·
Integración: para garantizar que los diferentes módulos se integren
con la aplicación. Éste es el propósito de la prueba de integración que
está cuidadosamente documentada.
·
Prueba beta (o validación), para garantizar que el software
cumple con las especificaciones originales.
·
Documentación: sirve para documentar información necesaria para los
usuarios del software y para desarrollos futuros.
·
Implementación
·
Mantenimiento: para todos los procedimientos correctivos
(mantenimiento correctivo) y las actualizaciones secundarias del software
(mantenimiento continuo).
El orden y la presencia de cada uno de
estos procedimientos en el ciclo de vida de una aplicación dependen del tipo de
modelo de ciclo de vida acordado entre el cliente y el equipo de
desarrolladores.
Modelos de ciclo de vida
Para facilitar una metodología común
entre el cliente y la compañía de software, los modelos de ciclo de vida se han
actualizado para reflejar las etapas de desarrollo involucradas y la
documentación requerida, de manera que cada etapa se valide antes de continuar
con la siguiente etapa. Al final de cada etapa se arreglan las revisiones de
manera que (texto faltante).
Modelo en cascada
El modelo de ciclo de vida en cascada
comenzó a diseñarse en 1966 y se terminó alrededor de 1970. Se define como una
secuencia de fases en la que al final de cada una de ellas se reúne la
documentación para garantizar que cumple las especificaciones y los requisitos
antes de pasar a la fase siguiente:
Modelo V
El modelo de ciclo de vida V proviene
del principio que establece que los procedimientos utilizados para probar si la
aplicación cumple las especificaciones ya deben haberse creado en la fase de
diseño.
Métodos rápidos
"El desarrollo de software de
"métodos rápidos" (también denominado Modelo rápido o
abreviado AG) reduce el tiempo del ciclo de vida del software (por lo
tanto, acelera el desarrollo) al desarrollar, en primera instancia, una versión
prototipo y después integrar la funcionalidad de manera iterativa para
satisfacer los requisitos del cliente y controlar todo el ciclo de desarrollo.
Los métodos rápidos se originaron por
la inestabilidad del entorno técnico y el hecho de que el cliente a veces es
incapaz de definir cada uno de los requisitos al inicio del proyecto. El
término "rápido" es una referencia a la capacidad de adaptarse a los
cambios de contexto y a los cambios de especificaciones que ocurren durante el
proceso de desarrollo. Por lo tanto, en el año 2001, 17 personas redactaron el manifiesto ágil, en el que expresaron los siguientes
puntos principales:
·
individuos e interacciones en lugar de procesos y herramientas
·
desarrollo de software en lugar de documentación exhaustiva
·
trabajo con el cliente en lugar de negociaciones contractuales
·
apertura para los cambios en lugar de cumplimiento de planes poco flexibles
Con la ayuda de los métodos rápidos, el
cliente tiene control total de su proyecto y logra una rápida implementación
del software. De esta forma, se permite al usuario involucrarse desde el inicio
del proyecto.
RAD - Desarrollo rápido de
aplicaciones
El Desarrollo rápido de aplicaciones
(o RAD) definido por James Martin a principios de la década de 1980,
consiste en un ciclo de desarrollo corto basado en tres fases (Requisitos,
Diseño y Construcción) con un plazo de entrega ideal de 90 a 120 días como
máximo.
DSDM
El DSDM (Método de Desarrollo
de Sistema Dinámico) se desarrolló para completar lo que le faltaba al método
RAD al proporcionar una estructura que tome en cuenta el ciclo de desarrollo
completo.
Las características principales del
método DSDM son las siguientes:
·
Participación del usuario
·
Desarrollo iterativo y creciente
·
Frecuencia de entrega mejorada
·
Pruebas integradas en cada fase
·
La aceptación de los productos entregados depende directamente del
cumplimiento de los requisitos.
El método proceso unificado (UP)
es un proceso de desarrollo iterativo y creciente. Esto significa que el
proyecto se divide en fases más cortas y que se envía una nueva versión gradual
al final de cada fase.
Este enfoque está basado en el modelo
UML para la descripción de la arquitectura del software (funcional, de
aplicación y física) y para el desarrollo del caso del usuario. Dicho modelo
describe los requisitos y las demandas del usuario.
RUP - Proceso unificado
racional
RUP (Proceso unificado racional) es
un método de desarrollo iterativo promovido por la compañía Rational
Software, que fue comprada por IBM.
El método RUP especifica,
principalmente, la constitución del equipo y las escalas de tiempo, así como un
número de modelos de documento.
XP - Programación extrema
El método XP (Programación extrema)
define un conjunto de prácticas óptimas para el desarrollo de aplicaciones en
excelentes condiciones al colocar al cliente en el centro del proceso de
desarrollo, manteniendo una cercana relación con dicho cliente.
La Programación extrema se basa en los
siguientes conceptos:
·
Los equipos de desarrollo trabajan directamente con el cliente durante
ciclos cortos de una o dos semanas como máximo.
·
La entrega de las versiones del software ocurre muy temprano y en
intervalos muy cortos para maximizar la interacción con el usuario.
·
Existe una fuerte colaboración entre el equipo de desarrollo mientras
trabaja en el código.
·
El código se prueba y depura a lo largo del proceso de desarrollo.
·
Existen indicadores que miden el progreso del proyecto para poder
actualizar el plan de desarrollo.
·
·
http://www.agilealliance.com/
·
http://www.agilemodeling.com/
·
http://www.extremeprogramming.org/
No hay comentarios:
Publicar un comentario