Enrique Muñoz

Documentación de Software

UNIDAD 1: REQUERIMIENTOS Y MODELADO DE SISTEMAS

El software tiene un ciclo de vida, bueno, en realidad es el proceso de la creación de ese

software el que tiene un ciclo de vida:

● Requerimientos​: son las necesidades que tiene un cliente y que van a ser
solucionados mediante la creación de software.
● Análisis​: se estudia el requerimiento para entender qué es lo que se quiere, qué
entradas recibe y cómo debe ser el resultado que se espera.
● Diseño​: se elabora un plano base y básico sobre los pasos que debemos realizar
para lograr la solución, por ejemplo, algoritmos en pseudocódigo, diagramas de
flujo, etc.
● Implementación​: se toman los planos realizados en la etapa de diseño de la
solución y se programan en un lenguaje de programación formal. Es la etapa
donde se desarrolla el software.
● Pruebas​: el software desarrollado se somete a un proceso de pruebas para
determinar su calidad y validez.
● Puesta en Producción​: el producto de software se entrega al cliente listo para ser
puesto en uso.
● Mantenimiento​: el producto de software deberá ser monitoreado con regularidad
para control y actualizaciones.

Este proceso se solía llevar a cabo utilizando ​metodologías​ de desarrollo ​tradicionales

como por ejemplo Cascada o Espiral. El problema era que el ciclo de producción lo veían
como un proceso con un inicio y un fin pactados, es decir, el proceso debe cumplir las
etapas en una cantidad de tiempo definida, una vez iniciado el proyecto, se debía ir etapa
tras etapa hasta el “fin”.

¿Qué es lo malo de las metodologías tradicionales?

Están apegadas a un plan, un acuerdo que debe ser cumplido “a como está”.

Al tener que primero tener que cumplir todas las etapas, el cliente deberá esperar hasta el
final para recibir el producto. Si, por alguna casualidad, algo fue malinterpretado en el
análisis de requerimientos y el producto no cumplió, o si, por ejemplo, el cliente hubiese
querido hacer cambios sobre algunas ideas de su producto, este quedaría insatisfecho y
un arreglo implicaría volver a realizar todo el proceso, o sea, volver a esperar y volver a
pagar y todo el resto.
 Enrique Muñoz

Documentación de Software

Metodologías Ágiles ...

Las metodologías de desarrollo ágiles como ​Kaban​, XP (​Extreme Programming​) o

SCRUM​, como su clasificación lo indica, vinieron para agilizar el proceso de desarrollo de
software mediante entregas iterativas (ciclos de desarrollo), incrementales (en cada ciclo
un aumento), no pegados a un plan en concreto (los requerimientos pueden cambiar). En
particular, se explicará ​un poco​ (porque es un tema muy amplio) la metodología SCRUM,
para ejemplificar de qué manera funciona el ambiente en estas metodologías.

REQUERIMIENTOS

Cuando una empresa o persona deciden optar por la creación de un software para cierto
propósito, en esa decisión están involucrados varios personajes llamados ​Stakeholders​,
entre los cuales están: la persona que patrocina el proyecto económicamente, la persona
que se encarga de la parte logística, quien se encarga del estudio de mercadeo, de la
proyección y el alcance, de los recursos humanos dedicados al proyecto, de los
administradores y jefes, entre otros; los Stakeholders son de algún modo todos los
involucrados o ​interesados del proyecto​ encargados de la gestión del producto.

Se puede definir los requerimientos de la siguiente manera:

● Una​ condición o necesidad​ de un usuario para resolver un problema o alcanzar

un objetivo.​ [Std 610.12-1900, IEEE: 62]
● Una condición o ​capacidad que debe estar presente​ en un sistema o
componentes de sistema para satisfacer un contrato, estándar, especificación u
otro documento formal. ​[Std 610.12-1900, IEEE: 62]
● Un requerimiento es simplemente una declaración abstracta de alto nivel de un
servicio que debe proporcionar​ el sistema o una restricción de éste. ​[Sommerville,
2005: 108]

La ingeniería de requerimientos ayuda a los ingenieros de software a ​entender mejor el

problema​ en cuya solución trabajarán. Incluye el conjunto de tareas que conducen a
comprender cuál será el impacto del software sobre el negocio, qué es lo que el cliente
quiere y cómo interactúan los usuarios finales con el software. ​[Pressman, 2006: 155]

Los requerimientos ​funcionales ​definen las funciones que el sistema será capaz de
realizar. Describen las transformaciones del sistema: ​recibir ciertas entradas para
producir ciertas salidas​.

Los requerimientos ​no funcionales​ tienen que ver con características que de una u otra
forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio),
 Enrique Muñoz

Documentación de Software

interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo),

portabilidad, estándares, etc.

Algunas ​técnicas ​utilizadas en las actividades de definición de requerimientos de un

sistema:

● Entrevistas y cuestionarios​ a los interesados (stakeholders) o a los usuarios

