República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación Superior

Universidad Bicentenaria de Aragua

Facultad de Ingeniería

Escuela de Ingeniería de Sistemas

San Joaquín-Edo Aragua

Ángel Cuevas. CI. 19.608.654

Análisis y diseño de sistemas II

22 de Julio de 2013

DISEÑO DE UN

SISTEMA

EVALUACION DEL PROTOTIPO

Los prototipos son una visión preliminar del sistema futuro que se

implantara. La elaboración de prototipos de un sistema de información es

una técnica valiosa para la recopilación rápida de información específica a

cerca de los requerimientos de información de los usuarios.

Los prototipos efectivos deben hacerse tempranamente en el ciclo de vida

del desarrollo de sistemas, durante la fase de determinación de

requerimientos.

Características de prototipos

El prototipo es una aplicación que funciona.

La finalidad del prototipo es probar varias suposiciones formuladas por

analistas y usuarios

Los prototipos se crean con rapidez

Los prototipos evolucionan a través de un proceso iterativo

Los prototipos tiene un costo bajo desarrollo

Fines de prototipos de aplicaciones

Los prototipos no contienen todas las características o lleva a cabo la

totalidad de las funciones necesarias del sistema final, más bien incluye

elementos suficientes para permitir a las personas utilizar el sistema

propuesto para determinar que les gusta, que no les gusta e identificar

aquellas características que deben cambiar o añadir.

Uso de prototipos de aplicación

Tiene dos usos principales:

Es un método eficaz para aclarar los requerimientos del usuario.

Verificar la factibilidad del diseño de un sistema.

Razones para el empleo de prototipos

Las razones para el uso de prototipos son el resultado directo de las

necesidades de diseñar y desarrollar sistemas de información con rapidez,

eficiencia y eficacia.

Está compuesto de tres partes esenciales que ayudan a un óptimo desarrollo

del diseño:

Aumento en la productividad

Redesarrollo planificado

Entusiasmo de los usuarios con respecto a los prototipos

Etapas del modelo de prototipos

El desarrollo de prototipos es una aplicación que se llevan de forma

ordenada, sin importar la herramienta.

Identificación de requerimientos

Desarrollo de un modelo que funcione

Utilizar el prototipo

Revisión del prototipo

Repetición del proceso las veces que sea necesario

Identificación de requerimientos

La determinación de los requerimientos de una Aplicación es tan importante

para el método de desarrollo de prototipos. Como lo es para el ciclo de

desarrollo de sistemas o análisis o Analista estructurado.

Desarrollo de un modelo que funcione

Permite a los usuarios conocer lo que se espera y del proceso de desarrollo.

Lenguaje que se va implementar

Pantallas y formatos para entrada de dato.

Módulos esenciales de procesamiento

Salida del sistema.

Utilizar el prototipo

Es la responsabilidad del usuario trabajar con él y evaluar sus características y

operaciones que permitan familiarizarse, permitiendo obtener cambio o

mejoras que sean necesarias.

Revisión del prototipo

Durante la evolución de los analistas de sistema desea capturar información

sobre los que les gusta y lo que les desagrada.

Repetición del proceso las veces que sea necesario

El proceso antes descrito se repite varia veces. El proceso finaliza cuando los

usuarios y analistas están de acuerdo en que el sistema ha evolucionado lo

suficiente como para incluirlo todas las características.

Uso del prototipo

Cuando el prototipo está terminado, el siguiente paso es tomas la decisión de

cómo proceder, para ello existen 4 caminos:

Abandono de la aplicación

Implantación del prototipo

Redesarrollo de la aplicación

Inicio del prototipo

Abandono de la aplicación

En algunos casos la decisión es descartar el prototipo y abandonar el

desarrollo de la aplicación. Es por esto que el usuario y el analista hayan

aprendido que el sistema era innecesario o que hayan encontrado otras

alternativas, de este modo ahorrara tiempo y recursos lo que permitirá a los

analistas invertir sus esfuerzos en las necesidades de otra aplicación.

Implantación del prototipo

