IMPLEMENTACIÓN DEL SISTEMA DE INFORMACIÓN

Jesús Jiménez

19701693

Evaluación del prototipo

El desarrollar sistemas interactivos implica utilizar ciclos de vida iterativos que permitan el desarrollar sistemas centrados en el usuario, es decir, que sean usables. Es evidente, por tanto, que la usabilidad es un objetivo fundamental a conseguir en una aplicación interactiva. El concepto de usabilidad es fácil de asimilar aunque conseguir que un producto sea usable ya es más difícil. En general, cuando se diseña un producto se está más preocupado en la funcionalidad que en la usabilidad. La aplicación de los métodos de evaluación de la usabilidad permite garantizar la obtención de la misma en una aplicación interactiva.

La evaluación de la usabilidad implica analizar el entorno y los usuarios que van a utilizar el producto, probar un prototipo, diseño o producto con una selección de usuarios, analizar el diseño con expertos, etc., en definitiva, conseguir su integración en el ciclo permitiendo la realización de un diseño centrado en el usuario.

El diseño y desarrollo de sistemas interactivos centrados en el usuario eva-luando la usabilidad nos permitirá desarrollar productos que produzcan más satisfacción al usuario, reducir los costes de mantenimiento porque al usuario le será más fácil utilizarlo, reducirá el coste de rediseño debido que a se han realizado evaluaciones ya desde el inicio del diseño y por tanto el diseño estará mucho más probado lo que implicará un menor coste y un mayor prestigio para los desarrolladores, una mayor audiencia al estudiar aspectos culturales y en general una mejor introducción del producto en el mercado. La evaluación de la usabilidad nos permitirá garantizar la usabilidad de la interfaz.

Esta etapa a pesar de estar situada como última en la lista del método propuesto, es un proceso que desde principio hasta el fin del proyecto se estará llevando a cabo. Durante las etapas de diseño y construcción, hay que tener la precaución de someter a prueba su funcionamiento, para que si alguna falla se llega a presentar no afecte al conjunto de elementos que conforman el prototipo. Por lo tanto, la evaluación es un proceso sistemático que prueba los elementos del prototipo y que debe realizarse durante las diferentes etapas de su desarrollo. Su propósito es recopilar información sobre las posibles fallas del modelo, con el fin de superarlas, tomando en cuenta tanto las características de los elementos del prototipo como sus efectos en la reacción de los Usuarios cuando lo utilizan.

Se evalúan los efectos que haya producido en el Usuario, en cuanto a logros, actitud e interés; en qué medida los contenidos han “quedado” en el Usuario o no, la monotonía que representa para ellos el material expuesto, la facilidad de acceso, la visualización del contenido, la disponibilidad del prototipo en el servidor, la velocidad de la navegación, etc. Una vez que todos los elementos en forma individual han sido probados, se procede a la prueba en conjunto de los mismos, esto para comprobar que funcionan perfectamente; en

este momento pueden surgir problemas, que quizás lleven a rediseñar alguna parte del modelo, o incluso a desecharlo completamente por no ajustarse a los requerimientos señalados.

Las pruebas de sistema buscan discrepancias entre el programa y sus objetivos o requerimientos, enfocándose en los errores hechos durante la transición del proceso al diseñar la especificación funcional. Esto hace a las pruebas de sistema un proceso vital de pruebas, ya que en términos del producto, número de errores hechos, y severidad de esos errores, es un paso en el ciclo de desarrollo generalmente propenso a la mayoría de los errores.

Las pruebas de sistema no son procesos para probar las funciones del sistema o del programa completo, porque ésta sería redundante con el proceso de las pruebas funcionales. Las pruebas del sistema tienen un propósito particular: para comparar el sistema o el programa con sus objetivos originales (Requerimientos funcionales y no funcionales).

Pruebas:

Las pruebas de sistema no se limitan a los sistemas. Si el producto es un programa, la prueba del sistema es el proceso de procurar demostrar cómo el programa, en su totalidad, no resuelve sus objetivos o requerimientos.

Las pruebas de sistema, por definición, son imposibles si no están los requerimientos por escrito, mensurables para el producto.

Las pruebas de sistema tienen como objetivo ejercitar profundamente el sistema comprobando la integración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica.

