/Proyecto-Final-Ingenieria-de-Software

Repositorio del proyecto final de ingeniería de software de la Universidad Católica del Ecuador.

Primary LanguageHTML

Proyecto-Final-Ingenieria-de-Software

Autores y roles

  • Bryan Cuvi - Analista
  • David Cazar - Diseñador
  • Andrés Cajamarca - Analista
  • Gabriela Gómez - Documentadora
  • Esteban Placencia - Asegurador de calidad
  • Angel Seraquive - Tester
  • Sebastián Tamayo - Analista, Diseñador, Programador
  • Sofía Villacís - Administradora de Proyecto

Fecha

Julio del 2022

Descripción general

Repositorio del proyecto final de ingeniería de software de la Universidad Católica del Ecuador.

Toda la documentación se puede encontrar dentro de la carpeta "Documentación", allí usted podrá encontrar documentación referida a:

  • Fase de planeación y estrategia
  • Ingeniería de requerimientos
  • Diseño del sistema
  • Construcción (Software) - Donde se podrá encontrar el código fuente
  • Pruebas del sistema
  • Implantación, trancisión, postmortem
  • Otra documentación adicional a cada fase

Descripción detallada del trabajo

El proyecto final de Ingeniería de Software pretende poner en práctica todos los conocimientos adquiridos a lo largo de la asignatura. Cada grupo definido simulará ser un grupo de trabajo de Ingeniería del Software (una empresa consolidada de desarrollo de software) y hacer todo lo necesario para ejecutar un proyecto de software que deberá ser elaborado en su totalidad para su cliente (su profesor).

Su profesor como un cliente tradicional tiene una idea de lo que quiere, aunque no tiene del todo claro el panorama de lo que espera al final o de cómo se lo puede hacer, por lo que es parte de su labor ayudar a su cliente a definir adecuadamente lo que se va a implementar, midiendo tiempos, y otorgando adecuadas funcionalidades ya que el pago no será en $$$, pero si será en los 50 puntos del 4to parcial.

Su cliente quisiera hacer un juego de Mastermind para que usuarios jueguen contra la computadora, pero eso es todo lo que tiene definido, el resto será definido e implementado con su soporte.

Para realizar todos los pasos aprendidos en este curso usted deberá elegir una metodología de proceso de desarrollo de software ágil que no sea el PSP, deberá profundizar más de lo que se vio durante el curso para esa metodología y deberá aplicarla completamente en la elaboración del proyecto. Esto se debe a que en el curso se han impartido varias metodologías, pero en ninguna se ha profundizado lo suficiente como para decir que se conocen todos los pasos y se puede aplicar completamente.

Se destinarán los días de una hora de clase para “reuniones con el cliente”, pero para ello “su empresa” debe ser tan profesional como sea posible. Deberá agendar oportunamente las citas que considere necesarias con el tiempo suficiente para que su cliente pueda organizar su horario, inclusive los correos electrónicos que envíe deberían estar alineados a las políticas de su empresa. Las actividades que realice en estas reuniones deberán ser las que usted considere con la documentación de respaldo que usted considere (tanto producto del uso de la metodología, como también la que haya definido en su empresa). Por ejemplo, debería concertar una primera cita para dar a conocer al cliente sobre su empresa, qué es lo que hacen y por qué debería ser contratada con el adecuado apoyo visual y profesional de su personal. También será necesario que organice al menos una reunión para poder tomar los requerimientos de su cliente. Otra reunión podría usarse para presentarle un primer avance, etc, etc.

Este proyecto puede empezar a hacerse desde el momento en que usted considere para las actividades que su empresa ya pueda hacer junto con el cliente. Pero se sugiere que el trabajo de toma de requerimientos se haga cuando ya se haya visto ese capítulo. Hasta tanto puede organizar una reunión para la presentación de su empresa o también conversaciones con el cliente a fin de definir más claramente lo que el cliente espera, también puede adelantarse realizando los formatos de los artefactos que se listan más adelante.

Las reuniones no necesariamente deben ser informativas o meras conversaciones, la iniciativa es un punto clave en esto. Por ejemplo, podría generar un formulario con una encuesta online para poder obtener mejores resultados en la toma de requerimientos.

Debido a que existirán varios grupos en el curso siempre se dará prioridad a quienes organicen reuniones y actividades primero en caso de falta de tiempo. Pero si el tiempo destinado los días en los que tenemos 1 hora de clase no fuera suficiente, podría darse alguna actividad en un día distinto, dentro de las horas de clase.

Los artefactos, resultado de su proceso de ingeniería dependen mucho de la metodología que tomen, pero se espera que existan los siguientes artefactos obligatoriamente:

• Presentación ejecutiva de la empresa

• Contrato de trabajo

• Lista de requerimientos determinados

• Diagramas de casos de uso

• Modelo físico de base de datos (si aplica)

• Modelo de clases

• Código fuente y código ejecutable del software producido

• Registro de pruebas realizadas y superadas

• Diferentes documentos de aprobaciones

• Actas firmadas

• Manual de usuario

• Acta de entrega-recepción

• Documento de aceptación final

Durante las reuniones, el grupo que no participe debe estar presente como espectador a fin de que pueda nutrirse de las ideas de sus compañeros y también de la retroalimentación que el profesor les pueda dar.

Durante la presentación final, no solo deberá presentar su software con sus funcionalidades, sino que debe dar especial atención a la metodología utilizada y hacer una exposición de todo el proceso de software. Distribución y manejo de roles. Los puntos fuertes y débiles que encontró durante su proceso de software.