El prototipo se convierte en el sistema que se necesita. Esta decisión se toma

bajo las siguientes circunstancias

Evolución del prototipo.

Aplicación (rapidez y eficiencia)

Efectos sobre otras aplicaciones

Estado de flujo

Redesarrollo de la aplicación

El redesarrollo de una aplicación puede presentarse como parte del método

del ciclo de vida del sistema de información.

Las dos formas de construcción de prototipos son:

1) El prototipo se emplea para la determinación de requerimientos

2) El prototipo se emplea como sustituto para el diseño e implementación

de aplicaciones

Inicio de un nuevo prototipo

En esta etapa lo opción es comenzar un nuevo proyecto de prototipo, de

esta manera satisfacer las necesidades de la organización. El desarrollo de

prototipo es mucho mejor.

PRUEBAS DEL SISTEMA

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). Dado este

propósito, se presentan dos implicaciones:

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

Se distinguen los siguientes tipos de pruebas:

Pruebas de comunicaciones.

Determinan que las interfaces entre los componentes del sistema funcionan

adecuadamente, tanto a través de dispositivos remotos, como locales.

Asimismo, se han de probar las interfaces hombre/máquina.

Pruebas de rendimiento.

Consisten en determinar que los tiempos de respuesta están dentro de los

intervalos establecidos en las especificaciones del sistema.

Pruebas de recuperación.

La prueba de recuperación es una prueba del sistema que fuerza el fallo del

software de muchas formas y verifica que la recuperación se lleva a cabo

apropiadamente.

Pruebas de volumen.

Consisten en examinar el funcionamiento del sistema cuando está trabajando

con grandes volúmenes de datos, simulando las cargas de trabajo esperadas.

Pruebas de sobrecarga.

Consisten en comprobar el funcionamiento del sistema en el umbral límite de

los recursos, sometiéndole a cargas masivas. El objetivo es establecer los

puntos extremos en los cuales el sistema empieza a operar por debajo de los

requisitos establecidos.

Pruebas de tensión.

La prueba de tensión es poner al programa a grandes cargas o tensiones. Esto

no se debe confundir con la prueba de volumen; una gran tensión es

volumen máximo de datos, o de actividad, en un tiempo corto. Una analogía

sería evaluar a un mecanógrafo. Una prueba de volumen se determinaría si el

mecanógrafo hiciera frente a un bosquejo de un informe grande; una prueba

de tensión se determinaría si el mecanógrafo puede mecanografiar a un

índice de 50 palabras por minuto.

Pruebas de disponibilidad de datos.

Consisten en demostrar que el sistema puede recuperarse ante fallos, tanto

de equipo físico como lógico, sin comprometer la integridad de los datos

Pruebas de facilidad de uso.

Consisten en comprobar la adaptabilidad del sistema a las necesidades de los

usuarios, tanto para asegurar que se acomoda a su modo habitual de trabajo,

como para determinar las facilidades que aporta al introducir datos en el

sistema y obtener los resultados.

Pruebas de operación.

Consisten en comprobar la correcta implementación de los procedimientos

de operación, incluyendo la planificación y control de trabajos, arranque y re

arranque del sistema, etc.

Pruebas de entorno.

Consisten en verificar las interacciones del sistema con otros sistemas dentro

del mismo entorno.

Pruebas de seguridad.

Consisten en verificar los mecanismos de control de acceso al sistema para

evitar alteraciones indebidas en los datos.

Pruebas de usabilidad.

Otra categoría importante de casos de prueba de sistema es la tentativa de

encontrar problemas de factores humanos, o usabilidad. Sin embargo, un

análisis de factores humanos sigue siendo una cuestión altamente subjetiva.

Pruebas de almacenamiento.

Los programas tienen de vez en cuando objetivos de almacenamiento que

indiquen, por ejemplo, la cantidad de memoria principal y secundaria que el

programa usa y el tamaño de los archivos temporales. Se diseñan casos de

prueba para demostrar que estos objetivos de almacenaje no han sido

encontrados

