UNIVERSIDAD EAN

FACULTAD DE INGENIERIA

INGENIERIA DE SISTEMAS

GESTION DE PROYECTOS DE SOFTWARE

GUIA 3. INGENIERIA DE SOFTWARE

DESARROLLO Y MODELADO DE SOFTWARE

ELABORADO POR

ANDRES SNEIDER JIMENEZ GARCIA

HAROLD FELIPE ZULUAGA GRISALES

MANUEL LEONARDO AYALA AYALA

WILLIAM ALEXANDER GOMEZ CIPRIAN

PRESENTADO A

EDICSON JAIR GIL ACOSTA

BOGOTA DC.

SEPTIEMBRE 6

2020
TABLA DE CONTENIDO

INTRODUCCION...............................................................................................................3

OBJETIVOS.......................................................................................................................4

ACTIVIDAD 1.....................................................................................................................5

PROCESOS, DESARROLLO, REQUERIMIENTOS Y MODELADO DE SOFTWARE....5

ACTIVIDAD 2.....................................................................................................................6

DEFINICIÓN DE REQUERIMIENTOS Y MODELADO DEL PROYECTO.......................6

2.1 Identifique los requerimientos y documente los resultados:....................................6

2.2 Describa al menos dos casos de prueba (Identifique la diferencia entre caso de
uso y caso de prueba, tenga en cuenta que son dos temas distintos) para el sistema
de información que le permitan verificar la validez de los requerimientos encontrados.
.....................................................................................................................................14

2.3 Realice el esquema de la arquitectura de negocio del proyecto que está

realizando, como se muestra en el capítulo 13 del libro básico de estudio. Pantaleo,
G. (2015). Ingeniería de Software. Disponible en la Base de Datos de LFAOMEGA.14

CONCLUSIONES............................................................................................................17

REFERENCIAS...............................................................................................................18
 INTRODUCCION

En esta guía de aprendizaje se analizaron los conceptos y principios en el desarrollo de un

proyecto de software teniendo en cuenta las metodologías y los estándares internacionales, el
ciclo de vida, los pasos en el análisis y diseño en un proyecto de software, los términos y
definiciones asociadas a la gestión y el rol de un director de proyecto y sus alcances.

Se pretende demostrar el aprendizaje de los conceptos mediante un caso práctico que permita
definir cada uno de los pasos y ejecutarlo como se llevaría a la práctica en el campo profesional
para desarrollar un proyecto a un cliente.
 OBJETIVOS

1. Publicar individualmente un vídeo en youtube exponiendo unas preguntas específicas con

base al capítulo 5 del libro dirección y gestión de proyectos de tecnología e información
en la empresa.
2. Definir específicamente los requerimientos funcionales y no funcionales del proyecto .
incluyendo el proceso para descubrirlos.
3. Describir dos casos de prueba para verificar la validez de los requerimientos.
4. Realizar el esquema de la arquitectura de negocio.
 ACTIVIDAD 1.

PROCESOS, DESARROLLO, REQUERIMIENTOS Y MODELADO DE SOFTWARE.

Trabajo Individual – Video control de lectura

De manera individual, a partir de la lectura del capítulo 5 del libro básico de estudio Gómez
Ruedas, J. (2016). Dirección y Gestión de Proyectos de Tecnologías de Información en la
Empresa.

Realice un vídeo en el que describa:

 La diferencia que existe entre modelo y metodología de desarrollo de software.

 Describa los diferentes modelos de ciclo de vida para el desarrollo de software.
 Describa las distintas metodologías que existen para el desarrollo de software y la
diferencia que existe entre ellas.
 Describa y explique cuáles son las diferentes metodologías de desarrollo ágil que existen.
 Explique la conveniencia de usar o no una metodología ágil.

Desarrollo de actividad individual

A continuación, se presenta los enlaces de video para cada integrante del grupo:

A. Video Andres Sneider Jimenez Garcia

https://youtu.be/_Ch9JzIiEMk

B. Vídeo Harold Felipe Zuluaga Grisales

