RESUMEN DE LA UNIDAD 1.

Unidad 1: Análisis
Especificación de requisitos: proceso de redacción o registro de los
requisitos. Se pueden utilizar tanto el lenguaje natural, como modelos
gráficos.
El análisis de requisitos es una de las tareas más importantes en el ciclo
de vida del desarrollo de software, puesto que en ella se determinan
los “planos” de la nueva aplicación.
Características de una buena ERS
1. Correcta: La ERS es correcta si y sólo si todo requisito que figura en ella
refleja alguna necesidad real. La corrección de la ERS implica que el
sistema implementado será el sistema deseado.
2. No ambigua: Un documento es no ambiguo si y solo si cada requisito
descrito tiene una única interpretación. Cada característica del
producto final debe ser descrita utilizando un término único.
3. Completa:
1. Incluye todos los requisitos significativos del software
(relacionados con la funcionalidad, ejecución, diseño, atributos
de calidad o interfaces externas).
2. Cumple con el estándar utilizado.
3. Aparecen etiquetadas todas las figuras, tablas, diagramas, etc.,
así como definidos todos los términos y unidades de medida
empleados.
4. Verificable: Se dice que es verificable si existe algún proceso no
excesivamente costoso por el cual una persona o una máquina pueda
chequear que el software satisface dicho requerimiento.
5. Consistente: Una ERS es consistente si y sólo si ningún conjunto de
requisitos descritos en ella son contradictorios o entran en conflicto.
6. Clasificada: Los requisitos pueden clasificarse por diversos criterios:
1. Importancia: Pueden ser esenciales, condicionales u opcionales.
2. Estabilidad: Cambios que pueden afectar al requisito
7. Modificable: Una ERS es modificable si cualquier cambio puede
realizarse de manera fácil, completa y consistente.
8. Explorable: Una ERS es explorable si el origen de cada requerimiento
es claro tanto hacia atrás (origen que puede ser un documento, una
persona etc.) como hacia delante (componentes del sistema que
realizan dicho requisito).
9. Utilizable durante las tareas de mantenimiento y uso: En la ERS
también se deben tener en cuenta las necesidades de mantenimiento.
El personal que no ha intervenido directamente en el desarrollo debe
ser capaz de encargarse de su mantenimiento. Así, dicha ERS actúa a
modo de plano de la aplicación, permitiendo incluso modificaciones
que no requieran un cambio en el diseño.
1.1.1 Norma IEEE830
A continuación se muestra la estructura de la ERS propuesta por el IEEE
en su estándar 830
1 Introducción
1.1 Propósito
1.2 Ámbito del Sistema
1.3 Definiciones, Acrónimos y Abreviaturas
1.4 Referencias
1.5 Visión general del documento
2 Descripción General
2.1 Perspectiva del Producto
2.2 Funciones del Producto
2.3 Características de los usuarios
2.4 Restricciones
2.5 Suposiciones y Dependencias
2.6 Requisitos Futuros
3 Requisitos Específicos
3.1 Interfaces Externas
3.2 Funciones
3.3 Requisitos de Rendimiento
3.4 Restricciones de Diseño
3.5 Atributos del Sistema
3.6 Otros Requisitos
4 Apéndices
5 Índice

1.1.2Trazabilidad de requisitos
La trazabilidad en la Ingeniería de Software es una práctica de control
que ayuda a obtener el producto en el dominio de la solución lo más
exacto y fiable posible a las necesidades expresadas por el cliente en
el dominio del problema.
Según el estándar IEEE 830-1998, la trazabilidad es la habilidad para
seguir la vida de un requerimiento en ambos sentidos, hacia sus
orígenes o hacia su implementación a través de las especificaciones
generadas durante el proceso de desarrollo. Es un factor de calidad.
1.2Descripción de Procesos Actuales o Modelado de Negocios
El modelo de negocios es el estudio de la organización.
Se examina la estructura de la organización
Examina el flujo de trabajo de la organización, los procesos
principales dentro de la compañía y como ellos trabajan.
Examina las entidades externas, cualquier individuo u otras
compañías, y como interactúan con el negocio, y observar las
implicaciones de esas interacciones.

¿Porque modelar el negocio?

Conocimiento de la visión organizacional
Re-ingeniería de procesos del negocio
Entrenamiento
Contexto para una solución de software
*¿Cuándo será necesario hacer el modelo del negocio?
 Cuando el grupo de trabajo es nuevo en la organización.
 Cuando la organización a enfrentado un reciente proceso de re-
ingeniería de negocios.
  Cuando la organización esta planificando un proceso de re-
ingeniería de negocios.
 Cuando el software a construir será utilizado por una porción
importante de la organización.
 Existen flujos de trabajo complejos dentro de la organización
que no están documentados.
 Cuando se es un consultor en una organización en la cuál no se
a trabajado antes.
*No es necesario cuando:
 Cuando se tiene un conocimiento de la estructura de la
organización, de las metas, de la visión y de los
clientes/usuarios.
 Cuando el software a construir será usado por una pequeña
parte de la organización, y no tiene un efectos en el resto del
negocio.
 Cuando los flujos de trabajo de la organización están bien
documentados.
 Cuando el tiempo lo permita, no todos los procesos tiene el
tiempo necesario para completar un análisis de negocio.
Etapas del modelado del negocio
1. Procesos de negocio y objetivos
2. Caso de uso del negocio
3. Roles
4. Modelar escenarios
(diagramas de secuencia, diagramas de actividades).
1. Especificar las informaciones y actividades incluidas
en cada diagrama de actividad.
Conceptos de modelado
Actores de negocios:
Un actor del negocio, es cualquier persona o cualquier cosa externa a
la organización pero que obra recíprocamente con ella.

Cliente

(f rom Business Use-Case Model)

Trabajadores del negocio (Business Workers)

Es un rol dentro de la organización. Importante, los trabajadores
del negocio son roles no posiciones. Una persona puede tener
varios roles, pero una sola posición.

Cliente

(f rom Business Use-Case Model)

Caso de uso de negocios

Lo que hace la organización

Registrar Pedido

(from Business Use-Case Model)

 Documentación

Proceso de
Negocio

Objetivo

Descripción
UML
Prioridad

El modelo de negocios en el proceso iterativo

Primera Forma
• La primera, es terminar primero el modelo de negocios y luego
comenzar con las iteraciones.
• Ventaja es que permite comprender completamente el
comportamiento del negocio antes de comenzar el diseño del sistema
• Desventaja es que los usuarios o clientes del extremo pueden desear
conseguir el sistema rápidamente y no estarán dispuesto a esperar por
el análisis del negocio primero

Segunda Forma
• La segunda forma, es incluir el modelo de negocios dentro del ciclo de
vida.
• la ventaja de dejarle estudiar la organización a medida que se crea el
sistema de software.
• se corre el riesgo del mal entendiendo de la organización, y por lo
tanto el sistema de software en construcción no resuelve
absolutamente las necesidades
Objetivo

Procesos de Negocio
Reglas de Negocio
Flujo de Tareas.
Agentes. - Describen restricciones y
Información y Reglas comportamientos.
Negocio. - NO son requisitos, pero
influyen en ellos.
- Determina políticas y
estructuras de la
información.
 1.3 Diagramas UML
2. El Lenguaje Unificado de Modelado (UML) fue creado para
forjar un lenguaje de modelado visual común y semántica y
sintácticamente rico para la arquitectura, el diseño y la
implementación de sistemas de software complejos, tanto en
estructura como en comportamiento. UML tiene aplicaciones
más allá del desarrollo de software, p. ej., en el flujo de
procesos en la fabricación.
3. En general, los diagramas UML describen los límites, la
estructura y el comportamiento del sistema y los objetos que
contiene. UML no es un lenguaje de programación. UML
guarda una relación directa con el análisis y el diseño
orientados a objetos.

Funcionales De objetos Dinámicos

• Se trata de • Se trata de
diagramas de • Los diagramas
diagramas de de interacción,
casos de uso clases que los diagramas
que describen describen la de máquina de
la estructura del estados y los
funcionalidad sistema en diagramas de
términos de actividades se
del sistema usan para
desde el objetos,
atributos, describir el
punto de comportamient
vista del asociaciones
o interno del
y sistema.
usuario.
operaciones.
Tipos de diagramas UML
UML usa elementos y los asocia de diferentes formas para formar diagramas que
representan aspectos estáticos o estructurales de un sistema, y diagramas de
comportamiento, que captan los aspectos dinámicos de un sistema.