Pruebas de configuración.

Programas tales como sistemas operativos, sistemas de gerencia de base de

datos, y programas de conmutación de mensajes soportan una variedad de

configuraciones de hardware, incluyendo varios tipos y números de

dispositivos de entrada-salida y líneas de comunicaciones, o diversos

tamaños de memoria. A menudo el número de configuraciones posibles es

demasiado grande para probar cada uno, pero en lo posible, se debe probar

el programa con cada tipo de dispositivo de hardware y con la configuración

mínima y máxima. Si el programa por sí mismo se puede configurar para

omitir componentes, o si puede funcionar en diversas computadoras, cada

configuración posible de este debe ser probada.

Pruebas de instalación.

Algunos tipos de sistemas de software tienen complicados procedimientos de

instalación. Las pruebas de los procedimientos de instalación es una parte

importante del proceso de prueba del sistema. Esto es particular de un

sistema automatizado de instalación que sea parte del paquete del

programa. Al funcionar incorrectamente el programa de instalación podría

evitar que el usuario tenga una experiencia acertada con el sistema. La

primera experiencia de un usuario es cuando él o ella instalan la aplicación. Si

esta fase se realiza mal, entonces el usuario/el cliente puede buscar otro

producto o tener poca confianza en la validez de la aplicación.

Pruebas de la documentación.

Las pruebas de sistema también se refieren a la exactitud de la

documentación del usuario. Una manera de lograr esto es utilizar la

documentación para determinar la representación de los casos anteriores de

prueba del sistema. Esto es, una vez se desea idear el caso de sobrecarga, se

utilizaría la documentación como guía para escribir el caso de prueba real.

También, la documentación del usuario debe ser el tema de una inspección,

comprobándola para saber si hay exactitud y claridad. Cuales quiera de los

ejemplos ilustrados en la documentación se deben probar y hacer parte de

los casos y alimentarlos al programa.

Propósito

El propósito principal es ejercitar profundamente el sistema de cómputo.

Aunque cada prueba tiene un propósito diferente, todos trabajan para

verificar que se hayan integrado adecuadamente todos los elementos del

sistema y que realicen las funciones apropiadas.

DOCUMENTACION DEL SISTEMA

La documentación de los sistemas debe incluirse como un ítem de

importancia en el plan de implementación. La misma debería incorporar

como mínimo: definición de los objetivos del sistema, análisis de impacto en

la organización (respecto a los procesos de negocio) y sus beneficios,

justificación técnica, económica y financiera del proyecto, análisis de impacto

en los recursos humanos, documentación de todos los programas que

integran el sistema, documentación de datos, archivos y bases de datos,

medidas de seguridad físicas y lógicas a adoptarse.

Aspectos fundamentales de la documentación

Debe ser rotulada con claridad y bien organizada.

Los diagramas deberán ser claros, no aglomerados y la escritura

manuscrita deberá ser legible.

La documentación deberá ser completa.

Se incluirá una leyenda o explicación de los términos utilizados.

La documentación siempre se conserva actualizada.

Asegúrese de que los estándares sean completos, actualizados,

documentados y legibles.

Tipos de documentación

Durante el desarrollo de un sistema, desde su concepción hasta su puesta en

marcha se ha de generar una gran cantidad de documentos, que en muchas

ocasiones se han visto modificados por documentos posteriores debido a

cambios en el sistema. Para evitar confusiones en las revisiones de la

documentación se desarrollan diferentes tipos de documentos dirigidos a las

personas que trabajarán con el sistema y para facilitar el mantenimiento del

mismo. El estilo de redacción de los manuales de documentación debe ser:

Concreto.

Ser preciso y definir los términos utilizados.

Utilizar párrafos cortos.

Utilizar títulos y subtítulos.

Utilizar formas activas en lugar de pasivas.

No emplear frases largas que presenten hechos distintos.

No hacer referencia a una información solamente con el número de

referencia

Generalmente existen solo dos tipos de manuales, el administrativo y

el de usuario.

Los diferentes tipos de documentación de sistemas son los siguientes:

Manual administrativo

Sirve como punto de partida al sistema propuesto, ya que será función de la

gerencia, de acuerdo con los usuarios de dicho sistema, determinar si lo

expuesto en él satisface los requerimientos del propio sistema. Una vez

lograda la aprobación, se estará en condiciones de iniciar el desarrollo del

sistema propuesto e ir integrando el resto de la documentación. El manual

tiene como finalidad el permitir a la alta gerencia tener la información

necesaria y suficiente sobre un sistema en particular y servir como fuente de

consulta una vez que el sistema ha sido implantado.

Contenido del manual administrativo.

Nombre del sistema.

Una descripción breve del nombre del sistema.

Equipo encargado del sistema.

Se describe a las personas que están involucradas en la creación del sistema.

Planteamiento.

Este punto tiene como finalidad registrar los antecedentes que servirán de

partida al desarrollo del análisis del sistema.

Objetivos del sistema.

Aquí se dejarán establecidos los objetivos que debe cubrir el sistema, en

forma clara y precisa para evitar errores de interpretación.

Entradas del sistema (información a captar).

Debe quedar especificado en este punto, los documentos fuentes que inician

las operaciones del sistema así como la información detallada de aquellos

conceptos que serán los datos a captar por el sistema. Se deberán mencionar

todos los datos que en forma secundaria originan una entrada importante al

sistema.

Salidas del sistema (resultados a obtener).

En este punto, solamente se describirán los resultados de mayor importancia

obtenidos a través de todo el proceso. En esta sección se debe dar mayor

énfasis a la información que el sistema proporciona cuidando de no hacer tan

sólo mención de los resultados a obtener.

Diagramación general del sistema.

Representaciones graficas del sistema (diagramas UML, para la explicación de

los procesos de la empresa).

Explicaciones de las fases del sistema.

Este punto se encuentra relacionado con el anterior ya que lo que se muestra

gráficamente, ahora se describe en forma genérica, explicando los procesos

que se llevan a cabo en cada dependencia sin profundizar en detalles

técnicos o específicos. Se deberá resaltar aquellas fases del proceso en las

cuáles se obtengan resultados de importancia así como aquellas que

requieran una supervisión especial.

Requerimientos del sistema.

Se establecen los costos de los requerimientos tanto humanos como

tecnológicos que va a necesitar el sistema.

Estimación de la fecha probable de implementación del sistema.

Es necesario que exista una fecha probable de implantación cuya base será la

terminación de todas las actividades para la creación del sistema, tales como:

análisis, programación, elaboración de formas, y otros. Se recomienda utilizar

diagrama de Gantt o de PERT para establecer el período de las actividades

requeridas para el desarrollo del sistema.

Consideraciones generales del nuevo sistema.

En este punto se deberá señalar las ventajas, desventajas, y principales

diferencias del nuevo sistema con el anterior, tales como seguridad,

disminución de costo, ahorro de tiempo, flexibilidad, confiabilidad y otros.

Manual de usuario.

Expone los procesos que el usuario puede realizar con el sistema implantado.

Para lograr esto, es necesario que se detallen todas y cada una de las

características que tienen los programas y la forma de acceder e introducir

información. Permite a los usuarios conocer el detalle de qué actividades

ellos deberán desarrollar para la consecución de los objetivos del sistema.

Reúne la información, normas y documentación necesaria para que el

usuario conozca y utilice adecuadamente el sistema.

Objetivos de los manuales de usuarios.

Que el usuario conozca cómo preparar los datos de entrada.

Que el usuario aprenda a obtener los resultados y los datos de salida.

Servir como manual de aprendizaje.

Servir como manual de referencia.

Definir las funciones que debe realizar el usuario.

Pasos para desarrollar el manual de usuario.

Identificar los usuarios del sistema.

Personal que se relacionará con el sistema.

Definir los diferentes tipos de usuarios.

Se presentan los diferentes tipos de usuarios que usarían el sistema. Ejemplo:

usuarios directos, indirectos.