Son pruebas de integración del sistema de información completo, y permiten probar el sistema en su conjunto y con otros sistemas con los que se relaciona para verificar que las especificaciones funcionales y técnicas se cumplen. Dan una visión muy similar a su comportamiento en el entorno de producción.

TIPOS DE PRUEBAS:

PRUEBAS DE FUNCIONALIDAD

Pruebas Funcionales: Se enfoca a validar funcionalidades específicas provistas por servicios requeridos, métodos, o casos de uso. Estas pruebas se implementan y ejecutan a nivel de unidades, unidades integradas, aplicaciones y sistemas.

Pruebas de Seguridad: Pruebas enfocadas en asegurar que la data o el sistema puede ser accesado solamente por aquellos actores autorizados.

Pruebas de Volumen: Pruebas enfocadas en la verificación de la habilidad de manejar grandes cantidades de data, bien sea como entrada, salida o residente en una base de datos.

Pruebas de Confiabilidad: Pruebas de Integridad: Se enfocan en probar la robustez (resistencia a fallas) y el uso adecuado del lenguaje, sintaxis y uso de recursos. Este tipo de prueba puede aplicarse tanto a unidades como a integración de unidades.

Pruebas de Estructura: Estas pruebas se enfocan en hallar problemas de adherencia del elemento objetivo a su diseño y formación. Típicamente, estas pruebas se realizan sobre aplicaciones Web, asegurando que todos los enlaces están conectados, los controles adecuados se muestran, y no hay contenido inaccesible.

Pruebas de Stress: Este tipo de prueba se enfoca a evaluar el comportamiento del sistema baso condiciones anormales. Stress del sistema se refiere a extrema carga, memoria insuficiente, no disponibilidad de servicios y hardware o recursos compartidos limitados. Este tipo de prueba permite comprender mejor cómo y qué áreas del sistema colapsarán, de este modo es posible planificar contingencias y actualizar el mantenimiento y planear y asignar recursos de antemano.

TIPOS DE PRUEBA PARA DESEMPEÑO

Pruebas de Benchmark: Compara el desempeño del elemento objetivo de la prueba con un sistema conocido y una carga de trabajo definida.

Pruebas de Contención: Validar que el elemento que se prueba maneja adecuadamente cuando muchos actores solicitan el mismo recurso.

Pruebas de Carga: Validar y evaluar aceptabilidad de un elemento de un sistema sobre diferentes cargas de trabajo mientras el sistema permanece constante. Generalmente se incluye simulación de cargas de trabajo promedio y pico que puedan ocurrir dentro de la tolerancia operacional normal.

Pruebas de Perfil de Desempeño: Monitorea el perfil en el tiempo incluyendo flujo de ejecución, acceso a data, llamadas a funciones para identificar cuellos de botella y procesos ineficientes.

TIPOS DE PRUEBA PARA SOPORTABILIDAD

Pruebas de Configuración: Se enfocan en evaluar aquellos elementos configurados para diferentes hardwares y/o configuraciones de software. Pueden implementarse como pruebas de rendimiento del sistema.

Pruebas de Instalación: Se enfoca en evaluar que el elemento a probar se instala como se indica, en diferentes hardware y /o configuraciones de sistemas de software y bajo diferentes condiciones (tales como espacio insuficiente en disco, interrupción de electricidad). Este tipo de prueba se aplica y ejecuta sobre aplicaciones y sistemas

PRUEBAS ALFA Y BETA

Cuando se construye software a medida para un cliente, se lleva a cabo una serie de pruebas de aceptación para permitir que el cliente valide todos los requisitos. La mayoría de los desarrolladores de productos de software llevan a cabo un proceso denominado pruebas alfa y beta para descubrir errores que parezca que sólo el usuario final puede descubrir.

Prueba alfa: se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado.

Prueba beta: se llevan a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no está presente normalmente. Así, la prueba beta es una aplicación en vivo del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas que encuentra durante la prueba beta e informa a intervalos regulares al desarrollador.

DOCUMENTACION

La documentación es un conjunto de elementos registrados sobre cualquier soporte que permita instruir o informar acerca de algo, en función de las necesidades específicas de aquellos que la utilizan.

Su Importancia

Constituye el respaldo formal de la información.

Es el elemento integrador que permite la apreciación unitaria y conjunta del sistema.

Facilita el conocimiento, interpretación, comprensión y divulgación del sistema.