finales
● A partir de ​sistemas existentes​ identificar elementos notables que puedan dar
alguna idea de la raíz de su existencia, ¿por qué ese elemento está ahí?
● Grabaciones de video y de audio​ sobre las conversaciones llevadas a cabo en
las reuniones sobre el producto en cuestión
● Brainstorming ​(tormenta de ideas) acerca de las características del producto
deseado
● Observación ​y análisis del negocio del que trata el producto
● Prototipos ​de las pantallas simulando la solución de la necesidad

Para continuar con la explicación, se necesita un sistema el cual modelar. ​OJO​ con el
siguiente enunciado de un proyecto que ​requiere​ la U:

“La U requiere una app en la que los e ​ ditores​ de las revistas de la U puedan crear
publicaciones​ hablando acerca de esas revistas y que el público pueda dejar
comentarios​ sobre esas publicaciones. Cabe mencionar que las publicaciones solamente
serán editadas por sus propios editores, o por alguna figura en calidad de ​administrador
con permisos totales. Para usar la app, los u ​ suarios​ necesitarán un correo y una
contraseña, por lo que deberán registrar una c ​ uenta.​ Cuando ingresan a la app, los
usuarios visualizarán una l​ ista​ de información r​ esumida​ de las publicaciones y al dar click
en uno de los elementos de la lista, se le mostrará una pantalla aparte con el ​detalle​ de
ese elemento (publicación), incluyendo los ​comentarios.​ Habrá una opción en la que los
usuarios deberán indicar la c ​ arrera​ a la que pertenecen, ya que, solamente los
estudiantes​ de la U podrán realizar comentarios, el público general e ​ xterno​ a la U, nada
más podrá leer las publicaciones y los comentarios (y tal vez podrá al menos dejar un
“like” o un “dislike”, pero no vamos a contar eso). Para la administración de los ​datos del
sistema​ (las cuentas, las publicaciones y los comentarios), se requiere una b ​ ase de
datos​ fácil de usar, por ejemplo, MySQL”.​

Note que el lenguaje utilizado en el enunciado anterior es un lenguaje de alguien que

conoce sobre temas de informática, posiblemente un designado de ese departamento.
Esto en la realidad no siempre es así. Un encargado de proyecto, lo que conoceremos
como ​Dueño del Producto​, simplemente transmite sus ideas sobre el producto o servicio
 Enrique Muñoz

Documentación de Software

que desea (o lo que desean los stakeholders a los cuales está representando) sin estar
obligado a conocer nada sobre informática, aunque eso es una cualidad deseable e ideal.
Las ideas que transmite un Dueño de Producto pueden ser conceptos abstractos sobre
problemas o situaciones que representan ciertos eventos en el accionar del negocio que
necesita sistematizar. Por ejemplo, el enunciado anterior pudo haber sido perfectamente
resumido en lo siguiente:

“Se necesita una app donde se publiquen temas sobre las revistas de la U para que los
estudiantes y las personas puedan ver estos temas y dejar comentarios. Se debe aplicar
algunas restricciones”.

En ese caso, si no podemos impulsar al Dueño del Producto para que suelte más
información, debemos nosotros mismos hacer el esfuerzo por inventar el resto de detalles,
por lo menos para comenzar, y después pulir esos detalles.

ENTIDADES

Una buena manera de comenzar con la documentación de un software es detectar cuáles

serán los ​principales elementos​ envueltos en el meollo ​del negocio​. Por ejemplo, en un
sistema financiero existen elementos fácilmente destacables aún y cuando nosotros no
sepamos nada de contabilidad; razonamos acerca de cuentas, clientes asociados a esas
cuentas, movimientos en las cuentas (créditos y débitos), usuarios del sistema,
administradores. En otro ejemplo, un sistema de aeropuertos tiene aviones, horarios,
destinos, tiquetes, personal, departamentos, clientes, usuarios del sistema, etc.

Para el Sistema Financiero, las entidades serían:

● Cuentas
● Clientes
● Movimientos
● Usuarios

Sistema de Aeropuerto:

● Aviones
● Horarios
● Destinos
● Tiquetes
● Etc.

Habiendo definido bien cuáles serán las entidades principales del sistema, el modelado
UML por medio de diagramas es más fácil y, por ende, el desarrollo del software se hará
más claro.
 Enrique Muñoz

Documentación de Software

Para abarcar todo el tema de UML, utilizaremos el requerimiento de la App de las revistas
de la U mencionado en la sección anterior. Es ​aconsejable ​realizar la ​definición de las
entidades del sistema​, aquellos elementos envueltos en el negocio y que están
marcadas en negrita en el párrafo del enunciado del proyecto. Tenemos ​publicaciones​,
editores​, ​comentarios​, c
​ uentas​(perfiles) y algunas otras entidades también forman parte
como las ​carreras​. Los editores usan la app para publicar y las cuentas son para que los
visitantes (estudiantes u otras personas) lean y comenten, y a eso sumemosle otra
persona que podrá administrar la app con control total, o sea, podríamos definir una sola
entidad de usuarios o definir cada una por aparte.