https://www.youtube.com/watch?
v=789uM_rKZRo&ab_channel=haroldfelipezuluagagrisales
C. Vídeo Manuel Leonardo Ayala Ayala

https://youtu.be/LWXqP01_rFw

D. Vídeo William Alexander Gomez Ciprian

https://youtu.be/s7cRWu4DVt0 

ACTIVIDAD 2.

DEFINICIÓN DE REQUERIMIENTOS Y MODELADO DEL PROYECTO

2.1 Identifique los requerimientos y documente los resultados:

 Describa el proceso de relevamiento (descubrimiento o identificación) de requerimientos,

la técnica utilizada y el instrumento utilizado. Tenga en cuenta la lectura de Pantaleo, G.
(2015).

2.1.1 Especificación de que desarrollar

La primera actividad para un desarrollo de software independiente de la metodología que se

vaya a usar es levantar el listado de requerimientos los cuales se dividen en dos:

Requerimientos funcionales: Son aquellos requerimientos que permiten como su nombre lo

indica la correcta funcionalidad del software a desarrollar, son los servicios que el sistema
debe suministrar a los usuarios.

Requerimientos No funcionales: son aquellos que nos indican el “como” debe funcionar este
sistema con su entorno operacional, es decir que necesita para operar. Podemos afirmar
también que son las limitaciones que tiene el sistema sobre sus funciones o servicios.

Para ambos casos estos deberán ser escritos de una manera clara y con frases simples claras y
directas.

2.1.2 Definición del Alcance

Se continúa con la definición del alcance, la cual se deriva de la identificación de los
requerimientos donde se puede obtener material para elaborar una propuesta técnico-
económica para la realización del proyecto. Para esta práctica es común tener estos listados
de requerimientos en un documento llamado: Especificación de requerimientos de Software
(ERS).

Como complemento al descubrimiento de los requerimientos se debe tener en cuenta el

comportamiento y la dinámica de los casos de uso para poder definir claramente el alcance
del proyecto. Estos casos de uso de hecho no son tan detallados y se obtienen de cada uno de
los actores y el uso que hacen al sistema.

Con el alcance estamos en condiciones de establecer la estimación del esfuerzo del equipo
del proyecto, para poder realizar una estimación mucha mas exacta y precisa de la que se
pudo haber presentado en la fase de preventa.

2.1.3 Acuerdo del proyecto

El acuerdo del proyecto se genera a partir del alcance, teniendo claro la estimación del
esfuerzo que surge a partir de este. Se puede incluir en la ERS una sección que muestre
claramente “qué” no se incluirá dentro del proyecto. En aquellos casos en donde no queda
claro el alcance del proyecto, se presta para discusión entre las partes e indica que no hubo
una buena definición en los temas del alcance del proyecto.

2.2 Técnicas de relevamiento

El objetivo esencial de estas técnicas es entender las necesidades del cliente, comprender los
requisitos y el porque de ellos, también son usadas para identificar las diferentes propiedades
del sistema actual que interfases tiene, y posibles conflictos o riesgos para el desarrollo del
proyecto. Se debe tener claro que no existe una técnica mejor que otra todo depende de
factores como tiempo, recursos y tipo de información donde se vaya a desarrollar el proyecto.

2.2.1 Entrevistas

Es una técnica sencilla y directa que hace parte de la mayoría de los procesos de proyectos de
ingeniería de software, para ello se debe definir los candidatos del negocio que van a ser
entrevistados también los representantes del equipo que desarrollará el sistema como son los
analistas, líder de proyecto, desarrolladores y arquitecto.

Para el desarrollo de esta técnica el equipo que desarrollará el software debe guiar la reunión
donde se busque encontrar características como el perfil del cliente, el problema como tal, el
entorno entre otras, con la información recolectada se analizará y se podrán llevar a cabo
otras entrevistas más focalizadas para poder entender correctamente el problema y evaluar las
posibles soluciones. Llevar a cabo estas reuniones es muy importante y definitivo ya que es
la forma de entender el contexto y necesidades de manera directa, estas reuniones no pueden
ser sustituidas por un envío de email con el cuestionario de preguntas.

