Contenido

Revisión de especificación de requisitos...............................................................................2

Norma IEEE830..............................................................................................................................2
Trazabilidad de requisitos...........................................................................................................6
Descripción de procesos actuales............................................................................................8
Diagramas UML...........................................................................................................................11
¿Por qué UML?........................................................................................................................11
Estudio de Factibilidad..............................................................................................................16
Análisis Costo-Beneficio...........................................................................................................17
Cómo calcular y analizar la relación costo-beneficio.................................................18
Referencias...................................................................................................................................21

pág. 1
Revisión de especificación de requisitos.
La especificación de requisitos de software (ERS) es una descripción completa del
comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos
de uso que describe todas las interacciones que tendrán los usuarios con el
software. Los casos de uso también son conocidos como requisitos funcionales.
Además de los casos de uso, la ERS también contiene requisitos no funcionales
(complementarios). Los requisitos no funcionales son requisitos que imponen
restricciones en el diseño o la implementación, como, por ejemplo, restricciones en
el diseño o estándares de calidad.

Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado

para su redacción debe ser informal, de forma que sea fácilmente comprensible
para todas las partes involucradas en el desarrollo.

Norma IEEE830
El estándar IEEE 830-1998 para el SRS (en inglés) o ERS (Especificación de
requerimientos de software) es un conjunto de recomendaciones para la
especificación de los requerimiento o requisitos de software el cual tiene como
producto final la documentación de los acuerdos entre el cliente y el grupo de
desarrollo para así cumplir con la totalidad de exigencias estipuladas.
Se espera que ayude a:
a) Los clientes de Software para describir con precisión lo que desean obtener;
b) Los proveedores de software para entender exactamente lo que quiere el
cliente;
c) Las personas para lograr los siguientes objetivos:

1) Desarrollar una especificación de requisitos software estándar (SRS) para sus

propias organizaciones;
2) Definir el formato y el contenido de sus especificaciones de requisitos de
software específicos;
3) Desarrollar elementos de apoyo locales adicionales, tales como una lista de
comprobación de la calidad de SRS, o un manual de SRS.

Consideraciones para la producción de un buen SRS

pág. 2
Esta cláusula se proporciona información básica que se debe considerar al escribir
un SRS. Esto incluye la siguiente:
Naturaleza del SRS
El SRS son especificaciones para un producto del software en particular,
programa o juego de programas que realizan ciertas funciones en un ambiente
especifico. El SRS puede escribirse por uno o más representantes del proveedor,
uno o más representantes del cliente o por ambos.
Los problemas básicos que se presentan al escribir un buen SRS van dirigidos a lo
siguiente:

Ambiente del SRS

El software puede contener toda la funcionalidad del proyecto esencialmente o
puede ser
parte de un sistema más grande. En el último caso habrá un SRS que declarará
las interfaces entre el sistema y su software modular y pondrá que función externa
y requisitos de funcionalidad tiene con el software modular.
Desde que el SRS tiene un papel especifico en el proceso de desarrollo de
software, el que lo define. debe tener el cuidado para no ir más allá de los límites
de ese papel. Esto significa que:
 Debe definir todos los requisitos del software correctamente. Un requisito
del software puede existir debido a la naturaleza de la tarea a ser resuelta o
debido a una característica especial del proyecto.
 No debe describir cualquier plan o detalles de aplicación. Estos deben
describirse en la fase del diseño del proyecto.

pág. 3
 No debe imponer las restricciones adicionales en el software. Estos se
especifican propiamente en otros documentos.

pág. 4
Características de un buen SRS.

PARTES DE UN SRS
Objetivo
 Delimitar el propósito del SRS;
 Especificar la audiencia prevista para el SRS.
Ámbito de aplicación
 Identificar el producto software que se produce por su nombre.
 Explicar lo que el producto software será, y si es necesario, no será
 Describir la aplicación del software especificado, incluyendo beneficios