Diagramas UML estructurales

 Diagrama de clases El diagrama UML más comúnmente usado, y la base principal

de toda solución orientada a objetos. Las clases dentro de un sistema, atributos y
operaciones, y la relación entre cada clase. Las clases se agrupan para crear
diagramas de clases al crear diagramas de sistemas grandes.

 Diagrama de componentes Muestra la relación estructural de los elementos del

sistema de software, muy frecuentemente empleados al trabajar con sistemas
complejos con componentes múltiples. Los componentes se comunican por medio
de interfaces.

 Diagrama de estructura compuesta Los diagramas de estructura compuesta se

usan para mostrar la estructura interna de una clase.

 Diagrama de implementación Ilustra el hardware del sistema y su software. Útil

cuando se implementa una solución de software en múltiples máquinas con
configuraciones únicas.

 Diagrama de objetos Muestra la relación entre objetos por medio de ejemplos del
mundo real e ilustra cómo se verá un sistema en un momento dado. Dado que los
datos están disponibles dentro de los objetos, estos pueden usarse para clarificar
relaciones entre objetos.

 Diagrama de paquetes Hay dos tipos especiales de dependencias que se definen

entre paquetes: la importación de paquetes y la fusión de paquetes. Los paquetes
pueden representar los diferentes niveles de un sistema para revelar la arquitectura.
Se pueden marcar las dependencias de paquetes para mostrar el mecanismo de
comunicación entre niveles.

Diagramas UML de comportamiento

 Diagramas de actividades Flujos de trabajo de negocios u operativos

representados gráficamente para mostrar la actividad de alguna parte o componente
del sistema. Los diagramas de actividades se usan como una alternativa a los
diagramas de máquina de estados.
  Diagrama de comunicación Similar a los diagramas de secuencia, pero el enfoque
está en los mensajes que se pasan entre objetos. La misma información se puede
representar usando un diagrama de secuencia y objetos diferentes.

 Diagrama de panorama de interacciones Hay siete tipos de diagramas de

interacciones. Este diagrama muestra la secuencia en la cual actúan.

 Diagrama de secuencia Muestra cómo los objetos interactúan entre sí y el orden de

la ocurrencia. Representan interacciones para un escenario concreto.

 Diagrama de máquina de estados Similar a los diagramas de actividades,

describen el comportamiento de objetos que se comportan de diversas formas en su
estado actual.

 Diagrama de temporización Al igual que en los diagramas de secuencia, se

representa el comportamiento de los objetos en un período de tiempo dado. Si hay
un solo objeto, el diagrama es simple. Si hay más de un objeto, las interacciones de
los objetos se muestran durante ese período de tiempo particular.

 Diagrama de caso de uso Representa una funcionalidad particular de un sistema.

Se crea para ilustrar cómo se relacionan las funcionalidades con sus controladores
(actores) internos/externos.

Cómo crear un diagrama UML:

Tutoriales y ejemplos
Para ilustrar cómo crear diferentes tipos de diagramas UML, prueba uno o todos estos
tutoriales para guiarte a través del proceso de trazar diagramas tanto estructurales como de
comportamiento.

Ejemplos de tutoriales de diagramas estructurales

DIAGRAMAS DE CLASES

Los diagramas de clases representan las estructuras estáticas de un sistema, incluidas sus
clases, atributos, operaciones y objetos. Un diagrama de clases puede mostrar datos
computacionales u organizacionales en la forma de clases de implementación y clases
lógicas, respectivamente. Puede haber superposición entre estos dos grupos.

1. Las clases se representan con una forma rectangular dividida en tercios. La sección
superior muestra el nombre de la clase, mientras que la sección central contiene los
 atributos de la clase. La sección inferior muestra las operaciones de la clase
(también conocidas como métodos).

2. Agrega formas de clases a tu diagrama de clases para modelar la relación entre esos
objetos. Además, podría ser necesario que agregues subclases.

3. Usa líneas para representar asociación, traspaso, multiplicidad y otras relaciones

entre clases y subclases. Tu estilo de notación preferido informará la notación de
estas líneas.

DIAGRAMAS DE COMPONENTES

