Proyecto de Software

Ingeniería de Software I
TRABAJO COLABORATIVO
TUTOR: BERRIO LOPEZ JUAN PABLO
INTEGRANTES:
LADY GALINDO SERRANO 1821022661
JIMÉNEZ MORENO MAURICIO ALBERTO 1811027758
ESTEFANIA VALBUENA RINCON 1821020985
LUIS OSWALDO QUINTERO VELASQUEZ 1811024524
LUIS CASTAÑEDA 1611025770
CRISTIAN CAMILO SOSA PINZON 1821020779
POLITECNICO GRANCOLOMBIANO
FACULTAD DE INGENIERIA, DISEÑO E INNOVACION
MODALIDAD VIRTUAL
2020
Tabla de Contenido
1. INTRODUCCION 3
2. OBJETIVOS 4
2.1. Objetivos generales 4
2.2. Objetivos especificos 4
3. JUSTIFICACION DEL MODELO 5
3.1 Ventajas 6
3.2 Mitigación de errores 6
4. ACTIVIDADES PARA LA EJECUCIÓN DEL PROYECTO 7
7
4.1 Análisis del requisito 7
4.2 Diseño del Sistema 8
4.3 Diseño del programa 8
4.4 Codificación 8
4.5 Pruebas 9
4.6 Verificación 9
4.7 Mantenimiento 9
5. ROLES Y ESPECIFICACIONES DEL EQUIPO 12
6. REQUERIMIENTOS FUNCIONALES 13
7. REQUERIMIENTOS NO FUNCIONALES 20
8. CASOS DE USO 22
9. DIAGRAMA DE CLASES 23
10 DISEÑO DEL MODELO ENTIDAD – RELACIÓN 23
11. CONCLUSIONES 24
12. MARCO LEGAL 25
13. REFERENCIAS 27
1. INTRODUCCION
En la actualidad, las fábricas de desarrollo de software están implementando metodologías ágiles
para satisfacer las necesidades de los clientes en el menor tiempo posible y con la mejor calidad
en sus productos.
Eso quiere decir que el tiempo es un factor determinante en todas y cada una de las decisiones
que se tomen en la construcción de un nuevo aplicativo. Por este motivo los procesos de software
intervienen para que las decisiones de gestión y desarrollo se tomen de la manera más eficiente y
reduciendo los riesgos.
Este documento tiene como propósito justificar la elección de un modelo de procesos, así como
reconocer y mitigar los riesgos asociados a la elección del modelo. Aplicar metodologías y
patrones de desarrollo de software, identificar y especificar los requerimientos funcionales y no
funcionales, implementar diagramas de clases, de estado y de secuencia. Con el fin de satisfacer
las necesidades de un cliente en el sector de la salud a medicina especializada sin tramites
adicionales.
2. OBJETIVOS
2.1. Objetivos Generales
Diseñar el proceso en la creación de un software a través de modelos y metodologías de
desarrollo que permitan satisfacer las necesidades de un cliente en el sector de la salud.
2.2. Objetivos Específicos
 Seleccionar el modelo de proceso que mejor se adapte al requerimiento del cliente.
 Describir las ventajas del modelo seleccionado y la mitigación de riesgos de este.
 Analizar los requerimientos funcionales y no funcionales para un cliente del sector salud.
 Diseñar el diagrama de clases para la solución de los requerimientos (base de datos y la
interfaz del software)
 Clasificar y analizar la información recolectada.
 Adquirir habilidades y profundizar en el lenguaje de programación dentro de los Modelos