2.2.2 Simulación de Usuario

Esta técnica facilita el estudio y la compresión del usuario como tal, literalmente es ponerse
en los zapatos del usuario donde se pueden integrar al ambiente de trabajo para el cual va a
ser desarrollado el software, permite entender muy bien sus necesidades.

Una falencia de esta técnica es que puede llegar a consumir tiempo considerable para tener la
simulación completa lo que deriva en mayores costos para el proyecto.

2.2.3 Escenarios

Son útiles para poder detallar un bosquejo de descripción de los requerimientos y

generalmente las personas encuentran más cómodo y sencillo vincularse a escenarios reales.

Con los escenarios podemos obtener descripciones como que esperan los usuarios del
sistema, escenario del flujo de los eventos, casos de que podría salir mal y como manejarlo,
información de actividades paralelas simultáneas y una descripción del estado del sistema
cuando se termina cada escenario.

2.2.4 Historietas (Storyboard)

Permite analizar la reacción del usuario frente a la propuesta que tiene el equipo de
desarrollo, se puede tomar como una aproximación o un anticipo sobre el sistema por parte
del cliente, es fácil de crear y modificar.
Se pueden definir tres tipos de historietas según la interacción con el usuario: historietas
pasivas, activas e interactivas.

Las historietas pasivan presentan una historia por medio de imágenes, screenshots o
presentaciones. Las historietas activas se pueden definir como una película que aun no ha
sido producida permitiendo al usuario una perspectiva del uso básico de la aplicación. Las
historietas interactivas requieren la participación del cliente de modo activo, se pueden
implementar por medio de simuladores o presentaciones interactivas.

Es evidente que las historietas interactivas son más costosas que las pasivas, su utilización
depende de la complejidad y riesgos del sistema, se sugiere empezar con una pasiva,
continuar con la activa y por último se implementarían las historietas interactivas.

En el proceso de generación de las historietas es muy importante conocer y detectar quienes

interactúan con el sistema que se está definiendo, así como los elementos que interactúan con
la aplicación y viceversa. Finalmente, no se debería invertir demasiado tiempo en su
elaboración ya que es muy probable que el usuario quiera hacer cambios.

2.2.5 Prototipado

Con esta técnica se elabora un modelo funcional del sistema que le permite tener al usuario
una idea de la aplicación y su flujo de información. Se usa en especial cuando hay cierta
incertidumbre con los requerimientos o cuando se necesita una respuesta rápida del usuario.

Por medio del prototipo el usuario podrá emitir su opinión para ajustar los requerimientos, lo
mas recomendable es hacer prototipos de las funcionalidades más complejas del sistema o
sobre la que menos conocimiento se tenga.

Existen muchas técnicas de prototipado una de ellas que son las versiones beta, pueden ser
reutilizadas como base para el desarrollo posterior. Esta técnica se puede usar en
combinación con otras técnicas.

 Para el proyecto propuesto en las guías anteriores defina los requerimientos funcionales y
no funcionales.
REQUERIMIENTOS FUNCIONALES

Registro de clientes de venta al por mayor

 Registrar de clientes.
 Información mínima para registrar clientes.
 Permitirá agregar varias direcciones al cliente.
 Permitirá agregar clientes sin número de cédula.
 Asociar una cantidad de crédito al cliente

Registro de productos y lista de precios

 Registro de inventario.
 Permitir ingresar lista de precios.
 Dar vigencia la lista de precios.
 Poder restringir la modificación de precios.
 Convenio para listas de precios

Ordenes de venta

 Asignar cliente al pedido de venta.

 Poder ingresar más de un pedido por cliente.
 Mostrar información al seleccionar un producto.
 Selecciona el precio de acuerdo al cliente
 Asignación automática de dirección de despacho.
 Verificación de crédito del cliente.
 Permitir crear pedidos en borrador.
 Llevar un control cuidadoso de productos remanentes
 Verificar que la cantidad que ordene el cliente esté disponible.
 Verificar cuando un producto solicitado este disponible automáticamente.