Los diagramas de componentes muestran cómo se combinan los componentes para formar

componentes más grandes o sistemas de software. Estos diagramas están diseñados para
modelar las dependencias de cada componente en el sistema. Un componente es algo
necesario para ejecutar una función de estereotipo. Un estereotipo de componente puede
constar de ejecutables, documentos, tablas de bases de datos, archivos o archivos de
bibliotecas.

1. Representa un componente con una forma rectangular. Debe tener dos rectángulos
pequeños en un lado o mostrar un icono con esa forma.

2. Agrega líneas entre formas de componentes para representar las relaciones

pertinentes.
DIAGRAMAS DE IMPLEMENTACIÓN

Un diagrama de implementación modela la implementación física y la estructura de los

componentes de hardware. Los diagramas de implementación muestran dónde y cómo
operarán los componentes de un sistema en conjunto con los demás.

1. Al trazar un diagrama de implementación, usa la misma notación que usas para un

diagrama de componentes.

2. Usa un cubo 3D para modelar un nodo (lo cual representa una máquina física o
máquina virtual).

3. Etiqueta el nodo con el mismo estilo que se usa para los diagramas de secuencia.
Agrega otros nodos según sea necesario, luego conéctalos con líneas.
 1.4 Estudio de factibilidad.
El ámbito del proyecto
Es importante que tanto el cliente como el desarrollador tengan la misma visión del
proyecto, por lo que la comunicación inicial es importante.

No solo se trata de que el cliente diga lo que requiere, porque muchas veces esta
lista de requisitos escapa de los limites del problema, así que lo primero será partir
de la necesidad o problema que da origen a la solicitud de desarrollo, dado que
dicha solicitud no es siempre hecha por quien esta mas ligado con el problema,
entendiendo que, quien solicita el software, usualmente no es quien lo va a tener
que utilizar, por lo que los requisitos e incluso el problema varían según el nivel de
la organización donde nos encontremos

Como podemos ver, en las partes altas de la organización la información que se

requiere es menos detallada, al gerente no necesitar saber cuando venido x
empleado hoy, sino cuanto se vendió en general, la función del sistema será apoyar
a la toma de decisiones; mientras que en el nivel mas bajo, se requiere un mayor
detalle y la función principal es llevar el control de las transacciones, mas que
procesar y generar información
Una vez que tenemos claro el problema, podremos definir el objetivo del proyecto,
el cual de forma intrínseca debe ser dar solución o respuesta a la necesidad que
origino la solicitud de desarrollo y con ello podremos dar inicio a los estudios
específicos para determinar la factibilidad del proyecto.

Factibilidad tecnica
Cuando hablamos de factibilidad tecnica, nos referimos al conjunto tecnologías que
la organización deberá tener, para que el software que se desarrolle funcione tal y
como ellos esperan que funcione, en este sentido comprende:

 Computadoras
 Periféricos
 Instalaciones y servicios de red e Internet
 Instalaciones eléctricas
 Espacios físicos.
Como podemos ver, es bastante amplio, ya que debemos determinar si hay las
condiciones físicas para que el cliente implemente la solución al problema, pero en
el estudio deberemos ir un poco mas allá, ya que si no cuenta con el 100% de lo que
se requiere a nivel físico, corresponde especificar que es lo que hace falta para
llegar a ese 100%.

Suponiendo que el cliente es una biblioteca que desea automatizar su sistema de

prestamos, empleando lector de código de barras y tarjetas con chip para los
usuarios, hay que determinar cual será a nivel técnica la mejor solución, para el
lector de código de barras lo puede comprar, pero para la emisión de tarjetas, tal
vez tenga que contratar el servicio de un tercero o en su caso sustituir las tarjetas
con chip por tarjetas con banda magnética o código de barras que ellos podrían
generar, en este punto igual debemos de considerar como desea ese biblioteca que
opere todo el proceso.

Pero aun no podemos llegar a determinar si es factible o no, pues para que dichas
disposiciones técnicas funcionen se debe de ver si hay el personal y el presupuesto
para realizarlo.

Factibilidad operativa
En los estudios de factibilidad operativa debemos analizar los recursos humanos
con los que cuenta la organización y la estructura organizacional de la misma.

En lo que respecta a los recursos humanos, debemos de ser la organización cuenta

