revista de analisis (2) pdf
DESCRIPTION
ÂTRANSCRIPT
Página 1
República bolivariana de Venezuela
Universidad Bicentenaria de Aragua
San Joaquín- turmero
Análisis y diseño
de sistemas II
Realizado por:
Doranna Rodriguez
Gerson Osorio
Daniel Villa
Kristel Rivero
Jhonny Becerra
Maracay 22 de julio del 2013
Página 2
Esta revista digital está
diseñada en el estudio de
Análisis y Diseño de Sistema,
en el cual aprenderemos a
diseñar diagramas, con el fin
de que le sea más sencilla a
la hora de su elaboración
para el usuario, ya que en la
actualidad existen numerosas
técnicas para que sea más
fácil y más útil a la hora del
trabajo de este mismo;
También encontraremos
otros temas como la
evaluación del prototipo que
nos permite evaluar o diseñar
con mejor interfaz lo que el
usuario desea conseguir,
hablaremos de pruebas,
manuales, documentos,
planificación del
adiestramiento entre otros
objetivos más, con anexos
para su mejor entendimiento.
Con esto queremos lograr
que el usuario obtenga ideas
y sugerencias a la hora de su
trabajo ya sea en una
empresa como también para
su preparación persona y/o
estudio del mismo.
Esperamos pues, que
nuestra revista digital sea de
su agrado y le ayude a la
hora de idear y elegir nuevas
posibilidades a la hora de su
trabajo y/o estudio.
Página 3
Métodos y Diagramación
Orientado a Objeto
El Lenguaje Unificado de Modelado
prescribe un conjunto de notaciones y
diagramas estándar para modelar sistemas
orientados a objetos, y describe la
semántica esencial de lo que estos
diagramas y símbolos significan.
Mientras que ha habido muchas
notaciones y métodos usados para el
diseño orientado a objetos, ahora los
modeladores sólo tienen que aprender una
única notación.
UML se puede usar para modelar
distintos tipos de sistemas: sistemas de
software, sistemas de hardware, y
organizaciones del mundo real. UML
ofrece nueve diagramas en los cuales
modelar sistemas.
Diagramas de Casos de Uso para
modelar los procesos ’business’.
Diagramas de Secuencia para
modelar el paso de mensajes
entre objetos.
Diagramas de Colaboración para
modelar interacciones entre
objetos.
Diagramas de Estado para
modelar el comportamiento de los
objetos en el sistema.
Diagramas de Actividad para
modelar el comportamiento de los
Casos de Uso, objetos u
operaciones.
Diagramas de Clases para
modelar la estructura estática de
las clases en el sistema.
Diagramas de Objetos para
modelar la estructura estática de
los objetos en el sistema.
Diagramas de Componentes para
modelar componentes.
Diagramas de Implementación
para modelar la distribución del
sistema.
CASO DE USO: El Diagrama de
Caso de Uso nos da el punto de entrada
para analizar los requisitos del sistema, y
el problema que necesitamos solucionar.
¿QUÉ ES UN CASO DE
USO?
Describen una interacción típica
entre un usuario (actores) y un
sistema de cómputo.
Es una técnica para capturar
información de cómo un sistema o
negocio trabaja actualmente, o de
cómo se desea que trabaje
Produce algo de valor para algún
actor como el cálculo de algún
resultado
Describe qué hace un sistema pero
no especifica cómo lo hace
El caso de uso capta alguna
función visible para el usuario.
El caso de uso puede ser pequeño
o grande.
El caso de uso logra un objetivo
discreto para el usuario.
Un caso de uso debe ser simple,
claro y conciso
Página 4
¿PARA QUE SIRVEN LOS
CASOS DE USO?
Para capturar el
comportamiento deseado
del sistema sin tener que
especificar cómo se
implementa ese
comportamiento
Como medio de
comprensión del sistema
para desarrolladores,
usuarios finales y expertos
del dominio
Ayudan a validar la
arquitectura y a verificar el
sistema en el transcurso
del desarrollo de este
¿CÓMO SE
REPRESENTAN?
Un caso de uso se representa en UML
como un óvalo:
En UML, un actor se representa como
monigote
ACTORES
Representa un conjunto de
roles que los usuarios de
los casos de uso juegan al
interactuar con éstos
Representa un rol que es
jugado por una persona, un
dispositivo hardware u
otro sistema que interactúe
con nuestro sistema
Se puede definir categorías
generales de actores (como
cliente) y especializarlos
(como ClienteComercial) a
través de relaciones de
generalización.
Un actor y un caso de uso
se pueden comunicar a
través de una asociación
en donde cada uno de ellos
pueden enviar y recibir
mensaje.
FLUJO DE EVENTOS
Cómo y cuándo empieza y
acaba el caso de uso
Cuándo interactúan con los
actores y que objetos se
intercambian
Conviene separa el flujo
principal de uno alternativo
Página 5
¿Cómo se debe crear un caso
de uso?
Tras localizar los actores, procede
el describirlos
especificar describiendo un flujo
de eventos
Los actores sólo pueden conectar
a los casos de uso a través de
asociaciones
Generalmente hay pocos actores
asociados a cada Caso de Uso
Preguntas clave:
¿cuáles son las tareas del
actor?
¿qué información crea,
guarda, modifica, destruye
o lee el actor?
¿debe el actor notificar al
sistema los cambios
externos?
¿debe el sistema informar
al actor de los cambios
internos?
RELACIONES
Para extraer el comportamiento de los
casos de uso en los que se incluye y
poniendo ese comportamiento en otros
casos de uso que lo extiende
Tipos:
- GENERALIZACIÓN
- EXTENSIÓN
- INCLUSIÓN
GENERALIZACIÓN
El caso hijo hereda el
comportamiento y
significado de caso de uso
padre
El hijo puede añadir o
redefinir el
comportamiento del padre
El Caso de Uso fuente
hereda la especificación
del Caso de Uso destino
EXTENSIÓN
Significa que un caso de
uso base incorpora
implícitamente el
comportamiento de otro
caso de uso en el lugar
especificado
indirectamente por el caso
de uso que extiende al
base
Se usa esta relación
cuando se tiene un caso de
uso que es similar a otro,
pero que hace un poco
más.
Página 6
INCLUSIÓN
Un caso base de uso base
incorpora expolisitamente
el comportamiento de otro
caso de uso en el lugar
especificado en el caso
base.
Se usa para evitar
describir el mismo flujo de
eventos repetidas veces,
poniendo comportamiento
común en un caso de uso
aparte
Se representa como una
dependencia estereotipada
con <<include>>
EJEMPLO DE CASO DE USO
DIAGRAMAS DE ESTADO:
El comportamiento en tiempo real de cada
clase que tiene comportamiento dinámico
y significativo, se modela usando un
Diagrama de Estado. El diagrama de
actividad puede ser usado también aquí,
esta vez como una extensión del diagrama
de estado, para mostrar los detalles de las
acciones llevadas a cabo por los objetos
en respuesta a eventos internos. El
diagrama de actividad se puede usar
también para representar gráficamente las
acciones de métodos de clases.
Página 7
DIAGRAMA DE CLASE: El
Diagrama de Clase es el diagrama
principal de diseño y análisis para un
sistema. En él, la estructura de clases del
sistema se especifica, con relaciones entre
clases y estructuras de herencia. Durante
el diseño, se usa el mismo diagrama, y se
modifica para satisfacer los detalles de las
implementaciones.
APROXIMACIÓN A UN
CASO DE USO GUIADO
En una aproximación a un Caso de Uso
guiado hacia el análisis orientado a
objetos, el diagrama de clases se
desarrolla a través de información
obtenida en los Casos de Uso, Diagramas
de Secuencia y Diagramas de
Colaboración. Los objetos encontrados
durante el análisis son modelados en
términos de la clase a la que instancian, y
las interacciones entre objetos son
referenciados a relaciones entre las clases
instanciadas.
Página 8
EXTENSIÓN GUIADA POR
LA RESPONSABILIDAD
La técnica de la tarjeta CRC se usa a
veces como una extensión a UML para
análisis guiados por la responsabilidad.
Las definiciones de clase son refinadas
basándose en las responsabilidades de
clase y en otras clases con las que
colabora para completar sus
responsabilidades.
Cada clase se representa en una tarjeta
índice (index card), y los diseñadores
establecen los papeles (roles) de las clases
en el sistema para definir su trabajo, y con
qué otras necesitan colaborar para
completar sus responsabilidades. Esta
información se pasa directamente a un
diagrama de clase; las responsabilidades
coinciden con los métodos de clase, las
colaboraciones se traducen en
asociaciones entre clases.
DISEÑO DEL SISTEMA
CON DIAGRAMAS DE
CLASE
Durante el diseño, el Diagrama de Clase
se elabora para tener en cuenta los
detalles concretos de la implementación
del sistema.
ARQUITECTURAS
MULTICAPAS
Una vez concienciados del diseño,
estableceremos la arquitectura del
sistema. Esto incluye establecer si será un
sistema simple diseñado para correr en
una sola máquina, un sistema 'two-tiered'
consistente en un cliente y un servidor, o
un sistema 'multi-tiered' con objetos
interfaz de usuario separados de los
objetos 'business', separado de la base de
datos, cada uno corriendo en plataformas
distintas.Una aproximación a dirigir el
diagrama de clase para un sistema
complejo es separar el diagrama en
secciones que muestren la lógica de la
aplicación, el diseño de la interfaz de
usuario, y las clases implicadas con el
almacenamiento de los datos. Esto se
puede hacer físicamente segmentando el
diagrama de clase, usando diagramas
separados para cada sección, o
simplemente añadiendo una propiedad a
cada clase que 'tracks' cada 'tier' al cual
pertenece.
DISEÑO DE
COMPONENTES
El desarrollo basado en componentes es
el proceso de ensamblar la combinación
correcta de componentes en la
configuración correcta para llevar a cabo
la funcionalidad deseada para un sistema.
Los componentes se representan en el
diagrama de clases de UML
especificando la interfaz de una clase o
paquete. Hay dos notaciones para mostrar
una interfaz - una es mostrar la interfaz
Página 9
como una 'regular class symbol' con el
estereotipo "interfz", con una lista de
operaciones soportadas por esta interfaz,
detalladas en el 'operation department'
(departamento de operación). 'The
alternate, shortcut notation' es mostrar la
interfaz como un circulo pequeño junto
con la clase con una línea sólida, con el
nombre de la interfaz en el círculo.
ANÁLISIS Y DISEÑO
'ITERATIVE'
El diagrama de clase se puede desarrollar
en una 'iterative fashion', a través de un
ciclo repetido de análisis, diseño e
implementación, y después vuelta al
análisis, para empezar el ciclo de nuevo.
Este proceso se suele llamar 'round-trip
engineering'. El modelado de
herramientas como System Architect
2001 puede facilitar este proceso
permitiéndote implementar el diseño en
un lenguaje como C++ o Java, y después
traer de vuelta al código a al diagrama de
clase, automáticamente actualizando la
información contenida en el diagrama y
en el 'underlying repository'.
DIAGRAMA DE GANTT
Es un método gráfico de planeación y
control en la que un proyecto se divide en
distintas actividades y se realizan
estimaciones acerca de cuánto tiempo
requiere cada una de ellas, así como el
total de tiempo necesario para terminar el
proyecto totalmente. En otras palabras,
esta gráfica muestra las relaciones de
tiempo entre los eventos de un programa
y fue desarrollada por Henry L. Gantt.Las
gráficas de Gantt son útiles para el
seguimiento de proyectos relativamente
pequeños, los cuales están integrados de
actividades que se realicen con
consecuencia ordenada; también para
planear actividades que se desarrollen en
serie, siendo su principal ventaja es que
es sencillo y un excelente instrumento
decomunicación con los usuarios finales.
Página 10
TAREA
Son actividades de un proyecto que se
realizan en una secuencia determinada.
Tarea predecesora: es una tarea que
debe comenzar o terminar antes de que
otra pueda comenzar.
Tarea sucesora: es una tarea que
depende del comienzo o del fin de una
tarea precedente.
Tareas de resumen: son aquellas que se
componen de subtareas y resume esas
subtareas.
DURACIÓN
Tiempo en que se llevará completar una
tarea definiendo su lapso de tiempo.
Hito: es una tarea sin duración (o días)
que se utiliza para identificar sucesos
significativos en la programación como la
finalización de una fase importante.
TRABAJO
Es el esfuerzo necesario para realizar una
tarea. Existen dos tipos de trabajo: el
trabajo de recursos individuales en una
tarea y el trabajo total en la tarea.
CALENDARIO DE UN PROYECTO
Designa la programación predeterminada
de los trabajos para todos los recursos
asignados al proyecto. Puede establecer el
calendario del proyecto para indicar un
período no laborable (como los días
festivos de la organización), establecer los
calendarios base para indicar la
información compartida entre los recursos
y modificar los calendarios de recursos
individuales para indicar los horarios
laborales, las vacaciones, los permisos y
las bajas por enfermedad.
PASOS A SEGUIR PARA
REALIZAR UNA
PLANIFICACIÓN
La planificación incluye a todas las
actividades que se requieren para la
selección del equipo de análisis de
sistemas, la asignación de proyectos
apropiados a los miembros de este
equipo, la estimación del tiempo que cada
tarea requiere para su ejecución, y la
programación del proyecto, de tal forma
que las tareas se concluyan
oportunamente.
La primera decisión del analista de
sistemas es determinar el grado de detalle
que usará al definir las actividades. El
primer nivel de detalle es en sí el ciclo de
desarrollo de sistemas; y se requiere
además de un enfoque estructurado.
Pasos:
Listar las actividades en columna.
Disponer el tiempo disponible para el
proyecto e indicarlo.
Página 11
Calcular el tiempo para cada actividad.
Indicar estos tiempos en forma de barras
horizontales.
Reordenar cronológicamente.
Ajustar tiempo o secuencia de
actividades.
SIMBOLOGÍA
Nombre Aspecto
Tarea
División …………
Progreso
Hito
Resumen
Tarea
resumida
División
resumida …………
Hito resumido
Progreso
resumido
Resumen del
proyecto
Evaluación
de prototipo 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
evaluando 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
Página 12
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.
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.
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.
CARACTERÍSTICAS COMUNES A
LAS PRUEBAS Y AL PROCESO DE
PRUEBA.
1. Para probar necesitamos código que se
pueda ejecutar.
Página 13
2. Para probar necesitamos saber cual es
el resultado esperado.
3. Una prueba es mejor que otra cuando
encuentra más errores.
4. Es imposible probar una aplicación al
100%.
5. Las pruebas no deben dejarse para el
final.
TIPOS DE PRUEBAS
Se distinguen los siguientes tipos
de pruebas:
Pruebas de Usabilidad Se centran en:
Factores humanos, Estética, Consistencia
con la interfaz de usuario, Ayudas en
línea y “context sensitive”, Wizards y
agentes, Documentación para el usuario
Materiales de entrenamiento
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
Página 14
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 diferenteshardware 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
Página 15
los problemas que encuentra durante la
prueba beta e informa a intervalos
regulares al desarrollador.
Implantación y Evaluación
La implantación es el proceso de
verificar e instalar el nuevo equipo,
entrenar a los usuarios, instalar la
aplicación y construir todos los archivos
de datos necesarios para utilizarla.
La evaluación de un sistema se lleva a
cabo para identificar puntos débiles y
fuertes. La evaluación ocurre a lo largo de
cualquiera de las siguientes dimensiones:
Evaluación operacional
Impacto organizacional
Opinión de los administradores
Desempeño del desarrollo
Método del Prototipo de Sistemas
Éste método hace que el usuario participe
de manera más directa en la experiencia
de análisis y diseño que cualquiera de los
ya presentados. Al igual que cualquier
sistema basado en computadora, está
constituido por software que acepta
entradas, realiza cálculos, produce
información ya sea impresa o presentada
en una pantalla, o que lleva a cabo otras
actividades significativas.
Los usuarios evalúan el diseño y la
información generada por el sistema.
Los usuarios pueden señalar las
características que les agradaría o no
tener, junto con los problemas que
presenta un sistema que existe y funciona,
con mayor facilidad que si se les pidiese
que las describieran en forma teórica o
por escrito.
En general, los pasos a seguir en el
proceso de desarrollo de prototipos son
los siguientes:
1) Identificar los requerimientos de
información que el usuario conoce junto
con las características necesarias del
sistema.
2) Desarrollar un prototipo que funcione
3) Utilizar el prototipo anotando las
necesidades de cambios y mejoras.
4) Revisar el prototipo con base en la
información obtenida a través de la
experiencia del usuario.
Página 16
5) Repetir los pasos anteriores las veces
que sea necesario, hasta obtener un
sistema satisfactorio.
Cuando el analista y el usuario deciden
que cuentan ya con la suficiente
información proveniente del proceso de
construcción del prototipo, determinan
cómo satisfacer los requerimientos ya
identificados.
Documentación
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
Página 17
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
desarrolla
rán.
-
Estructur
a.
- Soporte
en el que
se van a
generar.
-
Distribuc
ió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
Página 18
Manuales
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.
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
qué 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.
Página 19
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.
Página 20
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 cómo
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
Página 21
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 macro-administrativos y
procedimientos meso-administrativos 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
Página 22
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.
Preparación y planificación
de adiestramiento
FASE DE IMPLEMENTACIÓN
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.
Página 23
OBJETIVOS DEL SISTEMA DE
ADIESTRAMIENTO:
Incrementar la productividad.
Promover la eficiencia del trabajador, sea
obrero, empleado o funcionario.
Proporcionar al trabajador una
preparación que le permita desempeñar
puesto de mayor responsabilidad.
Promover un ambiente de mayor
seguridad en el empleo.
Ayudar a desarrollar condiciones de
trabajo más satisfactorias, mediante los
intercambios personales surgidos con
ocasión del adiestramiento.
Promover el mejoramiento de los
sistemas y procedimientos.
Contribuir a reducir los movimientos de
personal, tales como renuncias,
destituciones y otros.
Reducir el costo del aprendizaje.
Promover el mejoramiento de las
relaciones públicas de la institución, y de
los sistemas de comunicación internos.
Contribuir a reducir las quejas del
empleado y a proporcionar una moral de
trabajo más elevada.
Facilitar la supervisión de personal.
Promover los ascensos sobre la base del
mérito personal.
Contribuir a la reducción de los
accidentes de trabajo.
Reducir el costo de operación.
DETECCIÓN DE NECESIDADES DE
ADIESTRAMIENTO
Es un proceso mediante el cual se
establecen los requerimientos de
adiestramiento para el personal que labora
en la organización para programar las
diferentes acciones de adiestramiento.
OBJETIVOS: elaborar la planificación,
programación y ejecución de los
programas de adiestramiento, que
permiten adecuar al trabajador para el
ejercicio de determinada función o para la
ejecución de tareas específicas
establecidos por la organización en cada
puesto de trabajo.
Página 24
PLANIFICACIÓN DEL
ADIESTRAMIENTO
Es la integración del conjunto de
actividades, medios y recursos en una
estructura de acción, de acuerdo a los
objetivos propuestos, para mejorar el
desempeño de los trabajadores de la
organización a través de la realización de
actividades de adiestramiento.
PLAN ANUAL: es el documento que
recoge el total de las acciones de
adiestramiento cuya ejecución esta
prevista en un plazo determinado,
considerando los recursos.
RECURSOS: son los elementos
fundamentales para la elaboración de un
plan (humano, financiero, materiales y de
tiempo).
El programa de entrenamiento exige una
planeación que incluya los siguientes
aspectos:
Enfoque de una necesidad especifica cada
vez.
Definición clara del objetivo de
entrenamiento.
División del trabajo por desarrollar, en
módulos, paquetes o ciclos.
Determinación del contenido del
entrenamiento.
Elección de los métodos de entrenamiento
y de la tecnología disponible.
Definición de los recursos necesarios para
la implementación del entrenamiento,
como el tipo de entrenador o instructor,
recursos audiovisuales, maquinas,
equipos o herramientas necesarias,
materiales, manuales, etc.
Definición de la población objetivo, es
decir, el personal que va a ser entrenado,
considerando lo siguiente:
Número de personas.
Disponibilidad de tiempo.
Grado de habilidad, conocimientos y
tipos de actitudes.
Características personales de
comportamiento.
Lugar donde se afectará el entrenamiento,
considerando también el horario más
oportuno o la ocasión más propicia.
Época o periodicidad del entrenamiento,
considerando también el horario más
oportuno o la ocasión más propicia.
Calculo de la relación costo-beneficio del
programa.
Control y evaluación de los resultados,
considerando la verificación de puntos
críticos que requieren ajustes o
modificaciones en el programa para
mejorar su eficacia.
EJECUCIÓN Y DESARROLLO DEL
ADIESTRAMIENTO
(PRESUPUESTOS)
La ejecución del entrenamiento
presupone el binomio instructor/aprendiz.
Los aprendices son personas situadas en
cualquier nivel jerárquico de la empresa,
que necesitan aprender o mejorar los
conocimientos que tienen sobre alguna
actividad o trabajo. Los instructores son
personas situadas en cualquier jerárquico
Página 25
de la empresa, expertos o especializados
en determinada actividad o trabajo, que
transmiten sus conocimientos a los
aprendices. Los auxiliares, jefes o
gerentes pueden ser aprendices; así
mismos pueden ser instructores, cargo
que también puede desempeñar el
encargado o gerente de entrenamiento.
Además, el entrenamiento
presupone una relación
instrucción/aprendizaje. Instrucción es la
enseñanza originada de cierta tarea o
actividad; aprendizaje es la incorporación
del o enseñado a comportamiento del
individuo. Por tanto, aprender es
modificar el comportamiento gracias a lo
enseñado.
La ejecución del entrenamiento depende
de lo siguientes elementos:
Adecuación del programa de
entrenamiento al as necesidades de la
organización.
Calidad del material de entrenamiento
presentado.
Cooperación de los jefes y dirigentes de
la empresa.
Calidad y preparación de los instructores.
Calidad de los aprendices.
EVALUACIÓN Y SEGUIMIENTO DEL
ADIESTRAMIENTO (CONTROL)
La etapa final del proceso de
entrenamiento es la evaluación de los
resultados obtenidos. Es necesario evaluar
la eficiencia del programa de
entrenamiento. Esta evaluación debe
considerar dos aspectos:
Determinar si el entrenamiento
produjo las modificaciones deseadas en el
Comportamiento de los empleados.
Verificar si los resultados del
entrenamiento presentan relación con la
consecución de las metas de la empresa.
Además de estos dos aspectos, es
necesario determinar si las técnicas de
entrenamiento empleadas son efectivas.
La evaluación de los resultados
del entrenamiento puede hacerse en tres
niveles:
En el nivel organizacional. En este
nivel, le entrenamiento debe proporcionar
resultados como:
Aumento en la eficacia organizacional.
Mejoramiento en la imagen de la
empresa.
Mejoramiento en el clima organizacional.
Mejores relaciones entre la empresa y sus
empleados.
Facilidad en los cambios y en la
innovación.
En el nivel de los Recursos Humanos.
Reducción de la a rotación de personal.
Disminución del ausentismo.
Aumento de la a eficiencia individual de
los empleados.
Aumento de las habilidades de las
personas.
Página 26
Elevación del conocimiento de las
personas.
En el nivel de las tareas y obligaciones.
Aumento de la productividad.
Mejoramiento de la calidad de los
productos y servicios.
Reducción del ciclo de la producción.
Mejoramiento de la atención al cliente.
Reducción de índices de accidente.
Desde un punto de vista más amplio, el
entrenamiento parece una respecta lógica
a un marco de condiciones ambientales
mutables y a nuevos requisitos para la
supervivencia y el crecimiento
organizacional.
TIPOS DE ADIESTRAMIENTO
Es la orientación general, que se le
da al empleado para adecuarlo al puesto,
al grupo y a la institución. Este tipo de
formación tiene por meta crear una
actitud favorable del empleado y facilitar
su proceso de integración.
Adiestramiento a través de la
experiencia: consiste en reunir un grupo
de personas en base a tareas o áreas
similares para intercambiar experiencias,
métodos, recursos y otros. En tales
espacios se debe establecer un flujo
informativo precisando objetivos,
expectativas, dinámicas, metodología,
aspectos organizativos y el código para el
análisis. Este tipo de formación podría ser
muy útil, ya que de la experiencia de los
individuos o grupos se enriquece el
trabajo y se comparten vivencias muy
significativas.
Adiestramiento "en" y "para" la
organización: consiste en desarrollar al
máximo el potencial humano de la
institución por vía de la implementación
de un sistema de educación permanente
que abarque las siguientes etapas:
Preparación y actualización para el mejor
desempeño del cargo.
Preparación para otros cargos que pudiera
ocupar el empleado.
Preparación para el desarrollo general
integral.
La capacitación en las instituciones debe
basarse en las siguientes condiciones:
Las necesidades de las personas.
El crecimiento individual
La participación como aprendizaje activo.
La capacidad para dar respuestas a
necesidades de la realidad y la posibilidad
de aplicarlas a la vida cotidiana.
Los conocimientos y experiencias
de los participantes, revalorizando y
reforzando el aprendizaje existente e
incorporando nuevos conocimientos.
El aprendizaje en equipo que permite
mayor posibilidad de interacción e
intercambio.
Centros de adiestramiento y
especializados: habiendo procesado de
antemano las necesidades actuales y
futuras del personal, se puede ofrecer la
oportunidad de formación y
entrenamiento en un centro de
capacitación, para que el empleado asuma
Página 27
con mayor responsabilidad y eficacia el
trabajo que desempeña.
Análisis Económico
Es un término que se refiere tanto a:
Una disciplina formal (técnica) a
utilizarse para evaluar, o ayudar a evaluar,
en el caso de un proyecto o propuesta,
que en sí es un proceso conocido como
evaluación de proyectos;
Un planteamiento informal para tomar
decisiones de algún tipo, por naturaleza
inherente a toda acción humana.
Bajo ambas definiciones, el
proceso involucra, ya sea explícita o
implícitamente, un peso total de los
gastos previstos en contra del total de los
beneficios previstos de una o más
acciones con el fin de seleccionar la
mejor opción o la más rentable. Muy
relacionado, pero ligeramente diferentes,
están las técnicas formales que incluyen
análisis coste-eficacia y análisis de la
eficacia del beneficio.
El coste-beneficio es una lógica o
razonamiento basado en el principio de
obtener los mayores y mejores resultados
al menor esfuerzo invertido, tanto por
eficiencia técnica como por motivación
humana. Se supone que todos los hechos
y actos pueden evaluarse bajo esta lógica,
aquellos dónde los beneficios superan el
coste son exitosos, caso contrario
fracasan
Análisis costo y beneficios
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
Página 28
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
Página 29
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.
Conveniencia
Financiera
Página 30
Beneficios tangibles e
intangibles
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
Página 31
Conclusión
Para concluir en esta
revista digital nos hemos
enfocado y aclarado los temas
como la importancia de la
implementación, la evaluación de
prototipo en donde aprendimos
que es 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. Y
otros puntos como Preparación y
planificación de adiestramiento,
la conveniencia financiera y los
beneficios tangibles e intangibles.
Esperamos le haya sido de su
agrado, y que esta revista sea útil
a la hora de su trabajo. No solo
con la facilidad de los diagramas
sino también con los diferentes
conceptos de cómo se debe
trabajar en la empresa. Para así
sea de más utilidad y rapidez lo
que busca a realizar, ya que no
solo son temas planteados sino
también ejemplos realizados con
anexos para que les sea más fácil
el estudio del mismo.
Página 32
Bibliografía
ANDREW R., RICART J.
ESTRATEGIA Y SISTEMAS
DE INFORMACIÓN.
EDITORIAL MC. GRAW
HILL.
MARTIN J., ODELL J.
ANÁLISIS Y DISEÑO
ORIENTADO A OBJETOS.
EDITORIAL PRENTICE
HALL.
SEEN J. ANÁLISIS Y DISEÑO
DE SISTEMAS DE
INFORMACIÓN. EDITORIAL
MC. GRAW HILL.
DAVIS G., OLSON M.
SISTEMAS DE
INFORMACIÓN
GERENCIAL. EDITORIAL
MC. GRAW HILL.
KENDALL Y KENDALL.
ANÁLISIS Y DISEÑO DE
SISTEMAS. EDITORIAL
PRENTICE HALL.
Referencias Electrónicas
·http://www.monografias.com/tr
abajos12/recoldat/recoldat.shtm
l
·http://www.rena.edu.ve/cuarta
Etapa/Informatica/Tema11.html
·http://www.monografias.com/tr
abajos/anaydisesis/anaydisesis.s
html
·http://elvex.ugr.es/idbis/db/docs
/lifecycle.pdf