Docsity
Docsity

Prepara tus exámenes
Prepara tus exámenes

Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity


Consigue puntos base para descargar
Consigue puntos base para descargar

Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium


Orientación Universidad
Orientación Universidad

Ingeniería del Software I: Entrega Final - Metodologías de Programación - Prof. Linares, Ejercicios de Ingeniería del Software

Diagrama Clases uml y varios archivos correspondientes

Tipo: Ejercicios

2020/2021
En oferta
30 Puntos
Discount

Oferta a tiempo limitado


Subido el 26/05/2021

andres-saldarriaga-3
andres-saldarriaga-3 🇨🇴

5

(1)

3 documentos

1 / 43

Toggle sidebar

Esta página no es visible en la vista previa

¡No te pierdas las partes importantes!

bg1
INGENIERIA DEL SOTFWARE I
ENTREGA FINAL
METODOLOGIAS DE PROGRAMACION
TUTORA:
MARTINEZ ROJAS NATALIA
GRUPO 6
INTEGRANTES
FREDDY SANTIAGO PATARROYO FERNANDEZ - ID: 810010453
EYDER WILSON RIASCOS - ID: 1911925151
JORGE ANDRES SALDARRIAGA TIRADO - ID: 100237493
EDWIN HARVEY MORENO GARCIA - ID:100247953
CRISTIAN EDUARDO MARTÍNEZ PINEDA - ID: 100221929
INSTITUCIÓN UNIVERSITARIA POLITÉCNICO GRANCOLOMBIANO
FACULTAD DE INGENIERÍA, DISEÑO E INNOVACIÓN
ESCUELA DE TECNOLOGÍAS DE INFORMACIÓN Y
TELECOMUNICACIONES
2021
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27
pf28
pf29
pf2a
pf2b
Discount

En oferta

Vista previa parcial del texto

¡Descarga Ingeniería del Software I: Entrega Final - Metodologías de Programación - Prof. Linares y más Ejercicios en PDF de Ingeniería del Software solo en Docsity!

INGENIERIA DEL SOTFWARE I

ENTREGA FINAL

METODOLOGIAS DE PROGRAMACION

TUTORA:

MARTINEZ ROJAS NATALIA

GRUPO 6

INTEGRANTES

FREDDY SANTIAGO PATARROYO FERNANDEZ - ID: 810010453

EYDER WILSON RIASCOS - ID: 1911925151

JORGE ANDRES SALDARRIAGA TIRADO - ID: 100237493

EDWIN HARVEY MORENO GARCIA - ID:

CRISTIAN EDUARDO MARTÍNEZ PINEDA - ID: 100221929

INSTITUCIÓN UNIVERSITARIA POLITÉCNICO GRANCOLOMBIANO

FACULTAD DE INGENIERÍA, DISEÑO E INNOVACIÓN

ESCUELA DE TECNOLOGÍAS DE INFORMACIÓN Y