pertinentes, objetivos y metas;
 Ser coherente con las declaraciones similares en especificaciones de nivel
superior (si existen).
Definiciones, acrónimos y abreviaturas
Referencias
 Proporcionar una lista completa de todos los documentos referenciados en
el SRS en otra parte;
 Identificar cada documento por título, número de informe (si procede),
fecha, y la organización de edición;
 Especificar las fuentes de donde se pueden obtener las referencias.
Información general

pág. 5
  Describir lo que el resto del SRS contiene;
 Explicar cómo el SRS es organizado.

Descripción general
Perspectiva del producto
Esta subdivisión del SRS debe poner el producto en perspectiva con otros
productos. Si el producto es independiente y totalmente autónomo, que debe
indicarse aquí. Si el SRS define un producto que es un componente de un sistema
mayor, como ocurre con frecuencia, a continuación, esta subdivisión debe
relacionar los requisitos de ese sistema más grande a la funcionalidad del software
y debe identificar las interfaces entre dicho sistema y el software. Un diagrama de
bloques que muestra los componentes principales del sistema más grande,
interconexiones, y las interfaces externas puede ser útil. Esta sub-sección también
debe describir cómo el software opera dentro de diversas limitaciones. Por
ejemplo, estas limitaciones pueden incluir:
 Las interfaces del sistema.
 Las interfaces del sistema.
 Las interfaces de hardware.
 Las interfaces de software.
 Interfaces de comunicaciones.
 De memoria.
 Operaciones.
 Los requisitos de adaptación del sitio.
Funciones del producto
Esta sub-sección del SRS debe proporcionar un resumen de las principales
funciones que el software ejecutará. Por ejemplo, un SRS para un programa de
contabilidad puede utilizar esta parte para abordar el mantenimiento de cuenta del
cliente, el estado del cliente y la preparación de la factura sin mencionar la gran
cantidad de detalles que cada una de estas funciones requiere.
Características de los usuarios
Esta subdivisión del SRS debe describir las características generales de los
usuarios previstos del producto, incluyendo el nivel de educación, experiencia y
conocimientos técnicos. No se debe utilizar para indicar los requisitos específicos,
sino más bien debe proporcionar las razones por las cuales ciertos requisitos
específicos se especifican.
Limitaciones
Esta subdivisión del SRS debe proporcionar una descripción general de otras
cosas que van a limitar las opciones de sistema operativo para desarrolladores .

pág. 6
Trazabilidad de requisitos
La trazabilidad de requisitos es un concepto, cuando hablamos de gestión de
requisitos, que a veces relacionamos con un montón de trabajo, con la necesidad
de disponer de herramientas complejas, y en muchas ocasiones con una pérdida
de tiempo innecesaria. Sin embargo, es como la mayor parte de técnicas y
disciplinas de Business Analysis y Project Management, en su justa medida puede
contribuir de manera muy importante al éxito del proyecto.

En este post voy a explicar algunas consideraciones acerca de la importancia de

la trazabilidad de requisitos en los proyectos.
¿Qué es trazabilidad?
La trazabilidad es establecer una línea imaginaria que relacione hacia atrás los
requisitos con objetivos del proyecto, y hacia delante con test cases o releases.
Permite, por lo tanto, relacionar y establecer dependencias entre requisitos, y
también con otros elementos importantes en el proyecto (diseño técnico,
componentes de código, test cases, releases, incidencias…). Vemos una
ilustración de este concepto simplificada en la figura siguiente:

Realizamos trazabilidad para asegurar que los requisitos son aprobados y

gestionados de manera correcta a lo largo del ciclo de vida del proyecto.

¿Cuáles son los beneficios de la trazabilidad de requisitos?

