se refiere a métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan con el tiempo según la necesidad del proyecto
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
desarrollo agil
Son métodos que ponen el énfasis en agilizar el desarrollo
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
Revisión de código
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.
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.
Verificación de operadores lógicos
• Uso apropiado de paréntesis para operaciones lógicas.
• Uso apropiado de operadores lógicos (=, ,…etc.).
Comprobación del formato de salida
• Alineación y espaciado correcto
Comprobación de punteros
• Borrar siempre después de su uso
• Borrar solamente después que se crea o es nuevo
• Iniciar en NULL.
Comprobación de archivos
• Abrir y cerrar correctamente.
• Declaración correcta.
Comprobación y deletreo de nombres
• Identificación de terminación por puntuaciones y NULL.
Comprobación de secuencias
• Todas las estructuras y clases usan ‘.’ Y ‘->’ de forma correcta.
• Esta dentro del alcance de la declaración.
• Es consistente.
Llamada de función y formato de la llamada
• Punteros parámetros, y el uso de ‘&’
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
Las revisiones tienen un número de pruebas dinámicas del excedente de las ventajas.
• Se consideran mas efectivos
• Son una medida directa de defectos o cualidades de la calidad
• No requieren que el programa se este ejecutando
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:
• Resultado actual
• Resultados esperados
• Condiciones de tiempo o configuración especial
• Descripción de la prueba
• Objetivo de la prueba
• Nombre y numero de prueba
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:
• Tiempo actual por tarea por semana, y ara el proyecto.
• Planeación de hora de acuerdo a la tarea por semana, y para el proyecto.
• Nombre y número de la tarea.
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:
•COCOMO Model (Constructive Cost Model) es el modelo constructivo de costos. Este modelo es para la estimación de líneas de código.
• Ali Arifoglu. Metodología de software para la estimación de costos ACM Sigsoft Software Engineering.
Planeación Personal del Proceso
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:
• Planeación del horario
• Planeación de tareas
• Reporte de prueba.
• Estimación de tamaño.
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.
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:
Post-ejecución:
• Terminar el mejoramiento del proceso.
• Completar el resumen del plan del proyecto, con el tiempo actual, fallas, tamaño de los datos.
Desarrollo:
• Registrar el tiempo.
• Diseño, implementación, compilación, prueba.(PSP0.1)
Planeación
•Producir u obtener los requerimientos de las declaraciones.
•Registrar la fecha del proyecto.
•Estimación del tiempo requerido para el desarrollo.
•Estimación de nuevos totales como los cambios en las líneas de código requeridos en PSP0.1.
•Registrar el inicio del proyecto en el resumen del plan del proyecto.
Mejora del proceso
La mejora del proceso provee un registro de fallas problemas e ideas de mejora. Puede contener lo siguiente
• Condiciones que es necesario recordar para determinar el porque funciona bien el proceso o el porqué es deficiente.
• Lección aprendida
• Agregar comentarios sobre el proyecto.
• Dar prioridades a las sugerencias y explicar porque son importantes.
• Cuando será apropiado, relacionar las sugerencias de mejor para el problema.
• Identificación de los elementos del proceso que son afectados.
• Numeración de cada una de las sugerencias.
• Descripción de las sugerencias para mejorar el proceso.
• Descripción del impacto que tiene el producto o el proceso con la falla o problema.
• Descripción y las dificultades
• Numero del problema
• Descripción de la falla encontrada dentro del proyecto
Estándar de fallas
Estos pueden se algunas de las fallas que se registran y que se pueden tomar como un estándar:
Comentario de documentación, mensajes
Deletreo de sintaxis, puntuación, formato
Diseño del entorno, compilación, prueba, otro sistema de soporte de problemas
Construcción, Manejo de cambio de paquete, librería, control de versión
Configuración de sistema, sincronización, memoria
Función de conexión, enlace, recursividad,
Estructura de datos, contenido
Chequeo de mensajes de error
Procedimiento de la Interfaz, llamadas, referencias, I/O, formato de usuario
Declaración de asignación, duplicado de nombres, alcance, limitaciones
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.
•Tiempo que se llevo para reparar la falla
•Descripción del porque de la falla
•Fase donde la falla se elimino
•Fase donde se inicio la falla
•Tipo de falla (Documentación, sintaxis, asignación, interfase, etc.…)
•Numero de falla
•Fecha de la falla encontrada
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
Ventajas
-la integración entre lo que es propiamente desarrollo con mantenimiento de software
-la garantía de calidad
-educción de riesgos en el proyecto
Consta de:
- En conclusión los casos de uso son utilizados para:
• Tener una comunicación entre los participantes del proyecto
• Hacer Pruebas
• Verificar y validar la arquitectura del sistema
• Establecer el comportamiento deseado del sistema
- los desarrolladores crean una serie de modelos de diseño e implementación que llevan a cabotopic
caracteristicas
- está basado en componentes
- es soportado por herramientas que automatizan
- 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
- se tiene en cuenta 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
Tener una comunicación entre los participantes del proyecto
Hacer Pruebas
Verificar y validar la arquitectura del sistema
Establecer el comportamiento deseado del sistema
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.
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
desventajas
- no se sabe con certeza los costos finales
-metas claras para conocer el estado del proyecto
- requiere de mucha planeacion, administrativa y tecnica
- No es aconsejable para sistemas complejos y proyectos grandes debido a su tardia forma de encontrar problemas
- provee un impacto ventajoso frente al clente, entrega de partes del software
- con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya ue se implementa la funionalidad
parcial
Modelo incremental
Proceso de desarrollo unificado
Proceso Software Personal.
Modelo de espiral
Modelo de cascada
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
ventajas
-En la utilización de grandes sistemas a doblado la productividad.
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.
-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.
-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 puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
-Requiere experiencia en la identificación de riesgos
Modelo costoso
-Genera mucho tiempo en el desarrollo del sistema
-Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
-Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
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.
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
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
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.
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
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.
Desventajas
• 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.
• 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.
• 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.
Actividades
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.
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.
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.
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.
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).
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.
Modelos de Proceso del Software
Marcos de trabajos de las tareas
Se Dividen en:
