MÓDULO 7

CICLO DE VIDA DE SISTEMAS.

METODOLOGÍAS DE DESARROLLO.

Introducción a la Tecnología de la Información

y las Comunicaciones

Curso Virtual - Cátedra: Cecilia Oriolo

Octubre 2019
 Módulo 7 – Ciclo de vida de sistemas. Metodologías de desarrollo.

Conocemos la importancia de los sistemas de información para las

organizaciones, así como de que los mismos estén alineados con las necesidades
de la organización, tanto desde un punto de vista estratégico como a nivel
operativo.
Es por esto que resulta indispensable que la adquisición o desarrollo de los
sistemas esté bien planificada y gestionada, y para ello es necesario que todos los
actores, incluyendo a quienes toman las decisiones, conozcan las etapas y
actividades que implica. Sólo de esta manera podremos evaluar los tiempos,
costos y recursos necesarios, así como el impacto de solicitar modificaciones en
cada momento.

La situación que se plantea en la tira de la página siguiente es extremadamente

común en organizaciones de diferente tipo y tamaño, por lo que, como
profesionales de sistemas tenemos la responsabilidad de entender y poder
transmitirle a todas las áreas involucradas lo que necesitamos para que el
desarrollo del sistema sea posible, y sea exitoso.

Si bien la introducción de un nuevo sistema de información implica muchas

actividades como la modificación de procesos, la comunicación a los afectados,
etc., en este módulo nos vamos a enfocar en lo que refiere específicamente al
desarrollo, ya sea para modificar un sistema existente o para crear uno nuevo.

​1
Módulo 7 – Ciclo de vida de sistemas. Metodologías de desarrollo.

Fuente: http://www.softqatest.net/?p=667

​2
 Módulo 7 – Ciclo de vida de sistemas. Metodologías de desarrollo.

Ciclo de vida
Más allá del tipo de sistema que la organización requiera implementar, ya sea que
se elija adquirir un software ya desarrollado o realizar un desarrollo a medida,
cualquier proyecto de implementación requiere de una serie de etapas básicas. A
ese conjunto de etapas se lo llama ​ciclo de vida​.
En el caso del desarrollo de aplicaciones, el ciclo de vida incluye los pasos
necesarios para construirlo y para ponerlo en funcionamiento. Entender los pasos
que requiere construir un sistema es necesario, en primer lugar, para dimensionar
la complejidad del proceso: construir un sistema a medida, no implica sólo la
participación de un programador que construya el sistema, sino que requiere
etapas previas, de definición detallada de los requerimientos según las
necesidades del negocio, y etapas posteriores, en las que se debe verificar que el
sistema realice lo solicitado, corregir los errores encontrados (que existen en todo
proyecto), capacitar a los usuarios, y realizar diferentes tareas que permitan la
adaptación de la organización a los nuevos procesos y al sistema.
Comprender cada una de estas etapas permite poder realizar una mejor
planificación del proyecto, o evaluar las propuestas presentadas por los
proveedores, conociendo los diferentes roles que deben estar involucrados, así
como los productos que se deben entregar en cada momento.
La cantidad y denominación de las etapas puede variar según los autores, pero
básicamente son las que muestra la siguiente figura:

​3
 Módulo 7 – Ciclo de vida de sistemas. Metodologías de desarrollo.

Análisis de requerimientos
Cuando una organización decide implementar una solución con tecnología tiene
como objetivo final cubrir determinadas necesidades del negocio. Es primordial
no perder de vista este punto en cada etapa del proyecto, para garantizar su éxito.

Dentro de la etapa de análisis y diseño de la solución, una actividad fundamental

es identificar cuáles son los requerimientos de la organización. Como plantea
1
Gómez Fuentes ​ “​Los requerimientos especifican qué es lo que el sistema debe
hacer (sus funciones) y sus propiedades esenciales y deseables. La captura de
los requerimientos tiene como objetivo principal la comprensión de lo que los
clientes y los usuarios esperan que haga el sistema. U​ n requerimiento expresa el
propósito del sistema sin considerar cómo se va a implantar.​ ” “​El análisis de
requerimientos proporciona una vía para que los clientes y lo desarrolladores
lleguen a un ​acuerdo sobre lo que debe hacer el sistema​. La especificación,
producto de este análisis proporciona las pautas a seguir a los diseñadores del
sistema.​”