pág. 7
Una buena gestión de la trazabilidad nos aporta los siguientes beneficios:
Gestión óptima del alcance de la solución
En la medida que permite relacionar cada requisito con los objetivos de negocio
perseguidos, podemos evaluar el valor de cada requisito y así priorizar
correctamente, y evitar el Scope Creep (la frustrante sensación de que no se
acaban nunca los requisitos para este proyecto)
Gestionar cambios con mínimo impacto
Una buena trazabilidad permite poder evaluar el impacto de potenciales cambios
sobre requisitos de una manera completa: identificando requisitos y otros
componentes afectados, y su relación con los objetivos de negocio perseguidos.
Además, identificar más rápidamente las causas de problemas identificados, al
poder relacionar por ejemplo un test case que ha fallado con los requisitos que
incluye.
Ayuda a reducir riesgos en el proyecto
Permitiendo identificar dependencias críticas entre requisitos y, por lo tanto,
controlar mejor estas relaciones.
Ayuda a mantener consistencia entre requisitos
El hecho de mantener las relaciones nos ayuda a ser consistentes y coherentes,
utilizando siempre una misma terminología, y detectando situaciones de
inconsistencia rápidamente (ejemplo, requisito de negocio dice blanco, y requisito
de solución dice negro).
Permite monitorizar y controlar el ciclo de vida de requisitos
La matriz de trazabilidad puede ser la base sobre la que controlar qué requisitos
están validados, cuáles están pendientes o cuáles han sido rechazados. Permite
además identificar la línea base de requisitos correspondiente a una reléase
determinada.

¿Cómo podemos trazar requisitos de manera eficiente?

Está claro que la trazabilidad no aporta un valor directo a nuestro cliente, aunque
obviamente indirectamente sí. Por eso, el esfuerzo de trazabilidad tiene que
corresponderse con el proyecto en el que trabajamos: Proyectos más grandes, o
de mayor complejidad o riesgo requieren más trazabilidad. Pero demasiada
trazabilidad puede impactar directamente en coste, recursos y tiempo de proyecto.
Por ejemplo, en un proyecto con una fecha muy ajustada de entrega, el esfuerzo a
dedicar en trazabilidad debe ser el mínimo imprescindible.
Está claro entonces que, como en todos los aspectos de business analysis, una
única solución de trazabilidad para todos los proyectos, suele no ser una buena

pág. 8
idea. Entonces a la hora de decidir el nivel de trazabilidad y el esfuerzo necesario
debemos considerar los siguientes aspectos:
 Madurez en BA y PM personal y de nuestra organización
 Herramientas disponibles en nuestra organización y conocimiento de las
mismas
 Responsabilidad de mantenimiento de las relaciones de trazabilidad
El esfuerzo de poner en marcha un sistema de trazabilidad puede ser elevado,
pero solo se obtienen beneficios cuando se utiliza de manera continuada, por eso
si nuestra organización no dispone de las herramientas, podemos plantearnos
utilizar directamente una hoja de cálculo para la gestión de la trazabilidad.
Siempre insisto en los cursos en la necesidad de ser poco ambiciosos en cuanto a
trazabilidad: Si no disponemos de herramientas, las hojas de cálculo son muy
útiles, pero, en función del nivel de trazabilidad, podemos ahogarnos por el
esfuerzo requerido y debemos tener en cuenta, también que, si la matriz no refleja
fielmente la realidad, no nos servirá para nada. Por eso, siempre propongo un
conjunto mínimo de elementos que deberían estar siempre trazados:
 Objetivos o requisitos de negocio
 Requisitos de solución (al nivel que podamos, quizás relacionando también
casos de uso con modelo de datos)
 Test cases
 Releases
Finalmente, insistir en la importancia de la trazabilidad también para proyectos
ágiles. En este caso podremos utilizar el propio backlog y los paneles kanban
como herramientas de trazabilidad (relación de épicas, historias de usuario, tareas
técnicas, test cases, releases).

Descripción de procesos actuales

