UNIVERSIDAD NACIONAL DE INGENIERÍA

Facultad de Ingeniería Industrial y de Sistemas

SI505V – PRIMERA PRÁCTICA CALIFICADA

INSTRUCCIONES

• Los grupos serán los mismos que se indican en el directorio del curso
• Deben considerar de forma detallada cada uno de los puntos que se especifican en la sección
Enunciado.
• El desarrollo de cada uno de esos puntos se deberá desarrollar exclusivamente contenido
propio. En caso utilicen fuentes externas, como información de Internet o documentos de
ciclos anteriores o cursos anteriores, deben citarlos como referencias y proporcionar los
documentos (o links) para poderlos consultar.
• Los entregables son los siguientes:

o Informe: Consideren un documento con las secciones mencionadas en la sección de

enunciado.
o Documentación de Soporte: Todos los documentos que sustente su informe deben
ser presentados. Ello puede incluir sus diapositivas de presentación, documentación
de la empresa, referencias bibliográficas y de trabajos pasados, videos de
entrevistas. Hay una carpeta específica en la estructura que se ha creado.
o Video Individual: La sustentación del informe debe realizarse por todos los
integrantes del grupo. Cada uno de ellos deberá grabar un video explicando con el
mayor detalle posible la parte del trabajo que le fue asignada. Se calificará a cada
estudiante en función a la calidad del entregable y la claridad de la exposición.
Algunas consideraciones:
▪ Pueden utilizar las herramientas que deseen para realizar el video.
Asegúrense de tener la cámara encendida. Pueden utilizar material
adicional. Por ejemplo, una presentación, y proyectarla en pantalla.
▪ Su video debe estar subido en Internet (no es indispensable que esté con
acceso público). Pueden utilizar Youtube, Google Drive, etc. Es
responsabilidad de los alumnos asegurarse de que su video pueda ser
accedido por el link brindado sin ningún tipo de configuración adicional o
login.
▪ Debe ser posible identificar el video de cada estudiante. En caso sea un
video subido a Youtube, el título debe contener el nombre y apellido. Para
casos en los que hayan subido archivos, el nombre del archivo debe
contener dicha información.

• Toda la información mencionada debe estar subida en Internet en una carpeta compartida
(utilicen el servicio que consideren conveniente). Deberán proveer el link correspondiente
al docente. Recuerden que el contenido debe ser accesible sin ningún tipo de login o
consideración adicional.

• La fecha límite de entrega es el día lunes 4 de octubre a las 18:00. Este vencimiento incluye
tanto al informe como los videos individuales. No se considerarán entregas posteriores a
esa hora.

1
• De forma opcional el grupo podrá, en función a la retroalimentación que reciban de la
exposición, presentar una versión mejorada del documento. Asegúrense de considerar un
documento independiente al de la presentación original. La fecha límite para las mejoras es
el día domingo 10 de octubre al mediodía (12:00).

• Durante la clase, cada grupo deberá sustentar su entregable en un tiempo máximo de 7

minutos (puede hacerlo una sola persona o varias personas según lo decidan, optimicen el
uso del tiempo). Luego de la sustentación, el docente podrá realizar preguntas sobre el
trabajo a cualquier integrante del grupo.

• La calificación final tendrá en cuenta los siguientes aspectos:

o Calidad del informe presentado.
o Sustentación grupal (en clase).
o Calidad de la sección desarrollada por el alumno en su video individual.

2
ENUNCIADO

Considere en su informe las siguientes secciones:

1. Descripción del Tema y Motivación

Debe describirse de la forma más detallada posible el tema elegido. Si el grupo ha trabajado
específicamente con una empresa, debe describirse la actividad de la empresa, los
principales productos o servicios que ofrece y algunos detalles de su estructura interna y
procesos. Asimismo, debe detallarse el proceso de negocio de su elección. En caso se haya
elegido un proceso de negocio general (P.ej.: cobranzas, logística), es necesario hacer una
descripción del mismo y un desarrollo detallado de las actividades que forman parte de ese
proceso. Para ello pueden utilizar diversas fuentes bibliográficas.
En ambos casos, se recomienda hacer uso de diagramas de flujo para poder especificar de
una mejor forma el funcionamiento de los procesos. Cada una de las actividades que formen
parte de este diagrama deberán estar documentadas, así como sus entradas y salidas.

Asimismo, consideren una sección en la que comenten la motivación del grupo por la
elección de este tema, puede ser un tema eminentemente práctico (disponibilidad de la
empresa o contactos) o un tema de interés académico, por ejemplo.

2. Requerimientos

Teniendo claridad sobre el proceso de negocio elegido es posible trabajar con los
requerimientos del sistema. En todos los casos, independientemente del tema elegido y los
sistemas de información con los que cuente la empresa en la actualidad, deben asumir que
se desarrollará un sistema desde cero para dar soporte al proceso de negocio elegido.