Constituye un elemento imprescindible para el control interno en general y del sistema en particular; facilita el parámetro de referencia contra el cual se analizará y/o enjuiciará su comportamiento real.

Elimina los riesgos de dependencia con respecto a determinados individuos que conocen el sistema.

Es un elemento fundamental para la adecuada capacitación de los usuarios del sistema y facilita la comunicación con los mismos.

 

Modelos de formularios utilizados para documentar los sistemas de información:

 

Hoja de diseño de archivos o registros Índice de archivos Hoja de diagramación Hoja de diseño de salidas impresas y/o formularios Hoja de diseño de formatos de pantalla Hoja de programación Índice de programas Tabla de decisiones y/o alternativas Hoja de especificaciones del programa

La documentación básica necesaria de un sistema de información deberá contar con: 

Carpeta de papeles de trabajo (análisis):

Síntesis del documento de generación Presupuesto o plan de fijación de tareas Documentación del relevamiento detallado Formularios o comprobantes analizados Papeles de trabajo del análisis Estudio de factibilidad y diagnóstico

Carpeta de sistemas (diseño global):

Fijación de los objetivos del sistema Descripción global del sistema Modelo lógico del sistema (DFD, diccionario de datos, especificación de la

lógica) Diseño de entradas y salidas Normas y procedimientos para los usuarios (en

operaciones de rutina, de respaldo, de emergencia, de recupero, de uso de back-up).

Recursos materiales y humanos necesarios Estudio técnico-económico acerca de la posibilidad de procesar el sistema

mediante el uso de un computador

 

 

Carpeta de programas (diseño detallado):

Descripción detallista del programa Diagrama de lógica Descripción de entradas Descripción de salidas Descripción de archivos Tablas, cuadros de control de consistencia y parámetros utilizados Controles del programa sobre archivos y datos

Carpeta de operaciones:

Normas de control de entradas, salidas y de procesamientos Normas de operación, de recupero, de back-up, de seguridad de archivos Cronograma de procesos Descripción de usuarios

 

En esta tarea se recoge toda la información necesaria para la especificación de la documentación a entregar al usuario, que incluirá los manuales de usuario y, cuando proceda, los manuales de explotación.

Para ello, es necesario definir, entre otros, los siguientes aspectos:

- Tipo de documentos y estándares a seguir en la elaboración de los mismos.

- Formato en el que se desarrollarán.

- Estructura.

- Soporte en el que se van a generar.

- Distribución y mantenimiento de la documentación y copias a editar.

- Control de versiones.

Productos

De entrada

· Catálogo de Requisitos (DSI 1.2)

· Diseño de la Arquitectura del Sistema (DSI 7.2)

· Entorno Tecnológico del Sistema (DSI 7.2)

De salida

· Catálogo de Requisitos

Prácticas

· Catalogación

· Sesiones de Trabajo

Participantes

· Equipo del Proyecto

· Usuarios Expertos

· Responsable de Operación

EL MANUAL DE USUARIO

El manual de usuario es un documento técnico de un determinado sistema que intenta dar asistencia que sus usuarios.

Los manuales de usuario generalmente son incluidos a dispositivos electrónicos, hardware de computadora y aplicaciones. El manual de usuario puede venir tanto en forma de libro como en forma de documento digital, e incluso poder ser consultado por internet.

En general, un manual de usuario debería poder ser entendido por cualquier usuario principiante, como así también serle útil a usuarios avanzados.

El manual de usuario tiene como objetivo instruir al usuario en el uso del sistema y la solución de los problemas que puedan suceder en la operación.

Un manual de usuario completo suele tener:

Introducción

Objetivos del sistema

Guía de uso

Sección de solución de problemas.

E-mail o teléfonos de soporte técnico.

Introducción: Debe contener una pequeña descripción del Sistema.

Como funciona, para que es, quien lo puede utilizar, etc.

Objetivos del Sistema: b Trata de enumerar cuales son los propósitos generales del Sistema, para que fue creado, que es lo que se intenta solucionar con él.

Guía de Uso: Mediante capturas de pantallas, se le hace conocer al usuario el funcionamiento total del Sistema, para que es que sirve cada elemento del Sistema, y todo lo que involucre su manejo.

Sección de Solución de Problemas: Es una pequeña sección en la que incluimos de la manera más explícita qué problemas o dudas con las más comunes que el usuario se puede encontrar y como es que se solucionan.