El proceso de software es un conjunto de actividades y resultados asociados que
conducen a la creación de un producto de software”. [Sommerville 2002]
Cuando el proceso implica la construcción de algún producto, solemos referirnos
al proceso como Ciclo de Vida.
El proceso de desarrollo de software suele denominarse ciclo de vida del software,
porque describe la vida de un producto de software desde su concepción hasta su
implementación, entrega, utilización y mantenimiento.
Etapas generales en el desarrollo de software
 Planificación

pág. 9
Antes de comprometer los fondos para el desarrollo de un software o el
mantenimiento de un proyecto por lo general el cliente quiere una estimación de
cuánto costará el proyecto y cuánto durará.
Objetivo.
Es proporcionar un marco de trabajo que permita al gestor hacer estimaciones
razonables de recursos, costos y planificación temporal.
Producto de trabajo.
Plan del proyecto: deja por escrito las necesidades del cliente, así como lo que se
espera hacer para satisfacerlas.
 Definición y análisis de requerimientos
Objetivo.
Reunirse con los clientes para definir los requerimientos: son lo que los clientes y
usuarios quieren que haga el sistema. Los requerimientos definen el sistema.

 Diseño del sistema

Transformar el problema en una solución, es decir realizar un diseño del sistema
que satisfaga las necesidades de los clientes.
Objetivo.
El diseño consta de dos partes:
Diseño del sistema o conceptual: Se presenta el sistema desde la visión del
Cliente, solo se describen apariencia y funcionalidad.
Diseño técnico: el objetivo, es que los constructores comprendan el hardware y el
software concretos que se necesitarán para resolver el problema del cliente. Se
utiliza el diseño global para generar los diseños de los programas.

pág. 10
  Codificación
Proceso creativo que traduce el diseño a un lenguaje de programación.
Objetivo
Escribir los programas que implementen el diseño.

Demoler el producto de software con el propósito de detectar defectos. Objetivo La

etapa de Prueba consta de tres partes:
Prueba unitaria: prueba de los módulos por separado.
Prueba de integración: se reúnen piezas y se prueban.
Prueba del sistema: se prueba el sistema completo, para probar que las
funciones y relaciones estén bien.

 Liberación del producto

pág. 11
Es más que solo la entrega del producto, sino que es el momento del desarrollo en
que se ayuda a los usuarios a comprender el producto entregado y a sentirse
cómodos con él.
 Mantenimiento
Mantener un sistema que evoluciona constantemente.

Diagramas UML
El Lenguaje Unificado de Modelado o UML (“Unified Modeling Language”) es un
lenguaje estandarizado de modelado. Está especialmente desarrollado para
ayudar a todos los intervinientes en el desarrollo y modelado de un sistema o un
producto software a describir, diseñar, especificar, visualizar, construir y
documentar todos los artefactos que lo componen, sirviéndose de varios tipos de
diagramas.

Estos diagramas contenidos en UML son la forma más común y más utilizada de
modelado de software. Modelar consiste en hacer un diseño previo de una
aplicación antes de proceder a su desarrollo e implementación. De forma similar
que un arquitecto dibuja planos sobre la casa que va a construir, un analista de
software (u otros perfiles) crea distintos diagramas UML que sirven de base para
la posterior construcción/mantenimiento del sistema. El modelado es la principal
forma de visualizar el diseño de una aplicación con la finalidad de compararla con
los requisitos antes de que el equipo de desarrollo comience a codificar.

El modelado es vital en todo tipo de proyectos, pero cobra especialmente

importancia a medida que el proyecto crece de tamaño. Para que una aplicación
funcione correctamente, debe ser diseñada para permitir la escalabilidad, la
seguridad y la ejecución. Utilizando diagramas UML se consigue visualizar y
verificar los diseños de sus sistemas de software antes de que la implementación
del código haga que los cambios sean difíciles y demasiado costosos.

¿Por qué UML?

Los modelos o diagramas de UML nos ayudan a trabajar a un mayor nivel de

abstracción. Permite modelar cualquier tipo de aplicación corriendo en cualquier

pág. 12
combinación de hardware y software, sistema operativo, lenguaje de programación
y red, es decir, UML es independiente de la plataforma hardware sobre la que
actua el software. Su flexibilidad permite modelar cualquier tipo de aplicación e,
incluso, otros tipos de proyecto que no son puramente software.

UML ofrece ese modelado utilizando diagramas y se denomina lenguaje por ser
una forma común de expresarse por todos los analistas, desarrolladores y
usuarios. Está desarrollado para ayudar a todos estos (y más) perfiles a
especificar, visualizar, construir y documentar todos los componentes de un
proyecto. A pesar de que cada diagrama UML en particular aporta su visión
particular al modelado, el lenguaje en su conjunto tiene algunas características
que interesa resaltar:

 Es muy sencillo. Pese a que si es usado de forma completa puede llegar a

complicarse, lo normal es que se simplifique.
 Es capaz de modelar todo tipo de sistemas.
 Es un lenguaje universal, haciendo que todos los miembros del equipo se
relacionen a través de sus diagramas sean del ámbito que sean.
 Es fácilmente extensible. Tiene mecanismos sencillos para especializar los
conceptos fundamentales.
 Es visual y, por lo tanto, intuitivo.
 Es independiente del desarrollo, del lenguaje y de la plataforma.
 Bien ejecutado aporta un conjunto considerable de buenas prácticas.
 No está completo. Utilizando los distintos diagramas no podemos estar
seguros de comprender con totalidad el sistema que va a desarrollarse. Los
diagramas, para facilitar su comprensión pueden (y suelen) omitir
información, pueden tener partes que se entienden de distintas maneras o,
incluso, pueden tener conceptos que no pueden ser representados por
ningún diagrama.

Tipos de diagrama UML

Diagrama de Clases
Los diagramas de clases describen la estructura estática de un sistema. Las cosas
que existen y que nos rodean se agrupan naturalmente en categorías. Una clase
es una categoría o grupo de cosas que tienen atributos (propiedades) y acciones
similares. Un ejemplo puede ser la clase “Aviones” que tiene atributos como el
“modelo de avión”, “la cantidad de motores”, “la velocidad de crucero” y “la
capacidad de carga útil”. Entre las acciones de las cosas de esta clase se
encuentran: “acelerar”, “elevarse”, “girar”, “descender”, “desacelerar”. Un
rectángulo es el símbolo que representa a la clase, y se divide en tres áreas. Un
diagrama de clases está formado por varios rectángulos de este tipo conectados
por líneas que representan las asociaciones o maneras en que las clases se
relacionan entre sí.

pág. 13
Diagrama de Casos de Uso
Un caso de uso es una descripción de las acciones de un sistema desde el punto
de vista del usuario. Es una herramienta valiosa dado que es una técnica de
aciertos y errores para obtener los requerimientos del sistema, justamente desde
el punto de vista del usuario. Los diagramas de caso de uso modelan la
funcionalidad del sistema usando actores y casos de uso. Los casos de uso son
servicios o funciones provistas por el sistema para sus usuarios.

Diagrama de Estados
En cualquier momento, un objeto se encuentra en un estado particular, la luz está
encendida o apagada, el auto en movimiento o detenido, la persona leyendo o
cantando, etc. . El diagrama de estados UML captura esa pequeña realidad.

pág. 14
Diagrama de Secuencias
Los diagramas de clases y los de objetos representan información estática. No
obstante, en un sistema funcional, los objetos interactúan entre sí, y tales
interacciones suceden con el tiempo. El diagrama de secuencias UML muestra la
mecánica de la interacción con base en tiempos.