Definir los módulos en que cada usuario participará.

Se describen los módulos o procesos que se ejecutarán por cada usuario en

forma narrativa breve y clara.

Características del manual de usuario.

Al elaborar el manual de usuario, hay que tener en cuenta a quién va dirigido

es decir, el manual puede ser manejado desde el director de la empresa

hasta el introductor de datos. Por consiguiente, debe redactarse de forma

clara y sencilla para que lo entienda cualquier tipo de usuario.

Diagrama general del sistema.

Como está construido el sistema en una visión mucho más general.

Diagrama particular detallado.

Presentar gráficamente todos los pasos que se efectúen dentro del

departamento usuario a quien está dirigido este manual. Deben especificarse

los archivos de entrada, salida, los resultados, revisiones y procesos

manuales.

Instalación del sistema.

Explicación detallada de cómo se tiene que instalar el sistema incluyendo

módulos, bases de datos, documentación y ayuda en pantalla.

Iniciación al uso del sistema.

En este punto se explica cómo iniciarse en el sistema y cómo se pueden

utilizar sus cualidades comunes. Esta documentación debe decir al usuario

cómo salir de un problema cuando las cosas funcionan mal.

Manual de referencia.

Es el documento definitivo de cara al usuario y debe ser completo. Describe

con detalle las cualidades del sistema y su uso, los informes de error

generados y las situaciones en que surgen esos errores. Dependiendo del

sistema, los documentos al usuario se pueden proporcionar por separado o

reunidos en varios volúmenes. Los sistemas de ayuda en línea evitan que el

usuario pierda tiempo en consultas manuales.

Manual de operación.

Contiene la información que permite al personal de operación utilizar en

forma eficiente la operación de los sistemas de procesamiento electrónico.

Contenido del manual de operación:

Diagrama general del sistema

Este diagrama debe ser presentado gráficamente y en forma sencilla.

Representar los diagramas utilizando para ello diagramas de bloques (es el

mismo diagrama que se presenta en el manual administrativo).

Diagrama general del flujo del proceso electrónico.

Se representa en este diagrama todo el ambiente periférico que interactúa

en el sistema en cuanto a: entradas manuales, medios magnéticos y

dispositivos de salida. La simbología a utilizar debe ser establecida como

estándar. (Ejemplos: cintas, discos, disquetes).

Explicación genérica de las fases del sistema

Es una explicación clara, breve de todos los módulos que se presentan en el

diagrama general descrito anteriormente.

Diagrama de pantallas del sistema

Se presenta en este punto el flujo del sistema en las pantallas utilizadas por

cada módulo.

Puntos a documentar en una pantalla.

Explicación del recorrido en pantalla.

La documentación de sistemas

La documentación de sistemas es el conjunto de información que nos dice

qué hacen los sistemas, cómo lo hacen y para quién lo hacen. La

documentación consiste en material que explica las características técnicas y

la operación de un sistema. Es esencial para proporcionar entendimiento de

un sistema a quien lo vaya a usar para mantenerlo, para permitir auditoria

del sistema y para enseñar a los usuarios como interactuar con el sistema y a

los operadores como hacerlo funcionar. Existen varios tipos de

documentación. La de programas, que explica la lógica de un programa e

incluye descripciones, diagramas de flujo, listados de programas y otros

documentos. La del usuarios en forma general la naturaleza y capacidades

del sistema y cómo usarlo.

Otra definición sería la de registro físico, generalmente por escrito que

contiene los siguientes elementos:

Políticas y normas referentes al desarrollo del sistema, su

implantación, operación y mantenimiento.

El diseño del sistema de información administrativo.

Procedimientos para instalar el sistema de información administrativo.

Procedimientos para operar el sistema de información administrativo.

Procedimientos para mantener el sistema de información

administrativo.

Objetivos de la documentación de sistemas

Definir detalladamente el sistema

Explicar las características técnicas y la operación de un sistema.

Mejorar la comunicación

Proporcionar entendimiento de un sistema a quien lo vaya a usar para