Un paso previo a la especificación de estos requerimientos tiene que ver con la identificación
de los usuarios que participan en el sistema. Debe mencionarlos y describirlos
detalladamente. No debe utilizar nombres de personas, tampoco cargos específicos para
identificar a los usuarios. Cada uno de ellos debe identificarse en función al rol que cumplen
en el proceso de negocio (de ahí la importancia de documentar con claridad la sección
anterior).

Su especificación de requerimientos debe considerar la clasificación brindada en el curso

desde la perspectiva de Arquitectura: requerimientos funcionales, requerimientos de
atributos de calidad y restricciones (de existir). Por ello, por cada usuario debe identificar
aspectos relevantes a nivel de requerimientos, por ejemplo:

• ¿Qué opciones debería tener el usuario en el sistema? Piense, por ejemplo, en el

menú de opciones con que contará dicho usuario (perfil).
• ¿Qué actividades se desarrollarán para cada una de estas opciones?. Aquí es
recomendable que utilicen el formato de especificación de casos de uso planteado
en clase. Debe especificarse con claridad

3
 • ¿El usuario tiene requerimientos especiales en cuanto atributos de calidad? Por
ejemplo, podríamos tener usuarios con requerimientos especiales a nivel de
rendimiento (ejecución más rápida). También es posible que existan procesos
periódicos en función a ciclos de negocio (procesos batch). Podría ser, por ejemplo,
cálculo de intereses de préstamos, facturación de servicios, etc. ¿Existen
requerimientos especiales para estos procesos?

3. Módulos

Consideren una descripción básica de módulos para este primer entregable. Recuerden que
el objetivo principal es encontrar una estructura óptima de forma que su software pueda
cumplir con sus requerimientos de atributos de calidad.
Recuerden también primera estructura de módulos puede encontrarse descomponiendo la
aplicación por funciones (para ello es necesario conocer el proceso de negocio y los
requerimientos en detalle, de ahí la importancia de las secciones anteriores. En algunos
casos, ya se tiene una versión de modelamiento conceptual del caso. En ese contexto,
también es posible llegar a una modularización inicial agrupando entidades relacionadas.
Esta división del sistema debe tomar en cuenta esquemas de interacción con el usuario en
tiempo real y también algunos procesos batch que podrían ser requeridos (más detalles en
la sección anterior).

Debe representar esta estructura de forma gráfica. Puede utilizar un diagrama simple de
bloques, un diagrama de paquetes en UML u otra alternativa similar. Considere en esta
primera versión, posibles interacciones entre los módulos (las puede representar utilizando
flechas).

Cada uno de los módulos debe estar documentado tomando en cuenta (como mínimo) los
siguientes aspectos:

• Nombre del módulo.

• Responsabilidades.
• Interacciones con otros Módulos.

Extra: De forma adicional, pueden trabajar con la documentación de otros aspectos de la

arquitectura. Pueden, por ejemplo, utilizar diagramas UML. Una referencia que pueden
trabajar es el Modelo 4 + 1 de Kruchten. Aquí algunas referencias:

Kruchten’s 4 + 1 views of Software Design | by Puneet Sapra | The Mighty Programmer |

Medium

Architectural Blueprints—The “4+1” View Model of Software Architecture (ubc.ca)

4. Prototipo

Con la especificación detallada a nivel de requerimientos, es posible realizar la especificación

de las pantallas que tendría el sistema.

4
Por cada una de ellas es necesario documentar lo siguiente:

• Requerimiento asociado (asegúrese de tenerlos documentados, de forma que sea

sencillo el mapeo).
• Imagen de la interfaz. Considere tanto el flujo principal como los posibles flujos
alternativos.
• Principales entidades de su modelamiento conceptual que estarían participando.
Ello nos dará una idea de las tablas de base de datos que estaríamos
• Algunas notas en función a rendimiento o carga del proceso. Documente sus
primeras impresiones relacionadas a temas como los siguientes:
o ¿Existe alguna consideración especial en cuanto a rendimiento? Por
ejemplo, en sistemas que llegan a usuario final, un bajo rendimiento puede
tener como consecuencia la pérdida de una venta.
o ¿El volumen de información con el que trata la opción del sistema es
significativo? En esos casos, por ejemplo, podríamos tener procesos batch
que permitan optimizar estas consultas (¿hemos considerado ello en
nuestros módulos?).

Los requerimientos deben ser complementados con imágenes (mockups) de la interfaz de

usuario (pantallas - páginas). Para ello se recomienda utilizar alguna de las siguientes
herramientas:

• Figma: https://www.figma.com/
• Balsamiq Wireframes: https://balsamiq.com/wireframes/
• Adobe XD: https://www.adobe.com/la/products/xd.html