1. Modelos de mejora de procesos
1.1. Capability Maturity Model Integration
1.2. El Capability Maturity Model Integration (CMMI), en español «Integración de Modelos de Madurez de Capacidades» es uno de los modelos líderes basados en mejores prácticas. Son evaluaciones independientes las que confirman el grado con el que una organización siguen sus propios procesos, que no evalúa la calidad de los procesos o del software que se produce. CMMI ha reemplazado a CMM y tiene un ámbito global, no sólo en procesos destinados al desarrollo del software.
1.3. ISO 9000
1.4. ISO 9000 describe estándares para un proceso organizado formalmente para resultar en un producto y los métodos de gestión y monitoreo del progreso. Aunque este estándar se creó inicialmente para el sector de producción, los estándares de ISO 9000 también se han aplicado al desarrollo del software. Al igual que CMMI, que una organización está certificada con el ISO 9000 no garantiza la calidad del resultado final, sólo confirma que se ha seguido los procesos establecidos.
1.5. ISO 15504
1.6. ISO 15504, también conocido como Software Process Improvement Capability Determination (SPICE), en español «Determinación de la Capacidad de Mejora del Proceso de Software» es un marco para la evaluación de procesos de software. Este estándar tiene como objetivo un modelo claro para poder comparar procesos. SPICE se utiliza como en el caso de CMMI. Modela procesos para gestionar, controlar, guiar y monitorear el desarrollo del software. Este modelo se utiliza entonces para medir lo que una organización o proyecto hace durante el desarrollo del software. Esta información se analiza para identificar puntos débiles y definir acciones para subsanarlos. También identifica puntos fuertes que pueden adoptarse en el resto de la organización.
2. Modelos de Desarrollo de Software
2.1. Los modelos de desarrollo de software son una representación abstracta de una manera en particular. Realmente no representa cómo se debe desarrollar el software, sino de un enfoque común. Puede ser modificado y adaptado de acuerdo a las necesidades del software en proceso de desarrollo. Hay varios modelos para perfilar el proceso de desarrollo, cada uno de las cuales cuenta con pros y contras. El proyecto debería escoger el más apropiado para sus necesidades. En ocasiones puede que una combinación de varios modelos sea apropiado.
2.1.1. Existen tres paradigmas de los modelos de desarrollo de software:
2.1.1.1. 1. Paradigma Tradicional:
2.1.1.2. Es uno de los paradigmas más antiguo, se inventó durante la creación del método estructurado. Si se elige un proyecto, el método varia en etapas. Como todo modelo, existen sus pros y contras al usar este paradigma: Ventajas • Mayor control en cuanto a la programación del desarrollo. • Al tener control se reduce el riesgo de excesos de gastos. Desventajas • El usuario no participa en el proceso de desarrollo. • El proceso no se hace de forma secuencial. • El tiempo de desarrollo excede al estimado. • Si el usuario olvida aclarar pautas, esto puede significar, sobrecostos en el proyecto.
2.1.1.3. 2. Paradigma Orientado a Objetos: Estos modelos se basan en la Programación orientada a objetos; por lo tanto, se refiere al concepto de clase, el análisis de requisitos y el diseño. El modelo o paradigma orientado a objetos posee dos características principales, las cuales son:
2.1.1.4. * Permite la re-utilización de software. * Facilita el desarrollo de herramientas informáticas de apoyo al desarrollo, el cual es simple al implementarla en una notación orientado a objetos llamado UML.
2.1.1.5. 3. Paradigma de Desarrollo Ágil: Es un paradigma de las Metodologías De Desarrollo basado en procesos ágiles. Estos intentan evitar los tediosos caminos de las metodologías tradicionales enfocándose en las personas y los resultados. Usa un enfoque basado en el Valor para construir software, colaborando con el cliente e incorporando los cambios continuamente.
3. ¿Por qué contar con un proceso de software?
3.1. 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. Factores como la globalización han obligado a las organizaciones a contar con marcos de trabajo que las ayuden hacer las cosas de la manera más eficiente. Fue entonces que se incorporó la ingeniería de procesos al desarrollo de software.
4. Proceso para el desarrollo de software
4.1. también denominado ciclo de vida del desarrollo de software es una estructura aplicada al desarrollo de un producto de software.
5. Actividades del desarrollo de software
5.1. Planificación
5.2. La importante tarea a la hora de crear un producto de software es obtener los requisitos o el análisis de los requisitos. Los clientes suelen tener una idea más bien abstracta del resultado final, pero no sobre las funciones que debería cumplir el software.
5.3. Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un análisis del ámbito del desarrollo. Este documento se conoce como especificación funcional.
5.4. Implementación, pruebas y documentación
5.5. La implementación es parte del proceso en el que los ingenieros de software programan el código para el proyecto de trabajo que está en relación de las demanda del software, en esta etapa se realizan las pruebas de caja blanca y caja negra.
5.6. Las pruebas de software son parte esencial del proceso de desarrollo del software. Esta parte del proceso tiene la función de detectar los errores de software lo antes posible.
5.7. La documentación del diseño interno del software con el objetivo de facilitar su mejora y su mantenimiento se realiza a lo largo del proyecto. Esto puede incluir la documentación de un API, tanto interior como exterior. Prácticamente es como una receta de cocina
5.8. Despliegue y mantenimiento
5.9. El despliegue comienza cuando el código ha sido suficientemente probado, ha sido aprobado para su liberación y ha sido distribuido en el entorno de producción.
5.10. Entrenamiento y soporte para el software es de suma importancia y algo que muchos desarrolladores de software descuidan. Los usuarios, por naturaleza, se oponen al cambio porque conlleva una cierta inseguridad, es por ello que es fundamental instruir de forma adecuada a los futuros usuarios del software.
5.11. El mantenimiento o mejora de un software con problemas recientemente desplegado, puede requerir más tiempo que el desarrollo inicial del software. Es posible que haya que incorporar código que no se ajusta al diseño original con el objetivo de solucionar un problema o ampliar la funcionalidad para un cliente. Si los costes de mantenimiento son muy elevados puede que sea oportuno rediseñar el sistema para poder contener los costes de mantenimiento.
6. Principales Roles en el proceso de Desarrollo de Software
6.1. Un Rol se define como una “Función que alguien o algo cumple”
6.1.1. Descripción de roles en el Proceso de Desarrollo de Software
6.1.1.1. Gerente de proyecto
6.1.1.2. Tiene por función presentar informes sobre las litigaciones de riesgos, hacer cumplir los plazos y lleva el control de los costos. También organiza el equipo, realiza planificación y estima el tiempo de las actividades. En conclusión, resuelve problemas.
6.1.1.3. Analista de requerimientos
6.1.1.4. Se encarga del revelamiento de los requerimientos esenciales para el desarrollo del Software, la documentación de los requerimientos para así el resto del equipo lo pueda consulta en cualquier momento. Debe ser una persona con capacidad de abstracción y análisis.
6.1.1.5. Desarrollador de software o programador
6.1.1.6. Encargado de la concepción y el diseño, escribe el código, prueba lo que construye y se encarga de hacer el mantenimiento del código.
6.1.1.7. Testeador
6.1.1.8. Diseña y ejecuta las pruebas, para ello requiere conocer el producto a probar claro esta, estudiar funcionalidad del producto y desarrollar las pruebas que revelen incidentes críticos. Reporta los incidentes y provee información sobre la calidad del sistema.
6.1.1.9. Arquitecto de software
6.1.1.10. Determina las estructuras de la aplicación y las tecnologías con las que se construirá la aplicación. Está encargado del aseguramiento de la calidad, mejorar continuamente la arquitectura. Gestiona los requerimientos no funcionales, asume la dirección técnica para asegurar que todos los aspectos de la arquitectura se estén desarrollando de manera correcta.
6.1.1.11. Debe ser una persona con un innato sentido de liderazgo, dispuesto a formar a los integrantes del equipo, dispuesto a recibir y aplicar abiertamente recomendaciones.