mantenerlo y para enseñar a los usuarios como interactuar con el sistema y a

los operadores como hacerlo funcionar.

Vinculo para la capacitación

Ayudar al entrenamiento del nuevo personal dentro y fuera de la

organización de sistemas.

Optimizar la gestión de mantenimiento

Ser de utilidad para cualquiera que tenga la responsabilidad del

mantenimiento de los sistemas.

Fomentar la integración

Ayudar a los analistas y diseñadores de sistemas en el trabajo de integración

de sistemas.

Proporcionar estabilidad al sistema

Asegurar que el sistema opere correctamente.

Minimizar el consumo de recursos

Utilizar eficientemente los recursos que se dispongan.

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

COSTO Y BENEFICIO DEL SISTEMA

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

cuenta 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:

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.

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.

Hallar relación costo-beneficio: dividimos el valor actual de los beneficios

entre el valor actual de los costos del proyecto.

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.

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.

BENEFICIOS TANGIBLES E INTANGIBLES DE UN SISTEMA

Los beneficios tangibles son las que se miden en términos monetarios y los

beneficios intangibles no se pueden medir en términos monetarios pero sí

tienen un impacto en el negocio muy importante.

Los beneficios tangibles:

Mejora la productividad de los procesos y el personal

Reducir el costo de los productos y servicios adquiridos

Libro y la reducción de costes de envío

Reducción de inventarios

Reducción del tiempo de lead

Reducción de la obsolescencia de valores

Más rápido del producto / servicio de look-up y el tiempo de ordenar el

ahorro y el dinero

Automatizado de pedidos y los costos de pago, el procesamiento de

pagos y la reducción de papel

Los beneficios intangibles:

Aumenta la transparencia organizativa y responsabilidad

Precisa y un acceso más rápido a los datos para tomar decisiones

oportunas

Puede llegar a más vendedores, productores de las ofertas más

competitivas;

Mejora la respuesta del cliente

Ahorra tiempo y esfuerzo enorme en la entrada de datos;

Más controles lo que reduce el riesgo de mala utilización de los

recursos

Facilita la planificación estratégica

Para los informes de acuerdo a los estándares mundiales

CONCLUSION

En Conclusión un proyecto de desarrollo de un Sistema de Información

comprende varios componentes o pasos llevados a cabo durante la etapa del

análisis, el cual ayuda a traducir las necesidades del cliente en un modelo de

Sistema que utiliza uno más de los componentes: Software, hardware,

personas, base de datos, documentación y procedimientos.

En una organización o Empresa, el análisis y Diseño de Sistemas, es el

proceso de estudiar su Situación con la finalidad de observar cómo trabaja y

decidir si es necesario realizar una mejora; el encargado de llevar a cabo

estas tareas es el analista de sistemas.

Antes de comenzar con el desarrollo de cualquier proyecto, se conduce un

estudio de Sistemas para detectar todos los detalles de la situación actual de

la empresa. La información reunida con este estudio sirve como base para

crear varias estrategias de Diseño. Los administradores deciden que

estrategias seguir.

Los Gerentes, empleados y otros usuarios finales que se familiarizan cada vez

más con el uso de computadoras están teniendo un papel muy importante en

el desarrollo de sistemas.

Todas las organizaciones son Sistemas que actúan de manera recíproca con

su medio ambiente recibiendo entradas y produciendo salidas. Los Sistemas

que pueden estar formados por otros Sistemas de denominan subsistemas y

funcionan para alcanzar los fines de su Implantación.

REFERENCIAS BIBLIOGRAFICAS

http://www.slideshare.net/myjuankiz1/desarrollo-de-prototipos-5662958

http://www.slideshare.net/juandiaz89/estrategias-de-aplicacin-de-pruebas-

del-sistema-14842463

http://wiki.monagas.udo.edu.ve/index.php/Documentaci%C3%B3n_de_Siste

mas

http://aulavirtual.uba.edu.ve/pluginfile.php/959/mod_page/content/1/UNID

AD_IV/TemaIV/anlisis_costo_y_beneficios.html