Diagrama de Actividades
Un diagrama de actividades ilustra la naturaleza dinámica de un sistema mediante
el modelado del flujo ocurrente de actividad en actividad. Una actividad representa
una operación en alguna clase del sistema y que resulta en un cambio en el
estado del sistema. Típicamente, los diagramas de actividad son utilizados para
modelar el flujo de trabajo interno de una operación.

pág. 15
Diagrama de Colaboraciones
El diagrama de colaboraciones describe las interacciones entre los objetos en
términos de mensajes secuenciados. Los diagramas de colaboración representan
una combinación de información tomada de los diagramas de clases, de
secuencias y de casos de uso, describiendo el comportamiento, tanto de la
estructura estática, como de la estructura dinámica de un sistema.

Diagrama de Componentes
Un diagrama de componentes describe la organización de los componentes físicos
de un sistema.

Diagrama de Distribución
El diagrama de distribución UML muestra la arquitectura física de un sistema
informático. Puede representar a los equipos y a los dispositivos, y también
mostrar sus interconexiones y el software que se encontrará en cada máquina.

pág. 16
Estudio de Factibilidad
El estudio de factibilidad es un instrumento que sirve para orientar la toma de
decisiones en la evaluación de un proyecto y corresponde a la última fase de la
etapa pre-operativa o de formulación dentro del ciclo del proyecto. Se formula con
base en información que tiene la menor incertidumbre posible para medir las
posibilidades de éxito o fracaso de un proyecto de inversión, apoyándose en él se
tomará la decisión de proceder o no con su implementación.

El estudio de factibilidad debe conducir a:

 Determinación plena e inequívoca del proyecto a través del estudio de
mercado, la definición del tamaño, la ubicación de las instalaciones y la
selección de tecnología.
 Diseño del modelo administrativo adecuado para cada etapa del proyecto.

pág. 17
  Estimación del nivel de las inversiones necesarias y su cronología/lo mismo
que los costos de operación y el cálculo de los ingresos.
 Identificación plena de fuentes de financiación y la regulación de
compromisos de participación en el proyecto.
 Definición de términos de contratación y pliegos de licitación de obras para
adquisición de equipos y construcciones civiles principales y
complementarias.
 Sometimiento del proyecto si es necesario a las respectivas autoridades de
planeación y ambientales.
 Aplicación de criterios de evaluación tanto financiera como económica,
social y ambiental, que permita allegar argumentos para la decisión de
realización del proyecto.
Del estudio de factibilidad se puede esperar: o abandonar el proyecto por no
encontrarlo suficientemente viable, conveniente u oportuno; o mejorarlo,
elaborando un diseño definitivo, teniendo en cuenta las sugerencias y
modificaciones que surgirán de los analistas representantes de las alternas
fuentes de financiación, o de funcionarios estatales de planeación en los diferentes
niveles, nacional, sectorial, regional, local o empresarial. En consecuencia, los
objetivos de cualquier estudio de factibilidad se pueden resumir en los siguientes
términos:
 Verificación de la existencia de un mercado potencial o de una necesidad
no satisfecha.
 Demostración de la viabilidad técnica y la disponibilidad de los recursos
humanos, materiales, administrativos y financieros.
 Corroboración de las ventajas desde el punto de vista financiero,
económico, social o ambiental de asignar recursos hacia la producción de
un bien o la prestación de un servicio.

Análisis Costo-Beneficio
El análisis coste-beneficio (ACB) es una metodología para evaluar de forma
exhaustiva los costes y beneficios de un proyecto (programa, intervención o
medida de política), con el objetivo de determinar si el proyecto es deseable desde
el punto de vista del bienestar social y, si lo es, en qué medida. Para ello, los
costes y beneficios deben ser cuantificados, y expresados en unidades
monetarias, con el fin de poder calcular los beneficios netos del proyecto para la
sociedad en su conjunto. Esta metodología muestra además quién gana y quién
pierde (y por cuánto) como resultado de la ejecución del proyecto. El ACB se
utiliza en la evaluación ex ante como una herramienta para la selección de
proyectos alternativos o para decidir si la implementación de un proyecto concreto