de software.
3. JUSTIFICACION DEL MODELO
El proyecto se enfoca a dar solución en opción web y/0 app con énfasis a la solicitud de citas
médicas a especialistas de diferentes ramas con numero de remisión emitida por el medico inicial
tratante o internista; esta se desarrollará para ambientes web con utilización de usuario por
herramientas digitales como internet sea cual fuere la conexión sobre internet fija o móvil.
El enfoque de este proyecto y/o desarrollo, se basa en fases de programación según los
estándares de sistematización existentes, desde la planificación, pasando por la planeación,
desarrollo, con interfaz amigable para el usuario proporcionador de la información y que
alimentaran la Bases de datos que se ejecutaran para la posterior minería de datos.
Esta solución busca reaccionar a una necesidad del usuario de forma más efectiva y objetiva
Para el cliente en particular, tuvimos en cuenta que los requerimientos funcionales dados por él
abarcan un gran panorama de usabilidad de la app. Con base en esto sugerimos que no es
necesario, una vez se despliegue la app y web, de realizar algún ajuste. Por tal motivo optamos
por utilizar el modelo de cascada.
Dentro del grupo se tomó en cuenta los otros modelos, de los cuales se descartaron a
continuación se menciona el modelo y el motivo:

Modelo de cascada: No se puede modificar una vez se realice su entrega final, el diseño puede
contener un error que si no es detectado a tiempo puede requerir más demorada para ejecutar la
solución.
 Modelo de proceso incremental: Es difícil estimar un costo si no se tiene claro las metas,
se requiere realizar pruebas.
 Modelos de procesos por prototipos: Se requiere realizar varias pruebas por parte del
cliente, no se tiene un tiempo estimado para el producto y se puede presentar
inconveniente dado que se entrega un prototipo que no es totalmente funcional.
 Modelo de proceso espiral: Requiere de experiencia para tener un resultado exitoso y
contante participación que puede inferir con la organización.
3.1 Ventajas
 Una vez se tenga las etapas claramente definidas, se facilita la planeación y el
seguimiento, evitando de esa manera que se pasen las fechas de entrega, así como los
costos.
 Como el requerimiento funcional está bien definido por el cliente, esperamos que haya
muy pocas probabilidades de cambios y que los riesgos sean menores.

 De definirse muy bien las funcionalidades y las etapas de este modelo, crearemos la
aplicación en mucho menor tiempo que con cualquiera de los otros modelos.
3.2 Mitigación de errores
 Cambios en los requerimientos del cliente: para mitigar este riesgo debemos asegurar la
primera etapa del modelo.
 Pérdida de tiempo: gracias al análisis del requerimiento funcional, y con una buena
planeación esperamos que los tiempos para pasar de una etapa a la otra sea rápida y
concreta. De esa manera cada persona en las diferentes etapas del modelo va a tener un
rol muy bien especificado con una actividad también muy específica.
 El costo en la corrección de un error: Para evitar este error lo mejor es asegurar cada
etapa del modelo, siendo muy intuitivos y minuciosos en las actividades a las que cada
rol corresponda.
4. ACTIVIDADES PARA LA EJECUCIÓN DEL PROYECTO
Fases del modelo
ANALISIS DEL REQUISITO
DISEÑO DEL SISTEMA
DISEÑO DEL PROGRAMA
CODIFICACION
PRUEBAS
VERIFICACION
MANTENIMIENTO
4.1 Análisis del requisito: El proyecto se enfoca a dar solución en opción web con énfasis a la
solicitud de citas médicas a especialistas de diferentes ramas con numero de remisión emitida por
el medico inicial tratante o internista; esta se desarrollará para ambientes web con utilización de
usuario por herramientas digitales como internet sea cual fuere la conexión sobre internet fija o
móvil.
El enfoque de este proyecto y/o desarrollo, se basa en fases de programación según los
estándares de sistematización existentes, desde la planificación, pasando por la planeación,
desarrollo, con interfaz amigable para el usuario proporcionador de la información y que
alimentaran la Bases de datos que se ejecutaran para la posterior minería de datos.
Esta solución busca reaccionar a una necesidad del usuario de forma más efectiva y objetiva.
- Permisos de Acceso al sistema de control.
- Levantamiento de requerimientos funcionales y técnicos frente a la solución
- Análisis y revisión de software de programación a usar para cubrir la solución.
- Análisis y revisión de motor de base de datos a usar con la solución.
- Análisis y revisión de copyright frente al estado para licencia y manera de uso del
software.
4.2 Diseño del Sistema:
- Construcción de base de datos.
- Identificación de entidades y atributos.
- Identificación de tipo de dato y dominio de los atributos.
- Identificación de las llaves primarias y foráneas
4.3 Diseño del programa:
- Construcción de modelo entidad relación.

