Issuu on Google+

República Bolivariana de Venezuela Ministerio Del Poder Popular Para La Educación Universitaria Universidad Bicentenaria de Aragua Vicerrectorado Académico Facultad de Ingeniería Escuela de Ingeniería de Sistemas

Revista Digital  Componentes del Diseño de Sistema

Alcides Franco ‐ 5.451.716 Julio 2013

Edición 1   


República Bolivariana de Venezuela Ministerio Del Poder Popular Para La Educación Universitaria Universidad Bicentenaria de Aragua Vicerrectorado Académico Facultad de Ingeniería Escuela de Ingeniería de Sistemas

Revista Digital Componentes del Diseño de Sistemas Semestre: V.  Facilitador: Ing. Carla Hennig Sección: 1 Alumno: Alcides Franco ‐ 5.451.716 Cátedra: Análisis y Diseño de Sistemas II Periodo: 2013 ‐I

CONTENIDO Editorial…………………………………………………………2 Métodos y diagramas orientados a objetos …. 3 Prototipos ………………..…………………………………..6 Pruebas…………………………………………………….……8 Documentación…………………..………………….…….11 Manuales …………………………..…………….……..…..13 Análisis Costo Beneficio……….……………………….15 Proyección del  Negocio……….………………..…….16 Costos …………………………………….……………………17 Beneficios tangibles e intangibles……….………..18 Referencias Bibliográficas …………………………….19

2


Editorial La globalización de la tecnología implica entre otras cosas la  modernización de los medios y la concentración de la  información en dispositivos y medios que sean de fácil acceso..  La expansión y popularización de la INTERNET sumado a las  nuevas tecnologías están permitiendo un escenario propicio  para el desarrollo de nuevos conceptos de medio de difusión  de la información.. Estos trabajos quedan a disposición de la  comunidad generando información resumida y bibliografía en  una forma más amena y visual de ver la información de ahí la  importancia de las revista digitales Alcides Franco

Métodos y Diagramación Orientados a Objetos 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.  Algunas metodologias Existentes Catalysis: Un método orientado a objetos que fusiona mucho del trabajo  reciente en métodos orientados a objetos, y además ofrece técnicas  específicas para modelar componentes distribuidos.  Objetory: Un método de Caso de Uso guiado para el desarrollo, creado por  Ivar Jacobson.  Shlaer/Mellor: El método para diseñar sistemas de tiempo real, puesto en  marcha por Sally Shlaer y Steven Mellor en dos libros de 1991, Ciclos de vida  de Objetos, modelando el Mundo en Estados y Ciclos de vida de Objetos,  Modelando el mundo en Datos (Prentice Hall).  Fusion: Desarrollado en Hewlett Packard a mediados de los noventa como  primer intento de un método de diseño orientado a objetos estándar.  Combina OMT y Booch con tarjetas CRC y métodos formales  OMT: La Técnica de Modelado de Objetos fue desarrollada por James  Rumbaugh y otros,: publicada en el libro de gran influencia "Diseño y  Modelado Orientado a Objetos" (Prentice Hall, 1991). Un método que  propone análisis y diseño ’iterative’, más centrado en el lado del análisis.  Booch: Parecido al OMT, y también muy popular, la primera y segunda edición  de "Diseño Orientado a Objetos, con Aplicaciones" (Benjamin Cummings, 1991  y 1994), (Object‐Oriented Design, With Applications), detallan un método  ofreciendo también diseño y análisis ’iterative’, centrándose en el lado del  diseño. 

3


Diagramas UML

Diagrama de Caso de Uso 

• 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. 

Es 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 ¿PARA QUE SIRVEN LOS CASOS DE USO? Para capturar el comportamiento deseado del sistema sin tener que  especificar como 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 Un actor (1) es una clase de persona, organización, dispositivo o componente  de software externo que interactúa con el sistema. Los actores del ejemplo  son Cliente, Restaurante, Sensor de temperatura y Titular de tarjeta de  crédito.  Un caso de uso (2) representa las acciones que uno o varios de los actores  realizan a fin de conseguir un objetivo determinado. Los casos de uso del  ejemplo son Pedir menú, Actualizar menú y Procesar pago.  En un diagrama de casos de uso, los casos de uso están asociados (3) a los  actores que los realizan.  El sistema (4) es aquello que se está desarrollando. Podría tratarse de un  pequeño componente de software, cuyos actores simplemente fueran otros  componentes de software, o podría tratarse de un gran conjunto de  aplicaciones que se implementan en muchos equipos y dispositivos. Los  subsistemas del ejemplo son Sitio web de pedidos de menú, Empresa de  envío de menús y Versión 2 del sitio web.  4


Diagramas de Secuencia un diagrama de secuencia muestra una  interacción, que representa la secuencia de  mensajes entre las instancias de clases,  componentes, subsistemas o actores. El tiempo  fluye hacia abajo en el diagrama y muestra el flujo  de control de un participante a otro

Forma 

Elemento 

Descripción  Una línea vertical que representa la secuencia de eventos que se producen en  un participante durante una interacción, mientras el tiempo avanza. Este  participante puede ser una instancia de una clase, componente o actor.  Un participante que es externo al sistema que está desarrollando. Puede hacer  que aparezca un símbolo de actor en la parte superior de una línea de vida  estableciendo su propiedad Actor.  El remitente espera una respuesta a un mensaje sincrónico antes de continuar.  El diagrama muestra la llamada y el retorno. Los mensajes sincrónicos se utilizan  para representar llamadas de función ordinarias dentro de un programa, así  como otros tipos de mensaje que se comportan de la misma manera.  Un mensaje que no requiere una respuesta antes de que el remitente continúe.  Un mensaje asincrónico muestra sólo una llamada del remitente. Se utiliza para  representar la comunicación entre subprocesos diferentes o la creación de un  nuevo subproceso.  Un rectángulo sombreado vertical que aparece en la línea de la vida de un  participante y representa el período durante el que el participante está  ejecutando una operación. La ejecución comienza donde el participante recibe  un mensaje. Si el mensaje inicial es un mensaje sincrónico, la ejecución  finalizará con una flecha de «devolución» al remitente.  Un mensaje que vuelve a un participante que está esperando la devolución de  una llamada anterior. La aparición de ejecución resultante aparece encima de la  existente.  Un mensaje de un participante a sí mismo. La aparición de ejecución resultante  aparece encima de la ejecución de envío.  Un mensaje que crea un participante. Si un participante recibe un mensaje de  creación, este debe ser el primer mensaje que recibe.  Un mensaje asincrónico de un participante desconocido o no especificado.  Un mensaje asincrónico a un participante desconocido o no especificado.  Un comentario se puede adjuntar a cualquier punto de una línea de vida.  Agrega una secuencia de mensajes que se definen en otro diagrama. Para crear  un Uso de interacción, haga clic en la herramienta y arrastre por las líneas de  vida que desee incluir.  Una colección de fragmentos. Cada fragmento puede agregar uno o más  mensajes. Existen distintos tipos de fragmentos combinados. Para obtener más  información, Para crear un fragmento, haga clic con el botón secundario en un  mensaje, elija Rodear con y, a continuación, haga clic en un tipo de fragmento. 

Línea de vida 

Actor 

Mensaje sincrónico 

Mensaje asincrónico 

Incidencia de ejecución 

Mensaje de devolución de  llamada 

Automensaje 

Crear mensajes 

9  10  11 

Mensaje encontrado  Mensaje perdido  Comentario 

12 

Uso de interacción 

13 

Fragmento combinado 

14 

Protección de fragmentos 

Para establecer la protección, seleccione un fragmento, seleccione después la  protección y escriba un valor. 

Evento de destrucción 

Representa el punto en el que se elimina el objeto o ya no está disponible.  Aparece en la parte inferior de cada línea. 

5


¿Qué es un Prototipo? Es un modelo a escala o facsímil de lo real, pero no tan  funcional para que equivalga a un producto final, ya que no  lleva a cabo la totalidad de las funciones necesarias del  sistema final. Proporcionando una retroalimentación  temprana por parte de los usuarios acerca del Sistema. Importancia de Definir su Objetivo Siempre se debe establecer cuál es su objetivo, ya que un  prototipo puede ser útil en diferentes fases del proyecto,  por ello su objetivo debe ser claro. Durante la fase de  análisis se usa para obtener los requerimientos del usuario.  En la fase de diseño se usa para ayudar a evaluar muchos  aspectos de la implementación seleccionada. Propósitos del Prototipo En la fase de Análisis de un proyecto, su principal propósito  es obtener y validar los requerimientos esenciales,  manteniendo abiertas, las opciones de implementación.  Esto implica que se debe tomar los comentarios de los  usuarios, pero debemos regresar a sus objetivos para no  perder la atención. En la fase de Diseño, su propósito, basándose en los  requerimientos previamente obtenidos, es mostrar las  ventanas, su navegación, interacción, controles y botones al  usuario y obtener una retroalimentación que nos permite  mejorar el Diseño de Interfaz. Características de los Prototipos El proceso de desarrollo y empleo de prototipos tiene las  siguientes características: •El prototipo es una aplicación que funciona •Los prototipos se crean con rapidez •Los prototipos evolucionan a través de un proceso  iterativo •Los prototipos tienen un costo bajo de desarrollo

Información Obtenida con el uso del Prototipo •Reacciones Iniciales del Usuario: El profesional de Sistema por medio de  la observación, evaluación y la retroalimentación, obtendrá cómo  reaccionan los usuarios al trabajar con el prototipo, y que tan conveniente  es el acoplamiento entre las necesidades y las características modeladas en  el sistema. A través de la recopilación de tales reacciones, el profesional,  irá descubriendo nuevas perspectivas del prototipo, incluso si los usuarios  se encuentran satisfechos con él, o si habrá dificultades para vender o  implantar el sistema. •Sugerencias: Las sugerencias son el fruto de la relación de los usuarios  con el prototipo, las sugerencias aportadas por el usuario indican al  profesional porque caminos dirigirse para refinar el prototipo, modificarlo  o depurarlo, de forma que satisfaga mejor las necesidades de los usuarios. •Innovaciones: Las innovaciones son aquellas características nuevas del  sistema que no fueron contempladas previamente a la interacción con el  prototipo. •Prioridades: La información que se obtiene con el uso de prototipos  permite al profesional establecer prioridades y reorientar sus planes de  una manera menos costosas y con un mínimo de contratiempo. Una de las  peores cosas que le puede pasar a un profesional es diseñar e implantar un  sistema que el usuario no necesita, ni desea. 6


Prototipos  Es frecuente que los clientes no sepan lo que quieren, pero cuando  ven algo y utilizan prototipos, pronto saben lo que no quieren. Los prototipos son una representación limitada de un producto,  permite a las partes probarlo en situaciones reales o explorar su  uso, creando así un proceso de diseño de iteración que genera  calidad. Un prototipo puede ser cualquier cosa, desde un trozo de papel con  sencillos dibujos a un complejo software.

¿Por qué un prototipo?

APLICACIONES CANDIDATAS Los prototipos son más eficaces en el desarrollo de sistemas de información cuando se cumplen ciertas condiciones. Cualquiera de las siguientes cinco (5) condiciones sugieren la necesidad de utilizar un prototipo: •No se conocen los requerimientos: La naturaleza de la aplicación es tal, que existe poca información disponible con respecto a las características que debe tener el sistema para satisfacer los requerimientos de los usuarios. •Los requerimientos necesitan evaluarse: Se conocen los requerimientos aparentes de información, tanto de los usuarios finales como de la organización, pero es necesario verificarlos y validarlos. •Costos altos: La inversión de recursos financieros y humanos, así como el tiempo necesario para generar la aplicación es sustancial. Existen otros proyectos que también compiten por los mismos recursos. •Altos riesgos: La evaluación inexacta de los requerimientos del sistema o el desarrollo incorrecto de una aplicación ponen en peligro a la organización, a sus empleados y también a sus propios recursos. •Nueva tecnología: El deseo de instalar nueva tecnología ya sea en los campos de la informática y computación, comunicación de datos u otras áreas relacionadas, abre nuevas fronteras para la organización.

Porque son útiles para comunicar, discutir y definir ideas entre los  diseñadores y las partes responsables. Los prototipos apoyan la evaluación de productos, clarifican  requisitos de usuario y definen alternativas.

Prototipos de baja fidelidad Utilizan materiales distintos al del producto final, son baratos,  simples y fáciles de producir.  Son particularmente útiles en las fases iniciales del desarrollo,  durante el diseño conceptual.

Prototipo de alta fidelidad Son aquellos que se parecen al producto final y utiliza sus mismos  materiales.  Se  desaconseja el uso de prototipos de alta fidelidad porque: • Necesitan mucho tiempo para crearse. • Las pruebas tienden a centrarse en aspectos superficiales. • Los desarrolladores se resisten a cambiar algo que les ha llevado  horas crear.  • Crea excesiva expectación.  • Un error puede parar un test. 

7


Pruebas

¿Por qué probar?

Las fallas de software ocasionan graves pérdidas económicas; éstos son 100 a 1000 veces más costosos de encontrar y reparar después de la construcción. Evitar plazos y presupuestos incumplidos, insatisfacción del usuario, escasa productividad y mala calidad en el software producido y finalmente la pérdida de clientes. Automatizar el proceso de pruebas consigue reducciones de hasta un 75% en el costo de la fase de mantenimiento.

Definiciones importantes  Prueba (test): Actividad en la cual se somete a un sistema o uno de sus componentes a una  evaluación de los resultados que arroja en base a la ejecución de éste en condiciones  especificadas.  Caso de Prueba (test case): Conjunto de entradas y condiciones que arrojan resultados  esperados desarrollados con un objetivo en particular.  Error: Acción humana que produce o genera un resultado incorrecto.  Defecto: Es la manifestación de un error en el software. Un defecto es encontrado porque  causa una FALLA, la cuál es una desviación del servicio o resultado esperado.  Verificación: Determinar si los productos de una fase dada satisfacen las condiciones  impuestas al inicio de la fase. ¿Estamos construyendo correctamente el producto?  Validación: Evaluación de un sistema o uno de sus componentes durante o al final de su  desarrollo para determinar si satisface los requisitos.

¿Quiénes deben de probar o que se  debe probar?  Cada caso de prueba debe definir el resultado  de salida esperado. El programador debe evitar  probar sus propios programas, ya que desea  (consciente o inconscientemente) demostrar  que funcionan sin problemas. Se debe  inspeccionar a conciencia el resultado de cada  prueba, así, poder descubrir posibles síntomas  de defectos.  Al generar casos de prueba, se deben incluir  tanto datos de entrada válidos y esperados  como no válidos e inesperados. Las pruebas  deben centrarse en dos objetivos: Probar si el  software no hace lo que debe hacer Probar si el  software hace lo que no debe hacer, es decir, si  provoca efectos secundarios adversos.  Se deben evitar los casos no documentados ni  diseñados con cuidado. No deben hacerse  planes de prueba suponiendo que,  prácticamente, no hay defectos en los  programas y, por lo tanto, dedicando pocos  recursos a las pruebas. 

¿Por qué no probar todo?  Prácticamente imposible. Es imposible evaluar todas las posibilidades. Recursos (costos, tiempo, personal) ¿Cuántos ciclos de pruebas son  suficientes? 

8


Clasificación de las pruebas Pruebas unitarias: (componente, modulares o programa) Ejecutadas usualmente por los desarrolladores. Técnicas de caja blanca. Importante definir nivel de dependencia, a mayor independencia mayor efectividad. Pruebas de sistemas Ejecutadas por los desarrolladores o equipo de pruebas en un ambiente controlado. Deben demostrar que los sistemas cumplen con los requerimientos detallados en los documentos de especificaciones de funcionalidad y calidad. Tipos: Funcionales No funcionales Pruebas de integración Ejecutadas para exponer fallas en interfaces y en la interacción entre componentes. Ejecutadas por los desarrolladores. Técnicas: Big bang Top down Bottom up Middle‐out Funcionales: Requerimientos No funcionales: Carga Estrés Usabilidad Volumen Documentación Desempeño Seguridad Almacenamiento Instalación Recuperación Pruebas de aceptación: Ejecutadas por los usuarios y líderes de proyecto ó administradores en un ambiente simulado de operación. Deben demostrar que los sistemas cumplen con los requerimientos detallados en los documentos de especificaciones de funcionalidad y calidad. Pruebas de regresión: Determinar que las modificaciones no han causado fallas o efectos adversos. Determina que se cumple con los requerimientos. Modificaciones menores selección de pruebas. Pruebas de caja: Existen tres enfoques para el diseño de casos de prueba: El enfoque estructural o de caja blanca El enfoque funcional o de caja negra El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadísticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba. Las Pruebas de caja blanca realizan un seguimiento del código fuente de manera que se determinan las instrucciones, bloques, etc. en los que existen errores. Las pruebas dinámicas se dividen en dos: Explícitas: Ejecución de los casos de prueba, comparar los resultados obtenidos con los esperados. Implícitas: Análisis de los datos o información que el sistema entrega, para detectar funcionamientos erróneos.

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.

9


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 hardware 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. 10


Importancia

La documentación:

Constituye el respaldo formal de la información  Es el elemento integrador que permite la  apreciación unitaria y conjunta del sistema 

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.

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 

•aquellos que no pueden ser  omitidos

Convencionales

•Aquellos que enriquecen  los antecedentes  documentales del sistema •Su omisión no tendrá  consecuencias  irremediables

Los elementos  que conforman la  documentación de  los sistemas,  pueden ser  categorizados  como:

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 

Imprescindibles

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 11


Carpeta de papeles de trabajo (análisis): 

Carpeta de operaciones: 

•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

•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

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

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 

12


Programas Documentadores Se puede documentar con procesadores de texto Un programa que se puede utilizar para diseñar y/o  documentar es el Erwin. Un programa exclusivo para hacer o documentar  manuales de usuarios es el Help Workshop Otra manera de documentar la instalación y manejo  de una aplicación es generando archivos en formato  HTML (como una página Web).

MANUALES DE DOCUMENTACIÓN Durante el desarrollo de un sistema, desde su concepción  hasta su puesta en marcha se ha generado 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.  La documentación de un sistema debe ser marcada  adecuadamente, bien organizada actualizada y completa;  todos los términos utilizados deben explicarse. La  documentación se hará disponible a todos los usuarios de  acuerdo a sus necesidades. El estilo de redacción de los manuales de documentación  debe ser:

Tipos de Manuales • • • •

Manuales de Usuario Manuales de Operación Manuales de Sistemas Manuales de Procedimientos

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

• • • • • •

13


El manual de usuario

El manual técnico

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.

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: • 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. Utilidad del manual de procedimientos • 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. 

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.

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.  14


El análisis de costo‐beneficio  • 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 costo‐eficacia y  análisis de la eficacia del beneficio. El costo‐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 costo son exitosos, caso contrario  fracasan.

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 .

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 o la realización  o  actualización de un nuevo sistema. 15


Proyecto de Negocios El análisis para la evaluación de un proyecto de inversión debe simplificarse,  haciendo uso primero del sentido común, y luego de ciertas herramientas  que ayuden a realizar una evaluación metodológica racional, con la finalidad  de reducir la incertidumbre. Antes de pensar en hacer una inversión de  capital, es muy importante tener muy claro cuál es la necesidad de nuestra  empresa y qué se necesita para atenderla. Una vez ideada la inversión que  creemos necesitar, debemos tener claro dónde y cómo encaja esa nueva  máquina, ese nuevo camión, esa nueva línea de producto, en nuestro  negocio actual, y cómo va a ayudar para generar sinergias. “un proyecto es la  fuente de costos y beneficios que ocurren en distintos periodos de tiempo”.  Debemos encontrarle el sentido a la inversión que queremos hacer, …un  sentido que sea congruente con el negocio para después, iniciar el proceso  de identificación, cuantificación y valoración de los costos y beneficios. Una vez acreditada la viabilidad de la idea de inversión mediante una  evaluación previa con base en el sentido común, se deben realizar estudios  de mercado, técnicos, ambientales, legales y económicos para corroborar la  factibilidad del proyecto. Salvado lo anterior se puede iniciar el análisis de  gestión del financiamiento, a través del cual se define el costo de la inversión  y se intenta pronosticar los flujos de efectivo que causará el proyecto:  positivos como incremento en ventas y reducción de costos actuales, y  negativos como la inversión por si misma, los nuevos costos de  mantenimiento y la nueva fuerza laboral. Es de especial utilidad dibujar una línea de tiempo que considere el horizonte  de valuación (el tiempo entre que se realiza la inversión y se concluyen los  costos y beneficios derivados de ésta), en la que se identifiquen los ingresos y  los egresos implicados de manera gráfica, colocando a los egresos con flechas  hacia afuera de la línea y a los ingresos con flechas hacia adentro (figura 1)

Entendidos los flujos de efectivo, podemos iniciar con el uso de  ciertas herramientas relativamente sencillas para evaluar  cuantitativamente los beneficios de un proyecto, y compararlos con  los de proyectos alternativos Valor Presente Neto (“VPN”) y Tasa Interna de Retorno (“TIR”)  Son la base para la evaluación financiera de un proyecto. Se  consideran como una misma técnica porque en realidad es el mismo  método, pero expresado en distintos términos. Ambas consideran el  valor del dinero en el tiempo (no vale lo mismo un dolar hoy que el  mismo dolar dentro de un año). El VPN indica el valor hoy, de flujos de  efectivo (positivos y negativos) a percibirse en el futuro. Para  calcularse se necesita saber (1) el monto y tiempo de los flujos de  efectivo (de acuerdo a la línea de tiempo dibujada) y (2) la tasa de  descuento, que es la tasa que representa el costo de oportunidad.

Otros análisis importantes • • • • •

Análisis de sensibilidad Análisis de escenarios Análisis del punto de equilibrio Plazo de recuperación o “Payback” Árboles de decisión 16


Costos Iniciales,  Desarrollo ,  Venta El costo de producción de un paquete de software es insignificante, si se compara con el alto costo de su  desarrollo. Las empresas de software amortizan el desarrollo con la venta de una gran cantidad de  paquetes de software. El fabricante que más venda dispondrá de mayor dinero para el desarrollo,  marketing, distribución, etc., además de ganar crecientes economías de escala. Es por ello que el mercado  del software tiene tendencia al monopolio. Las compañías pequeñas desaparecen o se fusionan con  empresas más grandes, debido a su pequeña base instalada de usuarios, bajo soporte técnico y  presupuestos de desarrollo escasos. En esta industria el proceso de acumulación de ganancias puede ser  muy rápido. Cuando el producto es exitoso genera importantes ganancias, a diferencia de uno que no,  perderá mercado y será desplazado por otros que lo sustituirán y sus ganancias caerán abruptamente. Por  esta razón una vez que un fabricante ha logrado una porción del mercado lo defiende a toda costa. Las  técnicas habituales para defender su posición en el mercado son: cambio permanente (nuevas versiones),  complejidad innecesaria y uso de la propiedad intelectual.  Algunas técnicas de marketing con el mismo fin es el vapourware, que es cuando el software se  promociona mucho antes de ser presentado o simplemente nunca llega. Las compañías de software se  encargan de tener poderosas fuerzas de venta y canales de distribución Los gastos iniciales en desarrollo, marketing e infraestructura de soporte técnico para las versiones iniciales son significantes. El desarrollo  de nuevas versiones basadas en una anterior requiere menos gastos para desarrollar porque están basadas en la misma técnica de  desarrollo. Los márgenes gruesos en el negocio del software son a menudo 70% o 80% ya que se necesitan muy pocos gastos para soportar  una compañía de software. El trabajo del recurso humano es el mayor ítem ya que el desarrollo de software a menudo involucra el trabajo  en equipo de 6, 12 o incluso 100 personas. En la industria es común las compras hostiles o agresivas, Hay quienes dicen que la fusión de dos compañías es mucho más costosa que  desarrollar sus propios productos Un ejemplo es IBM, que en el pasado ha adquirido compañías como Tivoli, Corepoint, Lotus  Development. Es usual que las compañías de software tengan programas para reclutar socios de negocios (business partners program), con la cual  amplían su marco de acción. Hay que distinguir que la venta de software empaquetado es diferente a la venta de software a la medida o para empresas. En general el  software empaquetado es instalado por el usuario y está listo para ser usado. Ofrece una solución común a todos a diferencia de un  software a medida que satisface exactamente las necesidades del usuario. Además el soporte técnico se limita a un soporte telefónico. La  distribución de software empaquetado está a cargo de distribuidores mayoristas que compran a fabrica volúmenes considerables a precios  que les permiten una reventa con un cierto margen. El producto llega al usuario final a través de resellers o tiendas retail. Los márgenes de  un distribuidor mayorista pueden variar entre un 3‐5%, mientras que el reseller gana en torno al 10%.

17


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.  EJEMPLOS: 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  18


Referencias Bibliograficas • Carla Henning, Material Apoyo Unidad IV Análisis y Diseño de  Sistemas II, UBA • Kendall & Kendall; Análisis y Diseño de Sistemas; 3ª Edición;  Pearson Educación. • Roger S. Pressman; Ingeniería del Software;4ª Edición; Mc  Graw Hill • Davis G., Olson M. Sistemas de Información Gerencial.  Editorial Mc. Graw Hill. • Murdick R., Sistemas de Información Administrativa. Editorial  Prentice Hall. • 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.

19


Revista digital1 af