con personal con los conocimientos técnicos necesarios para operar el sistema que
se desarrollara, en este punto es claro que lo primero que se les pedirá son
conocimientos básicos de computo, claro esta que acceder a las redes sociales y
publicar en ellas no califica como conocimientos básicos de computo.
Es importante delimitar este estudio, pues lo único que nos interesa es encontrar al
personal que cuente con el perfil ideal para operar el sistema, en ningún momento
se pretende llegar a hacer una auditoria de puestos.

Debemos de tener claro de que cuando se desarrolla un sistema a la medida, las

personas que usaran el sistema van a necesitar capacitación y adiestramiento en el
uso del mismo.

La segunda parte del estudio, corresponde a estudiar la estructura orgánica de la

empresa, dado que la implementación de un nuevo sistema, puede requerir en un
momento determinado la creación de nuevos puestos o incluso áreas que antes no
existían,

Una vez concluido el estudio debemos de tener respuestas a los siguientes puntos
 ¿ Cuáles son las necesidades de capacitación ?
 ¿Será necesario crear nuevos puestos?
 ¿Será necesario crear nuevas áreas dentro de la empresa?
 ¿Se contratará nuevo personal ?
 ¿En qué modalidad se contratara el personal?
Factibilidad económica

En este punto es donde contrastaremos el presupuesto desarrollo, contra el

presupuesto del cliente, este último constituido por lo que el cliente esta dispuesto
a invertir o que tiene disponible para invertir.

Ahora bien, lo importante será como integrará el presupuesto de desarrollo, ya que

si no lo detallamos bien podemos caer en inconvenientes y retrasos, por lo que
derivado de todo el trabajo previo ya debemos de tener una idea del tamaño del
proyecto, en cuanto al numero de modelos, funciones, complejidad del mismo y
licencias, pero veamos el detalle de lo que deberá de incluir este presupuesto de
desarrollo:

Derivado dela factibilidad tecnica.

 Equipos de computo y periféricos que se necesita adquirir.
 Adecuación de las instalaciones
 Instalación de los equipos
 Instalación de los programas bajo licencia.
 Licencias de programas o bibliotecas especiales
Derivado de la factibilidad operativa
 Cursos de capacitación
 Modificación de la estrutura (costos de modificación de manuales de organización,
selección de personal )
Derivados de las etapas de desarrollo
 Mano de obra, ya sea en horas hombre o en lineas de codigo
 Papelería, electricidad y consumibles
 Capacitación
 Diseño de pruebas
 Tiempo de pruebas
Derivados de la instalación del sistema
 Mano de obra para la instalación
 Traducción y preparación de datos
 Soporte inicial
 Gastos varios
Algunos de estos puntos requieren ser ampliados, como las licencias de bibliotecas,
esto se refiere a los costos de las licencias para usar determinadas bibliotecas que
fueron creadas por otros desarrolladores y que no ahorraran tiempo, por ejemplo la
biblioteca para que PHP se pueda conectar con escáners TWAIN.

En la etapa de desarrollo, puede llegar a presentarse el caso de que no tengamos

programadores que tengan conocimientos en un aspecto especifico y deberemos de
invertir en la capacitación de nuestros programadores para poder cumplir con lo
que el cliente requiere.

Los gastos varios de la instalación se refieren a todos aquellos gastos derivados de

la logística de la instalación, como sería el transporte de hardware, el traslado de
personal para hacer la instalación, viáticos y demás costos derivados de dicha
actividad.

La traducción y preparación de datos, se refiere a las actividades que debamos

realizar para cargar en el sistema, los datos con los que comenzara a trabajar, estos
pueden provenir de un sistema alterno, un sistema anterior que será sustituido o
incluso documentación, estas actividades pueden no realizarse, si el cliente decide
que será su propio personal el que hará esta actividad.

La conclusión
Ahora llegamos a la parte mas importante, la conclusión, que en realidad rara vez
es una sola, ya que cuando el presupuesto de desarrollo es mayor al presupuesto
que el cliente tiene destinado, lo que se hace es elaborar una alternativa, en la cual
podemos suprimir ciertas funciones, modelos o características, con el fin de
ajustarnos al presupuesto del cliente, eso si, tratando de no perder el objetivo y la
funcionalidad, ya que de nada sirve desarrollar un sistema que el cliente puede
pagar pero que a final de cuentas no le resolverá su problema.