Ya sea que decidamos comprar un software ‘enlatado’ o desarrollar uno a medida

(en forma interna o tercerizada), el primer paso es definir en detalle cuáles son las
características que el sistema deberá tener para cubrir las necesidades
planteadas.

¿Quiénes participan?
Uno de los principales participantes en esta etapa es el ​analista funcional​, quien
cumple el rol de mediador entre las áreas de negocio, que requieren el sistema, y
las áreas técnicas, encargadas de construirlo. El analista funcional es el encargado
de relevar e interpretar las necesidades de la organización, y de documentarlas de
manera que puedan ser utilizadas para diseñar y construir el sistema
correctamente. Debido a su función, debe tener habilidades de comunicación,
conocimiento de los procesos de negocio y conocimientos técnicos acerca de la
construcción del software.

Pero el analista funcional no puede (o no debe) definir los requisitos de acuerdo a

su idea del mismo, sino que debe considerar las necesidades de las personas
relacionadas en forma directa o indirecta con el sistema: usuarios finales y sus
jefes o supervisores, áreas que utilizarán la información o que verán afectados sus
procesos por el uso del sistema, directivos, áreas técnicas que se ocupan de dar
mantenimiento a la infraestructura tecnológica, etc. Todas estas personas, que
tienen intereses diversos y que pueden influir en la creación o el uso del nuevo

1
Gómez Fuentes, Maria del Carmen. Notas del curso: análisis de requerimientos. UNIVERSIDAD
AUTONOMA METROPOLITANA. 2001.
http://www.cua.uam.mx/pdfs/conoce/libroselec/Notas_Analisis_Requerimiento.pdf

​4
 Módulo 7 – Ciclo de vida de sistemas. Metodologías de desarrollo.

sistema, son llamadas ​stakeholders​, y deben ser consideradas a la hora de definir

los requerimientos. Como no es viable que el analista revise todos los aspectos
con cada una de estas personas, y para facilitar y organizar la comunicación, se
seleccionan personas referentes, que conocen en detalle los procesos y posibles
necesidades de la organización, llamados ​usuarios clave​. El rol de los usuarios
clave es importantísimo en la construcción del sistema ya que además de ser los
principales conocedores del negocio, serán los encargados de verificar que los
requerimientos sean correctos y completos y, una vez desarrollado el sistema,
son los responsables finales de validar que el sistema cumple con lo requerido.

¿Qué tareas implica?

Para definir los requerimientos del sistema, el analista realiza entrevistas con los
usuarios clave y otros involucrados, en las cuales busca comprender el contexto
de la organización y las necesidades propias de cada área. Es normal que los
usuarios clave, no siempre logren traducir en palabras todo lo que esperan de la
aplicación, por lo cual el analista debe guiarlos en la definición, preguntando
acerca de aspectos específicos, escuchando atentamente para identificar
necesidades o dudas no expresadas, solicitando información a otras áreas,
contrastando pedidos de otros usuarios clave y proponiendo ideas de acuerdo a
su experiencia y conocimientos.

Para facilitar la comunicación de las ideas, el analista se vale de diferentes

herramientas para el modelado y representación de distintos aspectos del
sistema, por ejemplo, casos de uso, que focalizan en las acciones que los usuarios
podrán realizar y los pasos a seguir en cada una, o bocetos de pantallas y
prototipos, que permiten al usuario clave imaginar cómo será la interfaz del
sistema de manera que surjan nuevas ideas y correcciones.

Finalmente, el analista construye un documento llamado Especificación de

requerimientos en el cual se vuelca toda la información recolectada y los modelos
definidos, de manera organizada y entendible, para ser utilizados en el diseño del
sistema. La especificación del sistema debe incluir tanto las funciones y
comportamientos, como las restricciones del sistema.

Análisis de requerimientos
Vean las diapositivas 1 a 39 de la siguiente presentación para entender un poco
más acerca del tema:

https://es.slideshare.net/SergioRios/unidad-13-analisis-de-requerimientos

