Módulo 1.

Fundamentos de análisis de
sistemas y desarrollo del software

Introducción
Antes de meternos de lleno en el mundo de los sistemas de información, debemos tener
presentes algunos conceptos esenciales, que nos ayudarán a entender mejor los puntos que
vamos a tratar.

Comencemos con el concepto de información, podemos decir que se trata de un conjunto de

datos organizados, ya sean números, letras, imágenes, sonidos, etc., que dan el significado a
algo. 

Veamos un ejemplo: tu número del Documento Nacional de Identidad (DNI), tu nombre y apellido
y una foto tuya, son datos que, organizados, aportarán información o datos acerca de tu
identidad.

Para poder llevar a cabo este proceso de “dar significado” a ese conjunto de datos, existen ciertos
componentes que lo hacen posible. A continuación, los describimos.

Componente físico: “está formado por todos los aparatos electrónicos y mecánicos que
realizan los cálculos y el manejo de la información” (Junta de Andalucía, s.f.,
https://bit.ly/3Ja5K4y). 

Componente lógico: “se trata de información que se ingresa de las aplicaciones, y que los
componentes físicos trabajan para lograr emitir una salida, ya sea imagen, datos, etc.”
(Junta de Andalucía, s.f., https://bit.ly/3Ja5K4y).
 Componente humano: “está compuesto por los usuarios que trabajan con los equipos
como por aquellos que elaboran las aplicaciones” (Junta de Andalucía, s.f.,
https://bit.ly/3Ja5K4y), ya sea desarrollando los software informáticos o ingresando la
información para realizar sus operaciones. 

Estos procesos se realizan mediados por un ordenador o PC, que están compuestas por dos
partes bien diferenciadas. 

Hardware: son todos aquellos componentes físicos del ordenador, es decir, todo lo
que se puede ver y tocar, ya sea teclados, mouse, memorias, disco rígido.

Software: son las instrucciones que la PC necesita para funcionar, no existen

físicamente, pero son las aplicaciones donde llevamos a diario nuestro trabajo.
(Junta de Andalucía, s.f., https://bit.ly/3Ja5K4y).

¿Cómo funciona un ordenador?

La unidad de información más pequeña con la que puede trabajar una PC es el bit, cuyo
valor será 0 o 1. Para representar un único carácter, como puede ser una letra o un
número, el ordenador utiliza una secuencia de 8 bits denominada byte: 10101100. (Junta
de Andalucía, s.f., https://bit.ly/3Ja5K4y).
Para expresar la capacidad de almacenamiento de un ordenador se utilizan unidades mayores al
byte, como las siguientes.
Figura 1: Capacidad de almacenamiento de un ordenador

Fuente: Junta de Andalucía, s.f., https://bit.ly/3Ja5K4y 

Una PC acepta datos a través de medios externos de entrada (teclado, mouse, etc.) y que una
vez ingresados debe procesarlos en forma automática, utilizando software o aplicaciones
(procesador de textos, programa de cálculos, entre otros) para luego mostrar ese resultado por
algún medio de salida (pantalla, impresora, etc.). 

Este proceso es lo que, a lo largo de esta materia, conoceremos como sistema informático, “un
conjunto de elementos que hace posible el tratamiento automático de la información” (Junta de
Andalucía, s.f., https://bit.ly/3Ja5K4y), mediante un microprocesador y con intervención de un
analista de sistemas.

Es por ello por lo que, a lo largo de este módulo, nos introduciremos en estos conceptos
fundamentales para reconocer la importancia del ciclo de vida de un sistema de información
dentro de una organización.

Video de inmersión
Unidad 1. Los sistemas y las tecnologías de la
información en las empresas
Tema 1. Qué es un sistema
Como primera alternativa, debemos conocer que un sistema es “un conjunto de elementos o
componentes que interaccionan para alcanzar un objetivo. Los elementos por sí mismos y las
relaciones entre ellos determinan cómo funciona el sistema” (García, s.f., https://bit.ly/3CH9JU2). 

Veamos la imagen a continuación. Esta muestra un proceso en el que existe un ingreso

(información que se carga), un proceso donde se realizan los mecanismos (aplicación donde se
realiza la acción) y una salida (muestra de la información). En todo proceso existe la
retroalimentación constante.
Figura 2: Proceso

Fuente: García, s.f., https://bit.ly/3CH9JU2

Ahora estamos en condiciones de ir más allá con las definiciones y hablar de qué es un sistema
de información. Decimos, entonces, que:
 Un sistema de información es un conjunto de elementos o componentes interrelacionados
que recaban (entrada), manipulan (proceso), almacenan y distribuyen (salida) datos e
información y proporciona una reacción correctiva (mecanismo de retroalimentación) si no
se ha logrado cumplir un objetivo. (García, s.f., https://bit.ly/3CH9JU2) 
Un ejemplo clásico de sistema informático sería una o varias computadoras, junto con la persona
que lo maneja, los programas que contiene y los periféricos que los envuelven (impresora,
teclado, altavoces). 

Los sistemas de información están compuestos por cuatro grandes procesos, como los que
observamos en la figura 1 (gráfico del lavadero de autos). Vamos, entonces, a describir qué se
hace en cada uno de los procesos.

Figura 3: Procesos de los sistemas de información

Fuente: elaboración propia 

La entrada se define como “la actividad consistente en recolectar, captura o relevar la

información con la que vamos a estar trabajando” (García, s.f., https://bit.ly/3CH9JU2). 

Procesamiento es la transformación de datos en la muestra de la información que nosotros

queremos visualizar. En este proceso se pueden realizar diferentes acciones “como cálculos,
comparación de datos, toma de acciones alternas y almacenamiento de la información” (García,
s.f., https://bit.ly/3CH9JU2).

La salida es el proceso que muestra los resultados de lo que se llevó a cabo en la etapa de
procesamiento, que puede involucrar vista “por lo general en la forma de documentos, muestras
por pantalla o reportes” (García, s.f., https://bit.ly/3CH9JU2).

La retroalimentación es el proceso por el cual se analizan las actividades mencionadas

anteriormente y “se realizan los cambios para mejorar los procesos que fueron requeridos”
(García, s.f., https://bit.ly/3CH9JU2).

A partir de estos conceptos, vamos a hablar de los sistemas de información basados en

computadoras (CBIS, computer based information system), que es “el conjunto único de
hardware, software, bases de datos, telecomunicaciones, personas y procedimientos configurado
para recolectar, manipular, almacenar y procesar datos con el fin de convertirlos en información”
(García, s.f., https://bit.ly/3CH9JU2).

Figura 4: Procesos en los sistemas de información 

Fuente: elaboración propia

Es el proceso mediante el cual el sistema de información toma los datos que requiere para
procesar.
Es la capacidad del sistema de información para efectuar cálculos de acuerdo con una
secuencia de operaciones preestablecida.
El almacenamiento es una de las actividades o capacidades más importantes que tiene una
computadora, ya que a través de esta propiedad el sistema puede recordar la información
guardada en la sección o proceso anterior.
La salida es la capacidad de un sistema de información para sacar la información procesada
o bien datos de entrada al exterior.

Tema 2: Teoría general de sistemas. Sistemas de información

“La Teoría General de Sistemas (TGS) fue concebida por Ludwig von Bertalanffy en la década
de 1940 con el fin de proporcionar un marco teórico y práctico a las ciencias naturales y sociales”
(Román, 2011, https://bit.ly/36bJDfy). 

El enfoque de la teoría general de sistemas es una metodología basada en el análisis del estudio
interdisciplinario de los sistemas en general, tomados de manera global, para estudiar cómo
interactúan, cómo están constituidos, cómo se comunican entre sus propios elementos y con los
de otros sistemas.

Para aplicar los conceptos fundamentales de la teoría, se deben definir marcos de referencia, los
cuales vamos a describir a continuación.
El Primer Marco de referencia consiste en construir un modelo teórico que represente a
fenómenos generales que se encuentren en diferentes disciplinas. De hecho, busca en
 esencia reducir los sistemas concebibles a un número manejable. Por ejemplo, en todas
las áreas del saber humano se encuentran poblaciones de individuos, la idea es generar
un modelo que sea aplicable y válido en las diferentes disciplinas que tengan que ver con
poblaciones. Este primer marco de referencia presenta un objetivo de baja ambición, pero
con alto grado de confianza, al descubrir similitudes en las construcciones teóricas de las
diferentes disciplinas del saber y al desarrollar métodos teóricos aplicables por lo menos a
dos áreas de estudio del saber y al desarrollar métodos teóricos aplicables por lo menos a
dos áreas de estudio. 

El Segundo Marco de referencia consiste en ordenar jerárquicamente las disciplinas del

saber en relación con la complejidad organizacional de sus componentes en un nivel de
abstracción apropiado. Este segundo marco de referencia, presenta un objetivo de alto
grado de ambición y bajo de confianza, al desarrollar un conjunto de teorías interactuantes
o Sistema de Sistemas en áreas particulares del conocimiento humano, orientando la
investigación a llenar vacíos existentes. (Hurtado Carmona, 2010, p. 4) 

En la teoría general de sistemas existe lo que conocemos como la “información”, y a esto lo

llamamos teoría de las informaciones, que es la ciencia que se encarga de estudiar el manejo que
se le da a la información, para poder contribuir en la organización y cumplimiento de los objetivos
de cada uno de los sistemas con el que interactúa.

Si tomamos, como ejemplo, un sistema de información contable, en el caso de que el gobierno

haya decretado nuevas leyes que modifican las metodologías del pago de los impuestos, esta
información debe ser manejada adecuadamente con el fin de mantener “vivo” el sistema.

O este otro ejemplo: si en un almacén el ingreso de dinero no es el esperado, podemos pensar

que el problema es financiero, entonces, puede haber varias ramas que afecten este problema y
debemos saber cómo solucionarlo. Debemos ver los distintos rangos que lo complementan, como
clientes, empleados, mercancía. Para ello nos planteamos un plan de desarrollo y, como primer
objetivo, tenemos identificar de qué área viene el problema. Si la gente no se siente bien
atendida, si no va a comprar por algo en particular, o si hay pocos empleados para la cantidad de
clientes que ingresan, o tal vez el problema está en la mercancía, que no es de alta calidad. Estas
pueden ser algunas de las razones que pueden constituir el problema. Y teniendo en cuenta esto,
ya podemos empezar a buscar alguna solución a cada una de las dificultades que aparecieron. 

Este ejemplo es una breve explicación de que un analista de sistemas puede resolver un
problema, partiendo de lo general a algo específico.

Ahora que conocemos la finalidad de la teoría general de los sistemas, veamos el siguiente
mapa.

Figura 5: Teoría general de los sistemas

Fuente: Gutiérrez Gómez, 2013, https://bit.ly/3i17gdo

Características de los sistemas

Bertalanffy (1970) había definido que el sistema es un conjunto de procesos relacionados entre
sí. De allí salen dos conceptos fundamentales que son el propósito (u objetivo) y el globalismo (o
totalidad).

Propósito u objetivo: todo sistema tiene uno o algunos propósitos. Los elementos
(u objetos), como también las relaciones, establecen una distribución que trata
siempre de alcanzar un objetivo.
Globalismo o totalidad: un cambio en uno de los procesos del sistema, con
probabilidad producirá cambios en los otros. (Sesento García, 2008,
https://bit.ly/3vWk7pw) 

Conceptos relacionados con el análisis del sistema 

Como primer enfoque debemos conocer que existen “elementos” de un sistema, que son las
partes o componentes que lo conforman. Estos pueden ser imágenes, textos, aplicaciones
multimedia; si se logran identificar y organizarse, se llaman modelos.

Como segundo enfoque debemos conocer los “atributos” que son las características, estructuras
y funciones de los elementos de un sistema. 

Como tercer enfoque, tenemos los “modelos” que son representaciones por medio de
abstracciones o de gráficos, pero que enfocan ciertas partes importantes de un sistema. En
informática es muy utilizado el lenguaje de modelado unificado (UML) utilizado para especificar,
visualización, construcción y documentación de una estructura o proceso y su comportamiento.

Como cuarto enfoque hablamos de “subsistema”, que es un conjunto de elementos

interrelacionados que pertenecen a un sistema mayor. Como ejemplo podemos tomar “un sistema
de gestión”, que está constituido por subsistemas como el financiero, administrativo, de
inventarios, etc.

Como quinto enfoque, las “estructuras”, que hacen referencia a la articulación u organización, son
parte del orden que se le da dentro de la aplicación, pueden ser referidas a la programación o al
proceso, como también la base de datos.

Una estructura es una forma de sistematizar un conjunto de datos con el propósito de trabajar en
forma controlada y que la gestión sea mucho más simple. En el mundo de los lenguajes de
programación son las que nos permiten modificar, alterar los procesos o el flujo de ejecución de
un programa informático.

Tema 3. Características del análisis y diseño de sistemas

Las características del análisis y diseño de sistemas se refieren al proceso de examinar la
situación o comportamiento de aplicaciones que hay dentro de una empresa con el propósito de
mejorar con métodos y procedimientos más adecuados. 

Para ello, el desarrollo de sistemas tiene dos componentes.

Figura 6: Componentes del desarrollo de sistemas

Fuente: adaptación propia con base en Instituto de Educación Superior Tecnológico Público, s.f., https://bit.ly/37fF2JK

Como resumen, el análisis releva y define qué es lo que el sistema debe hacer. El diseño define
cómo alcanzar el objetivo. 
Actividades del análisis de sistemas
Una de las primeras actividades es determinar las razones y el alcance que va a tener el análisis,
buscar el motivo que está provocando la falla y por el cual nos convocaron.

Llevar a cabo un buen análisis de la situación, problema o falla, es saber qué tengo que
conseguir. Para lograrlo, las preguntas que deberías hacer son las siguientes.

¿Qué va a incluir el sistema? - ¿Qué información se necesita? - ¿Quién la necesita, cuándo,

dónde, cómo o en qué forma? - ¿En dónde se origina, cómo puede obtenerse?

Para responder estos interrogantes, debemos realizar la preparación para la elaboración, que
implica la agrupación de toda la información relevante. 

Ahora bien, una forma esencial para seguir buscando información, es continuar preguntando
sobre: la actividad de la organización (“qué”) - las personas involucradas (“quién”) - de qué
manera se desarrollan los procesos (“cómo”) - en qué momento (“cuándo”) - los gastos que
involucra (“cuánto”) - el ambiente donde se lleva a cabo el trabajo (“dónde”).

Diseño del sistema

El diseño del sistema usa la información recolectada en la etapa del análisis. Con esa información
comenzamos a realizar el diseño lógico de lo que necesitamos modificar o solucionar. Entonces,
podría decirse que el diseño es el proceso creativo de transformación del problema en una
solución.

Para ello, se determinan que son procesos para determinar la magnitud del cambio que
deseamos realizar, y es lo siguiente.

Diseño procedimientos: se establecen la captura de datos, que son los diseños de

entrada, para lo cual se grafican flujogramas o procesos.

Diseño de entrada: cuáles van a ser los ingresos de esos datos, qué utilizará el
usuario para ingresarlo (teclado, menú de pantalla, ratón, etc.).

Diseño de salidas: aquí definimos cómo va a ser la muestra de la información, si va a

ser impresión, salida por pantalla o salida por archivos, o procesos de comunicación
con otros sistemas (webService).

Diseño de base de datos: una vez definidos los métodos de entrada de la

información, definimos la estructura que guarda la información y los cálculos que se
realizan.

Diseño arquitectónico: esta es la etapa en la que trabajamos la relación entre cada

uno de los elementos estructurales del programa.

Diseño de la interfaz: acá se define la comunicación del sistema con los otros
componentes, con los usuarios; es la manera de vincular los procesos o
procedimientos, para lo cual se grafican prototipos de pantallas.

En esta etapa el diseñador de sistemas debe tomar decisiones y, para ello, debe contar con las
siguientes alternativas.

Organizar el sistema en subsistemas.

Identificar la concurrencia del problema.
Asignar los subsistemas a los procesos y tareas que deben desarrollar.
Conocer el acceso a recursos, perfiles y roles.
 Pensar la manera en cómo se va a realizar la implementación de control en software.
Manejar las condiciones con los usuarios, que estén preparados para el cambio.

Tema 4. El rol del analista de sistemas

¿Cómo se crean, diseñan, gestionan y manejan los sistemas de información? Gracias a los
analistas de sistemas. 

El analista de sistemas es un perfil que interactúa entre los usuarios y la tecnología o las
aplicaciones. Debe ser capaz de desempeñarse en diferentes roles, muchas veces en
simultáneo, por lo que debe conocer los procesos de entrada/salida de los datos y la producción
de información, para poder ayudar ante alguna eventualidad, diseñar procesos o gestionar
mejoras en los procesos de la organización en la que se desempeña.

En este sentido, el analista de sistemas, dentro de una organización, puede actuar como: 

1.-ANÁLISIS DE SISTEMAS (analista de información): es reunir información y determinar

los requisitos. Los analistas no son responsables del diseño de sistema.

2.-ANÁLISIS Y DISEÑO DEL SISTEMA (diseñadores de sistemas, diseñadores de

aplicaciones): el analista tiene la responsabilidad adicional de diseñar el nuevo sistema.

3.-ANÁLISIS, DISEÑO Y PROGRAMACIÓN DEL SISTEMA (analista programador):

desarrolla las especificaciones de diseño y escribe el software necesario para implementar
el diseño. (Educación Superior Tecnológico Público, s.f., https://bit.ly/37fF2JK) 

Cualidades y habilidades que el analista debe tener

Un analista debe entender que es un solucionador de problemas y que debe tener la capacidad
de lidiar cotidianamente con situaciones complejas. Además, el negocio requiere de algunas
competencias como tener conocimiento técnico, contar con experiencia para no generar pánico
frente a situaciones complejas y ser un comunicador para crear relaciones de confianza con los
usuarios. El analista debe saber que el suyo es un puesto exigente que requiere de estar en
evolución permanente, ya que ofrece nuevos retos constantemente.
Figura 7: Habilidades de un analista de sistemas
Fuente: Hireline, s.f., https://bit.ly/37k5z8J

Un perfil adecuado y algunas características 

Figura 8: Perfil adecuado de analista de sistemas

Fuente: Unidad Profesional Interdisciplinaria de Ingeniería y Ciencias sociales y Administrativas, s.f., https://bit.ly/3w2cNsw

Otros roles que el analista debe tener

Figura 9: Otros roles del analista de sistemas
Fuente: Unidad Profesional Interdisciplinaria de Ingeniería y Ciencias sociales y Administrativas, s.f., https://bit.ly/3w2cNsw

Unidad 2. Gestión de proyectos de desarrollo de

software
En esta unidad, trabajaremos las definiciones básicas para comprender cómo gestionar un
proyecto de desarrollo de software. Por ello, primero debemos definir que un proyecto es un
esfuerzo temporal realizado para crear un producto, servicio o resultado único.

El primer aspecto que debemos destacar de esta definición, es que un proyecto busca crear un
producto, servicio o resultado. Esto se denomina entregable, y puede ser un artículo producido,
un elemento terminado o un componente. Lo importante es que el entregable siempre debe ser
un elemento cuantificable. La capacidad de prestar un servicio o un resultado como, por ejemplo,
un documento o un proyecto de investigación, también puede ser considerado un entregable en
tanto se pueda cuantificar.

Por otro lado, esta definición también habla de que un proyecto es esfuerzo temporal y único,
esto significa que el proyecto debe tener un comienzo y un final definidos, característica que lo
diferencia de otro tipo de trabajos que pueden existir en las organizaciones como lo son las
operaciones, que son acciones más rutinarias, continuas y repetitivas, que se relacionan más
bien con el mantenimiento diario.

Ahora bien, sí podemos determinar que ambos conceptos tienen en común el hecho de ser
realizados por personas; están restringidos por la limitación de recursos y pueden ser planeados,
ejecutados y controlados. Estas personas que velan por el cumplimiento de los pasos o tareas
para el desarrollo de tal proyecto, son el equipo de proyectos.

Para llevarlo a cabo el proyecto, existen diferentes metodologías de ejecución. Es decir,

diferentes procedimientos racionales, técnicas concretas, habilidades y conocimientos específicos
que ayudarán a alcanzar ese objetivo deseado. En esta unidad, estudiaremos las metodologías
tradicionales y las ágiles. Todo en función de explicar el proceso de desarrollo de un proyecto,
cuyo objetivo básico es el de hacer predecible el trabajo, anticipar su costo, mantener un nivel
alto de calidad y determinar cuánto tiempo costará el desarrollo.

Tema 1. Fundamentos de proyectos de software

Un proyecto de software es una tarea bien definida, en un momento concreto en el tiempo,
durante el que se realizan una cantidad de pasos, procesos o combinatoria de operaciones desde
la recogida de requisitos, pasando por las pruebas y el mantenimiento, con el único objetivo de
lograr un producto o aplicación determinado.

La mayor parte de los productos de software son diseñados para satisfacer la necesidad de un
cliente, como cambiar la forma de mostrar información o hacer más fácil los procesos de su
organización.

Todos los proyectos de desarrollo de software juegan con las limitaciones del entorno, por lo que
traen con ellos riesgos determinados y por eso es esencial gestionarlos de manera eficiente.

Existen tres limitaciones principales para estos proyectos: tiempo, costo y calidad.

Figura 10: Limitantes del proyecto

Fuente: Tutoriales Point, s.f., https://bit.ly/3w2KVV5

Como se muestra en la imagen, una parte importante del proyecto consiste en “entregar un
producto de calidad, manteniendo el costo dentro de las limitaciones del presupuesto del cliente,
en el menor tiempo posible” (Tutoriales Point, s.f., https://bit.ly/3w2KVV5). Las tres variables
juegan un rol muy importante a la hora de gestionar el proyecto y hay muchos factores, internos y
externos, que pueden causar un impacto considerable en este triángulo, por lo que es
imprescindible que la gestión del proyecto pueda mantenerlas equilibradas y así conseguir el
éxito. 

Tema 2. Gestión de alcance y estimación de un proyecto software

El alcance del proyecto
Cuando hablamos de definir el alcance, nos referimos a conocer todas las actividades y procesos
que se deben tener en cuenta, para crear el entregable que requiere el proyecto, ya sea una
aplicación desde cero o determinadas mejoras que se puedan necesitar.

Esta etapa es esencial, porque en ella se crean las condiciones de lo que se va a realizar y lo que
no. Esto permite dividir el proyecto en tareas, determinar el tiempo que puede tomar cada una y
cuantificar o medir todo el proceso. Para esto es requisito que el equipo de proyectos pueda:

conocer los requerimientos o necesidades del cliente,

tener objetivos establecidos y posibles de realizar,
equilibrar las solicitudes permanentes de calidad, alcance, tiempo y costos,
adaptar el alcance, los planes y objetivos a las inquietudes y expectativas de los
interesados/clientes.

Durante la gestión del proyecto es necesario poder determinar puntos de control que permitan
saber dónde controlar cada etapa del proyecto. Estos puntos de control son: 

“Definir el alcance
Decidir su verificación y control
Dividir el proyecto en pequeñas partes para facilitar su gestión.
Verificar el alcance
Controlar el alcance incorporando cambios a este” (Tutoriales Point, s.f.,
https://bit.ly/3w2KVV5). 

Estimaciones del proyecto

Para que un proyecto sea un éxito, un punto importante son las estimaciones que se hacen de
él al comenzar, para tener claro las actividades y su duración. Para estimar se suelen utilizar
varios métodos.
Estimación del tamaño del software: este método se lo conoce con el nombre KLOC (kilo línea
de código), o calculando el número de puntos de función en el software.

Estimación del esfuerzo: este método es muy utilizado actualmente y toma tres parámetros
importantes para poder trabajar y calcular el esfuerzo. Ellos son:

lo que pueden aportar, desde la experiencia misma, los participantes de proyecto;

los datos históricos o las experiencias de esfuerzo de otros proyectos;
alguna formulación estándar de cálculo.

Estimación del tiempo: es un complemento a las estimaciones presentadas anteriormente. En

esta, los requerimientos se dividen por categorías según los requisitos y las relaciones que pueda
obtenerse entre los componentes del software. Esto se llama descomposición del trabajo y se
temporizan de acuerdo con el calendario, definido por día, semana o mes. La sumatoria total, de
acuerdo con el cálculo realizado, es el tiempo total que durará el proyecto.

Estimación del coste: esta estimación también se obtiene de los resultados que definimos en las
estimaciones anteriores, porque depende de los elementos o procesos mencionados
anteriormente. Para estimar el costo del proyecto se requiere tener en cuenta lo siguiente: 

“El tamaño del software

El hardware
Herramientas o software adicional, licencias, etc.
Recursos humanos formados para tareas concretas.
Consideraciones de viaje, movilidad.
Soporte” (Tutoriales Point, s.f., https://bit.ly/3w2KVV5). 

Para lograr el propósito mencionado anteriormente, existen diferentes técnicas de estimación

del proyecto, pero comúnmente hay dos que son las más utilizadas, las cuales describimos a
continuación.
Técnica de descomposición: Hay dos modelos fundamentales 
Línea de código. La estimación se realiza en representación al número de líneas de
códigos en el producto software.

Puntos de función. La estimación se realiza en representación al número de puntos de

función que hay en el producto software. (Tutoriales Point, s.f., https://bit.ly/3w2KVV5). 

Técnica de estimación empírica: 

 Son derivadas estas estimaciones, de fórmulas que se basan en LOC (línea de control) o
FPs (lenguajes de programación).
Modelo Putnam: […] El modelo Putnam dibuja el mapa de esfuerzos y tiempo que se
requiere para el tamaño del software.

COCOMO: significa 'COnstructive COst MOdel' (modelo de coste constructivo),

desarrollado por Barry W. Boehm. Divide el producto software en 3 categorías de software:
orgánica, semi-independiente e incrustado. (Tutoriales Point, s.f., https://bit.ly/3w2KVV5). 

Tema 3. Gestión de riesgos de un proyecto de software

En todo proyecto existen riesgos que pueden ser predecibles o no. En general, los riesgos
pueden originarse desde diferentes áreas. 

De la gestión de los recursos tangibles: siempre debemos partir de la base de que la

mayoría de los recursos que tenemos están disponibles en cantidades limitadas, y la falta
de recursos de alguno de ellos siempre obstaculiza cualquier desarrollo y puede traer
demoras en toda la planificación realizada. Por ello, es esencial tener contemplada la
posibilidad de poder distribuir recursos adicionales si es necesario, aun sabiendo que esto
puede aumentar el costo y el presupuesto del cliente.
De la gestión de los recursos humanos: ya que siempre habrá integrantes más o menos
capacitados, que tengan experiencia o no. Para evitar conflictos se hace necesario estimar
y distribuir los recursos adecuados para cada etapa del proyecto. Algunas pautas que
debemos considerar en todo proyecto son: 

1. identificar los recursos y las actividades para poder asignar las tareas y distribuir las
responsabilidades a cada miembro del equipo de desarrollo;

2. determinar el expertise de los recursos requeridos para cada fase concreta y su

disponibilidad.

Estimación errada en las actividades del proyecto, ya sea por actividades no

visualizadas, como mal determinado el tiempo: será importante aquí gestionar recursos
humanos y a los integrantes del equipo, incluyéndolos en el proyecto cuando sean
necesarios y retirándolos cuando ya no lo son.
Problemas de comunicación: un mal manejo de la comunicación puede crear vacíos en
las conexiones entre el cliente y la organización, entre los miembros del equipo, así como
con los proveedores de hardware, etc.
 Cambios tecnológicos de la organización que no fueron previstos: siempre pueden
existir cambios o pedidos requeridos que sean malinterpretados o que surgieron de
improviso y sobre los que deberemos trabajar sobre la marcha. 

Para poder disminuir los riegos al mínimo posible, es fundamental una adecuada gestión y
organización: 

-Planificación: este paso incluye la identificación de los accionistas, y la forma en que se

van a comunicar entre ellos.

-Compartir: después de determinar varios aspectos de la planificación, el director se

centra en compartir información correcta con la persona correcta y en el momento correcto
en el tiempo. Esto mantiene a todos los miembros del proyecto al día del progreso y del
estatus del proceso.

-Retroalimentación: los jefes del proyecto usan varias medidas y mecanismos de

retroalimentación y crean informes de estatus y de acción. Este mecanismo asegura que
la entrada de varios accionistas llegue al jefe del proyecto como su retroalimentación.

-Cierre: al final de cada evento […] se anuncia el cierre administrativo para actualizar a
cada accionista vía email, o distribuyendo una copia por escrito del documento o a través
de otro medio de comunicación efectivo. (Tutoriales Point, s.f., https://bit.ly/3w2KVV5) 

Además, para poder trabajar el proceso de la gestión del riesgo de manera adecuada, podemos
realizar varias actividades:
-Identificación - Anota todos los riesgos posibles, que pueden ocurrir en el proyecto.

-Categorizar - Categorizar riesgos ya conocidos en riesgo de intensidad alta, media y

baja, según el posible impacto que puedan tener en el proyecto.

-Gestionar - Analizar la probabilidad de ocurrencia de riesgos en las distintas fases.

Planificar para evitar o tener que afrontar riesgos. Intentar minimizar sus efectos
secundarios.

-Monitorear - Hacer un seguimiento de cerca de los riesgos potenciales y de sus

síntomas iniciales. También monitorear los efectos de los pasos que se han seguido para
mitigarlos o evitarlos. (Tutoriales Point, s.f., https://bit.ly/3w2KVV5)

Tema 4. Introducción a proyectos con metodologías ágiles

El concepto de ágil está cada vez más extendido, sobre todo en el mundo del desarrollo de
software, por ello, la primera pregunta que nos debemos realizar es ¿qué es ágil? 

La metodología ágil nace en contraposición a la metodología denominada “tradicional” o de

modelo en cascada. Con el modelo en cascada, los líderes de proyectos no eran partícipes en
forma activa en el desarrollo y no había suficiente flexibilidad como para adaptarse a los
potenciales cambios que pudieran surgir en el medio del desarrollo del producto.

Por eso, mientras que las metodologías tradicionales se centran especialmente en el control del
proceso, a través de “una rigurosa definición de roles, actividades, artefactos, herramientas y
notaciones para el modelado y documentación detallada” (Maida y Pacienzia, 2015,
https://bit.ly/3tQvOva), los enfoques ágiles centran las tareas y el trabajo en función de las
necesidades finales del cliente o de las expectativas del usuario, involucrándolo en cada etapa
del proceso de desarrollo. 

Una de las primeras premisas con las que nacen estas metodologías ágiles, fue la de evitar
perder la calidad y asegurar la mejora continua de los servicios, pero sin perder la rigurosidad ni
los formalismos implícitos en las buenas prácticas de trabajo. Por lo que sus adscriptos
elaboraron un “manifiesto ágil”, en el que determinaron los siguientes 4 principios fundamentales.

1- Individuos e interacciones por encima de procesos y herramientas

El individuo no es el único factor para tener en cuenta, ya que los equipos de trabajo son
extremadamente valiosos, de poco sirve un profesional especializado si no coopera con el
resto del equipo. […] 

El usuario final también forma parte, en cierto modo, del equipo de desarrollo, puesto que
es el encargado de determinar si el trabajo es útil y si la experiencia es positiva. Por ello,
su feedback es una de las bases del desarrollo. 

Los entornos de trabajo condicionarán en gran medida el resultado final. Si se tienen en

cuenta todos estos factores, la elección de las herramientas a utilizar y los procesos pasan
a un segundo plano, puesto que con un entorno de trabajo adaptado es altamente
probable que se encuentren las herramientas indicadas. (Digital Talen Agency, s.f.,
https://bit.ly/3i1iAWO) 

2- Software funcional por encima de documentación extensiva 

La metodología ágil prioriza el desarrollo de software funcional libre de errores a la
documentación continua […]. Básicamente, se trata de sacrificar el tiempo invertido en
documentación innecesaria e implementarlo en el desarrollo como tal. 

En definitiva, estos documentos deben ser escasos e ir al grano, ser breves, funcionales e
inteligibles para todo el equipo. Lo más importante es, al fin y al cabo, desarrollar un
software robusto y estable. (Digital Talen Agency, s.f., https://bit.ly/3i1iAWO)

3- Colaboración con el cliente por encima de la negociación contractual

Para que un proyecto pueda alcanzar el éxito es importante que exista complicidad entre
el cliente y el equipo de desarrollo. Como decíamos en el primer punto, el cliente debe
sentir que forma parte del equipo, aunque no trabaje directamente sobre el propio
desarrollo. Si esto se consigue, ambas partes comprenderán las necesidades de cada uno
y podrán trabajar conjuntamente para optimizar el desarrollo. Un contrato no establece la
 calidad o el valor del producto, sino que determina responsabilidades en el caso de
disputas contractuales entre el cliente y el proveedor. Por ello, las Metodologías Ágiles
impulsan las mejoras continuas con el objetivo de evitar que al final de todo el proceso el
cliente quiera modificar algo y que eso quede fuera del presupuesto. (Digital Talen Agency,
s.f., https://bit.ly/3i1iAWO)
4- Respuesta ante el cambio por encima de seguir un plan
Los proyectos deben adaptarse a los cambios que la propia organización sufre.
Actualmente, las empresas mutan de forma constante, puesto que tratan de adaptarse al
mercado. Por ello, es natural que el desarrollo de software sea un área dinámica y en
evolución continua. Planificar el proyecto de desarrollo es importante, pero no hay que
hacerlo de forma hermética y estricta, eliminando toda posibilidad de maniobra. La
planificación debe ser abierta y flexible para que adaptar el proyecto a los cambios sea
posible y sencillo. El objetivo de esto es que, al terminar todo el proceso de desarrollo, el
resultado siga siendo útil y no haya quedado obsoleto. (Digital Talen Agency, s.f.,
https://bit.ly/3i1iAWO)
Hoy existe una alta competitividad en el entorno de las tecnologías para los proyectos de software
y esto provoca que los sistemas tengan que desarrollarse rápidamente, pero siempre asegurando
la calidad y actualización en el código de los lenguajes de programación.

Otra particularidad de la metodología ágil son los entornos de trabajo, donde se busca conseguir
que los profesionales se encuentren motivados y comprometidos a la hora de aportar sus
desarrollos. Dentro de la metodología ágil, los frameworks más conocidos o utilizados son Scrum,
Kanban y XP, donde la particularidad de esta transformación es el comportamiento de los equipos
de trabajo, su forma de pensar, actuar o trabajar.

Al día de hoy, se conocen que existen 12 principios ágiles que definen las ventajas de estas
metodologías.

1. Hacer entregas continuas de software para aportar valor al cliente. 

2. Aceptar los cambios incluso al final del desarrollo para conseguir ventajas competitivas. 

3. Entregar un software funcional, entre cada dos semanas y dos meses, cuanto antes. 

4. Los responsables del negocio y los desarrolladores deben trabajar juntos día a día. 

5. Garantizar que el entorno de trabajo está adaptado a los desarrolladores para mantener
motivado al equipo. 

6. El diálogo cara a cara es fundamental para garantizar la comunicación en el equipo de

desarrollo. 

7. El software funcional marcará el progreso del proyecto. 

8. El ritmo de trabajo debe ser constante y el desarrollo, sostenido. 

9. La atención continua al diseño y a la calidad técnica mejoran la agilidad. 

10. La simplicidad en los procesos de desarrollo es esencial. 

11. Los mejores diseños y arquitecturas nacen de los equipos que se organizan y
 gestionan a sí mismos. 

12. El equipo debe evaluar regularmente cómo ser más efectivo y, en función a esto,
modifica su modo de proceder. (Digital Talen Agency, s.f., https://bit.ly/3i1iAWO)

¿Ágil o tradicional?

Como siempre, cuando aparecen estas nuevas metodologías, está la comparación con la que se
están reemplazando y como todo en lo que se refiere a sistemas no es algo único, les
mostraremos las comparaciones entre ambas metodologías. 

En las metodologías tradicionales el principal problema es que nunca se logra planificar

bien el esfuerzo requerido para seguir la metodología. Pero entonces, si logramos definir
métricas que apoyen la estimación de las actividades de desarrollo, muchas prácticas de
metodologías tradicionales podrían ser apropiadas. (Maida y Pacienzia, 2015,
https://bit.ly/3tQvOva)
Esto en combinación con una metodología ágil. Tener metodologías diferentes para aplicar de
acuerdo con el proyecto que se desarrolle es una idea más que interesante para que el analista
de sistemas pueda determinar parámetros para saber cuál usar. 

Video de habilidades

Pregunta de habilidades
Te invitamos a completar un documento EDT con la siguiente premisa: 

“EMPRESA LOGÍSTICA DE ALIMENTOS” donde el objetivo es desarrollar un software de entrega

de productos, armado de pedido, control de stock y reposición de productos.

Cierre
En el desarrollo de productos de software las etapas de análisis de requerimientos y diseño
toman gran parte del tiempo del proyecto. En este documento se pretende que el alumno logre
comprender y establecer unos parámetros de diseño generales que permitan agilizar la
implementación de proyectos tipo sistemas de control por software. 

La utilización de un ciclo de vida específico para el desarrollo de software trata de evitar

problemas en los alcances notables del modelo ofrecido. El ciclo de vida contempla la noción de
fases generales que constituyen un marco de situación, estableciendo fases de solución para un
subproblema concreto.

Con el constante desarrollo e innovación de las tecnologías utilizadas en las implementaciones de

software es deseable tener un modelo adecuándolo a necesidades y ambientes particulares en
cada organización. Si bien se han utilizado conceptos de paradigmas como el de desarrollo
orientado a objetos o sistemas en tiempo real, el modelo ha buscado generalizarse para que su
interpretación pueda hacerse según condiciones singulares de los problemas a tratar.

Microactividades

1. ¿Qué es un proceso de software?

2. ¿Qué es un modelo de proceso de software? Se pueden utilizar términos como ciclo de vida
y modelo de ciclo de vida.
3. ¿Cuáles son los costos que implica la ingeniería de software?
4. ¿En qué basan las metodologías ágiles?
5. ¿Qué son las técnicas de análisis y diseño de sistemas de información?
6. Mencioná 2 roles que deba desempeñar un analista de sistemas dando una definición de
cada rol.
7. ¿Qué cualidades personales son de utilidad para el analista de sistemas?
8. ¿Cuáles son los principios de las metodologías ágiles?

Valoración de los usuarios, participación alta en todo el proceso, consiste en colaboración directa
con el cliente para mantener una relación más participativa y cercana. 

En el siguiente descargable podrás ver las respuestas más acertadas a las preguntas:

Fuente: elaboración propia.

Glosario
Referencias
[Imagen sin título sobre sistema informático], (s.f.). Recuperado de
https://www.areatecnologia.com/informatica/sistema-informatico.html

Asana, (2021). El diagrama de PERT: qué es y cómo crearlo (incluye ejemplos). Recuperado de
https://asana.com/es/resources/pert-chart

Bertalanffy, V. (1970). Teoría General de Sistemas (2.da. ed.). Buenos Aires, Argentina: Ateneo

Digital Guide Ionos, (2018). UML, lenguaje de modelado gráfico. Recuperado de

https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/uml-lenguaje-unificado-de-
modelado-orientado-a-objetos/

Digital Talent Agency, (s.f.). Metodologías de gestión de proyectos. Recuperado de

https://www.dtagency.tech/cursos/metodologias_gestion_proyectos/tema_2-ModeloAgile.pdf

García, M. (s.f.). Unidad 1. Fundamentos del análisis y diseño de sistemas [apuntes de clases].
Recuperado de http://profmatiasgarcia.com.ar/uploads/tutoriales/DS-Unidad1.pdf

Gutiérrez Gómez, G. (2013). Teoría general de los sistemas. Bogotá, Colombia: Universidad
Santo Tomás. Recuperado de
https://repository.usta.edu.co/bitstream/handle/11634/23242/Teor%C3%ADa%20general%20de%
20sistemas.pdf?sequence=1&isAllowed=y 

Hireline, (s.f.). Perfil de analista de sistemas. Recuperado de https://hireline.io/mx/enciclopedia-

de-perfiles-ti/perfil-de-analista-de-sistemas

Hurtado Carmona, D. (2010). Teoría General de Sistemas: un enfoque hacia la ingeniería de

sistemas. España: Lulú Ediciones.

Instituto de Educación Superior Tecnológico Público, (s.f.). Metodología de análisis y diseño

de los sistemas de información. Recuperado de
http://istjaq.edu.pe/nosotros/contenido_virtual/pe/computacion_informatica/subidas/sa_iii/ud01/Se
mana%2005%20%20Metodolog%C3%ADa%20del%20An%C3%A1lisis%20y%20Dise%C3%B1o
%20de%20Sistemas.pdf

Junta de Andalucía, (s.f.). Tema 11 [apuntes de cátedra]. Recuperado de

https://www.juntadeandalucia.es/institutodeadministracionpublica/publico/anexos/empleo/c2.1000/
TEMA%2011.pdf

Maida, E. G.; Pacienzia, J. (2015). Metodologías de desarrollo de software [tesis de grado].

Recuperado de http://bibliotecadigital.uca.edu.ar/repositorio/tesis/metodologias-desarrollo-
software.pdf

Project Management Institute, (2008). Guía de los fundamentos para la dirección de proyectos
(4.ta. ed.). Estados Unidos: Project Management Institute.

Román, A. (2011). Herramientas de gestión para organizaciones y empresas. En Revista

Biomédica 11(11). Recuperado de https://www.medwave.cl/link.cgi/Medwave/Series/GES01/5226

Sesento García, L. (2008). Modelo sistémico basado en competencias para instituciones

educativas públicas [tesis de grado]. Recuperado de https://www.eumed.net/tesis-
doctorales/2012/lsg/teoria_sistemas.html#:~:text=PROP%C3%93SITO%20U%20OBJETIVO%3A
%20Todo%20sistema,una%20relaci%C3%B3n%20de%20causa%2Fefecto.

Tutoriales Point, (s.f.). Gestión del proyecto de Software. Recuperado de

https://www.tutorialspoint.com/sp/software_engineering/software_project_management.htm

Unidad Profesional Interdisciplinaria de Ingeniería y Ciencias sociales y Administrativas,

(s.f.). El analista de sistemas. Recuperado de
http://www.sites.upiicsa.ipn.mx/estudiantes/academia_de_informatica/analisis_de_sistemas/docs/
PDF/El_analista_perfil.pdf