E-mail o teléfonos de soporte técnico: Aquí solamente ponemos los datos de contacto de la persona encargada de proveer el soporte técnico al sistema, ya sea por correo electrónico o por teléfono.

MANUAL TÉCNICO

El manual técnico va dirigido a la dirección de IT, al administrador del sistema y a otros desarrolladores de software para que puedan darle mantenimiento en caso que se requiera.

También puede ser utilizado por el departamento de auditoría de sistemas.

Debe contener:

Objetivo y alcances del sistema

Manual de Normas, políticas y procedimientos de la organización en las que se basa el sistema para su implementación.

Descripción de bases de datos y diagramas de relación

Diseño de reportes y pantallas.

Objetivo y alcances del sistema: Que es lo que intentamos solucionar con la aplicación del Sistema, y que es lo que en realidad solucionamos, ya que existen ocasiones en las que no se logra por completo solucionar todo lo que habíamos requerido.

Manual de Normas, políticas y procedimientos de la organización en las que se basa el sistema para su implementación. Consiste en un listado del reglamento de la organización en la que se va a implementar el sistema.

Descripción de bases de datos y diagramas de relación Se muestran las tablas de las bases de datos, con la descripción de cada uno de sus campos, además del diagrama de relación entre las tablas

Manual técnico Diseño de Reportes y Pantallas Esta parte consiste únicamente en detallar de la mejor manera posible, como es que están diseñados los reportes y pantallas, que partes las constituyen, etc

MANUAL DE PROCEDIMIENTOS

Un manual de procedimientos es el documento que contiene la descripción de actividades que deben seguirse en la realización de las funciones de una unidad administrativa, o de dos ò mas de ellas.

El manual incluye además los puestos o unidades administrativas que intervienen precisando su responsabilidad y participación.

Suelen contener información y ejemplos de formularios, autorizaciones o documentos necesarios, máquinas o equipo de oficina a utilizar y cualquier otro dato que pueda auxiliar al correcto desarrollo de las actividades dentro de la empresa.

En él se encuentra registrada y transmitida sin distorsión la información básica referente al funcionamiento de todas las unidades administrativas, facilita las labores de auditoría, la evaluación y control interno y su vigilancia, la conciencia en los empleados y en sus jefes de que el trabajo se está realizando o no adecuadamente.

UTILIDAD

Permite conocer el funcionamiento interno por lo que respecta a descripción de tareas, ubicación, requerimientos y a los puestos responsables de su ejecución.

Auxilian en la inducción del puesto y al adiestramiento y capacitación del personal ya que describen en forma detallada las actividades de cada puesto.

Sirve para el análisis o revisión de los procedimientos de un sistema.

Interviene en la consulta de todo el personal.

Que se desee emprender tareas de simplificación de trabajo como análisis de tiempos, delegación de autoridad, etc.

Para establecer un sistema de información o bien modificar el ya existente.

Para uniformar y controlar el cumplimiento de las rutinas de trabajo y evitar su alteración arbitraria.

Determina en forma más sencilla las responsabilidades por fallas o errores.

Facilita las labores de auditoría, evaluación del control interno y su evaluación.

Aumenta la eficiencia de los empleados, indicándoles lo que deben hacer y como deben hacerlo.

Ayuda a la coordinación de actividades y evitar duplicidades.

Construye una base para el análisis posterior del trabajo y el mejoramiento de los sistemas, procedimientos y métodos.

CONFORMACIÓN DEL MANUAL

A) IDENTIFICACIÓN

Este documento debe incorporar la siguiente información:

Logotipo de la organización.

Nombre oficial de la organización.

Denominación y extensión. De corresponder a una unidad en particular debe anotarse el nombre de la misma.

Lugar y fecha de elaboración.

Número de revisión (en su caso).

Unidades responsables de su elaboración, revisión y/o autorización.

Clave de la forma. En primer término, las siglas de la organización, en segundo lugar las siglas de la unidad administrativa donde se utiliza la forma y, por último,

el número de la forma. Entre las siglas y el número debe colocarse un guión o diagonal.

B) ÍNDICE O CONTENIDO

Relación de los capítulos y páginas correspondientes que forman parte del documento.

C) PRÒLOGO Y/O INTRODUCCIÓN