TELECOMUNICACIONES

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

  • ENTREGA FINAL
    • OBJETIVOS
    • OBJETIVO GENERAL
    • OBJETIVOS ESPECÍFICOS
    • PLANTEAMIENTO DEL PROBLEMA
    • JUSTIFICACIÓN
    • MARCO TEÓRICO
  • ENTREGA UNO
    • OBJETIVOS
    • OBJETIVO GENERAL
    • OBJETIVOS ESPECÍFICOS
    • PLANTEAMIENTO DEL PROBLEMA
    • JUSTIFICACIÓN
    • MARCO TEÓRICO
    • POR QUE SE ESCOGIÓ EL MODELO POR PROTOTIPO
    • SOLUCIONANDO LAS DESVENTAJAS DEL MODELO POR PROTOTIPO...................
    • CONCLUCION PRIMERA ENTREGA
  • SEGUNDA ENTREGA
    • PLANTEAMIENTO DEL PROBLEMA
    • OBJETIVOS
    • OBJETIVO GENERAL
    • OBJETIVOS ESPECÍFICOS
    • JUSTIFICACIÓN
    • MARCO TEÓRICO
    • EL PLAN DE PROYECTO
    • ACTIVIDADES POR DESARROLLAR
    • ROLES A EJECUTAR Y QUIEN LO HARA
    • CUANDO SE EJECUTAN LAS ACTIVIDADES
    • REQUERIMIENTOS FUNCIONALES
    • REQUERIMIENTOS NO FUNCIONALES
    • DIAGRAMAS REPRESENTATIVOS
    • DEFINIENDO ALCANCES
    • CONCLUCION SEGUNDA ENTREGA
  • DIAGRAMAS ENTREGA FINAL
    • DIAGRAMAS DE SECUENCIA (entrega final)
    • DIAGRAMAS DE ESTADO (entrega final).............................................................................
    • final).............................................................................................................................................. ASIGNACION DE RESPONSABILIDADES EN DISEÑOS DE SOFTWARE (entrega
  • CONCLUSIONES
  • REFERENCIAS

ENTREGA FINAL

OBJETIVOS

OBJETIVO GENERAL

Realizar diagramas que representativos que modelen la secuencia, el estado y patrones de asignación contenidos en el desarrollo del proyecto OBJETIVOS ESPECÍFICOS

  1. Conocer en detalle los conceptos de interacciones
  2. Diseñar diagramas de secuencia, basados en los casos de uso propuestos
  3. Diseñar diagramas de estado, basados en los que se presentó previamente
  4. Comprender los usos diferentes de estos diagramas en las fases de requisitos y diseño PLANTEAMIENTO DEL PROBLEMA Al momento de elegir el prototipo a utilizar y en avance al desarrollo de software, cuyo proyecto exigido por un cliente final, se hace necesario contar con definiciones detalladas del comportamiento de software que se han planteado. Las herramientas utilizadas en las en cada una de las entregas, dan apertura a técnicas que fortalecieron la visibilidad del cómo se desarrollaría el software, sin embargo, debemos contar con la visualización para destacar el comportamiento de dichos procesos, sea cual sea o los más relevantes. JUSTIFICACIÓN Se debe representar por medio de diagramas el comportamiento del proyecto de software, para que en detalle sea evidenciadas las interacciones, transacciones y comunicación entre los diferentes actores, objetos y rutinas que lo componen. El prototipo selecto, deja plasmado la iniciativa de un proyecto final como beneficio al desarrollo, ya que se le puede dar continuidad a un desarrollo de software más completo por otro proyectante. Así mismo este trabajo desarrollado por nosotros, nos ha permitido diseñar la solución a una necesidad real basada en requerimientos indispensables y así, entregar un proyecto con sus partes teóricas, organizado el tiempo y diagramas.
  1. Encoger el modelo más adecuado para el proyecto que ayude al equipo a hacer el proyecto de la forma más eficiente.
  2. Desarrollar el software de la manera más eficiente siguiendo el modelo escogido. PLANTEAMIENTO DEL PROBLEMA A continuación, explicaremos el problema central de este proyecto, debemos escoger un modelo de proceso de desarrollo de software que permita al equipo realizar el proyecto propuesto por el cliente de la manera más ágil y sencilla y que nos permita satisfacer las necesidades del cliente y cumplir con los requisitos que este nos indica. Además de esto de explicarse por qué se escogió ese modelo para este proyecto y por qué este es el indicado y los otros modelos existentes no son tan adecuados como el modelo escogido. JUSTIFICACIÓN ¿Por qué es adecuado realizar este proyecto?, este proyecto se hace con el fin de identificar el mejor modelo para realiza el siguiente trabajo indicado por el cliente : “Necesita contar con una herramienta que me permita registrar una serie de profesionales dela salud que ofrecen diferentes servicios de acuerdo con una agenda definida y permitir a los usuarios en línea buscar el profesional que más se adapta a sus necesidades y agendar una cita con esta profesional una vez ha realizado el respectivo pago del servicio”. Para esto se debe evaluar cada uno de los modelos, mirar cuáles son sus beneficios y sus desventajas y escoger el que mejor se adecue mirando como beneficia al proyecto este modelo, como se puedes solucionar sus desvenas y que características del modelo ayudan a complementar bien el trabajo propuesto por el cliente y ayuda a cumplir todos los requerimientos de manera eficiente y bien hecha. Por esta razón es adecuado realizar este proyecto. MARCO TEÓRICO El modelo que se escogió para realizar este proyecto fue el modelo por prototipo ya que las ventajas que nos ofrece este proyecto para el equipo de software la más indicadas para este proyecto, además las desventajas se pueden solucionar con estrategias. A continuación de vamos a explicar más a fondo nuestra elección y por qué el modelo prototipo es el más indicado y los demás modelos existentes (Modelo cascada, Modelo

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:

  • Revisiones periódicas ineficientes entre el grupo
  • Carencia de liderazgo
  • Cargas de trabajo deficiente en su distribución
  • Carencia en cooperación y en los acuerdos u obligaciones POR QUE NO ES FACTIBLE EL MODELO INCREMENTAL El modelo incremental consiste en ser un modelo del tipo evolutivo, este modelo se encuentra basado en vacíos ciclos de cascada que son realimentados repetidamente. Este modelo es útil cuanto el personal necesario para realizar un proyecto no está completamente disponible, este modelo permite reducir el tiempo del desarrollo inicial, ya que se implementa la funcionalidad parcial. Este modelo reduce los riesgos del proyecto debido a que se basa en la realimentación de los avances y resulta ser más sencillo y acomodar cambios al tamaño del proyecto. En la siguiente imagen podemos ver cómo es un calendario de un proyecto con el modelo incremental, conociendo su forma en cascada que va retroalimentando y realizando entregas parciales del proyecto.

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

  1. Desarrollar el software siguiendo el modelo seleccionado por el grupo
  2. Definir un plan para este proyecto
  3. Identificar los requerimientos funcionales y no funcionales del cliente
  4. Cumplir con los que solita del cliente.
  5. Realizar una proyección de la duración del proyecto
  6. Realizar diagramas y cuadros de apoyo para la elaboración del proyecto. JUSTIFICACIÓN En él ahora tomó relevancia y casi que indispensable el uso de Tics en las compañías, es por ello que se requiere realizar un proyecto capaz de estandarizar algún proceso o varios de estos. A su vez que permita el uso de nuevas tecnologías para los requerimientos de mejora dentro del sistema que gestione citas de usuarios con profesionales de la salud. MARCO TEÓRICO La elaboración de un proyecto de para un desarrollo de software, requiere de actividades para entender al que lo solicita y a los que van a ejecutar dicho desarrollo, por lo tanto, basados en la metodología escogida “metodología de prototipos” cuyo diseño inicial se centra en una representación de aspectos visibles para el cliente final. Apoyados en éste, conduce a la construcción del prototipo en software, pues pasará de ser una parte superficial a ser un sistema completo. Previamente lo que puede dar a conocer, son los aspectos para ser clarificados de acuerdo con los requerimientos. los prototipos cuentan con las siguientes etapas: comunicación, planeación, modelado, construcción y despliegue.

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:

  • Realizaremos un contrato definiendo condiciones y características en las que se desarrollará el producto
  • Se escucharán por medio de reuniones las percepciones o ventajas existentes en el software desarrollado.
  • Se podrán realizar pruebas auxiliares que garanticen la buena interacción, fluidez y respuesta a los usuarios finales. ROLES A EJECUTAR Y QUIEN LO HARA Para ello tomaremos nuestro talento humano selecto que satisface cada una de las demandas para la ejecución del proyecto TABLA I ROL EJECUTOR Investigador, testeo, diseñador y escribe Ingeniero de software Conductor de la calidad de los procesos y capacitador Ingeniero industrial Diseñador, analista y define procesos Analista de software Orquestador, administra recursos Administrador de empresas (énfasis financiero) Diseña, implementa, pruebas Desarrolladores de software TABLA II ASPECTOS COMPLEMENTARIOS BASADOS EN LABORES Se encargará del cuerpo total de la ejecución del proyecto, basado en la información obtenida para esta necesidad Ingeniero de software Capacita al personal y socializa los procesos para que estos contengan la calidad deseada Ingeniero industrial se encargará de estudiar un problema de una complejidad determinada, descomponiendo el problema en subproblemas de menor complejidad Analista de software Se encargará de orquestar los requerimientos internos del proyecto, así como el personal selecto, además garantizar de realizar las proyecciones financieras que se requiera el proyecto en la selección de un lugar apropiado, planta y equipo Administrador de empresas (énfasis financiero) Es quien escribe, depura y actualiza el código fuente de un programa informático. Igualmente se encarga de la implementación de aplicaciones mediante un lenguaje de programación, que compilados pueda entender el hardware de un computador. Desarrolladores de software

CUANDO SE EJECUTAN LAS ACTIVIDADES

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:

  • IMG-TIEMPO-ACTIVIDADES
  • CRONOGRAMA-ACTIVIDADES