La etapa de análisis implica identificar los requisitos que tendrán los interesados
en el sistema, validarlos junto con ellos y documentarlos para ser utilizados en las

​5
 Módulo 7 – Ciclo de vida de sistemas. Metodologías de desarrollo.

etapas posteriores. A pesar de que aparenta ser una tarea sencilla, esta etapa es
compleja y de vital importancia por varios motivos:

● Es la base para el diseño y desarrollo (o configuración) del software. En

esta etapa se define qué es lo que deberá hacer el sistema, y en base a eso
se realizan las estimaciones de tiempo, recursos y, por lo tanto, costos.
Las características que no se hayan considerado en esta etapa no serán
contempladas por el sistema, o bien, implicarán cambios posteriores que
pueden tener un impacto alto en los tiempos y costos de implementación.
● Es un proceso complejo en el cual el componente humano juega un papel
importante. No debemos olvidar que esta etapa tiene un contenido muy
alto de comunicación y, por consiguiente, es muy común que exista
ambigüedad en los mensajes, problemas de interpretación y falta de
información (por diversas causas). Los analistas deben sortear estas
complejidades, definiendo los requerimientos con el mayor detalle y
claridad posible.
● La cantidad de requerimientos suele ser muy grande y variada, lo que
requiere priorizarlos y filtrar aquellos que tengan bajo o nulo impacto en el
negocio y/o que permitan ser incluidos en etapas posteriores.
● Costos: un correcto análisis reduce la posibilidad de que surjan costos
inesperados a lo largo del proceso de desarrollo e implementación del
sistema. Diversos estudios coinciden en el hecho de que corregir errores
en esta etapa implica costos mucho menores que su detección y
corrección en fases más avanzadas. Esto se da principalmente porque al
detectar un error, es necesario retomar las etapas anteriores para
corregirlo, por ejemplo, si durante las pruebas se detecta una funcionalidad
faltante, se necesita volver a analizar las características requeridas por esa
funcionalidad y su relación e impacto en otras partes del sistema; luego se
debe rediseñar y desarrollar el faltante, y finalmente volver a realizar las
pruebas completas. Todo esto requerirá nuevos tiempos y recursos, lo que
incrementa los costos finales, incluso poniendo en juego el éxito del
proyecto.

Diseño
Una vez identificados en detalle los requerimientos de los diferentes involucrados,
podemos comenzar a definir ​cómo ​vamos a darles solución: cómo van a ser las
pantallas definitivas, cómo estarán organizadas las funcionalidades, qué roles de
usuarios existirán y qué permisos tendrá cada uno, qué datos se usarán, cómo se
obtendrán y cómo estarán estructurados.

En esta etapa el analista funcional, utilizará diferentes herramientas para

representar el funcionamiento del sistema con foco en distintos aspectos, algo así

​6
 Módulo 7 – Ciclo de vida de sistemas. Metodologías de desarrollo.

como los “planos del sistema”. Entre esas herramientas, podemos encontrar, por
ejemplo, el diagrama de entidad-relación, que mencionamos en el módulo de
bases de datos, que permite representar los datos que almacenará el sistema y la
relación entre las entidades que agrupan dichos datos. También se puede
profundizar en los casos de uso, o utilizar diagramas de flujo de datos, que se
enfocan en la “circulación” de los datos entre diferentes partes del sistema.

En esta etapa, el analista podrá reunirse con el equipo que desarrollará el sistema,
para evaluar técnicamente las alternativas de solución y definir la más
conveniente o factible, y también trabajará junto con los usuarios clave,
presentándole los documentos de diseño de menor detalle técnico, para su
validación. Es probable que, con un diseño más concreto y detallado, surjan
nuevas dudas, requerimientos o correcciones, que retroalimentan la definición del
sistema.

Los documentos generados en esta etapa son muy importantes ya que, por un
lado, serán la base sobre la que se realizará el desarrollo, es decir, todo lo que no
esté incluido en ellos, puede omitirse e implicar cambios y correcciones futuros,
con el correspondiente impacto en tiempos y costos.

Por otro lado, serán útiles a futuro ya que evidencian el acuerdo con los usuarios
acerca de la solución y serán la base sobre la cual analizar posibles
modificaciones en el sistema.

