Se define como Proceso al conjunto ordenado de pasos a
seguir para llegar a la solución de un problema u obtención de un producto, en
este caso particular, para lograr la obtención de un producto software que
resuelva un problema.
Ese proceso de creación de software puede llegar a ser
muy complejo, dependiendo de su porte, características y criticidad del mismo.
Por ejemplo la creación de un sistema operativo es una tarea que requiere
proyecto, gestión, numerosos recursos y todo un equipo disciplinado de trabajo.
En el otro extremo, si se trata de un sencillo programa (ejemplo: resolución de
una ecuación de segundo orden), éste puede ser realizado por un solo
programador (incluso aficionado) fácilmente. Es así que normalmente se dividen
en tres categorías según su tamaño (líneas de código) y/o costo: de Pequeño,
Mediano y Gran porte. Existen varias metodologías para estimarlo, una de las
más populares es el sistema COCOMO que provee métodos y un software (programa)
que calcula y provee una estimación de todos los costos de producción en un
"proyecto software" (relación horas/hombre, costo monetario, cantidad
de líneas fuente de acuerdo a lenguaje usado, etc.).
Considerando los de gran porte, es necesario realizar
tantas y tan complejas tareas, tanto técnicas, de gerenciamiento, fuerte
gestión y análisis diversos (entre otras) que toda una ingeniería hace falta
para su estudio y realización: es la Ingeniería de Software.
En tanto que en los de mediano porte, pequeños equipos de
trabajo (incluso un avezado analista-programador solitario) puede realizar la
tarea. Aunque, siempre en casos de mediano y gran porte (y a veces también en
algunos de pequeño porte, según su complejidad), se deben seguir ciertas etapas
que son necesarias para la construcción del software. Tales etapas, si bien
deben existir, son flexibles en su forma de aplicación, de acuerdo a la
metodología o Proceso de Desarrollo escogido y utilizado por el equipo de
desarrollo o analista-programador solitario (si fuere el caso).
Los "procesos de desarrollo de software" poseen
reglas preestablecidas, y deben ser aplicados en la creación del software de
mediano y gran porte, ya que en caso contrario lo más seguro es que el proyecto
o no logre concluir o termine sin cumplir los objetivos previstos y con
variedad de fallos inaceptables (fracasan, en pocas palabras). Entre tales
"procesos" los hay ágiles o livianos (ejemplo XP), pesados y lentos
(ejemplo RUP) y variantes intermedias; y normalmente se aplican de acuerdo al
tipo y porte y tipología del software a desarrollar, a criterio del líder (si
lo hay) del equipo de desarrollo. etc.
Cualquiera sea el "proceso" utilizado y
aplicado en un desarrollo de software (RUP, FDD, etc), y casi
independientemente de él, siempre se debe aplicar un "Modelo de Ciclo de
Vida".
Análisis y
Especificación de requisitos
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.
Diseño y arquitectura
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
Reducir un diseño a código puede ser la parte más obvia
del trabajo de ingeniería de software, pero no es necesariamente la porción más
larga. La complejidad y la duración de esta etapa está intimamente ligada al o
a los lenguajes de programación utilizados.
Pruebas
Consiste en comprobar que el software realice
correctamente las tareas indicadas en la especificación. 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 practica 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 area 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.
Documentación
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
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
COCOMO
Es un modelo que permite estimar el costo, el esfuerzo, y programar la
hora de planificar una nueva actividad de desarrollo de software.
El modelo provee tres “niveles” de aplicación: básico, intermedio y
avanzado, basados en los factores considerados por el modelo.
Básico, es un modelo estático simplemente evaluado que calcula el esfuerzo (y
costo) del desarrollo del software como función del programa expresado en
líneas de código (LDC estimados).
Intermedio, calcula el esfuerzo del desarrollo del software como función del
tamaño del programa y un conjunto de “guías de costo” que incluye una
evaluación subjetiva del producto, hardware, personal y de los atributos del
proyecto.
Avanzado, incorpora todas las características de la versión
intermedia con una evaluación del impacto de las vías de costo en cada fase
(análisis, diseño, etc) del proceso de la ingeniería de software.
El
Modelo Constructivo de Costos (o COCOMO, por su acrónimo del ingléses
COnstructive COst MOdel) es un modelo matemático de base empírica utilizado
para estimación de costos1 de software. Incluye tres submodelos, cada uno
ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza
el proceso de desarrollo del software: básico, intermedio y detallado.
Este
modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos
de los 80, exponiéndolo detalladamente en su libro "Software Engineering
Economics" (Prentice-Hall, 1981).
Modelo básico.
Se utiliza para obtener una primera
aproximación rápida del esfuerzo, y
hace uso de la siguiente tabla de constantes para calcular distintos aspectos
de costes:
MODO
|
a
|
b
|
c
|
d
|
Orgánico
|
3.20
|
1.05
|
2.50
|
0.38
|
Semilibre
|
3.00
|
1.12
|
2.50
|
0.35
|
Rígido
|
2.80
|
1.20
|
2.50
|
0.32
|
Estos valores son para las fórmulas:
·
Personas necesarias por mes para llevar
adelante el proyecto (MM) = a*(Klb)
·
Tiempo de desarrollo del proyecto (TDEV)
= c*(MMd)
·
Personas necesarias para realizar el
proyecto (CosteH) = MM/TDEV
·
Costo total del proyecto (CosteM)
= CosteH * Salario medio entre los programadores y analistas.
Se puede observar que a medida que
aumenta la complejidad del proyecto (modo), las constantes aumentan de 2.4 a
3.6, que corresponde a un incremento del esfuerzo del personal. Hay que
utilizar con mucho cuidado el modelo básico puesto que se obvian muchas
características del entorno
Modelo intermedio
Este
añade al modelo básico quince modificadores opcionales para tener en cuenta en
el entorno de trabajo, incrementando así la precisión de la estimación.
Para
este ajuste, al resultado de la fórmula general se lo multiplica por el
coeficiente surgido de aplicar los atributos que se decidan utilizar.
Los
valores de las constantes a reemplazar en la fórmula son:
MODO
|
a
|
b
|
Orgánico
|
3.20
|
1.05
|
Semilibre
|
3.00
|
1.12
|
Rígido
|
2.80
|
1.20
|
Se
puede observar que los exponentes son los mismos que los del modelo básico,
confirmando el papel que representa el tamaño; mientras que los coeficientes de
los modos orgánico y rígido han cambiado, para mantener el equilibrio alrededor
del semilibre con respecto al efecto multiplicador de los atributos de coste.
Características
Pertenece a la categoría de modelos de subestimaciones
basados en estimaciones matemáticas. Está orientado a la magnitud del producto
final, midiendo el "tamaño" del proyecto, en líneas de código
principalmente.
Inconvenientes
- Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta los recursos necesarios para realizarlas.
- Se puede desviar de la realidad si se indica mal el porcentaje de líneas de comentarios en el código fuente.
- Es un tanto subjetivo, puesto que está basado en estimaciones y parámetros que pueden ser "vistos" de distinta manera por distintos analistas que usen el método.
- Se miden los costes del producto, de acuerdo a su tamaño y otras características, pero no la productividad.
- La medición por líneas de código no es válida para orientación a objetos.
- Utilizar este modelo puede resultar un poco complicado, en comparación con otros métodos (que también sólo estiman).
Modelo Detallado
Presenta principalmente dos mejoras respecto al anterior:
· Los factores correspondientes a los
atributos son sensibles o dependientes de la fase sobre la que se realizan las
estimaciones. Aspectos tales como la experiencia en la aplicación, utilización
de herramientas de software, etc., tienen mayor influencia en unas fases que en
otras, y además van variando de una etapa a otra.
· Establece una jerarquía de tres niveles
de productos, de forma que los aspectos que representan gran variación a bajo
nivel, se consideran a nivel módulo, los que representan pocas variaciones, a
nivel de subsistema; y los restantes son considerados a nivel sistema.
BIBLIOGRAFIA:
a) http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm
b) http://es.wikipedia.org/wiki/COCOMO
c)Sistemas VD “http://sistemasvd.wordpress.com/2008/07/05/fases-del-proceso-de-
desarrollo-del-software/”