Exposición sobre el documento, su contenido, objeto, áreas de aplicación e importancia de su revisión y actualización. Puede incluir un mensaje de la máxima autoridad de las áreas comprendidas en el manual.

D) OBJETIVOS DE LOS PROCEDIMIENTOS

Explicación del propósito que se pretende cumplir con los procedimientos.

Los objetivos son uniformar y controlar el cumplimiento de las rutinas de trabajo y evitar su alteración arbitraria; simplificar la responsabilidad por fallas o errores; facilitar las labores de auditoría; facilitar las labores de auditoría, la evaluación del control interno y su vigilancia; que tanto los empleados como sus jefes conozcan si el trabajo se está realizando adecuadamente; reducir los costos al aumentar la eficiencia general, además de otras ventajas adicionales.

E) AREAS DE APLICACIÓN Y/O ALCANCE DE LOS PROCEDIMIENTOS

Esfera de acción que cubren los procedimientos.

Dentro de la administración pública federal los procedimientos han sido clasificados, atendiendo al ámbito de aplicación y a sus alcances, en: procedimientos macroadministrativos y procedimientos mesoadministrativos o sectoriales.

F) RESPONSABLES

Unidades administrativas y/o puestos que intervienen en los procedimientos en cualquiera de sus fases

G) POLÍTICAS O NORMAS DE OPERACIÓN

En esta sección se incluyen los criterios o lineamientos generales de acción que se determinan en forma explícita para facilitar la cobertura de responsabilidad de las distintas instancias que participaban en los procedimientos.

Además deberán contemplarse todas las normas de operación que precisan las situaciones alterativas que pudiesen presentarse en la operación de los procedimientos. A continuación se mencionan algunos lineamientos que deben considerarse en su planteamiento:

Se definirán perfectamente las políticas y/o normas que circunscriben el marco general de actuación del personal, a efecto de que esté no incurra en fallas.

Los lineamientos se elaboran clara y concisamente, a fin de que sean comprendidos incluso por personas no familiarizadas con los aspectos administrativos o con el procedimiento mismo.

Deberán ser lo suficientemente explícitas para evitar la continua consulta a los niveles jerárquicos superiores.

H) CONCEPTO (S)

Palabras o términos de carácter técnico que se emplean en el procedimiento, las cuales, por su significado o grado de especialización requieren de mayor información o ampliación de su significado, para hacer más accesible al usuario la consulta del manual.

I) PROCEDIMIENTO (descripción de las operaciones). Presentación por escrito, en forma narrativa y secuencial, de cada una de las operaciones que se realizan en un procedimiento, explicando en qué consisten, cuándo, cómo, dónde, con qué, y cuánto tiempo se hacen, señalando los responsables de llevarlas a cabo. Cuando la descripción del procedimiento es general, y por lo mismo comprende varias áreas, debe anotarse la unidad administrativa que tiene a su cargo cada operación. Si se trata de una descripción detallada dentro de una unidad administrativa, tiene que indicarse el puesto responsable de cada operación. Es conveniente codificar las operaciones para simplificar su comprensión e identificación, aun en los casos de varias opciones en una misma operación.

J) FORMULARIO DE IMPRESOS. Formas impresas que se utilizan en un procedimiento, las cuales se intercalan dentro del mismo o se adjuntan como apéndices. En la descripción de las operaciones que impliquen su uso, debe hacerse referencia específica de éstas, empleando para ello números indicadores que permitan asociarlas en forma concreta. También se pueden adicionar instructivos para su llenado.

K) DIAGRAMAS DE FLUJO. Representación gráfica de la sucesión en que se realizan las operaciones de un procedimiento y/o el recorrido de formas o materiales, en donde se muestran las unidades administrativas (procedimiento general), o los puestos que intervienen (procedimiento detallado), en cada operación descrita. Además, suelen hacer mención del equipo o recursos utilizados en cada caso. Los diagramas representados en forma sencilla y accesible en el manual, brinda una descripción clara de las operaciones, lo que

facilita su comprensión. Para este efecto, es aconsejable el empleo de símbolos y/o gráficos simplificados.

L) GLOSARIO DE TÉRMINOS. Lista de conceptos de carácter técnico relacionados con el contenido y técnicas de elaboración de los manuales de procedimientos, que sirven de apoyo para su uso o consulta. Procedimiento general para la elaboración de manuales administrativos.