Facturas de venta

 Crear una lista de productos pendientes por facturar.

 Las facturas no son modificables.
  Permitir una factura para varios pedidos.
 Permite ingresar facturas manuales.
 Contabilización de facturas

REQUERIMIENTOS NO FUNCIONALES

Requerimientos de interfaz gráfica

 Máximo dos decimales por el campo del monto.

 No se permite trabajar con fechas futuras.
 Caracteres alfabéticos para nombre.
 Caracteres alfanuméricos y especiales para la dirección
 Seleccione de una lista preestablecida de países
 Seleccionar de una lista preestablecida departamentos
 Mostrar materiales existentes
 Definición de fechas contables
 Fácil impresión del registro de pago

Requerimientos de eficiencia

 Tener alta velocidad en las transacciones.

 Responder rápidamente a las solicitudes del usuario.
 Permitir trabajar simultáneamente sin demora
 Actualización rápida de la base de datos

Requerimientos de seguridad lógica y de datos

 Modificación de permisos del sistema restringido

 Respaldo frecuente del sistema de forma segura
 Encriptar la información
  Identificación de ataques de seguridad y respuesta acorde

Usabilidad

 Fácil usabilidad
 Baja tasa de errores por el usuario
 Contar con manuales de usuario
 Mensajes de errores informativos
 Módulo de ayuda en línea

Dependibilidad

 Alta disponibilidad
 Inicio y reinicio rápido
 Baja taza de Falla del sistema

Requerimientos funcionales del proyecto

 Clasifique y organice los requerimientos, para ello haga una matriz con los siguientes
campos:

https://universidadeaneduco-
my.sharepoint.com/:x:/g/personal/hzuluag56268_universidadean_edu_co/EcRBonBs6RhOsak46
ca6HaUBswGyR9Yp1e_Xjp3MjpR-1Q?e=8rAwfH

2.2 Describa al menos dos casos de prueba (Identifique la diferencia entre caso de
uso y caso de prueba, tenga en cuenta que son dos temas distintos) para el sistema de
información que le permitan verificar la validez de los requerimientos encontrados.

Nombre de Proyecto: Software para

ID Caso de Prueba: CP-registro-01
Gestión de Inventario
Autor Caso de Prueba: Andrés Jiménez Ambiente de Prueba: Pre producción

Fecha: 06-09-2020 Versión: 1

Propósito:

Verificar que se puedan registrar todo tipo de productos de manera correcta haciendo uso del
formulario correspondiente y mostrar el listado de productos desde un perfil de usuario regular.

Precondiciones:

* Cuenta de usuario Inventario

* Autenticación de Usuario Inventario

Actividades

# Acciones Salida Esperada Salida Obtenida

Debe mostrar la interfaz

Dirigirse a la opción del menú y Se mostró la interfaz de
1 establecida para crear un
dar clic en "Nueva producto" registro de productos
producto

Diligenciar los campos del Se diligenció los campos del

2
formulario formulario

Se mostró el mensaje
Validar campos obligatorios en Mensaje que muestre que es
3 cuando no se llenó el
el formulario obligatorio el campo
campo obligatorio

Establecer categoría del Se estableció la categoría

4
producto del producto

Se estableció el precio
5 Establecer el precio unitario
unitario

El archivo se carga
Se adjunta la imagen y se
Adjuntar imágenes de correctamente y se muestra
6 muestra el mensaje
referencia del producto un mensaje que evidencie lo
correctamente
sucedido.

El registro se guarda en la Guarda el registro del

7 Clic en Crear producto base de datos y muestra un producto y redirige al
mensaje. listado de productos

8 Después de creado el producto Se muestra la interfaz Muestra la interfaz del

 se re direcciona al listado de
establecida para el listado de
productos creados por el listado de productos.
productos
usuario

Resultados Obtenidos

Resultados: Aprobado Severidad: No Aplica

