Proceso
de Software
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, tantas 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. Algunos de esos procesos son Extreme Programming (XP), Rational
Unified Process (RUP), Feature Driven Development (FDD), 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".
Se estima que, del total de
proyectos software grandes emprendidos, un 28% fracasan, un 46% caen en severas
modificaciones que lo retrasan y un 26% son totalmente exitosos. Cuando un
proyecto fracasa, rara vez es debido a fallas técnicas, la principal causa de
fallos y fracasos es la falta de aplicación de una buena metodología o proceso
de desarrollo. Entre otras, una fuerte tendencia, desde hace pocas décadas, es
mejorar las metodologías o procesos de desarrollo, o crear nuevas y
concientizar a los profesionales en su utilización adecuada. Normalmente los
especialistas en el estudio y desarrollo de estas áreas (metodologías) y afines
(tales como modelos y hasta la gestión misma de los proyectos) son los
Ingenieros en Software, es su orientación. Los especialistas en cualquier otra
área de desarrollo informático (analista, programador, Lic. en Informática,
Ingeniero en Informática, Ingeniero de Sistemas, etc.) normalmente aplican sus
conocimientos especializados pero utilizando modelos, paradigmas y procesos ya
elaborados.
Es común para el desarrollo
de software de mediano porte que los equipos humanos involucrados apliquen sus
propias metodologías, normalmente un híbrido de los procesos anteriores y a
veces con criterios propios.
El proceso de desarrollo
puede involucrar numerosas y variadas tareas, desde lo administrativo, pasando
por lo técnico y hasta la gestión y el gerenciamiento. Pero casi rigurosamente
siempre se cumplen ciertas etapas mínimas; las que se pueden resumir como
sigue:
Análisis 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. Se han
ideado modelos y diversos procesos de trabajo para estos fines. Aunque aun 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).
Diseño y arquitectura
Se refiere a
determinar cómo 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á íntimamente 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 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
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.
COnstructive COst MESel del (COCOMO) es un algorítmico Modelo de la valoración del coste del software convertido cerca Barry Boehm. El modelo utiliza una básica regresión fórmula, con los parámetros que se derivan de datos históricos del proyecto y de características actuales del proyecto.
COCOMO
COnstructive COst MESel del (COCOMO) es un algorítmico Modelo de la valoración del coste del software convertido cerca Barry Boehm. El modelo utiliza una básica regresión fórmula, con los parámetros que se derivan de datos históricos del proyecto y de características actuales del proyecto.
COCOMO primero fue publicado en 1981 Barry J. Boehm Libro Economía de la tecnología de dotación lógica como modelo para estimar esfuerzo, coste, y el horario para los proyectos del software. Dibujó en un estudio de 63 proyectos en TRW Espacio aéreo donde Barry Boehm era el director de la investigación y de la tecnología del software en 1981. El estudio examinó los proyectos que se extendían de tamaño a partir de 2000 a 100.000 líneas del código, y lenguajes de programación que se extienden de asamblea a PL/I. Estos proyectos fueron basados en modelo de la cascada del desarrollo del software que era el proceso frecuente del desarrollo del software en 1981.
Referencias a esta del modelo llamada típicamente él COCOMO 81. En 1997COCOMO II fue convertido y finalmente publicado en 2001 en el libroValoración del coste del software con COCOMO II. COCOMO II es el sucesor de COCOMO 81 y se satisface mejor para estimar proyectos modernos del desarrollo del software. Proporciona más ayuda para moderno procesos del desarrollo del software y una base de datos actualizada del proyecto. La necesidad del nuevo modelo vino mientras que la tecnología del desarrollo del software se movió desde el chasis y el procesamiento por lotes de noche al desarrollo de escritorio, a la reutilidad del código y al uso de los componentes de software disponibles. Este artículo se refiere COCOMO 81.
COCOMO consiste en una jerarquía de tres cada vez más detallados y de formas exactas. El primer nivel, COCOMO básico es buena para aprisa, la orden temprana, áspera de las estimaciones de la magnitud de los costes del software, pero su exactitud debe limitado a su carencia de factores explicar diferencia en cualidades del proyecto (Conductores del coste). COCOMO intermedio toma estos conductores del coste en consideración y COCOMO detallado explica además la influencia de las fases del proyecto individual.
COCOMO básico son los parásitos atmosféricos, el modelo solo-valorado que computa esfuerzo del desarrollo del software (y coste) en función del tamaño del programa expresado en líneas estimadas del código. COCOMO se aplica a tres clases de los proyectos del software:
- Los proyectos orgánicos - son los proyectos relativamente pequeños, simples del software en los cuales los equipos pequeños con el buen trabajo de la experiencia del uso a un sistema de requisitos menos que rígidos.
- los proyectos - (de tamaño y complejidad) Semi-se separan los proyectos intermedios del software en los cuales los equipos con los niveles mezclados de la experiencia deben resolver una mezcla de requisitos rígidos y menos que rígidos.
- Los proyectos - se encajan los proyectos del software que se deben desarrollar dentro de un sistema de hardware apretado, de software, y de apremios operacionales.
Las ecuaciones básicas de COCOMO toman la forma
E=ab(KLOC)bb
D=cb(e)db
P=E/D
Donde está el esfuerzo E aplicado en persona-meses, D es el tiempo de desarrollo en meses cronológicos, KLOC es el número estimado de líneas entregadas del código para el proyecto (expresado en millares), y P es el número de la gente requerida. Los coeficientes ab, bb, cb y db se dan en la tabla siguiente.
Proyecto del software
|
ab
|
bb
|
cb
|
db
|
Orgánico
|
2.4
|
1.05
|
2.5
|
0.38
|
Semi-separado
|
3.0
|
1.12
|
2.5
|
0.35
|
Encajado
|
3.6
|
1.20
|
2.5
|
0.32
|
COCOMO básico es bueno para aprisa, temprano, la orden áspera de las estimaciones de la magnitud del software cuesta, pero no explica diferencias en apremios del hardware, calidad y experiencia del personal, uso de herramientas modernas y de técnicas, y otras cualidades del proyecto sabidas para tener una influencia significativa en costes del software, que limita su exactitud.
COCOMO intermedio esfuerzo del desarrollo del software de los cálculos como función del tamaño del programa y de un sistema de los “conductores del coste” que incluyen el gravamen subjetivo del producto, del hardware, del personal y de las cualidades del proyecto. Esta extensión considera un sistema de cuatro “los conductores costados”, cada uno con un número de cualidades del subsidiario:
- Cualidades de producto
- Confiabilidad requerida del software
- Tamaño de la base de datos del uso
- Complejidad del producto
- Cualidades del hardware
- Apremios de funcionamiento Run-time
- Apremios de la memoria
- Volatilidad del ambiente virtual de la máquina
- Tiempo de turnabout requerido
- Cualidades del personal
- Capacidad del analista
- Capacidad de la tecnología de dotación lógica
- Experiencia de los usos
- Experiencia virtual de la máquina
- Experiencia del lenguaje de programación
- Cualidades del proyecto
- Uso de las herramientas del software
- Uso de los métodos de la tecnología de dotación lógica
- Horario requerido del desarrollo
Cada uno de las 15 cualidades recibe un grado en una escala del seis-punto que se extienda de “muy bajo” a “superior” (en importancia o valor). Un multiplicador del esfuerzo de la tabla abajo se aplica al grado. El producto de todos los multiplicadores del esfuerzo da lugar a coeficiente de adaptación del esfuerzo (EAF). Los valores típicos para EAF se extienden a partir de la 0.9 a 1.4.
Conductores del coste
|
Grados
| |||||
Muy bajo
|
Bajo
|
Nominal
|
Alto
|
Muy arriba
|
Superior
| |
Cualidades de producto
| ||||||
Confiabilidad requerida del software
|
0.75
|
0.88
|
1.00
|
1.15
|
1.40
| |
Tamaño de la base de datos del uso
|
0.94
|
1.00
|
1.08
|
1.16
| ||
Complejidad del producto
|
0.70
|
0.85
|
1.00
|
1.15
|
1.30
|
1.65
|
Cualidades del hardware
| ||||||
Apremios de funcionamiento Run-time
|
1.00
|
1.11
|
1.30
|
1.66
| ||
Apremios de la memoria
|
1.00
|
1.06
|
1.21
|
1.56
| ||
Volatilidad del ambiente virtual de la máquina
|
0.87
|
1.00
|
1.15
|
1.30
| ||
Tiempo de turnabout requerido
|
0.87
|
1.00
|
1.07
|
1.15
| ||
Cualidades del personal
| ||||||
Capacidad del analista
|
1.46
|
1.19
|
1.00
|
0.86
|
0.71
| |
Experiencia de los usos
|
1.29
|
1.13
|
1.00
|
0.91
|
0.82
| |
Capacidad de la Software Engineer
|
1.42
|
1.17
|
1.00
|
0.86
|
0.70
| |
Experiencia virtual de la máquina
|
1.21
|
1.10
|
1.00
|
0.90
| ||
Experiencia del lenguaje de programación
|
1.14
|
1.07
|
1.00
|
0.95
| ||
Cualidades del proyecto
| ||||||
Uso de las herramientas del software
|
1.24
|
1.10
|
1.00
|
0.91
|
0.82
| |
Uso de los métodos de la tecnología de dotación lógica
|
1.24
|
1.10
|
1.00
|
0.91
|
0.83
| |
Horario requerido del desarrollo
|
1.23
|
1.08
|
1.00
|
1.04
|
1.10
| |
La fórmula intermedio de Cocomo ahora toma la forma:
E=ai(KLoC)(bi).EAF
Donde está el esfuerzo E aplicado en persona-meses, KLoC es el número estimado de millares de líneas entregadas de código para el proyecto, y EAFes el factor calculado arriba. El coeficiente ai y el exponente bi se dan en la tabla siguiente.
Proyecto del software
|
ai
|
bi
|
Orgánico
|
3.2
|
1.05
|
Semi-separado
|
3.0
|
1.12
|
Encajado
|
2.8
|
1.20
|
El tiempo de desarrollo D aplicaciones del cálculo E de la misma forma que en el COCOMO básico.
COCOMO detallado - incorpora todas las características de la versión intermedia con un gravamen del impacto del conductor del coste en cada paso (análisis, diseño, etc.) del proceso de la tecnología de dotación lógica.
Bibliografía:
a) Sistemas VD “http://sistemasvd.wordpress.com/2008/07/05/fases-del-proceso-de-desarrollo-del-software/”
No hay comentarios:
Publicar un comentario