



































Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Prepara tus exámenes
Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Prepara tus exámenes con los documentos que comparten otros estudiantes como tú en Docsity
Los mejores documentos en venta realizados por estudiantes que han terminado sus estudios
Estudia con lecciones y exámenes resueltos basados en los programas académicos de las mejores universidades
Responde a preguntas de exámenes reales y pon a prueba tu preparación
Consigue puntos base para descargar
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Comunidad
Pide ayuda a la comunidad y resuelve tus dudas de estudio
Descubre las mejores universidades de tu país según los usuarios de Docsity
Ebooks gratuitos
Descarga nuestras guías gratuitas sobre técnicas de estudio, métodos para controlar la ansiedad y consejos para la tesis preparadas por los tutores de Docsity
Diagrama Clases uml y varios archivos correspondientes
Tipo: Ejercicios
Oferta a tiempo limitado
Subido el 26/05/2021
5
(1)3 documentos
1 / 43
Esta página no es visible en la vista previa
¡No te pierdas las partes importantes!
En oferta
Resumen Siendo esta la última entrega, hemos anexado la primera y segunda con el fin de completar la entrega final. El método selecto fue de Prototipos para la elaboración y desarrollo del proyecto de software, cuyos planteamientos, definiciones y requerimientos se han estipulado, a su vez, hemos contemplado los requerimientos funcionales y no funcionales, también hemos cubierto las necesidades del personal para realizarlo, contando con una estimación de tiempo. Ahora, vamos a complementar este diseño con diagramas de secuencia, estado, extraído basado en los requerimientos encontrados. Palabras clave: Roles, identificación, requerimiento, funcional, no funcional, diagrama, diseño, clases, secuencial, patrones Abstract With this being the last delivery, we have attached the first and second in order to complete the final delivery. The selected method was of prototypes for the elaboration and development of the software project, whose approaches, definitions and requirements have been stipulated, in turn, we have contemplated the functional and non-functional requirements, we have also covered the staff needs to carry out the project, with an estimate of time. Now, let's complement this design with sequence, state, extracted diagrams based on the requirements found. Keywords: Roles, identification, requirement, functional, non-functional, diagram, design, classes, sequential, patterns
APLICAR Y SUSTENTAR EN DIAGRAMA DE CLASES EL USO DE PATRONES
Realizar diagramas que representativos que modelen la secuencia, el estado y patrones de asignación contenidos en el desarrollo del proyecto OBJETIVOS ESPECÍFICOS
incremental, Modelo por prototipo, Modelo en espiral, Modelo de programación extrema, Crystal Methodologies, Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), TSP Team Software Process, SCRUM) no son tan adecuados como el modelo por prototipo. POR QUE SE ESCOGIÓ EL MODELO POR PROTOTIPO El modelo prototipo es un modelo tradicional, es decir ya tiene una estructura conformada como vamos a ver a continuación: Fig. 1 Como se puede ver este modelo es muy parecido al modelo en cascada y al modelo incremental solo que mejorado ya que este modelo nos permite satisfacer al cliente mediante prototipos, por esta razón, se escogió en este proyecto ya que podemos minimizar el riesgo de realizar un producto que no satisfaga al cliente, realizar un prototipo inicial y mostrándolo al cliente en caso del que al cliente no se satisfaga de este modelo, podemos hablar con él y cambiarle todo lo que no le satisfaga, ya teniendo un prototipo que le guste, podemos usar este modelo en todo el proceso del proyecto. Siguiendo encontramos la etapa de planeación donde hablaremos de los requerimientos del cliente y hablaremos de como implementar todas esas funcionalidades en el prototipo mostrado al cliente anteriormente. En la etapa de modelado vamos a implementar lo hablado en la etapa de planeación realizando un prototipo funcional y mostrarlo al cliente, con eso el cliente nos dirá que
todos los objetivos de una actividad para continuar con la ejecución de la siguiente, en otras palabras cada fase depende de la fase inmediatamente anterior para su adecuada ejecución, en términos generales esta seria la gran desventaja que tiene este modelo y la razón por la cual no se utilizaría para el desarrollo en cuestión ya que implicaría una baja capacidad de respuesta en caso de que se realice algún cambio afectando todo el proyecto, a eso se suma la pérdida de tiempo de esperar el inicio y finalización de cada etapa para iniciar en una nueva, adicional que el cliente no podrá ver ningún avance sino solo hasta el final del mismo. POR QUE NO ES FACTIBLE EL MODELO DE PROGRAMCION EXTREMA La programación extrema XP es una metodología para desarrollar proyectos de una forma ágil, rápida y efectiva para administrar y ejecutar proyectos, sin embargo, el hecho de que tal vez no todos los proyectos se adapten a esta metodología se convierte en una desventaja ya que es recomendable emplearlo solo en proyectos a corto plazo. Una de sus principales intenciones es fomentar la comunicación entre los clientes y los desarrolladores, pero es muy posible que el hecho de involucrar al cliente en decisiones técnicas cuando no es un experto en el proceso puede ser contraproducente y demorar el despliegue del desarrollo del software, por otra parte los procesos muchas veces se modifican sin que haya registro, solo los involucrados conocen bien el desarrollo y esto puede suponer una desventaja si más adelante hay que pedir explicaciones. La metodología empleada por este modelo es rápida y con cambios constantes por tal razón también es difícil llevar un registro e historial de lo que se ha hecho. POR QUE NO ES FACTIBLE EL MODELO DSDM Si bien, el proceso Dynamic Systems Development Method (DSDM), mantiene similitud como un sistema de software rápido con el Modelo por Prototipos, debido a que la calidad del producto es mejorada a través de la participación del usuario y se pueden disminuir tiempo y el costo de los proyectos, como los pactados. No obstante, se sabe que ningún sistema o producto es realizado a la perfección en el primer intento, por lo tanto, el proceso
DSDM, necesita una alta participación de los usuarios o clientes, para que los desarrolladores no asuman criterios que no son ciertos y la entrega del producto deberá ser a tiempo, respetando presupuesto y asegurando calidad. El proceso DSDM requiere que se complica la iteración con la funcionalidad suficiente como para que inicie la siguiente iteración y creemos que no es una metodología común por lo que dificultaría un poco entenderlo. POR QUE NO ES FACTIBLE EL MODELO ADS Por otra parte, el proceso Adaptive Software Development (ASD), se considera algunas desventajas en comparación con el modelo elegido por Prototipos, debido a que el ciclo entre la planeación y construcción es bueno, porque permite entregar productos con alta calidad, pero la prolongación de paso entre ciclos por errores o cambios que no son detectados afecta tanto a la calidad del producto como a su costo total. Dado a que ASD es una metodología ágil implica no realizar procesos que son requeridos en el método de prototipos, lo cual implica que clientes o usuarios grandes los cuales necesitan llevar un mayor control a procesos, tener tareas asignadas a un estado o proceso especifico, y en las cuales dicho incremento de procesos no afectan en gran medida al costo final del producto, para estos clientes el elegir una metodología tradicional resulta mucho más rentable tanto por el gran volumen de personal, de productos, y de costos que se manejan y para los cuales se tendrá un mayor control. POR QUE NO ES FACTIBLE EL MODELO EN ESPIRAL Este método en su proceso de evolución del software acompaña la filosofía de interacción del modelo de construcción Prototipo con los aspectos sistemáticos y controlados del modelo cascada e incremental.
En su estructura metodológica, establece un entorno donde el trabajo en equipo es primordial “únicamente el equipo de trabajo” no hay más involucrados. Es decir, el usuario final, no se encuentra involucrado como lo hacen otros métodos “pues, no es el enfoque”. La disciplina y autodisciplina en llenado de las documentaciones dadas, compromiso a ejecutar el plan trazado, contar con métricas y parámetros, los miembros del equipo deberán satisfacer estas exigencias, además de conocer o haberse entrenado en PSP. Algunas deficiencias que podemos encontrar son:
Fig. 3 POR QUE NO ES FACTIBLE EL MODELO SCRUM El modelo de Scrum es una metodología ágil y flexible que permite gestionar el desarrollo de software, este modelo se trabaja por periodo de tiempos largos y se divide en varias semanas que las denominan Spring, esto consiste en desglosar las tareas en lo que mas puedan y poder entender todo el proyecto a su máximo objetivo y poder entregar avances significativos en cada Spring. Este método se utiliza para el trabajo colaborativo en los equipos y es considerado un marco de gestión de proyectos agiles, el Scrum incluye un conjunto de reuniones, herramientas y funciones que de formas muy coordinadas pueden ayudar a estructurar y gestionar los trabajos de los equipos involucrados en el proyecto. Una de las características que tiene la metodología Scrum es que es desarrollo incremental y se centra en el producto final realizando entregas parciales y funcionales. En la siguiente imagen podemos observar cómo es el organigrama de un modelo de Scrum.
profesionales de la salud ubicando el perfil que se acomode para así pagar este tipo de servicio. OBJETIVOS OBJETIVO GENERAL Realizar un proyecto para el desarrollo de un software que satisfaga las necesidades expuestas en el enunciado, para la adquisición de servicios con profesionales de la salud perfilados y adaptados por los usuarios quienes los escogerán online según sea la necesidad. OBJETIVOS ESPECÍFICOS
Estas realidades llevan a una conclusión: debe hacerse ingeniería con el software en todas sus formas a través de todos sus dominios de aplicación (software de sistemas, software de aplicación, software de ingeniería y ciencias, software incrustado, software de línea de productos, aplicaciones web y software de inteligencia artificial). Lo cual conduce, a la “ingeniería del software”. (2: Pressman, Roger S. Ingeniería del software. Un enfoque práctico. Séptima edición. Nueva York : McGraw-Hill , 2010. ) Gráfico 1: Capas de la ingeniería de software Fuente: Pressman, Roger S. Ingeniería del software. Un enfoque práctico. Séptima edición. Nueva York : McGraw-Hill , 2010. EL PLAN DE PROYECTO Como hemos elegido el modelo de prototipos y una vez revisado la necesidad, este proyecto requiere: al menos de ocho (8) personas, sin embargo, estando en acuerdo nuestro grupo, consideramos que con siete (7) es suficiente. Los perfiles que constatamos fueron: tres (3) desarrolladores de software, un (1) ingeniero de software, un (1) ingeniero industrial, un (1) administrador de empresas con énfasis en finanzas y un (1) analista de software y una estimación de tiempo de Seis (6) meses. Por otra parte, se necesita recolectar y definir las fuentes de información “persona (s) a entrevistar” para que sea más idóneo el progreso de los requerimientos. Estos requerimientos los:
Como hemos estimado una duración de seis meses, los distribuiremos de la siguiente forma Gráfico 2: Gráfico 2 Cronograma de actividades Gráfico 3 Gráfico 3 La estimación de tiempo en cuanto detalles se encuentra los anexos titulados por nombre: