ANALISIS DE SISTEMAS II Enero 2014 - Edici贸n 01
Componentes de un sistema de informaci贸n
Ediciones DIOH
Indice Evaluación del Prototipo 3
Etapas del prototipo de sistemas 4 Importancia de definir su objetivo 3 Propositos del Prototipo 3
Las Pruebas Son Necesarias 6 República Bolivariana de venezuela Ministerio Popular Para la Educación Superior Universidad Bicentenaria de Aragua San Joaquin de Turmero - Edo. Aragua Autores: Domingo Oropeza, C.I. 14.890.589 Jose Felix Vargas, C.I. 7.238.535 Facilitador: Ing. Carla Hening
Caja blanca 8 Caja negra 9 Caja negra y programación modular 9 Pruebas de integración 7 Pruebas de validación 8 Pruebas funcionales 7 Ventajas de las pruebas unitarias 6
Manuales del sistema 10
Manual Administrativo 12 Manual del usuario 12 Manual de operación 13 Objetivos de la documentación de sistemas 13
Catedra: Analisis y Diseño de Sistemas II
Referencias 14
EDITORIAL Antes de comenzar el desarrollo de cualquier proyecto, se conoce un estudio de sistema s para detectar todos los detalles de la situación actual en la empresa. La información reunida sirve como base para crear varias estrategias de diseño. Los administradores deciden qué estrategia seguir mientras que los gerentes, empleados y otros usuarios finales que se familiarizan cada vez más con el empleo de computadoras que están teniendo un papel muy importante en el desarrollo de sistemas.
2
Evaluación del Prototipo
E
en diferentes fases del proyecto, por ello su objetivo deb eser claro. Durante la fase de análisis se usa para obtener los requeri-
l prototipo es un modelo a
por parte de los usuarios acerca mientos del usuario. En la fase
escala o facsímil de lo real,
del Sistema.
de diseño se usa para ayudar a
pero no tan funcional para que
evaluar muchos aspectos de la
equivalga a un producto final, ya Importancia de definir su
implementación selecionada.
que no lleva a cabo la totalidad
objetivo
de las funciones necesarias del
sistema final. Proporcionando
blecer cuál es su objetivo, ya
una retroalimentación temprana
que un prototipo puede ser útil
un proyecto, el principal propó-
Siempre se debe esta-
Propositos del Prototipo En la fase de análisis de
3
sito es obtener y validar los re-
riencia o información, o donde
analistas y usuario deben de tra-
querimiento esenciales, man-
los costos y riesgos de que se
bajar juntos para identificar los
teniendo abiertas, las opciones
cometa un error pueden ser al-
requerimientos conocidos que
de implementación. Esto implica
tos.
tienen que satisfacer.”
que se debe tomar los come-
2. Desarrollo de un modelo de
nentarios de los usuarios, pero
trabajo
debemos regresar a sus objeti-
vos para no perder la atención.
ceso de construcción del proto-
La construcción de pro-
tipo con el desarrollo de un plan
totipos representa una estra-
general que permita a los usua-
tegia de desarrollo, cuando no
Etapas del prototipo de rios conocer lo que se espera de
es posible determinar todos los
sistemas
requerimientos del usuario. Es 1. Identificación de requeri-
“Es fácil comenzar el pro-
ellas y del proceso de desarrollo. Un cronograma para el inicio
por ello que incluye el desarrollo
mientos conocidos
y el fin de la primera interacción
interactivo o en continua evolu-
“La determinación de los
es de gran ayuda. En el desarro-
ción, donde el usuario participa
requerimientos de una aplica-
llo del prototipo se preparan los
de forma directa en el proce-
ción es tan importante para el
siguientes componentes:”
so.
método de desarrollo de proto-
3. Utilización del prototipo
contiene
tipos como lo es para el ciclo de
condiciones únicas de aplica-
desarrollo de sistemas o análisis
usuario trabajar con el prototi-
ción, en donde los encargados
estructurado. Por consiguiente,
po y evaluar sus características
del desarrollo tienen poca expe-
antes de crear un prototipo, los
y operación. La experiencia del
Este
método
Cracteristicas 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.
“Es responsabilidad del
sistema bajo condiciones reales permite obtener la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios, así como las características inadecuadas”. 4
4. Revisión del prototipo
“Durante la evaluación
los analistas de sistemas desean capturar información sobre los que les gusta y lo que les desagrada a los usuarios.”
“Los cambios al prototipo
son planificados con los usuarios antes de llevarlos a cabo, sin embargo es el analista res-
Es frecuente que los clientes no sepan lo que quieren, pero cuando ven algo y utilizan prototipos, pronto saben lo que quieren. ponsable de tales modificaciones.” 5. Repetición del proceso las veces que sea necesarias
“El proceso antes descrito
se repite varias veces, el proceso finaliza cuando los usuarios y analistas están de acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las características necesarias.”
5
Las Pruebas Son Necesarias
U
na prueba unitaria en programación es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión. La idea es escribir casos de prueba para cada función no trivial o método en el módulo de forma que cada caso sea independiente del resto.
Ventajas de las pruebas unitarias El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las
partes individuales son correctas. Proporcionan un contrato escrito que el trozo de código debe satisfacer. Estas pruebas aisladas proporcionan cinco ventajas básicas: Las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura (lo que se ha dado en llamar refactorización), puesto que permiten hacer pruebas sobre los cambios y así asegurarse de que los nuevos cambios no han introducido errores. Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración.
6
Requisitos de efectividad para las pruebas unitarias Automatizable: no debería requerirse una intervención manual. Completas: deben cubrir la mayor cantidad de código. Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra. Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc. Aunque estos requisitos no tienen que ser cumplidos al pie de la letra, se recomienda seguirlos o de lo contrario las pruebas pierden parte de su función.
Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo. Dado que la única interacción entre los casos de prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock (mock object) para simular el comportamiento de objetos complejos. Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos. Limitaciones Es importante darse cuenta de que las pruebas unitarias no descubrirán todos los errores del código. Por definición, sólo prueban las unidades por sí solas. Por lo tanto, no descubrirán errores de integración, problemas de rendimiento y otros problemas que afectan a todo el sistema en su conjunto. Además, puede no ser trivial anticipar todos los casos especiales de entradas que puede recibir en realidad la unidad de programa bajo estudio. Las pruebas unitarias sólo son efectivas si se usan en conjunto con otras pruebas de software.
da en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software. Las pruebas funcionales se hacen mediante el diseño de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informático.
Pruebas de integración Pruebas integrales o pruebas de integración son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias. Únicamente se
Pruebas funcionales
Una prueba funcional es una prueba basa-
7
refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecha en conjunto, de una sola vez. Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos. Las pruebas de integración (algunas veces llamadas integración y testeo I&t) es la fase del testeo de software en la cual módulos individuales de software son combinados y testeados como un grupo. Son las pruebas posteriores a las pruebas unitarias y preceden el testeo de sistema.
Pruebas de validación Las pruebas de validación en la ingeniería de software son el proceso de revisión que el sistema de software producido cumple con las especificaciones y que cumple su cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto, que también utiliza técnicas tales como evaluaciones, inspecciones, y tutoriales. La validación es el proceso de comprobar lo que se ha especificado es lo que el usuario realmente quería. Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iniciales. La pre-
Tipos de Validación Pruebas de aceptación: desarrolladas por el cliente. Pruebas alfa: realizadas por el usuario con el desarrollador como observador en un entorno controlado (simulación de un entorno de producción). Pruebas beta: realizadas por el usuario en su entorno de trabajo y sin observadores.
Enfoques a la verificación Dinámica de verificación: también conocido como ensayos o experimentación. Estática de verificación: también conocido como análisis.
gunta a realizarse es: ¿Es esto lo que el cliente quiere?. Características Comprobar que se satisfacen los requisitos: • Se usan la mismas técnicas, pero con otro objetivo. • No hay programas de prueba, sino sólo el código final de la aplicación. • Se prueba el programa completo. • Uno o varios casos de prueba por cada requisito o caso de uso especificado. • Se prueba también rendimiento, capacidad, etc. (y no sólo resultados correctos). • Pruebas alfa (desarrolladores) y beta (usuarios).
Caja blanca En programación, se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo. Así como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del módulo, las de caja blanca están dirigidas a las funciones internas. Entre las técnicas usadas se encuentran; la cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecución), pruebas sobre las expresiones lógico-aritméticas, pruebas de camino de datos (definición-uso de variables), comprobación de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego para las iteraciones máximas,
8
muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento. Un sistema formado por módulos que cumplan las características de caja negra será más fácil de entender ya que permitirá dar una visión más clara del conjunto. El sistema también será más robusto y fácil de mantener, en caso de ocurrir un fallo, éste podrá ser aislado y abordado más ágilmente. Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un módulo concreto, para luego realizar las de caja negra sobre varios subsistemas (integración).
máximas menos uno y más uno. En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse a los métodos de la clase, pero según varias opiniones, ese esfuerzo debería dedicarse a otro tipo de pruebas más especializadas (un argumento podría ser que los métodos de una clase suelen ser menos complejos que los de una función de programación estructurada).
Caja negra En teoría de sistemas y física, se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra deben estar
Caja negra y Programación modular En programación modular, donde un programa (o un algoritmo) es divido en módulos, en la fase de diseño se buscará que cada módulo sea una caja negra dentro del sistema global que es el programa que se pretende desarrollar, de esta manera se consigue una independencia entre los módulos que facilita su implementación separada por un equipo de trabajo donde cada miembro va a encargarse de implementar una parte (un módulo) del programa global; el implementador de un módulo concreto deberá conocer como es la comunicación con los otros módulos (la interfaz), pero no necesitará conocer como trabajan esos otros módulos internamente; en otras palabras, para el desarrollador de un módulo, idealmente, el resto de módulos serán cajas negras.
9
Manuales del sistema
por lo tanto, un documento de comunicación técnica que busca brindar asistencia a los sujetos que usan un sistema. Más allá de su especificidad, los autores de los manuales intentan apelar a un lenguaje ameno y simple para llegar a la mayor cantidad posible de receptores.
Dada su complejidad, to-
dos los productos electrónicos
U
o informáticos suelen contar n manual es una publica-
significado de un manual de
con su propio manual de usua-
ción que incluye los as-
usuario. Este tipo de publica-
rio. Los artículos más simples
pectos fundamentales de una
ciones brinda las instrucciones
(como una pelota o una mesa)
materia. Se trata de una guía
necesarias para que un usuario
no requieren de explicaciones
que ayuda a entender el funcio-
pueda utilizar un determinado
para que los consumidores se-
namiento de algo, o bien que
producto o servicio. Por ejem-
pan cómo utilizarlos.
educa a sus lectores acerca de
plo, si el manual de usuario
un tema de forma ordenada y
está referido a un teléfono móvil
rios suelen estar escritos en
concisa. Un usuario es, por otra
(celular), incluirá los conceptos
diversos idiomas y contar tanto
parte, la persona que usa ordi-
y las guías necesarias para su
con textos como con imágenes.
nariamente algo o que es desti-
utilización, detallando las fun-
De esta forma se facilita la com-
nataria de un producto o de un
ciones de sus teclas, las opcio-
prensión de los conceptos. Los
servicio.
nes disponibles a través de los
diagramas y esquemas también
diferentes menús, etc.
son habituales.
Estas dos definiciones
nos permiten comprender el
Un manual de usuario es,
Los manuales de usua-
Una estructura frecuen10
te de los manuales de usuario
ta abrumado por términos como
han estudiado sus funciones de
incluye una introducción al pro-
“email”, “home” o “touch”; sin
la a a la z.
ducto en cuestión, un índice
embargo, dos décadas atrás, la
con los contenidos del manual,
realidad era muy distinta.
positivos que exigen muy poca
la guía en sí misma, una sec-
Los manuales de usua-
intuición por parte del usuario
ción de problemas frecuentes y
rio sufren de un fenómeno
para ser comprendidos y apro-
su forma de solucionarlos, los
muy particular, que tiene mati-
vechados, no todos gozamos
datos de contacto y un glosario.
ces cómicos a la vez que fina-
de esa predisposición a nivel in-
les trágicos: muy poca gente
telectual; por otro lado, existen
rra una serie de elementos cul-
los consulta. Por lo general, la
determinadas funciones que,
turales y lingüísticos muy difíci-
decisión de no leer un manual
por diferentes motivos, no sal-
les de adaptar a otras lenguas.
está íntimamente relacionada
tan a la vista y requieren de la
En la actualidad, dada la masifi-
con la personalidad, con el tipo
información específica para ser
cación de Internet y de produc-
de persona, y no se da espon-
descubiertas.
tos tales como los smartphones
táneamente; en otras palabras,
(ejemplos en sí mismos de un
existen quienes nunca lo hacen
nual tiene varios objetivos, y
nombre en un idioma extranje-
y quienes no acaban de desen-
uno de ellos es advertir a los
ro), es raro que alguien se sien-
volver el producto hasta que no
consumidores de las limitacio-
En muchos casos, las
Si bien hay muchos dis-
traducciones de los manuales de usuario suelen ser poco confiables, dejando en evidencia que el documento original fue escrito en un idioma diferente. En parte, este problema puede ser justificable si se tiene en cuenta que ciertas tecnologías reciben un nombre específico en su país de origen que encie-
La redacción de un ma-
11
nes de los productos para evitar
Contenido del manual administrativo
quejas por fallos que podrían
• • • • • • • • • •
Nombre del sistema. Equipo encargado del sistema. Planteamiento. Objetivos del sistema. Entradas del sistema (información a captar). Salidas del sistema (resultados a obtener). Diagramación general del sistema. Explicaciones de las fases del sistema. Requerimientos del sistema. Estimación de la fecha probable de implementación del sistema. • Consideraciones generales del nuevo sistema.
haber sido evitados. Y es ésta la razón por la cual todos deberíamos invertir los escasos minutos necesarios para interiorizarnos acerca de los artículos que adquirimos; la consecuencia de actuar impacientemente puede ser una espera de largas semanas, hasta que los técnicos oficiales reparen nuestros dispositivos, o bien nos envíen uno de repuesto, probablemente usado.
Manual Administrativo
expuesto en él satisface los re-
Sirve como punto de par-
querimientos del propio sistema.
tida al Sistema propuesto, ya
Una vez lograda la aprobación,
que será función de la gerencia,
se estará en condiciones de ini-
de acuerdo con los usuarios de
ciar el desarrollo del Sistema
dicho Sistema, determinar silo
propuesto e ir integrando el resto de la documentación.
El manual tiene como fi-
nalidad el permitir a la alta gerencia tener la información necesaria y suficiente sobre un sistema en particular y servir como fuente de consulta una vez que el Sistema ha sido implantado.
Manual del usuario
Expone los procesos que 12
Características del manual de usuario • Diagrama general del sistema. • Diagrama particular detallado. • Instalación del sistema. • Iniciación al uso del sistema. • Manual de referencia. el usuario puede realizar con el sistema implantado. Para lograr esto, es necesario que se detallen todas y cada una de las características que tienen los programas y la forma de acceder e introducir información. Permite a los usuarios conocer el detalle de qué actividades ellos deberán desarrollar para la consecución de los objetivos del sistema. Reúne la información, normas y documentación necesaria para que el usuario conozca y utilice adecuadamente la aplicación desarrollada.
Manual de operación
Contiene la información
que permite al personal de ope-
ración utilizar en forma eficiente
Contenido del manual de operación
la operación de los sistemas de
• Diagrama general del sistema. • Diagrama general del flujo del proceso electrónico. • Explicación genérica de las fases del sistema. • Diagrama de pantallas del sistema. • Puntos a documentar en una pantalla.
procesamiento electrónico.
Objetivos de la documentación de sistemas
Definir detalladamente el
sistema, explicar las características técnicas y la operación de un sistema.
ra de la organización de siste-
mas.
Mejorar la comunicación,
proporcionando el entendimien-
Optimizar la gestión de
to de un sistema a quien lo vaya mantenimiento, asi ser de utilia usar para mantenerlo y para
dad para cualquiera que tenga
enseñar a los usuarios como in-
la responsabilidad del manteni-
teractuar con el sistema y a los miento de los sistemas. operandos como hacerlo funcio- nar.
Fomentar la integración,
para ayudar a los analistas y diVinculo para la capacita-
señadores de sistemas en el tra-
ción, Ayudar al entrenamiento
bajo de integración de sistemas.
del nuevo personal dentro y fue-
Proporcionar estabilidad
al sistema, asi asegurar que el sistema opere correctamente.
Minimizar el consumo de
recursos, utilizando eficientemente los recursos que se dispongan.
13
Referencias • Etapas del prototipo de sistemas. Fecha de consulta: diciembre 27, 2013 desde http://aydds4to.blogspot.com/2012/04/etapas-del-prototipo-de-sistemas.html • Análisis de sistema. Fecha de consulta: diciembre 26, 2013 desde http://5tosemestreinganalisisdesistemas.blogspot.com/p/ desarrollos-y-prototipos.html • Guía del usuario. (2013, 20 de noviembre). Wikipedia, La enciclopedia libre. Fecha de consulta: diciembre 28, 2013 desde http://es.wikipedia.org/w/index.php?title=Gu%C3%ADa_del_ usuario&oldid=70915934. • Definicion del Manual de Usuario. Fecha de consulta: diciembre 28, 2013 desde http://definicion.de/manual-de-usuario/ Documentación de sistemas, http://www.monografias.com/trabajos6/dosi/dosi.shtml • Documentación de sistemas, Fecha de consulta enero 04, 2014 desde http://www.monografias.com/trabajos6/dosi/dosi. shtml