Seguimiento: No Aplica

Tabla: Caso de prueba 1

ID de
ID Escenario producto Categoria Valor Estado Resultado esperado
Búsqueda de Visualización del
1 producto 001 confeccion 100000 activo detalle del producto
Mensaje " Producto
2 Producto no existe 001 confeccion 100000 descontinuado no Existe"
Pedido no existe y
usuario cancela la Visualización de la
3 búsqueda 001 confeccion 100000 F pantalla principal
usuario cancela la Visualización de la
4 búsqueda N/A N/A N/A N/A pantalla principal
Mensaje "Datos
Datos escasos o escasos o
5 incorrectos - 30-02-2020 100000 N/A incorrectos"
Datos escasos o
incorrectos y usuario 001 Visualización de la
6 cancela la búsqueda N/A N/A N/A pantalla principal

Nombre de Proyecto: Software para Gestión de Inventario

ID Caso de Prueba: CP-Orden de ventas-01

Autor: Andrés Jiménez Ambiente de Prueba: Pre producción

Fecha: 06-09-2020 Versión: 1

Propósito:

Validar los pedidos pendientes por facturar a través de la interfaz gráfica permitida a los usuarios
encargados de gestionar las facturas de venta

Precondiciones:

* Cuenta de usuario Ventas

* Autenticación de Usuario Ventas

 Actividades

# Acciones Salida Esperada Salida Obtenida

Debe mostrar la interfaz Se mostró la interfaz que

Dirigirse a la opción del menú y
1 establecida para el listado de muestra el listado de los
dar clic en "Listado de pedidos"
todos los pedidos pedidos.

Se debe mostrar únicamente

Filtrar el listado de pedidos por Se filtra el listado de
2 los pedidos que aún no estén
tipo "pendientes" pedidos.
facturados y contabilizados.

Debe enviar a la interfaz

El usuario debe dar clic en algún Se redirecciono a la interfaz
3 donde se detalla el cliente y
pedido pendiente correcta.
valores de los productos.

Mostrar un mensaje de Se muestra el mensaje

Dar clic en el botón de "Generar
4 confirmación de generación correcto con las opciones de
Factura"
de factura al usuario actual. "Aceptar" o "Cancelar".

Mostrar un mensaje de
Se muestra el mensaje
confirmación de correo
5 Enviar Factura al cliente correcto con las opciones de
electrónico del cliente para
"Enviar" o “Modificar".
enviar factura.

Se debe mostrar un mensaje

Se muestra el mensaje
Dar clic en el botón de de confirmación cambiar
6 correcto con las opciones de
"Contabilizar factura" estado del pedido y
"Aceptar" o "Cancelar".
contabilizar .

Resultados Obtenidos

Resultados: Aprobado Severidad: No Aplica

Seguimiento: No Aplica

Tabla: Caso de prueba 2

Fecha de
ID Escenario ID de pedido pedido Cliente Productos Resultado esperado
Búsqueda de Adornos de Visualización del
1 pedido 20200609-1 06-09-2020 Panamericana navidad detalle del pedido
Mensaje " Pedido no
2 Pedido no existe 20200609-1 06-09-2020 Panamericana F Existe"
 Pedido no existe
y usuario
cancela la Visualización de la
3 búsqueda 20200609-1 06-09-2020 Panamericana F pantalla principal
usuario cancela Visualización de la
4 la búsqueda N/A N/A N/A N/A pantalla principal
Mensaje "Datos
Datos escasos o escasos o
5 incorrectos 20200609-1 30-02-2020 - N/A incorrectos"
Datos escasos o
incorrectos y
usuario cancela 20200609-1 Visualización de la
6 la búsqueda N/A N/A N/A pantalla principal

2.3 Realice el esquema de la arquitectura de negocio del proyecto que está

realizando, como se muestra en el capítulo 13 del libro básico de estudio. Pantaleo,
G. (2015). Ingeniería de Software. Disponible en la Base de Datos de LFAOMEGA.

La empresa La Mina Adornos tiene cinco principales procesos de negocio:

1. La gestión de clientes: busca la satisfacción de los clientes y la fidelización de estos para

que compren, dando buena imagen y prestigio a la empresa.
2. Gestión de compras: compras a tiempo para satisfacer la demanda de productos en cada
sucursal de venta y en tienda virtual. Teniendo en cuenta las condiciones de cada
proveedor, cartera, temporadas y la rotación del inventario.
3. Distribución de productos: proceso de distribución y abastecimiento de productos para
cada sucursal de la empresa, según rotación de inventario y temporadas.
4. Facturación de productos y servicios: proceso de registro de factura en cada sucursal
en el sistema de facturación POS.

Como servicios principales la empresa tiene:

 1. Venta de productos y servicios en tienda física: los clientes tienen a su disposición una
gran variedad de productos para la elaboración de manualidades, confección y demás
labores afines, los cuales se pueden adquirir en mostrador, en cada una de las sucursales
de venta de la empresa La Mina Adornos.
2. Venta de productos por medios digitales: se ofrece el servicio de compra en línea, en la
tienda virtual www.lamina.com.co.
3. Despacho y envió a clientes de productos vendidos: La Mina Adornos brinda el
servicio de mensajería para envió de cada compra en la zona de Bogotá.

Aplicaciones utilizadas por La Mina Adornos:

1. Sistema de facturación POS: este software fue desarrollado por la empresa con el fin de
hacerlo a la medida. En este se registra cada venta realizada en cada sucursal.
2. Sistema para la gestión de inventarios: actualmente la empresa usa un software para la
gestión de inventario de un tercero, pero la finalidad de este proyecto es desarrollar un
nuevo sistema con todos los requerimientos de la empresa para optimizar cada uno de sus
procesos de gestión de inventario, compras, ventas y logística.
3. Sistema contable: la empresa usa el sistema de contable World Office para administrar
su contabilidad y gestión financiera.
4. Tienda virtual: la empresa tiene el servicio de comercio electrónico con el proveedor
Shopify.

A continuación de se presenta la arquitectura del negocio de La Mina Adornos, haciendo

uso del esquema SOA:

Figura 1. Esquema SOA

Fuente. Elaboración propia

CONCLUSIONES

 Se determinaron los requerimientos funcionales del proyecto.

 Se determinaron los requerimientos no funcionales
 Se Aplico conocimiento de casos de uso y casos de prueba en la práctica del proyecto
planteado
 REFERENCIAS

Cobb, Charles G. (2016). Guía para Dominar la Gestión de Proyectos Ágil. Book Summary, p1-
9. Disponible en la Base de Datos de EBSCO host.

Gómez Ruedas, Jesús (2016). Dirección y Gestión de Proyectos de Tecnologías de Información

en la Empresa. FC Editorial. Capítulo 5 páginas 141-172. Disponible en la Base de Datos
de ELIBRO.

Pantaleo, G. (2015). Ingeniería de Software. Primera Edición, Alfaomega capítulos 10, 11, 12 y
13. Disponible en la Base de Datos de ALFAOMEGA.

Axelrod, C. W. (2013). Engineering Safe and Secure Software Systems; Primera edición,
Editorial Artech House. Disponible en la Base de Datos ebrary.

Cabot Sagrera, J. (2013); Ingeniería del software. Primera edición digital, Editorial UOC.
Disponible en la Base de Datos E-Libro.

Mohapatra, P.K.J. (2010). Software Engineering. Primera edición; Editorial New Age
International. Disponible en la Base de Datos ebrary.

Pablos, Heredero, Carmen de, et al. Organización y transformación de los sistemas de

información en la empresa (4a. ed.), ESIC Editorial, 2019. Disponible en la Base de
Datos ELIBRO.
Pressman, R. (2010). Ingeniería del software. Séptima edición, McGraw-Hill Interamericana.
Disponible en la Base de Datos Ebooks 7-24.

http://www.pmoinformatica.com/2015/05/requerimientos-no-funcionales-ejemplos.html