- Implementación del modelo en motor de base de datos
- Diseño de ventanas de software de inventario.
- Manipulación de código frente a las ventanas creadas.
4.4 Codificación:
- Codificar requerimientos funcionales.
- Codificación sistema de autenticación.
4.5 Pruebas:
Realización de pruebas de funcionabilidad.
- Implementación de software en fase beta y realización de pruebas por parte del
desarrollador.
- Realización últimos ajustes en el paquete solución.
- Empaquetamiento de software con asistente de instalación y ejecución de pruebas de
instalación en ambientes y/o dispositivos SmartPhone
- Prueba de los técnicos en campo para determinar estabilidad del Software Aplicación
Citas especialistas Médicos.
4.6 Verificación:
- Garantizar conectividad.
- Garantizar tiempos en funcionalidad 7x24.
- Instalación de motor e implementación de la base de datos en equipo productivo.
- Instalación de software en equipo productivo.
- Capacitación a administradores y personal de soporte para el manejo del software de
inventario.
- Publicación de Aplicativo en los diferentes Market Place, App Store, Play Store de los
Fabricantes para la descarga de Usuarios, con los navegadores disponibles del mercado.
4.7 Mantenimiento:
- Acompañamiento al usuario, (Tiempo Determinado mientras se estabiliza el desarrollo,
Garantía) de como se ha comportado el sistema.
- Ingeniería social para Registrar modificaciones o adiciones que el usuario requiera frente
a la solución instalada. (Control de Cambios).
- Revisión y análisis de nuevas actualizaciones que el sistema requiera que estén dentro del
proyecto, como mejoras en rendimiento y mantenimiento de base de datos, (Sub Menús,
Ampliación Base de datos - Capacidad en GB)
Volumen del proyecto
El software Creado (incluye aplicación móvil) como destino cliente final según pasos
implementados y métodos que se utilizan en el desarrollo de un proyecto de software. El
método desarrollo lineal y secuencial así:
FC1 - Accesa PF con valores de 1 a 10 búsqueda de capacidades solicitadas.
FC2 - Determinar por medio de ítems según la importancia de la solicitud.
FC3 – Establecer Líneas de código.
FC4 – Productividad Y Calidad.
FC5 – Costo.
Este último punto se tomarán un valor x para determinar un estimado del costo del desarrollo
según KLDC (número estimado de Líneas de Código distribuidas (en miles) para el
proyecto.)
PF (Punto de función)
FAE (Personas por Mes)
E (Esfuerzo)
T (Tiempo)
KLDC = (PF * Líneas de código X por cada PF) /1000 = (X*X) /1000 = X
Coeficientes para usar según KLDC:
- Proyecto Software.
- Orgánico.
- Semi-acoplado.
- Empotrado.
- Cálculo de la variable FAE.
- Cálculo del esfuerzo del desarrollo.
- Cálculo tiempo de desarrollo.
- Tiempo.
- -Productividad.
Localización del Proyecto Ubicación a nivel nacional servidor con bases de datos,
Link página web del Proyecto es http://www.Medespecializados.gov.co

5. ROLES Y ESPECIFICACIONES DEL EQUIPO
Se envía en documento en adjunto.
6. REQUERIMIENTOS FUNCIONALES
IDENTIFICADOS: Nombre:
R1 Validar registro del Paciente
Tipo: REQUERIMIENTO QUE ¿CRÍTICO?
(NECESARIO/DESEABLE LO UTILIZA O No
) ESPECIALIZA:
Necesario
PRIORIDAD DE DOCUMENTOS DE VISUALIZACIÓN ASOCIADOS:

DESARROLLO:
Alta
ENTRADA: SALIDA:
• Número y tipo de documento Registro correcto de una persona
• Apellidos y Nombres completos
DESCRIPCIÓN:
Precondición: Se debe disponer de un usuario para que este sea registrado
Descripción: Se registrará en el sistema toda la información necesaria para llevar a cabo el
registro de una persona
Postcondición: Se realizará el registro de una persona
MANEJO DE SITUACIONES ANORMALES
1. Persona ya registrada en el sistema (se mostrará en pantalla un mensaje que dirá que la
persona ya está registrada en el sistema)
CRITERIOS DE ACEPTACIÓN
Se supondrá por defecto que hay al menos dos criterios de aceptación:
1. Los datos ingresados al sistema en el momento de realizar el registro de una persona son
correctos y los indicados y establecidos para llevar a cabo su correcto registro en el
sistema y poder realizar sus trámites dentro del mismo.
1. Los datos no fueron diligenciados en su totalidad (mensaje que indique faltan datos por
ser diligenciados)
2. Los datos no corresponden a los solicitados en el sistema (el sistema mostrara un
mensaje que indicara que los datos ingresados no son del tipo de los que fueron solicitados
para llevar a cabo el registro)
1. Tras efectuar el registro del usuario los datos serán aprobados por el sistema y el
registro del usuario será exitoso
IDENTIFICADOR: NOMBRE:
R2 Validar registro del Medico
Tipo: REQUERIMIENTO QUE CRÍTICO?

(NECESARIO/DESEABLE LO UTILIZA O No
) ESPECIALIZA: R2
Necesario

DESARROLLO:
Alta
ENTRADA: SALIDA:
Datos del registro del Medico solicitados Registro del Medico validado y/o exitoso
por el sistema
DESCRIPCIÓN:
Precondición: ingresar datos solicitados por el sistema para el registro del Medico
Descripción: posteriormente al registro del Medico en el sistema se validará el registro
correspondiente.
Postcondición: se validará el registro del Medico si los datos ingresados son correctos.