Desarrollo
En esta etapa se construye el sistema propiamente dicho: se escribe el código
fuente, se crean las tablas u objetos en las bases de datos, se configura el
hardware y software de sistema necesarios, etc.

Los principales actores de esta etapa son los arquitectos y desarrolladores de

software, junto con el apoyo de áreas de infraestructura tecnológica (para la
configuración de bases de datos, servidores, etc..) y de los analistas funcionales
(para consultar dudas y definir situaciones que puedan surgir).

Además de escribir el código una responsabilidad importante es documentarlo,

con el objetivo de explicar aquellas cosas que no resulten evidentes o claras a
partir de la lectura del propio código, tanto para otros desarrolladores como para
sí mismo como referencia a futuro, en caso de que se requiera modificar el
sistema. La documentación del código, suele hacerse con comentarios dentro del
mismo código fuente (algo así como los comentarios de Word…) y dan una idea
de para qué se escribió determinada porción de código o por qué se hizo de
determinada manera.

​7
 Módulo 7 – Ciclo de vida de sistemas. Metodologías de desarrollo.

Pruebas
Una vez diseñado y desarrollado el sistema, es necesario verificar que el producto
satisface las necesidades del negocio que se plantearon al inicio del ciclo. Existen
distintos tipos de pruebas:

● Pruebas unitarias​: son las que realiza el desarrollador durante la

construcción, con el objetivo de verificar que cada parte del sistema, por
separado, funciona según lo esperado.
● Pruebas de sistema: ​son realizadas por testers, y también por analistas
funcionales. Su objetivo principal​ es encontrar errores antes de la
implementación​, y de este modo brindar mayor calidad al producto final.
Para esto tomarán los requerimientos y definiciones originales, y
verificarán si el sistema cumple con cada uno de ellos, y buscarán fallas en
el funcionamiento, tanto en los circuitos normales como en aquellos que
sean excepcionales o ante posibles errores por parte de los usuarios.
● Pruebas de aceptación​: también conocidas como UAT (User Acceptance
Test), estas pruebas son realizadas por los usuarios clave. Son pruebas
funcionales sobre el sistema completo, y tienen como objetivo verificar
que el mismo satisface las necesidades del usuario. En esta instancia será
importante distinguir errores, que corresponden a diferencias con la
definición original, de los pedidos de cambio o mejoras, relacionadas con
nuevas necesidades planteadas por el usuario y no expresadas en los
requerimientos originales. En este segundo caso, deberá definirse qué
cambios son requeridos para una primera versión del sistema, y cuáles se
podrían incorporar en futuras etapas para no retrasar los tiempos del
proyecto.

Todas los tipos de prueba tienen el objetivo de minimizar los errores que
aparecen durante el uso del sistema, los cuales tienen un mayor costo de
corrección. Es por esto que las pruebas probablemente impliquen la necesidad de
correcciones, iniciando nuevamente ciclos pequeños (o no tanto) de
análisis-diseño-desarrollo.

Para la realización de pruebas de sistema, los testers (o QC - Quality Control)

utilizarán diferentes herramientas, pero la principal son los casos de prueba, en los
cuales se detalla cada prueba a realizar, contemplando cuál debería ser el
resultado esperado y, luego, cuál fue el resultado obtenido.

Al finalizar el proceso, se realiza un informe de pruebas, en el que se detallan los

errores encontrados, su importancia (si impiden el funcionamiento del sistema, si
son mejoras, etc.). También suelen incluirse indicadores sobre la calidad del

​8
 Módulo 7 – Ciclo de vida de sistemas. Metodologías de desarrollo.

sistema (por ejemplo, % de casos de prueba exitosos/erróneos) para determinar

la conveniencia de implementarlo o no.

Ambientes de trabajo
Llamamos ambientes o entornos a diferentes instalaciones de la aplicación
(incluyendo hardware y software) creados para diferentes propósitos a lo largo
del ciclo de vida de desarrollo.

Si bien la cantidad de ambientes dependerá del tamaño y grado de madurez de

cada área de sistemas, así como de la complejidad de los mismos, es común
identificar 3 ambientes principales:

El ​ambiente de Desarrollo ​es el lugar donde se codificará el sistema. Es donde se

traduce a código lo que diseñó el arquitecto y el analista funcional. A este
ambiente acceden principalmente los desarrolladores, ya que son los
responsables por el código con el que se está trabajando. En este ambiente el
desarrollador codificará y hará las pruebas unitarias que sean necesarias.

El ​ambiente de​ ​Pruebas​, también conocido como ambiente de Calidad o de

Testing, es un entorno en donde se harán las pruebas integrales y de usuario, para
detectar posibles errores y por último aprobar la solución final. En el ambiente de
pruebas tienen acceso tanto el desarrollador (que es quien pasa el código desde
el ambiente de desarrollo hacia el ambiente de pruebas, lo que se conoce como
implementar o “deployar”), como el analista funcional y el usuario clave, que son
quienes participarán en las pruebas integrales y de usuario).

El ​ambiente de Producción​, es el entorno donde operan los usuarios finales una

vez finalizado todo el proceso de desarrollo y donde se registran los datos y se
obtienen reportes para el funcionamiento de la organización. Las
implementaciones o “deploys” en este entorno no deben ser realizadas por
analistas funcionales ni por desarrolladores, para mantener la confidencialidad de
los datos y la integridad del sistema (al evitar que se estén haciendo
modificaciones no controladas). Es por esto que suele realizarlos un área
diferente, comúnmente llamada “operaciones” o “centro de procesamiento de
datos”, que es la responsable del correcto funcionamiento y monitoreo de este
entorno.

¿Por qué necesitamos diferentes ambientes?

Por un lado es importante para mantener seguros los datos de la organización. En
el ambiente de producción se tiene acceso a la información real de la actividad de
la empresa (por ejemplo información de ventas, estados contables, registro de
empleados, de clientes, etc.). Es información sensible y en su mayoría confidencial
que hay que cuidar y resguardar. Si el desarrollo y/o las pruebas se hicieran

​9
 Módulo 7 – Ciclo de vida de sistemas. Metodologías de desarrollo.

directamente en el ambiente de producción, se pondría en riesgo la integridad de

la información y los datos de la compañía y estarían teniendo acceso a
información confidencial personas que no deberían tenerlo. Es por esto que es
fundamental la separación de ambientes.

Por otro lado, la separación de los ambientes de testing y desarrollo permite el

desarrollador pueda avanzar en cambios o correcciones, sin afectar lo que está
probando el tester o el usuario. Adicionalmente permite que las pruebas se
realicen con una aplicación lo más parecida posible al entorno donde finalmente
trabajarán los usuarios (Ambiente de Producción); el ambiente de desarrollo
generalmente tiene distinta capacidad al de producción, por lo que la solución
puede que no responda de la misma manera o no tenga el mismo rendimiento.

Metodologías de desarrollo
Existen distintas metodologías para encarar el desarrollo de un sistema de
información (más allá de quién lo desarrolle, sea In-house o tercerizado), todas se
basan en las mismas etapas generales (que vimos previamente) y las adaptan
según el objetivo de cada una:

Las principales metodologías son:

- Por Etapas​: su objetivo es cumplir las etapas de forma secuencial.

- En cascada​: su objetivo es reducir riesgos, incorporando prototipos y
retroalimentación para no llega al fin del desarrollo sin detectar posibles
errores.
- En espiral​: es una evolución del modelo en cascada buscando. Cada nueva
versión progresiva mejora la anterior, buscando reducir riesgos de
modificaciones. Puede incluir el uso de prototipos e incorpora tareas
paralelas y por módulos.
- Incrementales​: destaca la segmentación del sistema en sub-sistemas o
módulos más pequeños que puedan ser puestos en marcha en forma
independiente y que sean de utilidad para el negocio.
- Ágiles​: proponen la realización de desarrollos cortos con alta participación
del usuario clave, poca planificación y con implementación inmediata.

Los diferentes modelos se describen en detalle en la bibliografía obligatoria.

Bibliografía
Pressman, Roger. Ingeniería de Software. 7ma Edición. McGraw Hill. ISBN
978-607-15-0314-5

​10