Resumen de la sesion nº 2 del curso diseño y arquitectura de software

1.-Modelos de ciclo de vida del software

El ciclo de vida de un software son las etapas por las que pasa un proyecto de sfotware. Existen diversos modelos de ciclo de vida de un software, que será resumido a continuación: 

1.       Lineal: También conocido como modelo secuencial, involucra etapas secuenciales de desarrollo donde cada fase debe completarse antes de pasar a la siguiente. Menos flexible para cambios de requisitos.

 
2.       Cascada Puro: Un enfoque secuencial donde cada fase (requisitos, diseño, implementación, pruebas, mantenimiento) se completa antes de pasar a la siguiente. Adecuado para proyectos con requisitos estables.

 
3.       En V: Similar al modelo cascada, enfatiza la relación entre las fases de desarrollo y las de prueba. Las pruebas son paralelas al desarrollo.

4.       Sashimi: Un modelo en el que se superponen las fases, permitiendo la ejecución parcial de las fases en paralelo.

 
5.       Cascada con Subproyecto: Variante de cascada donde las fases principales se dividen en subproyectos separados y se aplican modelos en cascada independientes para cada uno.

 

6.       Iterativo: Implica la repetición de ciclos de desarrollo, cada uno produciendo incrementos funcionales del software. Adecuado para proyectos donde los requisitos pueden cambiar.

 
7.       Evolutivo: Se enfoca en crear un prototipo funcional inicial y luego evoluciona a través de varias iteraciones basadas en feedback.
 

8.       Espiral: Un modelo que combina elementos del enfoque en cascada con iteración y gestión de riesgos. Los ciclos se repiten en espiral, incorporando feedback y ajustes.

 
9.       Prototipo: Involucra la creación de versiones iniciales (prototipos) del software para validar requisitos y conceptos antes del desarrollo completo.

 
10   Incremental: El desarrollo se divide en incrementos más pequeños y funcionales, cada uno construyendo sobre el anterior. Entregas frecuentes y flexibilidad para cambios.

 
11  Orientado a Objeto: Se basa en principios de programación orientada a objetos, donde se diseñan y desarrollan componentes reutilizables

2. Stakeholders y tipos de requerimientos

Stakeholders: 

Patrocinadores: Son individuos o entidades que proporcionan recursos financieros y respaldo estratégico al proyecto. Los patrocinadores suelen tener un interés directo en el éxito del proyecto y pueden estar involucrados en la toma de decisiones clave.

 Usuarios Directos: Son las personas que interactuarán directamente con el sistema de software una vez que esté en funcionamiento. Estos usuarios utilizan el software para cumplir sus tareas y lograr sus objetivos, por lo que sus necesidades y opiniones son esenciales para el diseño y desarrollo exitoso del sistema.

 Usuarios Indirectos: Aunque no utilizan el software directamente, los usuarios indirectos pueden verse afectados por él de alguna manera. Esto podría incluir personas cuyas tareas están relacionadas o dependen del sistema, pero no lo utilizan activamente.

Definidores de Reglas (Stakeholders con Poder de Decisión): Estos son los individuos o grupos que establecen las reglas, políticas y regulaciones que afectan al proyecto o sistema. Tienen la autoridad para tomar decisiones que impactarán en el desarrollo y funcionamiento del software

Requerimientos:

Requerimientos Funcionales: Funcionalidades y acciones que el sistema debe realizar, como procesamiento de transacciones o generación de informes. 

Requerimientos No Funcionales: Criterios de calidad y restricciones, como rendimiento, seguridad, usabilidad y escalabilidad.

Requerimientos: DINO

Deseables. El usuario lo desea pero no es necesario.

Importantes. Su implementacion si se lleva a cabo.

No implementables. No se relacionan con el software.

Obligatorio. Siempre se implementan de lo contrario el software no funciona.

3. Buenas prácticas en el desarrollo del software.

La Norma Técnica Peruana ISO 12207 establece pautas para los procesos en el ciclo de vida del software, abarcando adquisición, desarrollo, operación, mantenimiento y desactivación. Es relevante para la gestión efectiva de proyectos y la calidad del software en Perú, basándose en estándares internacionales para garantizar procesos sólidos y resultados exitosos en todas las etapas del desarrollo y operación de software.

Puntos importantes de la norma

 

• 1.       Procesos de Ciclo de Vida: Define procesos específicos a lo largo del ciclo de vida del software, incluyendo adquisición, suministro, desarrollo, operación, mantenimiento y desactivación.
• 2.       Planificación de Proyectos: Establece pautas para la planificación y gestión de proyectos de software, incluyendo la identificación de riesgos y la definición de objetivos.
• 3.       Requisitos: Se centra en la captura, análisis y gestión de requisitos, asegurando que el software cumpla con las necesidades de los usuarios.
• 4.       Diseño y Construcción: Cubre la especificación detallada, el diseño y la implementación del software, incluyendo la creación de documentación técnica.
• 5.       Pruebas y Validación: Define la planificación y ejecución de pruebas para asegurar que el software funcione correctamente y cumpla con los requisitos.
• 6.       Mantenimiento y Evolución: Proporciona directrices para el mantenimiento y la evolución del software, incluyendo la gestión de cambios y actualizaciones.
• 7.       Documentación: Enfatiza la importancia de la documentación en todas las etapas del ciclo de vida del software.
• 8.       Gestión de la Configuración: Detalla cómo gestionar las versiones y cambios en el software y la documentación relacionada.
• 9.       Aseguramiento de la Calidad: Establece prácticas para garantizar la calidad del software a lo largo de su ciclo de vida.
• 10.   Gestión de Riesgos: Aborda la identificación y gestión de riesgos que podrían afectar al proyecto y al software

REFERENCIAS:

http://www.repositorio.unacar.mx/jspui/bitstream/1030620191/199/1/acalan%2074-2.pdf

https://www.senasa.gob.pe/senasa/descargasarchivos/2014/11/Certificacion-citricos-a-mexico_26_mayo_2105_2.pdf

https://elvex.ugr.es/idbis/db/docs/design/2-requirements.pdf