No se trata de abaratar costos, ni de entregar algo que no funcione, a fin de cuentas

el software es evolutivo, podemos dar al cliente funcionalidad básicas y después
agregarlas cuando el cliente tenga el recurso para agregarlas.

Un aspecto muy importante de la conclusión es mostrar y sobre todo sustentar los

beneficios que se obtendrán con la implementación del sistema, beneficios a nivel
económico, administrativo, publicitario y de competitividad.
 1.5Analisis de Costo-Beneficio.
La técnica de análisis coste/beneficio tiene como objetivo fundamental
proporcionar una medida de los costes en que se incurre en la realización
de un proyecto y comparar dichos costes previstos con los beneficios
esperados de la realización de dicho proyecto. Esta medida o estimación
servirá para:
 Valorar la necesidad y oportunidad de acometer la realizació n del
proyecto.
 Seleccionar la alternativa más beneficiosa para la realizació n del
proyecto.
 Estimar adecuadamente los recursos econó micos necesarios en el
plazo de realizació n del proyecto.
Es de destacar la necesidad cada vez mayor de guiarse por criterios
económicos y no sólo técnicos para la planificación de trabajos y
proyectos. Por ello se hace una primera introducción sobre las técnicas y
métodos de evaluación de conceptos económicos, con el fin de
proporcionar a los profesionales criterios que les ayuden en la planificación
de proyectos y evaluación de alternativas.

Conceptos
Punto de amortización (Break-Even Point)
Es el momento en el tiempo en que el conjunto de beneficios obtenidos
por la explotación del nuevo sistema iguala al conjunto de costes de todo
tipo que ha ocasionado. A partir del punto de amortización (Break-Even
Point), el sistema entra en fase de aportar beneficios netos a la
organización.
Periodo de amortizació n (PayBack)
Es el periodo de tiempo que transcurre desde que los costes son máximos
hasta que se alcanza el punto de amortización (Break-Even Point), es decir,
en cuanto el sistema empieza a aportar beneficios. Cuanto menor sea el
periodo de amortización (Payback) de un Sistema, más atractivo será para
la organización acometer su implantación.
Retorno de la Inversió n – ROI (Return of Investment)
Es el rendimiento de la inversión expresada en términos de porcentaje. Se
calcula mediante la fórmula siguiente:
ROI = 100 x (Beneficio Neto Anual – Coste Desarrollo Anualizado) /
Inversión Promedio
Siendo:
Beneficio Neto Anual: Es la ganancia que aporta el sistema como
consecuencia de su uso, es decir los beneficios obtenidos más los gastos
no incurridos. Deben restársele los gastos operacionales anuales y los de
mantenimiento del sistema.
Coste Desarrollo Anualizado: Total del gasto inicial de desarrollo del
sistema, dividido por los años que se supone que va a ser operativo.
Inversió n Promedio: Total de la inversión realizada (costes de desarrollo,
hardware, software, etc.) dividido por el total de conceptos en los que se
invierte.
Descripció n
Para la realización del análisis coste/beneficio se seguirán los siguientes
pasos:
1. Producir estimaciones de costes/beneficios.
2. Determinar la viabilidad del proyecto y su aceptació n.
1. PRODUCIR ESTIMACIONES DE COSTES-BENEFICIOS
Se realizará una lista de todo lo que es necesario para implementar el
sistema y una lista de los beneficios esperados del nuevo sistema.
En general, los costes suelen ser medibles y estimables en unidades
económicas, no así los beneficios, los cuales pueden ser tangibles o no
tangibles. En un análisis de costes y beneficios se deben considerar
aquellos aspectos tangibles, es decir, medibles en valores como dinero,
tiempo, etc., y no tangibles, es decir, no ponderables de una forma
objetiva.
Entre los beneficios no tangibles pueden estar:
 El aumento de cuentas debido a un mejor servicio a los clientes.
 La mejora en la toma de decisiones debido a una mejora en el soporte
