4. ¿Qué es el Proceso de Software?
Un proceso del software es un conjunto de actividades que conducen a la creación
de un producto de software. Estas actividades pueden consistir en el desarrollo de
software desde cero en un lenguaje de programación estándar. Sin embargo cada
vez se desarrolla nuevo software ampliando y modificando los sistemas existentes
y configurando e integrando software comercial o componentes del sistema.
5. Proceso de Software
▪ Conjunto estructurado de actividades y resultados asociados requeridos para
desarrollar un sistema de software.
▪ Las actividades varían dependiendo de la organización y del tipo de sistema a
desarrollar.
▪ Debe estar explícitamente modelado si va a ser bien administrado.
▪ Los procesos han evolucionado para explotar las capacidades de las personas de
una organización, así como las características específicas de los sistemas que se
están desarrollando.
7. Actividades de los
Procesos de Software
Aunque existen muchos procesos diferentes de software,
algunas actividades fundamentales son comunes para
todos ellos:
• Especificación de software. Se debe definir la funcionalidad de
software y las restricciones de operación
• Diseño e implementación del software. Se debe validar el
software que cumpla su especificación.
• Validación del software. Se debe validar el software para
asegurar que hace lo que el cliente desea
• Evolución del software. El software debe evolucionar para
cubrir las necesidades cambiantes del cliente.
8. ¿Por qué contar con un Proceso de Software?
▪ Hasta hace poco tiempo, la producción de software era realizada con un enfoque
artístico, a diferencia de un enfoque industrial. Ante la constante presencia de
proyectos fallidos, y con el objetivo de mejorar la calidad de los productos, en los
últimos años las organizaciones introdujeron los métodos de ingeniería de Software.
▪ A partir de estos, se formalizó el enfoque de ingeniería de producto para desarrollar
software. Fue entonces que se incorporó la ingeniería de procesos al desarrollo de
software.
9. Proceso de Software
efectivo
Un proceso de Software efectivo habilita a la organización
a incrementar su productividad al desarrollar Software:
▪ Permite estandarizar esfuerzos, promover reutilización,
repetición y consistencia entre proyectos.
▪ Provee la oportunidad de introducir mejores prácticas a la
industria.
▪ Establece la base para mejoras futuras.
▪ Permite entender que las herramientas deben ser utilizadas
para soportar un proceso.
11. Modelos del Proceso de Software
Un modelo de software es una representación abstracta de un proceso del
software. Cada modelo del proceso representa un proceso desde una perspectiva
muy particular u así proporciona sólo información parcial sobre ese proceso. Desde
un punto de vista técnico se puede decir que el proceso de software es un marco
de trabajo de las tareas que se requieren para construir software de alta calidad.
12. Modelo de Cascada
Se denomina modelo en cascada porque su característica
principal es que no se comienza con un paso hasta que no se ha
terminado el anterior. El modelo en Cascada establece que el
software debe ser construido, rigurosamente, a través de una
transformación sucesiva de documentos, siguiendo una estrategia
lineal de desarrollo. Primero saber qué se quiere y después,
cuando se conozca todo lo que se quiere, empezar a construirlo.
Ingeniería y Análisis
del Sistema
Análisis de los
Requerimiento
s
Diseño
Codificación
Prueba
Mantenimiento
13. Modelo de Cascada
Ventajas
▪ La Ventaja de este método radica en su sencillez ya
que sigue los pasos intuitivos necesarios a la hora
de desarrollar el software.
Desventajas
▪ Los proyectos reales raramente siguen el flujo
secuencial que propone el modelo; siempre hay
iteraciones y se crean problemas en la aplicación del
paradigma.
▪ Normalmente, es difícil para el cliente establecer
explícitamente al principio todos los requisitos. El
ciclo de vida clásico lo requiere y tiene dificultades
en acomodar posibles incertidumbres que pueden
existir al comienzo de muchos productos.
▪ El cliente debe tener paciencia. Hasta llegar a las
etapas finales del proyecto, no estará disponible una
versión operativa del programa.
14. Basado en
Componentes
▪ La creación de sistemas intensivos en software requiere
dividir el sistema en componentes con interfaces bien
definidas, que posteriormente serán ensamblados para
generar el sistema. Esta característica en un proceso de
desarrollo, permite que el sistema se vaya creando a
medida que se obtienen o que se desarrolla y maduran
sus componentes.
▪ Un componente, es una parte del sistema, física y
reemplazable, que está sujeto á, y proporciona la
implementación de un conjunto de interfaces.
15. Basado en Componentes
Fases
Cada ciclo consta de cuatro fases: inicio,
elaboración, construcción, y transición:
▪ Inicio: Definición del proyecto.
▪ Elaboración: Planificación del proyecto,
especificación de características y
elaborar arquitectura base.
▪ Construcción: Construcción del
sistema.
▪ Transición: Transición a usuarios
Inicio Elaboración Construcción Transición
Tiempo
Visión Arquitectura Capacidad
inicial
Edición
del
producto
16. Desarrollo Evolutivo
▪ El desarrollo evolutivo se basa en la idea de desarrollar
una implementación inicial, exponiéndola a los
comentarios de los usuarios y refinándola a través de las
diferentes versiones hasta que se desarrolla un sistema
adecuado. Las actividades de validación y
especificación, desarrollo y validación se entrelazan en
vez de separarse, con una rápida retroalimentación entre
ellas.
17. Desarrollo Evolutivo
Ventajas
▪ La producción de sistemas con enfoque evolutivo
para el desarrollo de software suele ser más efectivo
que el enfoque de cascada, ya que satisface las
necesidades inmediatas de los clientes.
▪ La especificación de puede desarrollar en forma
creciente.
▪ Tan pronto los usuarios desarrollen un mejor
entendimiento de su problema, éste se puede
reflejar en el sistema de software.
Desventajas
▪ El proceso no es visible. Los administradores tienen
que hacer entregas regulares para medir progreso.
Si los sistemas se desarrollan rápidamente, no es
rentable producir documentos que reflejen cada
versión del sistema.
▪ A menudo los sistemas tienen una estructura
deficiente. Los cambios continuos tienden a
corromper la estructura del software. La
incorporación de cambios se convierte cada vez
más en una difícil tarea y costosa.