1. Los datos ingresados y solicitados para el registro del Medico son incorrectos y no se
puede hacer su validación en el sistema.
1. El registro del Medico es validado por el sistema después de comprobar que los datos
ingresados son correctos
R3 Consultar registro usuario
Tipo: ) REQUERIMIENTO CRÍTICO?
(NECESARIO/DESEABL QUE LO UTILIZA O No
E ESPECIALIZA:
Necesario R1
R2
PRIORIDAD D DOCUMENTOS DE VISUALIZACIÓN ASOCIADOS:

E
DESARROLLO:
Media
ENTRADA: SALIDA:
Datos del usuario Formato con los datos del registro del
usuario
DESCRIPCIÓN:
Precondición: haber realizado en el sistema el registro correspondiente al registro de un
usuario
R4 Consultar registro del Paciente
Tipo: REQUERIMIENTO CRÍTICO?
(NECESARIO/DESEABLE QUE LO UTILIZA O No.
) ESPECIALIZA: R1
Necesario

DESARROLLO: Media
ENTRADA: SALIDA:
Datos del paciente y citas asociadas Formato con los datos del paciente y el
número de remisión
DESCRIPCIÓN:
Precondición: haber diligenciado el formato requerido por el sistema para el registro de un
usuario
Descripción: permite consultar en el sistema los datos del usuario
Postcondición: se mostrará en pantalla los datos del usuario y sus citas con remisión

1. Los datos del usuario ingresados al sistema no existen
2. Los datos ingresados al sistema son incorrectos
1. Se muestra en pantalla los datos del usuario y su información de citas y remisiones
Descripción: permitirá consultar en el sistema los datos ingresados por el usuario en su
registro
Postcondición: se mostrará en pantalla los datos que el usuario diligenció en el registro.

1. Los datos ingresados en el módulo consulta no corresponden
2. El usuario no aparece registrado en el sistema
1. El resultado mostrado por el sistema es el esperado para el usuario
R5 generar información de usuario
E ESPECIALIZA:
Necesario R1
R2
R3

DESARROLLO: E
Alta
ENTRADA: SALIDA:
Consulta registro de usuario Reporte del registro efectuado por el
usuario
DESCRIPCIÓN:
Precondición: haber realizado una consulta previa del registro del usuario y solicitar la
generación del reporte con los datos diligenciados
Descripción: permitirá ver en pantalla los datos diligenciados e ingresados por el usuario
para su correspondiente registro en el sistema
Postcondición: se generará el reporte correspondiente a la consulta del usuario con sus
datos previamente diligenciados en el sistema
1. El sistema no genera la información del usuario
2. Los datos del usuario no existen en el sistema
1. La generación del reporte de la información de un usuario es generada por el
sistema correctamente
R6 Actualizar información del usuario
E ESPECIALIZA:
Necesario R1
R2
R4

E
DESARROLLO:
Media
ENTRADA: SALIDA:
Registro de usuario Actualización de la información de
usuario exitosa
DESCRIPCIÓN:
Precondición: Haber realizado el registro de usuario y haber realizado una consulta previa
de la información para actualizarla
Descripción: permitirá hacer cambios en la información ingresada durante el registro de un
usuario y así guardar y actualizar cambios en el sistema
Postcondición: se actualizará la información necesaria correctamente
1. Los datos en el sistema no fueron configurados
1. La actualización de la información en el sistema fue exitosa
Identificador: Nombre:
R7 Consultar Remisiones
TIPO: REQUERIMIENTO QUE LO ¿Crítico?

Necesario UTILIZA O ESPECIALIZA: no
R1
R2
PRIORIDAD D Documentos de visualización Asociados:
DESARROLLO: E
Media
ENTRADA: SALIDA:
Registro de usuario, registro de citas, Se muestra en pantalla el número de remisión
registro asignación. cita especializada y médicos especialistas
disponibles.
DESCRIPCIÓN:
Precondición: El sistema realizara la búsqueda de la remisión y asocia los médicos
especialistas disponibles con datos de contacto en un registro actualizado, mediante el
ingreso de datos del paciente.
Descripción: Con el ingreso de los datos del paciente y remisión se realizará la búsqueda
en el sistema y se mostrará cupos de citas disponibles.
Postcondición: El sistema realizará la verificación de datos e información del cliente y
realizará la búsqueda de los cupos disponibles.

1. Datos de usuario no válidos (mensaje mostrando que los datos no son correctos).
2. No se encuentra remisión (mensaje mostrando que no ha sido generado).
3. El formato del archivo no se puede abrir (mensaje mostrando que no se encuentra
el programa necesario para abrir el siguiente formato).
CRITERIO DE ACEPTACIÓN
1. Al validar la consulta de los datos de los usuarios el sistema realizara la búsqueda de
la cita y luego lo mostrara en pantalla.
2. Se realiza la muestra en pantalla de la cita y especialistas disponibles.
3. La verificación de los datos de paciente, remisión y especialistas serán aceptados.
Identificador: Nombre:
R8 Buscar Especialistas
TIPO: REQUERIMIENTO QUE ¿Crítico?

Necesario LO UTILIZA O No
ESPECIALIZA:
PRIORIDAD D Documentos de visualización Asociados:

DESARROLLO: E
Alta
ENTRADA: SALIDA:
Asignación citas especialistas Ubicación del especialista en listado
DESCRIPCIÓN:
Precondición: ingresar especialista para su ubicación.
Descripción: se ingresa el especialista y ubica las fechas disponibles de atención.
Postcondición: especialista correcto y ubica fechas de posible cita para asignar.

1. No se encuentra especialista en listado
2. No es posible ubicar el listado de especialistas
1. listado validado con la fecha y especialista indicada por el usuario
7. REQUERIMIENTOS NO FUNCIONALES
Atributos de calidad
Listado de los atributos de calidad y la descripción y su respectiva ficha (puede utilizar
la ficha de requerimientos funcionales con algunas modificaciones).
Requisito Descripción
Eficiencia Conjunto de atributos que relacionan el desempeño y la
cantidad de recursos necesitados bajo condiciones establecidas
Fiabilidad Conjunto de atributos relacionados con la capacidad del

software de mantener su nivel de prestación bajo condiciones
establecidas durante un periodo de tiempo establecido.
Confiabilidad Este término es necesario sea separado en varios elementos que

permiten darle al software el matiz de fiable. Sus componentes
son:
Completitud
Consistencia y precisión
Solidez
Simplicidad
Calidad en los procesos de desarrollo
Seguridad y Verificabilidad, estas dos últimas que se determinan
con el sistema en uso.
Disponibilidad Grado en el cual un sistema o componente es operacional y
accesible cuando es requerido para su uso.
Usabilidad Conjunto de atributos relacionados con el esfuerzo necesario

para el uso, y en la valoración individual de tal uso, por un
establecido o implicado conjunto de usuarios.
Mantenibilidad Conjunto de atributos relacionados con la facilidad de extender,
modificar o corregir errores en un sistema o software.
Flexibilidad Facilidad con la que un sistema o componente puede ser

modificado para ser usado en ambientes diferentes para los
cuales fue diseñado inicialmente.
Extensibilidad Consiste en la facilidad de adaptación del software a nuevos
requisitos o cambios en la especificación. REUTILIZACIÓN es
otro factor de calidad que consiste en crear elementos de
software que sirvan para construir distintas aplicaciones.
Seguridad Propiedad de un sistema para salvaguardar la privacidad e

integridad de la información.
Integridad No ocurrencia de alteraciones no autorizadas de información.
Interoperabilidad Es la condición mediante la cual sistemas heterogéneos pueden

intercambiar procesos o datos.
Concurrencia Capacidad que tiene un sistema para que ingresen múltiples
usuarios al mismo tiempo.
Accesibilidad Éste no se refiere a la facilidad de uso, sino a la posibilidad de
acceso. En concreto a que el diseño, como prerrequisito
imprescindible para ser usable, posibilite el acceso a todos sus
potenciales usuarios, sin excluir a aquellos con limitaciones
individuales (discapacidades, dominio del idioma, etc.) o
limitaciones derivadas del contexto de acceso (software y
hardware empleado para acceder, ancho de banda de la
conexión empleada, etc.)
DIAGRAMAS UML
Se detallan los diagramas que se validaron en el proceso del sistema y que son necesarios para el
diseño y la implementación de este.
• Diagrama de casos de uso

Se realiza un diagrama de caso de uso para los principales requerimientos y funcionalidades del
sistema.
8. CASOS DE USO
9. DIAGRAMA DE CLASES
Diseño del modelo Entidad – Relación
Este modelo de datos para representar las Entidades de información (Conjunto de datos) y las
relaciones que las componen. En este modelo, se considera la base de datos como un conjunto de
relaciones, las cuales se almacenan en una tabla (Conjunto de filas).
El diseño del modelo relacional de la base de datos para el subsistema de seguridad con la
respectiva especificación.
10. CONCLUSIONES
 Se escoge este tipo de modelo (Cascada) ya que se asemeja a un prototipo y que
consta de 7 fases ya descritas en el documento, el cual es el ideal para implementar un
desarrollo.
 Para este tipo de requerimientos, los errores conceptuales se pueden evitar en el
desarrollo.
 El modelo presenta una documentación técnica viable para que dentro del desarrollo
sin un ingeniero faltase se puede retroalimentar para las fases posteriores.

 Se pueden realizar monitoreo y pruebas en las diferentes fases.
 Se genera el desarrollo con un orden lógico y con insumos básicos para el desarrollo.
 Servidor básico a utilizar Windows Server (Según Requerimientos).
 Sistema Operativo del usuario ya por defecto, para el funcionamiento del desarrollo.
 Servidor con capacidad de soportar un motor de Bases de datos suministrado por el
cliente y que minimiza costos adicionales para el desarrollo.
 Hosting para el alojamiento de la aplicación y descarga de la mismas que será
proporcionado por el cliente y que esto conlleva a monos tiempos de ejecución del
desarrollo facilitando las pruebas y bajos costos.
 Como complemento en la conclusión el grupo de información anteriormente descrita
se pude tomar como iniciativa real ya que para un desarrollo de este tipo se interactúa
con el cliente según la necesidad colocando como beneficios todas las herramientas
físicas y técnicas con las que cuentan para mejorar la experiencia de los clientes
actuales, mejorando los tiempos de servicio y la atención de la entidad de salud.
11. MARCO LEGAL
Las leyes en Colombia como incentivos para promover las iniciativas digitales se necesita
implementar las estructuras legales actuales con el fin de establecer en los modelos contractales
adoptando actividades adoptadas al las actividades empresariales en desarrollos digitales que
aseguran el buen funcionamiento de los proyectos de este tipo.
Marcos legales actuales para este desarrollo y como soporte en el marco legal tenemos las
siguientes:
Ley 1341 de 2009 define un marco legal propicio para el desarrollo de los contenidos digitales.
Sobre esta ley se apoya el proyecto para la creación legal de software para equipos móviles.
Plan Vive Digital Colombia busca proyectar al país regional y mundial de contenidos digitales
y fomentar el desarrollo de contenidos digitales, aplicaciones móviles y web a través de clúster
que potencien la industria nacional.
Ley 1273 de 2009 modifica el código penal para la inclusión de un bien jurídico tutelar que se
llamaría “de la protección de la información y de los datos”, que sirve para el debido cuidado de
los sistemas que hagan uso de tecnologías de la información y las comunicaciones. Respecto a
este articulado, el software producto de este proyecto estará diseñado teniendo en cuenta el
cuidado de los datos del usuario final y de terceros sobre los cuales la aplicación guarde datos.
El acatamiento y cumplimiento de estas y otras leyes, o derivaciones de las mismas que afecten
el producto o el proceso de producción de software aplicativo; corresponden a los principios y
normas que, alineadas con el código de ética profesional de la Ingeniería (ley 842 de 2003); en
todo momento enmarcan las actividades y productos que genere este proyecto, que tiene en
cuenta pero no se limita a: software de aplicación, actualizaciones al software, código fuente,
documentación de Ingeniería de software (casos de uso, control de flujo de datos, etc.), licencias
tipo EULA (End User License Agreement) en formato GPL (General Public License) del
software final y de las herramientas de desarrollo, estudios de factibilidad, diseño de proyecto,
etc.
12. REFERENCIAS
 Marco Teórico, 2.3. Modelos de la ingeniería del software. Recuperado de
https://www.marcoteorico.com/curso/91/ingenieria-de-software/854/modelos-de-la-
ingenieria-del-software
 Asp Gems, Metodología de desarrollo de software (III) – Modelo en Espiral. Fecha de
publicación. 5 de abril de 2019. Recuperado de
https://aspgems.com/metodologia-de-desarrollo-de-software-iii-modelo-en-espiral/
 Globe, Modelo de desarrollo incremental. Recuperado de
https://www.globetesting.com/modelo-de-desarrollo-incremental/
 Pablo Domínguez. Openclassrooms, En qué consiste el modelo en cascada. Fecha de
publicación 2 de junio de2020. Recuperado de
https://openclassrooms.com/en/courses/4309151-gestiona-tu-proyecto-de-
desarrollo/4538221-en-que-consiste-el-modelo-en-cascada
 Arturo Rodríguez Cabello. Prezi, Ciclos de vida del software. Fecha de publicación 20 de
julio de 2018. Recuperado de https://prezi.com/p/0ls67axy0wry/caracteristicas-ventajas-
desventajas-y-las-etapas-de-las-metodologias-cascada-espiral-e-incremental/
 Javier Garzas. Ciclos de vida para gestionar un proyecto software: cascada, espiral,
iterativo, incremental o ágil. Fecha de publicación 3 de julio de 2013. Recuperado de
https://www.javiergarzas.com/2013/07/ciclos-de-vida-software.html

Proyecto de Software

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Proyecto de Software

Încărcat de

Drepturi de autor:

Formate disponibile

Ingeniería de Software I

TUTOR: BERRIO LOPEZ JUAN PABLO

LADY GALINDO SERRANO 1821022661

JIMÉNEZ MORENO MAURICIO ALBERTO 1811027758

ESTEFANIA VALBUENA RINCON 1821020985

LUIS OSWALDO QUINTERO VELASQUEZ 1811024524

LUIS CASTAÑEDA 1611025770

CRISTIAN CAMILO SOSA PINZON 1821020779

FACULTAD DE INGENIERIA, DISEÑO E INNOVACION

En la actualidad, las fábricas de desarrollo de software están implementando metodologías ágiles

reduciendo los riesgos.

patrones de desarrollo de software, identificar y especificar los requerimientos funcionales y no

funcionales, implementar diagramas de clases, de estado y de secuencia. Con el fin de satisfacer

las necesidades de un cliente en el sector de la salud a medicina especializada sin tramites

2.1. Objetivos Generales

Diseñar el proceso en la creación de un software a través de modelos y metodologías de

desarrollo que permitan satisfacer las necesidades de un cliente en el sector de la salud.

2.2. Objetivos Específicos

 Seleccionar el modelo de proceso que mejor se adapte al requerimiento del cliente.

 Describir las ventajas del modelo seleccionado y la mitigación de riesgos de este.

 Diseñar el diagrama de clases para la solución de los requerimientos (base de datos y la

interfaz del software)

 Clasificar y analizar la información recolectada.

 Adquirir habilidades y profundizar en el lenguaje de programación dentro de los Modelos

3. JUSTIFICACION DEL MODELO

estándares de sistematización existentes, desde la planificación, pasando por la planeación,

desarrollo, con interfaz amigable para el usuario proporcionador de la información y que

alimentaran la Bases de datos que se ejecutaran para la posterior minería de datos.

por utilizar el modelo de cascada.

continuación se menciona el modelo y el motivo:

se requiere realizar pruebas.

cliente, no se tiene un tiempo estimado para el producto y se puede presentar

inconveniente dado que se entrega un prototipo que no es totalmente funcional.

 Modelo de proceso espiral: Requiere de experiencia para tener un resultado exitoso y

contante participación que puede inferir con la organización.

 Una vez se tenga las etapas claramente definidas, se facilita la planeación y el

muy pocas probabilidades de cambios y que los riesgos sean menores.

3.2 Mitigación de errores

4. ACTIVIDADES PARA LA EJECUCIÓN DEL PROYECTO

Fases del modelo

ANALISIS DEL REQUISITO

DISEÑO DEL SISTEMA

DISEÑO DEL PROGRAMA

estándares de sistematización existentes, desde la planificación, pasando por la planeación,

desarrollo, con interfaz amigable para el usuario proporcionador de la información y que

alimentaran la Bases de datos que se ejecutaran para la posterior minería de datos.

- Permisos de Acceso al sistema de control.

- Levantamiento de requerimientos funcionales y técnicos frente a la solución

- Análisis y revisión de software de programación a usar para cubrir la solución.

- Análisis y revisión de motor de base de datos a usar con la solución.

4.2 Diseño del Sistema:

- Construcción de base de datos.

- Identificación de entidades y atributos.

- Identificación de tipo de dato y dominio de los atributos.

- Identificación de las llaves primarias y foráneas

4.3 Diseño del programa:

- Construcción de modelo entidad relación.

- Implementación del modelo en motor de base de datos

- Diseño de ventanas de software de inventario.

- Manipulación de código frente a las ventanas creadas.

- Codificar requerimientos funcionales.

- Codificación sistema de autenticación.

Realización de pruebas de funcionabilidad.