informá tico.
La valoración de los beneficios no tangibles se debe estimar de una forma
subjetiva y será realizada por las áreas correspondientes.
A menudo es conveniente desglosar los costes estimados a lo largo del
proyecto, para ofrecer una información más detallada de la distribución de
los recursos de cara a la dirección.
En la estimación de costes se considerarán, entre otros, los siguientes
aspectos:
 Adquisició n de hardware y software: El que sea preciso para el
desarrollo, implantación y normal funcionamiento del sistema. Se debe
considerar la saturación de máquinas o sistemas actuales como
consecuencia de la entrada en vigor del nuevo sistema.
 Gastos de mantenimiento de hardware y software anteriores.
 Gastos de comunicaciones: Líneas, telé fono, correo, etc.
 Gastos de instalació n: Cableado, acondicionamiento de sala, recursos
humanos y materiales, gastos de viaje, etc.
 Coste de desarrollo del sistema.
 Gastos del mantenimiento del sistema: Coste anual.
 Gastos de consultoría: En caso de requerirse algún consultor externo
en cualquier etapa del proyecto.
 Gastos de formació n: De todo tipo (Desarrolladores, Operadores,
Implantadores, Usuario Final, etc.).
 Gastos de material: Papel, toner, etc.
 Costes derivados de la curva de aprendizaje: De todo el personal
involucrado: Desarrolladores, Técnicos de Sistemas, Operadores, y desde
luego, Usuarios.
 Costes financieros, de publicidad, etc.

En la estimación de beneficios se pueden considerar cuestiones como las

siguientes:
 Incremento de la productividad: Ahorro o mejor utilización de
recursos humanos.
 Ahorro de gastos de mantenimiento del sistema actual.
 Ahorros de adquisició n y mantenimiento de hardware y
software, o reutilizació n de plataformas sustituidas.
 Incremento de ventas o resultados, disminució n de costes:
Producidos por una mejora de la gestión (rotación de stock, “just in time”,
analítica de clientes, etc.).
 Ahorro de material de todo tipo: Sustituido por datos electrónicos
que proporciona el sistema, como por ejemplo: papel, correo, etc.
 Beneficios financieros.
 Otros beneficios tangibles: Ahorro de recursos externos,
consultoría, formación, etc.
 Beneficios intangibles: Incremento de la calidad del producto o
servicio, mejora de la imagen de la compañía, mejora en la atenció n al
cliente, mejora en la explotació n, etc.
 2. DETERMINAR LA VIABILIDAD DEL PROYECTO
Se basará en uno de los métodos siguientes:
Retorno de la Inversió n:
Este método consiste en calcular el coste y el beneficio anual, conociendo
el coste total al inicio del proyecto “C0”, para determinar en qué año se
recupera el coste total inicialmente estimado.

AÑO COSTE BENEFICIO BENEFICIO NETO

0 C0 0

1 C1 B1 B1 – C1

2 C2 B2 B2 – C2

n Cn Bn Bn – Cn

El año de recuperación de la inversión se produce cuando ∑ Beneficio

Neto = C0.
Valor Actual:
Este método permite tener en cuenta que un gasto invertido durante un
cierto tiempo produce un beneficio.
El método consiste en determinar el dinero que es viable invertir
inicialmente para que se recupere la inversión en un periodo de tiempo
definido previamente.
El resultado depende del tipo de interés (r) utilizado en la evaluación.
Se debe calcular, en primer lugar, el beneficio neto que se obtendrá cada
año. Dicho beneficio no es real, ya que se debe estimar el valor real de
dicha cantidad en el año n.
Para ello se aplica la fórmula:
Valor Actual = Beneficio neto / (1 + r/100)n siendo n = año 1,..,i
Se debe estudiar en cuántos años se recupera la inversión realizada
inicialmente, o bien, si en un periodo de años fijado previamente se retorna
la inversión y, por tanto, es viable el proyecto.
Si la inversión es el C0, se determinará la viabilidad del proyecto
consultando la siguiente tabla:

AÑO COSTE BENEFICIO VALOR ACTUAL

0 C0

1 C1 B1 V.A1 = (B1 – C1) / (1 + r / 100)

2 C2 B2 V.A2 = (B2 – C2) / (1 + r / 100) 2

n Cn Bn V.An = (Bn – Cn) / (1 + r / 100) n

El proyecto será viable si ∑ VAi > C0 a lo largo del periodo fijado.