ANALISIS DE SISTEMAS

Trabajo Investigativo 01

Marcela Hernndez Ortegn 20111078041 Carlos Andrs Bernal Cano 20111078006

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD TECNOLOGICA BOGOTA D.C 2013

INTRODUCCION

El software es el conjunto de instrucciones que implementan un conocimiento y tambin puede ser definido por ser la parte lgica de la mquina. En el siguiente trabajo explicaremos su evolucin, caractersticas y las metodologas XP y OMT mediante algunos ejemplos.

EVOLUCION DEL SOFTWARE Primera etapa 1950-1969: Existan pocos mtodos sistemticos. No haban tcnicas de programacin. El desarrollo del software se realizaba virtualmente sin ninguna planificacin. El software se diseaba a medida para cada aplicacin y era utilizado por la misma persona u organizacin. La documentacin del software no exista. Lo ms importante era el hardware. El procesamiento era en Bach. No existan bases de datos. Segunda etapa 1970-1974: Se introduce nuevos conceptos de interaccin hombre-maquina Establecimiento del software como producto y la llegada de las casas del software Los patronos de la industria, del gobierno y de la universidad se aprestaban a desarrollar el mejor paquete de software y ganar asi mucho dinero. Tercera etapa 1975-1985 Surgen sistemas Distribuidos, mltiples computadoras, cada una ejecutando funciones concurrentes y comunicndose con alguna otra. Se vuelve notablemente complejo los sistemas informticos. Llegada y amplio uso de los microprocesadores. Surgen nuevas reas de trabajo como: inteligencia artificial. Redes Sistemas distribuidos. Cuarta etapa Se crean potentes maquinas personales controladas por sistemas operativos sofisticados. Se crean aplicaciones de software avanzadas. Se crean sistemas expertos. Redes neuronales artificiales

 Computacin en paralelo. Tecnologas orientadas a objetos. 4.1 Descripcin del ISO/IEC 12207-1: ISO/IEC 12207: Es el estndar para los procesos de ciclo de vida del software de la organizacin ISO. La estructura del estndar ha sido hecha de manera que pueda ser adaptada a las necesidades de cualquiera que los use. El estndar se base en dos principios fundamentales para as poder conseguir que se adecue a las necesidades: 1. Modularidad: su objetivo es conseguir procesos con un minimo acoplamiento y una mxima cohesin. 2. Responsabilidad: establecer un responsable para cada proceso.

ISO/IEC 12207-1: El estndar ISO/IEC 12207-1 define los requisitos que deben cumplir una evaluacin para que produzca resultados repetibles, fiables y consistentes. Marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotacin y el mantenimiento de un producto de software abarcando la vida del sistema desde la definicin de requisitos hasta la finalizacin de sus uso

4.2 Descripcin ISO/IEC 15504-2: Es el estndar vigente hoy en da es el ISO/IEC 15504 y se divide a la vez en cinco partes que entre ellas se encuentra la ISO/IEC 15504-2. Sin embargo, el beneficio principal derivado de esta revision, ha sido la ampliacin del alcance del estndar, que ya no restringe su aplicacin a los procesos del ciclo de vida. Sino que puede ser utilizados como un mecanismo de evaluacin de cualquier tipo de de procesos.

4.3 Descripcin IEEE STD 1074: El estndar IEEE STD 1074 para los procesos de vida del software describe el conjunto de actividades y procesos obligatorios para el desarrollo y mantenimiento de software. Tiene como objetivo establecer un marco comn para el desarrollo de modelos para el proceso de construccin y proporciona algunos ejemplos de situaciones tpicas. El estndar IEEE 1074 lista seis grupos de procesos para el desarrollo de software a travs de 17 procesos. Una aproximacin lgica a la adquisicin, el suministro, el desarrollo, la explotacin y el mantenimiento del software.

CONCEPTOS 5.1 CICLO DE VIDA DEL SOFTWARE: Describe el desarrollo de software, desde la fase inicial hasta la fase final. El propsito del quieren software es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicacin, es decir, para garantizar que el software cumpla los requisitos para la aplicacin y verificacin de los procedimientos de desarrollo. Se asegura de que los mtodos utilizados son apropiados.

El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto. Permite a los desarrolladores concentrarse en la calidad del software. En los plazos de implementacin y en los costos asociados. El ciclo de vida bsico de un software consta de los siguientes procedimientos: Modelos de ciclo de vida: Los modelos de vida se han actualizados para facilitar una metodologa entre el cliente y la compaa. Los modelos de vida al ser actualizados reflejan las etapas de desarrollo y la documentacin requerida Modelo en cascada: Diseado en 1966 y se termin alrededor de 1970. Se define como una secuencia de fases en la que al final de cada una de ellas se rene la documentacin para garantizar que cumple las especificaciones y los requisitos antes de pasar a la fase siguiente.

 Modelo V: Proviene del principio que establece que los procedimientos utilizados para probar si la aplicacin cumple las especificaciones ya deben haberse creado en la fase de diseo.

5.2 PROCESO DE DESARROLLO DE SOFTWARE:

1. Definicin de objetivos: Definir el resultado del proyecto y papel en la estrategia global. 2. Anlisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restriccin que se pueda aplicar. 3. Diseo general: Requisitos generales de la arquitectura de la aplicacin. 4. Diseo en detalle: definicin precisa de cada subconjunto de la aplicacin. 5. Programacin: es la implementacin de un lenguaje de programacin para crear las funciones definidas durante la etapa de diseo. 6. Prueba de unidad: prueba individual de cada subconjunto de la aplicacin para garantizar que se implementaron de acuerdo con las especificaciones.

7. Integracin: para garantizar que los diferentes modulos se integren con la aplicacin. Este es el propsito de la prueba de integracin que esta cuidadosamente documentada. 8. Prueba beta: para garantizar que el software cumple con las especificaciones originales. 9. Documentacin: sirve para documentar informacin necesaria para los usuarios del software y para desarrollos futuros. 10. Implementacin. 11. Mantenimiento: pata todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software. 5.3 Metodologa del desarrollo de software: Una metodologa puede seguir uno o varios modelos de ciclo de vida, es decir, el ciclo de vida indica que es lo que hay que obtener a lo largo del desarrollo del proyecto pero no como hacerlo. La metodologa indica cmo hay que obtener los distintos productos parciales y finales. Clasificacin de las metodologas: 1. Estructuradas: 1.1 Orientadas a procesos: Especificacin estructurada: Diagrama de flujos de datos. Diccionario de datos. Especificaciones de procesos.

1.2 Orientadas a datos. Jerrquicas: La estructura de control del programa debe ser jerrquica y se debe derivar de la estructura de datos del programa. El proceso de diseo consiste en definir primero las estructuras de los datos de entrada y salida. Mezclarlas todas en una estructura jerarquica de programa y

despus ordenar detalladamente la lgica procedimental para que se ajuste a esta estructura. El diseo lgico debe preceder y estar separado del diseo fsico.

No jerrquicas Planificacin: construir una arquitectura de la informacin y una estrategia que soporte los objetivos de la organizacin. Anlisis: comprender las reas del negocio y determinar los requisitos del sistema. Diseo: establecer el comportamiento del sistema deseado por el usuario y que sea alcanzable por la tecnologa. Construccin: construir sistemas que cumplan los tres niveles anteriores. 2. Orientadas a objetos revolucionarios o puros. Sintetizas o evolutivos. 3. Para sistemas a tiempo real manejo de interrupciones. Comunicacin y sincronizacin entre tareas. Gestin de procesos concurrentes. Respuesta oportuna ante eventos externos. Datos continuos o discretos. 5.4 Proyecto de software: Es el proceso de gestin para la creacin de un sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimacin. Caractersticas del software: Las mtricas del software se refieren a un amplio rango de medidas para el software de computadoras dentro del contexto de la planificacin del proyecto de software, las mtricas de calidad pueden ser aplicadas a

organizaciones, procesos y productos los cuales directamente afectan a la estimacin de costos. Mtricas de productividad: se centran en el rendimiento del procesos de la ingeniera de software. Mtricas de calidad: proporcionan una indicacion de como se aju a el software, a los requerimientos implcitos y explicitos del cliente. Mtricas tcnicas: se centran en el carcter del software ha sido desarrollado. Mtricas orientadas al tamao: son utilizadas para obtener medidas directas del resultado y la calidad de la ingeniera del software. Mtricas orientadas a la funcin: son medidas indirectas del software y del proceso por el cual se desarrollara; se centran en la funcionalidad o utilidad del programa los llamados puntos de funcin. Mtricas orientadas a las personas: consiguen informacin sobre la forma en que la gente desarrolla software de computadora y sobre el puto de vista huano de la efectividad de las herramientas y mtodos. PROCESO DE DESARROLLO DE SOFTWARE 6.1. Nombre: PROCESO DE CASCADA. 6.2. DESARROLLO DE SOFTWARE EN

Caractersticas: Es el ms utilizado. Es una visin del proceso de desarrollo de software como una sucesin de etapas que producen productos intermedios. Para que el proyecto tenga xito deben desarrollarse todas las fases. Las fases continan hasta que los objetivos se han cumplido. Si se cambia el orden de las fases, el producto final ser de inferior calidad.

6.3.

Etapas: Las etapas del mtodo de desarrollo en cascada son: Anlisis de requisitos: se analizan las necesidades de los usuarios finales del software para determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificacin de requisitos), que contiene la especificacin completa de lo que debe hacer el sistema sin entrar en detalles internos. Diseo del sistema: se descomponen y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (documento de diseo del software), que contiene la descripcin de la estructura relacional global del sistema y la especificacin de lo que debe hacer cada una de sus partes, asi como la manera en que se combinan unas con otras. Diseo del programa: es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario asi como tambin los anlisis necesarios para saber que herramientas usar en la etapa de codificacin. Codificacin: es la fase de programacin o implementacin propiamente dicha. Aqu se implementa el cdigo fuente, haciendo uso de prototipos as como pruebas y ensayos para corregir errores. Pruebas: los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser puesto. Implantacin: el software obtenido se pone en produccin. Se implantan los niveles de software y hardware que componen el proyecto. La implantacin es la fase con ms duracin y con ms cambios en el ciclo de elaboracin de un proyecto. Es una de las fases finales del proyecto

6.4.

Ejemplo explicativo:

Software que halle el factorial de un nmero. Anlisis de requisitos: hallar el factorial de un nmero n donde la respuesta del software sea inmediata. El software no debe gastar muchos recursos de memoria en sus procesos. Diseo del sistema: el software se ha realizado en lenguaje c el compilador que utilizamos es Dev-C++ su estructura es orientada a objetos donde posee una clase pblica llamada factorial, dos funciones que son: el main y una funcin llamada proceso que recibe y no retorna. Diseo del programa: Pseudocodigo: Inicio N, Factorial, j como enteros Factorial = 1 Para j = 1 a N Factorial = Factorial * j Fin para Mostrar Factorial Fin Codificacin: #include <iostream> using namespace std; class factorial{ public: void proceso(int); }; void factorial::proceso(int n) { int fa=1;

for (int i=1;i<=n;i++) fa*=i; cout<<"el factorial de "<<n<<" es "<<fa<<endl; } int main() { factorial a; int n; cout<<"ingrese el nmero a calcular: "<<endl; cin>>n; a.proceso(n); } Prueba:

Nos pedir ingresar el nmero al que se le desea hallar el factorial:

Ingresamos el nmero.

Y la respuesta nos aparecer inmediatamente:

METODOLOGIA DE DESARROLLO DE SOFTWARE 01 7.1 Nombre: XP 7.2 Caractersticas: la revisin de cogido es buena hay que programar en pares. el diseo es bueno, debemos refactorizar el cdigo. las pruebas y test son buenas, pruebas unitarias y TDD la participacin del cliente es buena, hagamos que el cliente sea un integrante de nuestro equipo. combinar el cdigo es muy bueno pues usamos integracin continua. Entregar versiones es bueno entonces nuestro desarrollo tiene que ser iterativo e incremental. lo simple es apreciado y fcil de entender. 7.3 Etapas: 1. Etapa de exploracin: En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de inters para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologas y prcticas que se utilizaran en el proyecto- se prueba la tecnologa y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La etapa de exploracin toma de pocas semanas a pocos meses, dependiendo del tamao y familiaridad que tengan los programadores con la tecnologa. 2. Etapa del planeamiento: Se priorizan las historias de usuario y se acuerda el alcance del relase. Los programadores estiman cuanto esfuerzo requiere cada historia y a partir de all se define el cronograma. La duracin del cronograma del primer relase no excede normalmente dos meses. La fase de planeamiento toma un par de das. Se deben incluir varias iteraciones para lograr un relase. El cronograma fijado en la etapa de planeamiento se realiza a un nmero de iteraciones. Cada una toma de una a cuatro semanas en ejecucin. La primera iteracin crea un sistema con la arquitectura del sistema

completo- esto es alcanzado seleccionando las historias que harn cumplir la construccin de la estructura para el sistema completo. El cliente decide las historias que se seleccionaran para cada iteracin. Las pruebas funcionales creadas por el cliente se ejecutan al final de cada iteracin. Al final de la ltima iteracin el sistema est listo para produccin. 3. Etapa de produccin: requiere prueba y comprobacin extra del funcionamiento del sistema antes de que este se pueda liberar al cliente. En esta fase, los nuevos cambios pueden todava ser encontrados y deben tomarse la decisin de si se incluyen o no en el relase actual. Durante esta fase, las iteraciones pueden ser aceleradas de una a tres semanas. Las ideas y las sugerencias pospuestas se documentan para una puesta en prctica posterior por ejemplo en la fase de mantenimiento. Despus de que se realice el primer relase productivo para uso del cliente, el proyecto de xp debe mantener el funcionamiento del sistema mientras que realiza nuevas iteraciones. 4. Etapa de mantenimiento: requiere de un mayor esfuerzo para satisfacer tambin las tareas del cliente. As, la velocidad del desarrollo puede desacelerar despus de que el sistema est en la produccin. La fase de mantenimiento puede requerir la incorporacin de nueva gente y cambiar la estructura del equipo. 5. Etapa de muerte: ocurre cuando el cliente no tiene ms historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentacin final del sistema y no se realizan ms cambios en la arquitectura. La muerte del proyecto ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.

7.4 diagramas utilizados en cada etapa:

7.5 ejemplo explicativo: Un ejemplo de una empresa que aplico Extreme Programming es ONess, cuyo objetivo es un proyecto open source para el negocio textil mayorista desarrollado con tecnologas open source innovadoras. ONess cubre todos estos aspectos, y, aunque su inicial aplicacin es la gestin en empresas del sector textil, su modularidad hace que partes del sistema sean aplicables a muy distintos mbitos de las tecnologas de la informacin. Algunas de sus caractersticas son:

Es fcilmente extensible, el tiempo de creacin de nueva funcionalidad es realmente muy pequeo. Est basado en software open source ampliamente utilizado y probado, con una gran comunidad de usuarios, lo que proporciona un soporte de gran calidad. Dispone de mecanismos de seguridad y gestin de permisos, lo que permite mostrar distinta informacin segn el rol del usuario as como definir las acciones que pueden realizar y las que no.

Promueve la separacin de roles entre los desarrolladores gracias al patrn MVC (Model-View-Controller) y la separacin en capas y mdulos funcionales. Soporta la prctica totalidad de los sistemas de gestin de bases de datos relacionales: MySQL, PostgreSQL, Oracle,... Es internacionalizable, los mensajes de la aplicacin pueden ser traducidos a cualquier idioma y cada usuario los ver automticamente en el suyo. Es open source, proporcionando entre otras ventajas una gran flexibilidad.

METODOLOGIA DE DESARROLLO DE SOFTWARE 02 8.1 Nombre: OMT 8.2 Caractersticas: Proporciona una serie de pasos perfectamente definidos al desarrollador. Tratamiento especial de la herencia. Facilita el mantenimiento dada la gran cantidad de informacin que se genera en el anlisis. Es fuerte en el anlisis, Hay pocos mtodos para encontrar inconsistencias en los modelos. Interaccin de objetos no soportada explcitamente en ninguna herramienta grfica. Es dbil en el diseo. 8.3 Etapas: Etapa de anlisis: El objetivo del anlisis es desarrollar un modelo del funcionamiento del sistema. El modelo se expresa en trminos de objetos y relaciones, el control dinmico de flujo y las transformaciones funcionales. El proceso de capturar los requerimientos y consultar con el solicitante debe ser continuo a travs del anlisis. A saber:

1. Contar con una descripcin inicial del problema (enunciado del problema). 2. Construir un modelo de objetos. Modelo de objetos = diagramas del modelo de objetos + diccionario de datos. 3. Desarrollar un modelo dinmico. Modelo dinmico = diagramas de estado + diagrama global de flujo de eventos. 4. Construir un modelo funcional. Modelo funcional = diagramas de flujo de datos + restricciones. 5. Verificar, iterar y refinar los tres modelos: 6. Agregar al modelo de objetos operaciones clave que sean descubiertas durante la preparacin del modelo funcional. No deben mostrarse todas las operaciones durante el anlisis, slo las ms importantes. 7. Verificar que las clases, asociaciones, atributos y operaciones sean consistentes y completos al nivel seleccionado de abstraccin. Comparar los tres modelos con el enunciado del problema y el conocimiento relevante al dominio y probar los modelos usando varios escenarios. 8. Desarrollar escenarios ms detallados (incluyendo condiciones de error) como variaciones de los escenarios bsicos, para verificar an ms los tres modelos. 9. Iterar los pasos anteriores segn sea necesario para completar el anlisis. Etapa de diseo de sistemas: Durante el diseo de sistemas, se selecciona la estructura de alto nivel del sistema. Existen varias arquitecturas cannicas que pueden servir como un punto de inicio adecuado. El paradigma orientado a objetos no introduce vistas especiales en el diseo del sistema, pero se incluye para tener una cobertura completa del proceso de desarrollo de software. Los pasos son: 1. Organizar el sistema en subsistemas. 2. Identificar la concurrencia inherente al problema. 3. Asignar subsistemas a procesadores y tareas.

4. Escoger la estrategia bsica para implantar los almacenamientos de datos en trminos de estructuras de datos, archivos y bases de datos. 5. Identificar recursos globales y determinar los mecanismos para controlar su acceso. 6. Seleccionar un esquema para implantar el control del software: 7. Usar la ubicacin dentro del programa para mantener el estado, 8. o implantar directamente una mquina de estado, 9. o usar tareas concurrentes. 10. Considerar las condiciones de frontera. 11. Establecer prioridades de decisin sobre caractersticas deseables del producto de software. Etapa de diseo de objetos: Durante el diseo de objetos se elabora el modelo de anlisis y se proporciona una base detallada para la implantacin. Se toman las decisiones necesarias para realizar un sistema sin entrar en los detalles particulares de un lenguaje o base de datos particular. El diseo de objetos inicia un corrimiento en el enfoque de la orientacin del mundo real del modelo de anlisis hacia la orientacin en la computadora requerida para una implantacin prctica. Los pasos son: 1. Obtener las operaciones para el modelo de objetos a partir de los otros modelos: Encontrar una operacin para cada proceso en el modelo funcional. 2. Definir una operacin para cada evento en el modelo dinmico, dependiendo de la implantacin del control. 3. Disear los algoritmos para implantar las operaciones: Escoger los algoritmos que minimicen el costo de implementacin de las operaciones. 4. Seleccionar las estructuras de datos apropiadas para los algoritmos. 5. Definir clases internas y operaciones nuevas segn sea necesario. 6. Asignar las responsabilidades para las operaciones que no estn asociadas claramente con una sola clase.

7. Optimizar las rutas de acceso a los datos: Agregar asociaciones redundantes para minimizar los costos de acceso y maximizar la conveniencia. 8. Reacomodar los clculos para una mayor eficiencia. 9. Guardar los valores derivados para evitar recalcular expresiones complicadas. 10. Implantar el control del software introduciendo el esquema seleccionado durante el diseo de sistemas. 11. Ajustar la estructura de clases para incrementar la herencia: Reacomodar y ajustar las clases y las operaciones para incrementar la herencia. 12. Abstraer el comportamiento comn de los grupos de clases. 13. Usar delegacin para compartir comportamiento donde la herencia sea semnticamente invlida. 14. Disear la implantacin de las asociaciones: Analizar las travesas de las asociaciones. 15. Implantar cada asociacin como un objeto distinto o agregando atributos objeto-valor a una o ambas clases en la asociacin. 16. Determinar la representacin de los atributos de los objetos. 17. Empaquetar las clases y las asociaciones en mdulos.

8.4. Diagramas utilizados en cada etapa:

8.5 Ejemplo explicativo: El siguiente ejemplo explicativo fue sacado de http://www.willydev.net/descargas/prev/OMT2.pdf Sistema de cajero automtico: ATM (Automated Teller Machine) Disear el software para dar soporte a una red bancaria automatizada, que incluya tanto cajeros humanos como cajeros automticos (CA), y que debern ser compartidos por un consorcio de bancos. Cada banco proporciona sus propias computadoras para mantener sus cuentas y procesar transacciones relativas a ellas. Las terminales de cajero son propiedades de cada banco, y se comunican directamente con las computadoras del banco. Los cajeros humanos insertan los datos de la cuenta y de la transaccin. Los cajeros automticos se comunican con una computadora central que aprueba las

transacciones con los bancos adecuados. Los cajeros automticos admiten tarjetas, interaccionan con el usuario, se comunican con el sistema central para llevar a cabo la transaccin, entregan dinero e imprimen recibos. El sistema necesita mantener unos registros adecuados y tambin las oportunas medidas de seguridad y debe admitir accesos concurrentes a una misma cuenta de forma correcta. Los bancos proporcionarn su propio software para sus computadoras; el analista debe disear el software para los CA y para la red. El coste del sistema compartido ser prorrateado entre los bancos de acuerdo con el nmero de clientes que tengan sus tarjetas de crdito. Una red de CA ANLISIS Modelo de objetos: Identificar los objetos y la clase. Clases extradas de los nombres de definicin del problema Clases de CA identificadas a partir del conocimiento del dominio del problema Clases Incorrectas Clases Correctas Preparar un diccionario de datos Cuenta Cuenta individual de un banco a la cual se le pueden aplicar transacciones. Las cuentas pueden ser de varios tipos; como mnimo sern de ahorro o a la vista. Un cliente puede tener ms de una Cada Punto que permite a los clientes introducir sus propias transacciones empleando una tarjeta de crdito como identificacin. El CA interacciona con el cliente para obtener informacin de la transaccin, la enva a la computadora central para su verificacin y procesamiento, y suministra dinero al usuario. Suponemos que el CA no necesita funcionar independientemente de la red. Banco: Una institucin financiera que tiene cuentas para clientes y que proporciona tarjeta de crdito que autorizan para acceder a dichas cuentas a travs de la red de CA.

Computadora de banco: Computadora de un banco, que tiene una interfaz con la red de CA, y con los puestos de cajeros del propio blanco. ste puede tener su propia red interna de computadoras para procesar las cuentas, aunque slo nos concierne la que se comunica con la red. Tarjeta de Crdito: Tarjeta que le ha sido asignada a un cliente del banco, y que le autoriza para acceder a cuentas empleando un CA. Cada tarjeta contiene un nmero y cdigo de banco, que estarn codificados, con toda probabilidad, de acuerdo con los estndares nacionales para tarjetas de crdito y de dbito (bancarias). El cdigo del banco le identifica de forma nica dentro del consorcio. El nmero de la tarjeta determina las cuentas a las cuales puede acceder. Una tarjeta no accede necesariamente a todas las cuentas del cliente. Toda tarjeta bancaria es poseda por un nico cliente, pero pueden existir mltiples copias de ella de modo que es preciso considerar la posibilidad de su uso simultneo en varias mquinas distintas. Cajero: Empelado de un banco que est autorizado para efectuar transacciones en los terminales de cajero y para admitir y proporcionar dinero y cheques a los clientes. Las transacciones, el dinero y los cheques gestionados por cada cajero deben ser insertados en las computadoras y controlados debidamente. Terminal de cajero: Puesto en el cual los cajeros introducen transacciones de sus clientes. Los cajeros proporcionan dinero y cheques; el terminal imprime recibos. El terminal de cajero se comunica con la computadora del banco para verificar y procesar las transacciones. Computadora central: Computadora explotada por el consorcio y encargada de despachar las transacciones entre los CA y las computadoras de los bancos. Verifica los cdigos de los bancos, pero no procesa directamente las transacciones. Consorcio: Organizacin de los bancos que contrata y explota la red de CA. La red slo admite transacciones para los bancos del consorcio. Cliente Poseedor de una o ms cuentas de un banco. Un cliente puede ser una o ms personas o compaas; la correspondencia no es relevante para este problema. Una misma persona que tenga una cuenta en distintos bancos ser considerada como varios clientes distintos. Transaccin nica solicitud completa de operaciones que afecta a cuentas de un solo cliente. Hemos especificado que los CA deben de proporcionar dinero, aunque no debera excluirse la posibilidad de imprimir cheques o de admitir

dinero o cheques. Quiz sea necesario tambin ofrecer la flexibilidad para operar sobre cuentas de distintos clientes, aunque esto no se necesita todava. Las distintas operaciones deben cuadrar correctamente. Diccionario de datos para las clases de CA. Identificar asociaciones entre objetos Locuciones Verbales La red bancaria incluye cajeros y CA El consorcio comparte los CA. El banco proporciona la computadora del banco. La computadora del banco proporciona las cuentas. La computadora del banco procesa las transacciones de cada cuenta. El banco posee el punto de caja. El punto de caja se comunica con la computadora del banco. El cajero introduce las transacciones para la cuenta. Los CA se comunican con la computadora central para la transaccin. La computadora central verifica la transaccin con el banco. El CA admite tarjetas bancarias. El CA interacciona con el usuario. El CA proporciona dinero. El CA imprime recibos. El sistema gestiona accesos concurrentes. Los bancos aportan su software. Los costes se prorratean entre los bancos. Locuciones verbales implcitas El consorcio est formado por bancos. Los bancos tienen cuentas.

El consorcio posee la computadora central. El sistema se encarga del registro. El sistema se encarga de la seguridad. Los clientes tienen tarjeta de crdito. Conocimiento del dominio del problema Las tarjetas de crdito acceden a cuentas. Los bancos emplean cajeros. Asociaciones para la definicin del problema de un CA. Diagrama inicial para un sistema ATM. Modelo de objetos de un CA con sus atributos Organizar y simplificar la clase de objetos usando herencia. Modelo de objetos de un CA con atributos y herencia 1. Verificar que existen las vas de acceso adecuadas para las probables consultas. 2. Iterar y refinar el modelo. Modelo de objetos del CA despus de otra revisin Agregar las clases en mdulos MODELADO DINMICO: Se preparan escenarios de secuencias tpicas de interaccin. El CA pide al usuario que inserte una tarjeta; el usuario inserta una tarjeta de crdito. El CA admite la tarjeta y lee su nmero de serie. El CA solicita la contrasea; el usuario escribe "1234". El CA verifica el nmero de serie y la contrasea con el consorcio; esta la comprueba con el banco "39" y notifica la aceptacin al CA.

El CA pide al usuario que seleccione la clase de transaccin que desea (retirar fondos, hacer un ingreso o una transferencia); el usuario selecciona retirar fondos. El CA verifica que la cantidad se encuentre dentro de los lmites de crdito predefinidos, y pide al consorcio que procese la transaccin; ste pasa la solicitud al banco, que eventualmente confirma el xito de la misma y proporciona el nuevo saldo disponible en cuenta. El CA proporciona el dinero y pide al usuario que lo recoja; ste toma el dinero. El CA pregunta si el usuario desea continuar; ste dice que no. El CA imprime un recibo, expulsa la tarjeta y pide al usuario que la recoja; el usuario toma el recibo y la tarjeta. El CA pide a un usuario que inserte una tarjeta. Escenario normal de un CA. El CA pide al usuario que inserte una tarjeta; inserta una tarjeta de crdito. El CA admite la tarjeta y se lee un nmero de serie. El CA solicita la contrasea; el usuario escribe "9999". El CA verifica el nmero de serie y la contrasea con el consorcio, que los rechaza despus de consultar con el banco adecuado. El CA indica que la contrasea es incorrecta, y pide al usuario que vuelva a escribirla; ste usuario escribe "1234", y la tarjeta es admitida por el consorcio tras verificar el CA. El CA pide al usuario que seleccione la clase de transaccin que desea; el usuario selecciona una retirada de fondos. El CA pregunta la cantidad de dinero; el usuario cambia de opinin y pulsa "cancelar". El CA expulsa la tarjeta y pide al usuario la recoja, el usuario la recoge. El CA pide a un usuario que inserte una tarjeta. Un escenario de CA con excepciones. Se identificar sucesos que acten entre objetos.

Formato de la interfaz ATM Se prepara un seguimiento de sucesos para cada escenario. Seguimiento de sucesos para un escenario de CA. Diagrama de flujo de sucesos para el ejemplo de CA. Se construye un diagrama de estados. Diagrama de estados para la clase CA Diagrama de estados para la clase Consorcio. Diagrama de estados para la clase Banco. Se comparan los sucesos intercambiados entre objetos para verificar la congruencia. MODELO FUNCIONAL: Identificar los valores de entrada y salida. Valores de entrada y salida para el sistema CA. Construir diagramas de flujo de datos que muestren las dependencias funcionales. Diagrama de flujo de datos del ms alto nivel para el CA Diagrama de flujo de datos para el proceso efectuar transaccin en un CA. Describir funciones. Actualizar cuenta (cuenta, cantidad, tipo-de-transaccin) -> dinero, recibo, mensaje Si la cantidad que se intenta retirar supera el saldo disponible, Rechazar la transaccin y no entregar ningn dinero. Si la cantidad que se intenta retirar no supera el saldo disponible, Cargar el importe y dispensar el efectivo solicitado Si la transaccin es un ingreso, Abandonar el importe y no dispensar efectivo.

Si la transaccin es una peticin de saldo No dispensar efectivo. En todo caso, El recibo muestra el nmero del CA, fecha, hora, nmero de cuenta, tipo-detransaccin, importe (si lo hubiere) y nuevo saldo. Descripcin de la funcin actualizar cuenta.

Identificar las restricciones. Especificar los criterios de optimizacin

Diseo Arquitectura del Sistema CA Control de un CA Pseudocdigo Hacer para siempre Mostrar pantalla principal Leer tarjeta Repetir Pedir contrasea Leer contrasea Verificar cuenta Hasta que la verificacin de cuenta sea correcta Repetir Repetir Preguntar clase de transaccin Leer clase Leer cantidad

Comenzar transaccin Esperar que acabe Hasta que la transaccin sea correcta Dispensar efectivo Esperar a que lo tome el cliente Preguntar si contina Hasta que el usuario quiera terminar Expulsar tarjeta Esperar hasta que el cliente tome la tarjeta

CONCLUSINES El desarrollo de software y la programacin es uno de los pilares fundamentales de la informtica y al cual se dedican muchas horas de esfuerzos en empresas, colegios, academias y universidades. Conforme a la tecnologa va avanzando, van apareciendo nuevas soluciones, nuevas formas de programacin, nuevos lenguajes y un sin fin de herramientas que intentan realizar el trabajo del desarrollador un poco ms fcil.

BIBLIOGRAFIA http://es.kioskea.net/contents/223-ciclo-de-vida-del-software http://books.google.com.co/books?id=PZQoZ9KTNaEC&pg=PA17&lpg= PA17&dq=ISO/IEC+12207-1&source=bl&ots=P_J4CffDW&sig=OhGzsP2QAfP41kmaWd8Ov5o4kmA&hl=es&sa=X&ei=tX 0SUq2dNsrm2gWHyIGYDw&ved=0CHUQ6AEwCQ#v=onepage&q=ISO %2FIEC%2012207-1&f=false http://wiki.monagas.udo.edu.ve/index.php/Metodolog%C3%ADas_para_ el_desarrollo_de_software