Trabajo de procesos de negocios, empresa AIEP Soft Ltd.

Descripción del Caso

La empresa AIEP Soft Ltd., donde usted trabaja ha tenido muchos problemas con la calidad de sus productos lo que ha provocado grandes pérdidas económicas a la empresa. El gerente de Tecnología lo nombra a usted como nuevo Jefe del Área de Desarrollo de Software, como primera actividad se le solicita que defina el nuevo proceso de Desarrollo de Software que permita mejorar y asegurar la calidad en las diferentes aplicaciones que la empresa desarrolla.

Requerimiento

Se debe elaborar un documento que describa el nuevo proceso de Desarrollo de Software y realizar una presentación.

Restricciones

1. El documento debe contener como mínimo 5 páginas y como máximo 10 páginas, con interlineado sencillo o 1,5 líneas.
2. El trabajo es en grupo de máximo 2 estudiantes
3. El documento corresponde a un 70% de la nota
4. Debe realizar una presentación de 5 minutos del contenido de todo el documento (30%)
5. Fecha de entrega y presentación sábado 2 de mayo de 2020 en horario de clase.

Documento Proceso de Desarrollo de Software

Introducción (5 puntos)

En esta sección debe indicar la importancia de disponer de un proceso de desarrollo de software

La razón básica por la que se requiere disponer de un proceso de desarrollo es mejorar la seguridad de trabajo eliminando riesgos innecesarios y conseguir un producto de la máxima calidad. ... Mejorar la reusabilidad, de forma que gran parte del trabajo que se realiza pueda ser reutilizado en próximos proyectos.

Proceso de Desarrollo (40 puntos)

Debe describir las etapas del desarrollo de software, de manera independiente de la metodología a utilizar. (Para este trabajo elegimos proceso de desarrollo en cascada)

Para un excelente trabajo en el desarrollo de software lo realizamos por etapas las cuales son:

1. Análisis: Esta es la primera etapa en la cual se extraen los requisitos del producto que los clientes tienen en mente de lo que tiene que realizar el software, esta etapa es muy importante realizar el análisis ya que es muy probable que el cliente tenga ideas que sean contradictorias, ambiguas o incompletas, plasmándolas en una especificación de los requisitos.
2. Diseño y Arquitectura: En esta etapa se determina las mejores herramientas transformando lo requerimientos definidos en el análisis para el funcionamiento del producto, tanto en diseño y especificación del sistema.
3. Programación: En esta etapa se realiza el plasmar todos los requerimientos y diseños a código independiente del lenguaje a realizarlo la duración de esta etapa puede variar de acuerdo a las modificaciones que se van dando en el transcurso del trabajo.
4. Pruebas: En esta etapa se comprueba que el producto realice correctamente las tareas requeridas, en la cuales las podemos realizar probando la funcionabilidad de cada módulo del producto y posteriormente de manera integral. En esta etapa las pruebas se suelen realizar por personas distintas al desarrollador, pero como para un trabajo más óptimo el desarrollador debe realizar sus propias pruebas.
5. Documentación: En esta etapa se documenta todo sobre el desarrollo del software y de la gestión del proyecto con el propósito de un mantenimiento futuro, correcciones o ampliaciones del sistema, realizando las modelaciones, diagramas, pruebas, manuales de usuario y técnico, etc. integración de sistemas, pruebas de sistema y de integración.
6. Mantenimiento:Como última etapa se realiza el mantener y mejorar para solucionar errores descubiertos y nuevos requisitos del sistema, como errores o bugs, como también ampliar el sistema creado y como plazo 2/3 de los procesos de software es dar mantenimiento.

[pic 1]

Metodologías (15 puntos)

En esta sección describir las siguientes metodologías a usar, e indicar en que tipos de proyectos se usará cada una de ellas:

1. Cascada

El modelo en cascada es un enfoque clásico en el desarrollo de software que describe un método de desarrollo lineal y secuencial. Consta de cinco a siete fases, cada fase está definida por diferentes tareas y objetivos, por lo que la totalidad de las fases describe el ciclo de vida del software hasta su entrega. Una vez finalizada una fase, sigue el siguiente paso de desarrollo y los resultados de la fase anterior pasan a la siguiente fase.

El modelo original en cascada consta de siete fases sucesivas:

• Requisitos del sistema.
• Requisitos de software.
• Análisis de requerimientos.
• Diseño de programas.
• Implementación.

• Probando.
• Lanzamiento.

Los tipos de proyectos donde usar esta metodología son:

• Al enfrentarse a iniciativas estáticas, donde no es muy probable la introducción de cambios se realizarán a lo largo del proceso de desarrollo.
• Cuando se cuenta con equipos de trabajo de menor experiencia, que pueden beneficiarse de una estructura más rígida, como la que propone esta metodología.
• En trabajos reducidos y con complejidad controlada.

1. Scrum

Scrum es un marco de trabajo para desarrollo ágil de software, es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo y obtener el mejor resultado posible de proyectos, caracterizado por:

• Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto.
• Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos auto organizados, que en la calidad de los procesos empleados.
• Solapar las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o en cascada.

[pic 2]

Características de Scrum

Scrum es un marco de trabajo que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.

Los roles principales en Scrum son el Scrum Master, que procura facilitar la aplicación de Scrum y gestionar cambios, el Product Owner, que representa a los stakeholders (interesados externos o internos), y el Team (equipo) que ejecuta el desarrollo y demás elementos relacionados con él.

Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo y debe ser lo más corta posible), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar (PBI, Product Backlog Item).  Scrum permite la creación de equipos auto organizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.

La metodología se basa en:

• El desarrollo incremental de los requisitos del proyecto en bloques temporales cortos y fijos.
• Se da prioridad a lo que tiene más valor para el cliente.
• El equipo se sincroniza diariamente y se realizan las adaptaciones necesarias.
• Tras cada iteración (un mes o menos entre cada una) se muestra al cliente el resultado real obtenido, para que este tome las decisiones necesarias en relación a lo observado.
• Se le da la autoridad necesaria al equipo para poder cumplir los requisitos.
• Fijar tiempos máximos para lograr objetivos.
• Equipos pequeños (de 3 a 9 personas cada uno).

Roles en Scrums

Product Owner

El Product Owner se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner ayuda al usuario a escribir las historias de usuario, las prioriza, y las coloca en el Product Backlog.

ScrumMaster (o Facilitador)

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.

Equipo de desarrollo

El equipo tiene la responsabilidad de entregar el producto. Es recomendable un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).

Roles Auxiliares

Los roles auxiliares en los "equipos Scrums" son aquellos que no tienen un rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo, deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados ("stakeholders"). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.

...