FASE DE IMPLEMENTACION

Comprende la adquisición e integración de los recursos físicos y conceptuales, en esta fase se ejecutan todas las instalaciones y adiestramiento necesario para poder colocar el sistema en modo funcional

En esta fase se siguen los siguientes pasos: Planificación de la implementación, Anuncio de la implementación del nuevo sistema, Adquisición del hardware, Adquisición del software, Preparación de la base de datos, Preparación de las instalaciones físicas, Capacitación a los usuarios y participantes, Preparación del proceso de corte y cambio del uso y Corte y cambio al nuevo sistema.

FASE DE USO Y MANTENIMIENTO

Esta es la etapa final del ciclo de desarrollo de sistemas. En esta fase se pone en ejecución todo el trabajo realizado por parte de analistas y usuarios, Comprende: supervisión, evaluación y modificación de un sistema en el momento que deje de ser efectivo para las nuevas tareas que ocurran en un futuro.

En esta fase se siguen los siguientes pasos: Uso del sistema, para cumplir con los objetivos propuestos, Auditoria del sistema, Mantenimiento del sistema y Formulación de propuestas de reingeniería.

 

ANALISIS ECONOMICO

Para la identificación de los costos y beneficios del proyecto que son pertinentes para su evaluación, es necesario definir una situación base o situación sin proyecto; la comparación de lo que sucede con proyecto versus lo que hubiera sucedido sin proyecto, definirá los costos y beneficios pertinentes del mismo.

La evaluación puede ser realizada desde dos ópticas diferentes:

a) La evaluación privada:

Que a su vez tiene dos enfoques: la evaluación económica, que asume que todo el proyecto se lleva a cabo con capital propio y, por lo tanto, no toma en cuanta el problema financiero; y la evaluación financiera, que diferencia el capital propio del prestado.

b) La evaluación social

En ésta, tanto los beneficios como los costos se valoran a precios sombra de eficiencia o de cuenta. “Para la evaluación social interesa el flujo de recursos reales (de los bienes y servicios) utilizados y producidos por el proyecto.

Los costos y beneficios sociales podrán ser distintos de los contemplados por la evaluación privada económica.

La evaluación económica tiene como objetivo el determinar el impacto que el proyecto produce sobre la economía como un todo. La evaluación social se diferencia de la anterior por incorporar explícitamente el problema distribucional dentro de la evaluación. Esta integración de eficiencia con equidad se traduce en una valoración de “precios sociales”.

En los proyectos sociales se ha planteado la cuestión de quién afronta los costos desde una perspectiva diferente. Al respecto hay tres respuestas posibles: el individuo, el gobierno local, o la sociedad en su conjunto

Desde el punto de vista individual, se considera la perspectiva del beneficiario del proyecto. La perspectiva de la comunidad local plantea el problema de la fuente de financiamiento. Respecto a la sociedad nacional, hay que considerar no solo los costos y beneficios directos, sino también los de carácter secundario e intangible.

El ACB permite determinar los costos y beneficios a tener en cuenta en cada una de las perspectivas consideradas previamente. Por otro lado, mediante la actualización, hace converger los flujos futuros de beneficios y costos en un momento dado en el tiempo (valor presente o actual) tornándolos comparables. Relaciona, por último, los costos y beneficios del proyecto, utilizando indicadores

sintéticos de su grado de rentabilidad, según la óptica de la evaluación (privada o social).

 

El análisis costo-beneficio es una herramienta financiera que mide la relación entre los costos y beneficios asociados a un proyecto de inversión con el fin de evaluar su rentabilidad, entendiéndose por proyecto de inversión no solo como la creación de un nuevo negocio, sino también, como inversiones que se pueden hacer en un negocio en marcha tales como el desarrollo de nuevo producto o la adquisición de nueva maquinaria.

Mientras que la relación costo-beneficio (B/C), también conocida como índice neto de rentabilidad, 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.

B/C = VAI / VAC

Según el análisis costo-beneficio, un proyecto o negocio será rentable cuando la relación costo-beneficio es mayor que la unidad.

B/C > 1 → el proyecto es rentable

Los pasos necesarios para hallar y analizar la relación costo-beneficio son los siguientes:1. Hallar costos y beneficios: en primer lugar hallamos la proyección de los

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

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. Hallar relación costo-beneficio: 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 viable pues 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.