pág. 18
es socialmente deseable. También puede ser empleado ex post para cuantificar el
valor social neto de un proyecto previamente ejecutado.
Lo que mide principalmente el análisis costo-beneficio es la relación costo-
beneficio (B/C), también conocida como índice neto de rentabilidad, la cual es un
cociente que se obtiene al dividir el Valor Actual de los Ingresos totales netos o
beneficios netos (VAI) entre el Valor Actual de los Costos de inversión o costos
totales (VAC) de un proyecto.

Conocer relación costo-beneficio de un proyecto de inversión nos permite conocer

su rentabilidad y así, por ejemplo, saber si el proyecto es viable y qué tan atractivo
es en comparación con otros proyectos.

La fórmula de la relación costo-beneficio es:

B/C = VAI /
VAC

En donde:

 B/C: relación costo-beneficio.

 VAI: valor actual de los ingresos totales netos o beneficios netos.

 VAC: valor actual de los costos de inversión o costos totales.

Según el análisis costo-beneficio un proyecto de inversión será rentable cuando la

relación costo-beneficio sea mayor que la unidad (ya que los beneficios serán
mayores que los costos de inversión), y no será rentable cuando la relación costo-
beneficio sea igual o menor que la unidad (ya que que los beneficios serán iguales
o menores que los costos de inversión):

 un B/C mayor que 1 significa que el proyecto es rentable.

 un B/C igual o menor que 1 significa que el proyecto no es rentable.

Cómo calcular y analizar la relación costo-beneficio

A continuación, se presentan los pasos necesarios para calcular y analizar la
relación costo-beneficio:

1. Identificar costos y beneficios: en primer lugar, debemos hacer la

proyección de los costos de inversión o costos totales y de los ingresos
totales netos o beneficios netos del proyecto para un periodo de tiempo
determinado.

pág. 19
 2. Convertir costos y beneficios a un valor actual: debido a que los montos que
hemos proyectado no toman en cuenta el valor del dinero en el tiempo (hoy
en día tendrían otro valor), debemos actualizarlos a través de una tasa de
descuento.

3. Calcular relación costo-beneficio: a continuación, dividimos el valor actual

de los beneficios entre el valor actual de los costos del proyecto.

4. Analizar relación costo-beneficio: si el valor resultante es mayor que 1 el

proyecto es rentable, pero si es igual o menor que 1 el proyecto no es
rentable y, por tanto, no es viable ya que significa que los beneficios serán
iguales o menores que los costos de inversión o costos totales.

5. Comparar con otros proyectos: si tendríamos que elegir entre varios

proyectos de inversión, teniendo en cuenta el análisis costo-beneficio,
elegiríamos aquél que tenga la mayor relación costo-beneficio.

Fuente 2:

El análisis del costo-beneficio es un proceso que, de manera general, se refiere a

la evaluación de un determinado proyecto, de un esquema para tomar decisiones
de cualquier tipo. Ello involucra, de manera explícita o implícita, determinar el total
de costos y beneficios de todas las alternativas para seleccionar la mejor o más
rentable. Este análisis se deriva de la conjunción de diversas técnicas de gerencia
y de finanzas con los campos de las ciencias sociales, que presentan tanto los
costos como los beneficios en unidades de medición estándar usualmente
monetarias para que se puedan comparar directamente.

La técnica del costo-beneficio se relaciona de manera directa con la teoría de la

decisión. Pretende determinar la conveniencia de un proyecto a partir de los
costos y beneficios que se derivan de él. Dicha relación de elementos, expresados
en términos monetarios, conlleva la posterior valoración y evaluación.

