Modelos de proceso de desarrollo del software
¿Qué es un proceso?
Un conjunto de tareas ordenadas que tienen como objetivo alcanzar o cumplir algunas metas.
¿Qué es un modelo de proceso de desarrollo del software?
Un conjunto de tareas ordenadas que tienen como objetivo producir soluciones de software.¿Qué es un modelo?
Un
modelo es una representación de una realidad compleja. Modelar es desarrollar
una descripción lo más exacta posible de un sistema y de las actividades
llevadas a cabo en él.
Cuando
un proceso es modelado, con ayuda de una representación gráfica (diagrama de
proceso), pueden apreciarse con facilidad las interrelaciones existentes entre
distintas actividades, analizar cada actividad, definir los puntos de contacto
con otros procesos, así como identificar los subprocesos comprendidos. Al mismo
tiempo, los problemas existentes pueden ponerse de manifiesto claramente dando
la oportunidad al inicio de acciones de mejora.
El modelado
de procesos, así como su nombre lo indica, tiene 2 aspectos que lo definen: el
modelado y los procesos. Frecuentemente, los sistemas, conjuntos de procesos y
subprocesos integrados en una organización, son difíciles de comprender,
amplios, complejos y confusos; con múltiples puntos de contacto entre sí y con
un buen número de áreas funcionales, departamentos y puestos implicados. Un
modelo puede dar la oportunidad de organizar y documentar la información sobre
un sistema.
Diagramado
Diagramar
es establecer una representación visual de los procesos y subprocesos, lo que
permite obtener una información preliminar sobre la amplitud de los mismos, sus
tiempos y los de sus actividades.
La
representación gráfica facilita el análisis, uno de cuyos objetivos es la descomposición
de los procesos de trabajo en actividades discretas. También hace posible la
distinción entre aquellas que aportan valor añadido de las que no lo hacen, es
decir que no proveen directamente nada al cliente del proceso o al resultado
deseado. En este último sentido cabe hacer una precisión, ya que no todas las
actividades que no proveen valor añadido han de ser innecesarias; éstas pueden
ser actividades de apoyo y ser requeridas para hacer más eficaces las funciones
de dirección y control, por razones de seguridad o por motivos normativos y de
legislación.
Diagramar
es una actividad íntimamente ligada al hecho de modelar un proceso, que es por
sí mismo un componente esencial en la gestión de procesos de negocios.
Todo el desarrollo del software se puede caracterizar como bucle de resolución de problemas en
el que se encuentran cuatro etapas distintas
ESTADO ACTUAL (STATUS QUO):
«representa el
estado
actual de sucesos».
DEFINICIÓN DE PROBLEMAS:
identifica el
problema específico a resolverse; el
DESARROLLO TÉCNICO :
resuelve el
problema a través de la
aplicación de alguna tecnología
INTEGRACIÓN DE SOLUCIONES:
ofrece los
resultados (por ejemplo: documentos,
programas, datos, nueva función
comercial, nuevo producto)
a los que solicitan la solución en primer
lugar.
Con independencia del modelo de
proceso que se
seleccione para un proyecto de
software, todas las etapas coexisten simultáneamente
en algún nivel de detalle. las cuatro etapas tratadas anteriormente se aplican igualmente al análisis de una aplicación completa y a la generación de un pequeño segmento de código.
MODELO LINEAL SECUENCIAL
Llamado algunas veces «ciclo de vida
básico» o modelo en cascada», el modelo lineal secuencial sugiere un enfoque sistemático,
secuencial, para el desarrollo del software que comienza en un nivel de
sistemas y progresa con el análisis, diseño, codificación,
pruebas y mantenimiento
Análisis de los requisitos del
software.
Para comprender la naturaleza del (los) programa(s) a construirse, el
ingeniero («analista») del software debe comprender el dominio
de información del software, así como la función requerida,
comportamiento, rendimiento de interconexión.
Diseño.
se centra en cuatro atributos distintos de programa: estructura de datos, arquitectura de software, representaciones de interfaz y
detalle procedimental (algoritmo).
Generación de código.
El diseño
se debe traducir en una forma legible por la máquina. El paso
de generación de código lleva a cabo esta tarea. Si se
lleva a cabo el diseño de una forma detallada, la
generación de
código se realiza mecánicamente.
Pruebas.
Una vez que se ha generado el
código, comienzan las pruebas del programa. detección de errores y asegurar
que la entrada definida produce resultados reales de acuerdo con los resultados
requeridos.
¿Por qué algunas veces falla el
modelo lineal?
- A menudo es difícil que el cliente exponga explícitamente todos los requisitos. El modelo lineal secuencial lo requiere y tiene dificultades a la hora de acomodar la incertidumbre natural al comienzo de muchos proyectos.
- El cliente debe tener paciencia. Una versión de trabajo del (los) programa(s) no estará disponible hasta que el proyecto esté muy avanzado
Modelo
de Construcción
De
Prototipos
El paradigma de construcción de prototipos comienza con la recolección de
requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición.
El diseño rápido se centra en una representación de aspectos del software que serán visibles para el usuario/cliente (enfoques de
entrada y formatos
de salida). El diseño rápido lleva a la construcción de un prototipo.
En la mayoría de los proyectos, el primer
sistema construido apenas se puede utilizar
y se tiene que tirar, porque incluso la mejor planificación no es omnisciente como para que esté
perfecta la primera vez.
La iteración ocurre cuando el prototipo
se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador
comprenda mejor lo que se necesita hacer.
La construcción de prototipos puede ser problemática por las siguientes razones:
- El cliente ve una versión de trabajo del software, sin saber que con la prisa de hacer que funcione no se ha tenido en cuenta la calidad del software global o la facilidad de mantenimiento a largo plazo.
-
Se puede utilizar un sistema operativo o lenguaje de programación inadecuado simplemente porque está disponible
Modelo
DRA
El Desarrollo
Rápido de Aplicaciones (DRA)es un modelo de proceso
del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo
extremadamente corto. Es una adaptación a «alta velocidad» del modelo lineal secuencial en el que se
logra el desarrollo
rápido utilizando una construcción basada
en componentes.
Si se comprenden bien los requisitos y se
limita el ámbito
del proyecto, el proceso DRA permite al equipo de desarrollo crear un «sistema
completamente funcional» dentro de períodos cortos de tiempo (por ejemplo: de 60 a
90 días)
Modelado
de Gestión. El flujo de información entre las funciones
de gestión se
modela de forma que responda a las
siguientes preguntas: ¿Qué
información conduce el proceso de gestión? ¿Qué información se
genera? ¿Quién
la genera? ¿A dónde va la información? ¿Quién la procesa?
Modelado de datos. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.
Modelado del proceso. Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar,
suprimir, o
recuperar un objeto de datos.
Generación de aplicaciones. En lugar de crear software con
lenguajes de programación de tercera generación, trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). Se utilizan herramientas para facilitar la
construcción del software.
Pruebas y entrega. Como el proceso DRA enfatiza la reutilización, ya se han comprobado
muchos de los componentes de los programas. Esto reduce
tiempo de pruebas.
Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.
Modelos Evolutivos de Proceso Del
Software
Los
modelos evolutivos son iterativos. Se caracterizan
por la forma en que permiten a los
ingenieros del software desarrollar
versiones cada vez mas completas del software.
El modelo incremental: El
modelo incremental combina
elementos del modelo lineal secuencial
con
la
filosofía
interactiva de construcción de
prototipos. el modelo incremental aplica secuencias lineales
de forma escalonada mientras progresa el tiempo
en el calendario. Cada secuencia lineal
produce un «incremento» del software
suplementarias .
Modelo
Espiral
Es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Se
desarrolla en una serie de versiones
incrementales.
Durante las primeras iteraciones,
la versión incremental
podría ser un modelo en papel
o un prototipo. Durante las últimas iteraciones,
se producen versiones cada vez más
completas del sistema
diseñado.
El modelo en espiral se divide en
un número de actividades de marco de trabajo, también
llamadas regiones de tareas. La Figura 2.8 representa un modelo en espiral que contiene seis
regiones de tareas:
Comunicación con el cliente- las
tareas requeridas para establecer
comunicación entre el desarrollador y el cliente.
planificación- las
tareas requeridas para definir recursos,
el tiempo y otra información relacionadas con el
proyecto.
análisis de
riesgos- las tareas requeridas para evaluar
riesgos técnicos y de gestión.
ingeniería- las
tareas requeridas para construir una o más representaciones de la aplicación.
construcción y acción- las tareas
requeridas
para
construir, probar, instalar y proporcionar soporte al usuario (por
ejemplo: documentación y práctica)
evaluación del
cliente- las tareas requeridas para
obtener la reacción del cliente según la evaluación
de las representaciones del software creadas
durante
la etapa de ingeniería e implementada
durante la etapa de
instalación.
El
objetivo de esta actividad es
mostrar los requisitos del cliente. En un contexto ideal,
el desarrollador simplemente pregunta al cliente lo
que se necesita y el cliente proporciona detalles suficientes para
continuar. Desgraciadamente, esto raramente ocurre.
En realidad el cliente y el desarrollador entran
en un proceso de negociación, donde el cliente puede
ser preguntado para sopesar la funcionalidad, rendimiento, y
otros productos o características del sistema
frente
al coste y al tiempo de comercialización
| Modelo | Silla |
| Ciclo de Vida | Silla |
| Proceso | Barco |
| Método | Miércoles |
| Métodología | Miércoles |
| Herramienta | Martes |
| Paradigma | Martes |
