Modelos de Proceso del Software
Marcos de trabajos de las tareas
Se Dividen en:
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
Actividades
Ingeniería y Análisis del Sistema
Debido a que el software es siempre parte de un sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software.
Análisis de los requisitos del software
Análisis: Se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (Documento de Especificación de Requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos (debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas).
Diseño
El diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación.
Codificación
Es la fase de programación. Aquí se desarrolla el código fuente, el diseño debe traducirse en una forma legible para la maquina, haciendo uso de prototipos así como pruebas y ensayos para corregir errores.
Prueba
Una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Se comprueba que funciona correctamente antes de ser puesto en explotación.
Mantenimiento
El software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán cuando se hayan encontrado errores, esto en lugar de que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.
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. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.
La Ventaja
La Ventaja de este método radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.
Es un modelo de proceso de software evolutivo ha sido desarrollado para cubrir las mejores características tanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo al mismo tiempo un nuevo elemento: el análisis de riesgo
Actividades
Planificación
Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, se analizan e identifican los riesgos.
Análisis de riesgo
El proyecto se revisa y se toma la decisión de si se debe continuar con un ciclo posterior de la espiral
Ingeniería.
En este sector se desarrolla y se valida. Después de la evaluación de riesgos, se elige un modelo para el desarrollo del sistema
Evaluación del cliente
El cliente evalúa el trabajo de ingeniería (cuadrante de evaluación de cliente) y sugiere modificaciones. Sobre la base de los comentarios del cliente se produce la siguiente fase de planificación y de análisis de riesgo.
Desventajas
-Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
-Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
-Genera mucho tiempo en el desarrollo del sistema
Modelo costoso
-Requiere experiencia en la identificación de riesgos
ventajas
-El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
-Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.
-El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de -evolución del producto.
El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se -aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas.
-En la utilización de grandes sistemas a doblado la productividad.
Modelo de cascada
Modelo de espiral
Proceso Software Personal.
Proceso de desarrollo unificado
Modelo incremental
El modelo incremental aplica secuencias lineales de forma escalonada mientras avanza el tiempo. Corrige la necesidad de una secuencia no lineal de pasos de desarrollo. Cada secuencia lineal produce un incremento del software
ventajas
- con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya ue se implementa la funionalidad
parcial
- provee un impacto ventajoso frente al clente, entrega de partes del software
desventajas
- No es aconsejable para sistemas complejos y proyectos grandes debido a su tardia forma de encontrar problemas
- requiere de mucha planeacion, administrativa y tecnica
-metas claras para conocer el estado del proyecto
- no se sabe con certeza los costos finales
Es un modelo complejo con mucha terminología propia, pensado principalmente para el desarrollo de grandes proyectos. Es un proceso que puede adaptarse y extenderse en función de las necesidades de cada empresa
Consta de:
Características del Proceso Unificado de Desarrollo
El Proceso Unificado guía a los equipos de proyecto en cómo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto.
Dirigido por casos de uso
Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un resultado de valor a un usuario. Los casos de uso modelan los requerimientos funcionales del sistema.
En conclusión los casos de uso son utilizados para
Establecer el comportamiento deseado del sistema
Verificar y validar la arquitectura del sistema
Hacer Pruebas
Tener una comunicación entre los participantes del proyecto
caracteristicas
- se tiene en cuenta el tiempo al mercado y los riesgos del proyecto
- la captura de los requerimientos y en el establecimiento de una guía arquitectónica, para diseñar y probar el sistema hecho de
a cuerdo a los requerimientos y a la arquitectura
- es soportado por herramientas que automatizan
- está basado en componentes
Dirigido por casos de uso
- los desarrolladores crean una serie de modelos de diseño e implementación que llevan a cabotopic
- En conclusión los casos de uso son utilizados para:
• Establecer el comportamiento deseado del sistema
• Verificar y validar la arquitectura del sistema
• Hacer Pruebas
• Tener una comunicación entre los participantes del proyecto
Ventajas
-educción de riesgos en el proyecto
-la garantía de calidad
-la integración entre lo que es propiamente desarrollo con mantenimiento de software
Es un sistema estructurado de descripciones, de medidas, y de los métodos de proceso que pueden ayudar a ingenieros a mejorar su actividad personal.
Los siguientes procesos
Registro de fallas
El registro de una falla se usa para tener los defectos encontrados y corregidos. El objetivo de esto es determinar donde se pierde mucho tiempo y ser lo mas minucioso posible con los datos.
•Fecha de la falla encontrada
•Numero de falla
•Tipo de falla (Documentación, sintaxis, asignación, interfase, etc.…)
•Fase donde se inicio la falla
•Fase donde la falla se elimino
•Descripción del porque de la falla
•Tiempo que se llevo para reparar la falla
Estándar de fallas
Estos pueden se algunas de las fallas que se registran y que se pueden tomar como un estándar:
Declaración de asignación, duplicado de nombres, alcance, limitaciones
Procedimiento de la Interfaz, llamadas, referencias, I/O, formato de usuario
Chequeo de mensajes de error
Estructura de datos, contenido
Función de conexión, enlace, recursividad,
Configuración de sistema, sincronización, memoria
Construcción, Manejo de cambio de paquete, librería, control de versión
Diseño del entorno, compilación, prueba, otro sistema de soporte de problemas
Deletreo de sintaxis, puntuación, formato
Comentario de documentación, mensajes
Mejora del proceso
La mejora del proceso provee un registro de fallas problemas e ideas de mejora. Puede contener lo siguiente
• Descripción de la falla encontrada dentro del proyecto
• Numero del problema
• Descripción y las dificultades
• Descripción del impacto que tiene el producto o el proceso con la falla o problema.
• Descripción de las sugerencias para mejorar el proceso.
• Numeración de cada una de las sugerencias.
• Identificación de los elementos del proceso que son afectados.
• Cuando será apropiado, relacionar las sugerencias de mejor para el problema.
• Dar prioridades a las sugerencias y explicar porque son importantes.
• Agregar comentarios sobre el proyecto.
• Lección aprendida
• Condiciones que es necesario recordar para determinar el porque funciona bien el proceso o el porqué es deficiente.
Documentación del proceso
En esta parte se debe tener documentada la planeación el desarrollo y el post ejecución del proceso. En seguida se describe que es lo que debe contener cada uno de ellos.
Se divide en:
Planeación
•Registrar el inicio del proyecto en el resumen del plan del proyecto.
•Estimación de nuevos totales como los cambios en las líneas de código requeridos en PSP0.1.
•Estimación del tiempo requerido para el desarrollo.
•Registrar la fecha del proyecto.
•Producir u obtener los requerimientos de las declaraciones.
Desarrollo:
• Diseño, implementación, compilación, prueba.(PSP0.1)
• Registrar el tiempo.
Post-ejecución:
• Completar el resumen del plan del proyecto, con el tiempo actual, fallas, tamaño de los datos.
• Terminar el mejoramiento del proceso.
Planeación Personal del Proceso
El PSP1 estima el tamaño del software, hace una prueba de reporte del PSP. Adicionalmente contribuye a PSP1 estimar los recursos y el horario.
El PSP1 intenta establecer el proceso de forma ordenada y repetida para desarrollar el software usando el tamaño, recursos y horarios estimados.
Las tareas que se incluyen del PSP0 y PSP0.1 agregan lo siguiente:
• Estimación de tamaño.
• Reporte de prueba.
• Planeación de tareas
• Planeación del horario
Estimación de tamaño
Las siguientes disciplinas se usan para estimar las líneas de código. Se debe tener el tamaño de los datos sobre un número de proyectos previamente desarrollados para poder establecer estimaciones iniciales.
Puntos de Función:
• Ali Arifoglu. Metodología de software para la estimación de costos ACM Sigsoft Software Engineering.
•COCOMO Model (Constructive Cost Model) es el modelo constructivo de costos. Este modelo es para la estimación de líneas de código.
Planeación de Tareas
La planeación de las tareas implica estimar el tiempo de desarrollo y de los datos de la terminación para cada tarea del proyecto. Este también proporciona una base según el horario que se sigue. El plan debe contener lo siguiente:
• Nombre y número de la tarea.
• Planeación de hora de acuerdo a la tarea por semana, y para el proyecto.
• Tiempo actual por tarea por semana, y ara el proyecto.
PSP1 Reporte de pruebas
El reporte de pruebas se usa para mantener un registro de pruebas de ejecución y resultados obtenidos. Estos pueden ser tan detallados como se desee, con esto se puede hacer la misma prueba y obtener los mismos resultados. El reporte incluye lo siguiente:
• Nombre y numero de prueba
• Objetivo de la prueba
• Descripción de la prueba
• Condiciones de tiempo o configuración especial
• Resultados esperados
• Resultado actual
Revisión de código
El objetivo principal de la revisión de calidad es mejorar la calidad del programa examinando parte o todo el sistema y su documentación asociada.
Se divide en:
Las revisiones tienen un número de pruebas dinámicas del excedente de las ventajas.
• No requieren que el programa se este ejecutando
• Son una medida directa de defectos o cualidades de la calidad
• Se consideran mas efectivos
La revisión de código consiste en la comprobación de la inicialización de la variable y sus parámetros
• En el inicio del programa, inicio de los ciclos, formato de la llamada de la función
Llamada de función y formato de la llamada
• Punteros parámetros, y el uso de ‘&’
Comprobación y deletreo de nombres
• Es consistente.
• Esta dentro del alcance de la declaración.
• Todas las estructuras y clases usan ‘.’ Y ‘->’ de forma correcta.
Comprobación de secuencias
• Identificación de terminación por puntuaciones y NULL.
Comprobación de archivos
• Declaración correcta.
• Abrir y cerrar correctamente.
Comprobación de punteros
• Iniciar en NULL.
• Borrar solamente después que se crea o es nuevo
• Borrar siempre después de su uso
Comprobación del formato de salida
• Alineación y espaciado correcto
Verificación de operadores lógicos
• Uso apropiado de operadores lógicos (=, ,…etc.).
• Uso apropiado de paréntesis para operaciones lógicas.
Las revisiones técnicas o inspecciones de programa son similares excepto porque su objetivo principal es identificar las fallas o defectos tales como anomalías en el código, errores lógicos, incumplimiento de estándares.
desarrollo agil
Son métodos que ponen el énfasis en agilizar el desarrollo
algunos metodos agiles:
Adaptive Software Development (ASD)
Agile Unified Process (AUP)
Crystal Clear
Feature Driven Development (FDD)
Lean Software Development (LSD)
Kanban
Open Unified Process (OpenUP)
Programación Extrema (XP)
Método de desarrollo de sistemas dinámicos (DSDM)
Scrum