Este método puede aplicarse no solo al mundo empresarial, sino también a obras
sociales, proyectos colectivos o individuales, entre otros, para lo cual se debe
prestar atención a la importancia y cuantificación de las consecuencias
económicas y/o sociales. La clave es encontrar o tomar la decisión adecuada, o
sea, la que aportará mayor rentabilidad, de un conjunto de posibles soluciones o
propuestas.

Es importante señalar que tomar una decisión implica elegir entre dos o más
cursos de acción alternativos, por lo que el costo de oportunidad es otro factor a
tener en cuenta, pues representa lo que se deja de ganar por haber rechazado el
valor de la siguiente mejor opción. Siguiendo esta lógica, uno de los preceptos que
propone el análisis costo-beneficio consiste en que no importa que tan adecuada
sea la solución otorgada a un problema, la alternativa, o la propuesta, pues no

pág. 20
dejará de tener un costo. En tal sentido, algunas cuestiones clave en el análisis
serían:

 Si el costo de la solución sobrepasa el del problema.

 Si la solución es más cara pero trae mejorías que no se cuantifican en
términos monetarios e influyen en el aspecto social.
 ¿Se debe considerar aquella información que afecta los posibles cursos de
acción?

En fin, cada análisis es diferente y requiere un pensamiento cuidadoso e

innovador, pero eso no quiere decir que no se tenga una secuencia estándar de
pasos y procedimientos a seguir. Los pasos comunes a realizar en el análisis
costo-beneficio serían los siguientes:

 Formular los objetivos y metas que se persiguen con el proyecto.

 Examinar los requerimientos y limitaciones.
 Determinar y/o estimar en términos monetarios los costos y beneficios
relacionados con cada opción.
 Incorporar toda la información importante además de los datos de costos y
beneficios de cada una de las alternativas.
 Distribuir los costos y beneficios a través del tiempo.
 Convertir la corriente futura de costos y beneficios a su valor actual.
 Establecer una relación donde los beneficios sean el numerador y los
costos el denominador (beneficios/costos).
 Realizar una comparación de las relaciones beneficios-costos en las
diferentes propuestas. La mejor solución es la que ofrece el más alto nivel
de relación.
 Determinar el beneficio neto de cada posible decisión. Se calcula mediante
la diferencia entre los beneficios presentes y futuros y los costos en los que
se incurre para su realización.
 Evaluar y comparar cada alternativa.
 Tomar la decisión en función del enfoque utilizado, las metas y los
objetivos.

Para decidir la mejor alternativa se pueden considerar otras herramientas, entre

las que se destaca la utilización de métodos y criterios de valoración de proyectos
que toman en cuenta el valor del dinero en el tiempo. Por otra parte, existen
diversos enfoques en el análisis del costo-beneficio, pero, en esencia, el objetivo
es la cuantificación máxima posible de los beneficios y costos en términos
monetarios. Por ende, para el logro de los pasos referidos, se deben dominar los
conceptos de este análisis.
pág. 21
pág. 22
Referencias
https://es.wikipedia.org/wiki/Especificación_de_requisitos_de_software
http://www.icesi.edu.co/departamentos/tecnologias_informacion_comunicaciones/p
royectos/lisa/home/analisis/srs/srs
https://es.calameo.com/read/0057603408626f6748c17
https://www.studocu.com/es/document/universidad-catolica-de-
colombia/ingenieria-de-software/otros/ejemplo-formato-ieee-830/5670142/view
https://www.netmind.es/knowledge-center/trazabilidad-de-requisitos-hasta-que-
nivel/
https://www.crecenegocios.com/analisis-costo-beneficio/
http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S2073-60612017000200022
https://es.slideshare.net/SergioRios/unidad-12-a-introduccin-a-los-proceso-de-
software-modelos-tradicionales
https://www.gestiopolis.com/que-es-el-estudio-de-factibilidad-en-un-proyecto/
https://diagramasuml.com
https://www.teatroabadia.com/es/uploads/documentos/iagramas_del_uml.pdf

pág. 23