Modulo Asoo

ANALISIS
DE
SISTEMAS
ORIENTADO A OBJETOS
Autor: Wilfredo Montero Mogolln
Edicin 2011
I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos
PRESENTACION
Hoy en da las empresas de mundo se esfuerzan por tener una mayor participacin en el mercado, lo que ha originado el desarrollo de estrategias de distribucin y la implementacin de tcnicas tanto de venta como de atencin que refuercen los objetivos econmicos de los negocios. El ambiente corporativo, se caracteriza por una dependencia cada vez mayor de informacin oportuna y precisa a todos los niveles de la organizacin, lo cual con el aumento de la competencia y las dificultades en el ambiente econmico a nivel mundial, conduce a pensar que la sobrevivencia de las empresas depender en gran medida de su capacidad de respuesta a las necesidades de informacin. La asignatura orienta al estudiante a reconocer y aprehender la importancia del anlisis y juicio crtico de realidades problemticas observadas y vividas en forma personal y en el continuo proceso de negocio de diversas empresas del medio. Fortaleciendo de esta manera sus capacidades de comprensin e interpretacin de casos propuestos durante las sesiones de clase. La asignatura motiva al estudiante a expresar su opinin de forma clara y coherente, defendiendo con entusiasmo sus ideas, valorando y respetando las ideas expresadas por sus compaeros; sesin de clase en un ambiente de dilogo continuo. El Autor. convirtiendo la
CAPITULO I Los Sistemas de Informacin y la Ingeniera Web
Contenido:
LOS SISTEMAS DE INFORMACIN CICLO DE VIDA DEL SOFTWARE METODOLOGAS DE DESARROLLO DE SOFTWARE TCNICAS E INSTRUMENTOS PARA LA RECOPILACIN DE INFORMACIN INGENIERA DE SOFTWARE ORIENTADO A OBJETOS INGENIERIA WEB
LOS SISTEMAS DE INFORMACIN

1. CONCEPTOS INICIALES: 1.1. Datos. Es un conjunto de seales o signos con un significado particular. 1.2. Comunicacin. Es el proceso mediante el cual un conjunto de signos y/o seales salen y llegan desde un emisor a un receptor. 1.3. Informacin. La informacin la componen datos que se han colocado en un contexto significativo y til y se ha comunicado a un receptor, quien la utiliza para tomar decisiones. 2. Categoras de la Informacin: Se puede clasificar de muchas formas diferentes pero para una empresa la importancia que tiene es respecto a quien va dirigida y para quien es til. 2.1. Estratgica Informacin estratgica es un instrumento de cambio. Enfocada a la planeacin a largo plazo Orientada a la alta administracin. 2.2. Tctica Informacin de control administrativo Es un tipo de informacin compartida. Tiene una utilidad a corto plazo. 2.3. Operacional Informacin rutinaria. Muestra la operacin diaria. Tiene una utilidad a muy corto plazo.
3. Sistema de Informacin (SI): 3.1. Definicin 1: Es un grupo de gente, una serie de procedimientos o equipo de procesamiento de datos que escoge, almacenan, procesan y recuperan datos para disminuir la incertidumbre en la toma de decisiones mediante el suministro de informacin a los niveles gerenciales para que sea utilizada eficientemente. 3.2. Definicin 2: Es el medio por el cual los datos fluyen de una persona o departamento hacia otros y puede ser cualquier cosa, desde la comunicacin interna entre los diferentes componentes de la organizacin y lneas telefnicas hasta sistemas de cmputo que generan reportes peridicos para varios usuarios. 3.3. Definicin 3: Los sistemas de informacin es el medio por el cual se enlazan todos los componentes de un sistema para alcanzar el objetivo.
4. Caractersticas de los sistemas de informacin modernos: Sistemas sencillos sirviendo a funciones y niveles mltiples dentro de la empresa. Acceso inmediato en lnea a grandes cantidades de informacin. Fuerte confiabilidad en la tecnologa de telecomunicaciones. Mayor cantidad de inteligencia y conocimientos implcita en los sistemas. La capacidad para combinar datos y grficas.
5. Elementos de los Sistemas de Informacin
6. Clasificacin de los sistemas de informacin: 6.1. Transaccionales.(Sistemas transaccionales) Las principales caractersticas son: A travs de stos suelen lograrse ahorros significativos de mano de obra. Normalmente son el primer tipo de SI que se implanta en las organizaciones.
Son intensivos en entrada y salida de informacin; sus clculos y procesos suelen ser simples y poco sofisticados. Tienen la propiedad de ser recolectores de informacin. Son fciles de justificar ante la direccin ya que sus beneficios son visibles y palpables. 6.2. Sistemas de Apoyo a las decisiones (Sistemas de Soporte a las Decisiones, Sistemas Gerenciales o Sistemas Ejecutivos, Sistema de Soporte para la Toma de Decisiones en Grupo.) Suelen introducirse despus de haber implantado los sistemas transaccionales. Suelen ser intensivos en clculos y escasos en entradas y salidas de informacin. La informacin que generan sirve de apoyo a los mandos intermedios y de alta administracin en el proceso de la toma de decisiones. No suelen ahorrar mano de obra. La justificacin econmica para el desarrollo de estos sistemas es difcil. Suelen ser SI interactivos y amigables, con altos estndares de diseo grfico y visual, ya que estn dirigidos al usuario final. Apoyan la toma de decisiones que por su naturaleza son repetitivas. Pueden ser desarrollados directamente por el usuario final sin la participacin operativa de los analistas. 6.3. Sistemas Estratgicos: (Sistemas Expertos (ES), Sistemas Estratgicos) Su funcin principal no es apoyar a la automatizacin de procesos operativos ni proporcionar informacin para la toma de decisiones. Sin embargo, este tipo de sistemas puede llevar a cabo dichas funciones. Suelen desarrollarse "in house". Tpicamente su forma de desarrollo es a base de incrementos y a travs de su evolucin permanente dentro de la organizacin.
7
Su funcin es lograr ventajas que los competidores no posean, tales como ventajas en costos y servicios diferenciados con clientes y proveedores. Apoyan el proceso de innovacin dentro de la empresa. 7. Objetivos generales de los SI La principal funcin de un SI es proporcionar a los encargados de la toma de decisiones, datos oportunos y exactos que les permitan tomar y aplicar las decisiones necesarias que mejoren al mximo la relacin que existe entre los recursos de la empresa. Este sistema tiene el propsito general de ayudar a los gerentes en la planeacin, control y toma de decisiones. Asegurar que la informacin exacta y confiable est disponible cuando se necesite y que se le presente en forma fcilmente aprovechable. Incrementar la productividad operacional. Hacer que el proceso de informacin deje de ser informacin fragmentada, conjeturas inspiradas en la intuicin y solucin de problemas aislados. 8. El reto de los sistemas de informacin: 8.1. El reto estratgico de los negocios Los cambios tecnolgicos se mueven ms rpido que los cambios de los seres humanos o las instituciones. Necesitarn del uso de la tecnologa para simplificar la comunicacin y la coordinacin. Si las instituciones solo automatizan lo que hacen actualmente, dejan pasar en gran medida el potencial de la tecnologa de la informacin. 8.2. El reto de la globalizacin. Que los sistemas puedan dar soporte a las ventas y compras de productos en muchos pases. Dadas las diferencias en el lenguaje, culturales y polticas daban lugar a un caos y a la falla de controles de la administracin central. 8.3. El reto de la arquitectura de la informacin. Nuevas formas de hacer negocios Dan ms importancia el hardware, software y redes.
8
8.4. El reto de la inversin en los sistemas de informacin. Una cosa es usa la tecnologa de informacin para disear, producir, entregar y mantener nuevos productos, y otra cosa es ganar dinero haciendo esto. Cambio organizacin debido al desarrollo de sistemas ms eficientes. 8.5. El reto de la responsabilidad y control. Los SIBC juegan un papel crtico en los negocios, en el gobierno y en la vida diaria, entonces debemos asegurarnos que sean precisos, confiables y seguros. Los sistemas automticos o semiautomticos que funciones mal pueden traer daos desastrosos. Una empresa hace una inversin al desastre si emplean sistemas que no operen como debieran, que no den informacin que las personas puedan interpretar y usar correctamente. 9. Razones para iniciar Proyectos de Sistemas de Informacin: 9.1. Capacidad Mayor velocidad de Procesamiento. Incremento en el Volumen. Recuperacin ms rpida de la informacin. 9.2. Control Mayor exactitud y mejora en consistencia. 9.3. Comunicacin: Mejora en la comunicacin. Integracin de reas de la Empresa. 9.4. Costos Monitoreo de costos. Reduccin de costos. 9.5. Ventaja Competitiva Atraer clientes. Dejar fuera a la competencia. Mejores acuerdos con los proveedores. Desarrollo de nuevos productos.
9
CICLO DE VIDA DEL SOFTWARE

1. Ciclo de Vida Una aproximacin lgica a la adquisicin, el suministro, el desarrollo, la explotacin y el mantenimiento del software IEEE 1074 Un 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 los requisitos hasta la finalizacin de su uso ISO 12207-1 2. Procesos del Ciclo de Vida Software
3. Modelo Cascada
10
3.1. CRITICAS No refleja realmente el proceso de desarrollo del software Se tarda mucho tiempo en pasar por todo el ciclo Perpetua el fracaso de la industria del software en su comunicacin con el usuario final El mantenimiento se realiza en el cdigo fuente Las revisiones de proyectos de gran complejidad son muy difciles Impone una estructura de gestin de proyectos
4. Modelo Incremental
4.1. Observaciones: Se evitan proyectos largos y se entrega Algo de valor a los usuarios con cierta frecuencia El usuario se involucra ms Difcil de evaluar el coste total Difcil de aplicar a sistemas transaccionales que tienden a ser integrados y a operar como un todo Requiere gestores experimentados Los errores en los requisitos se detectan tarde. El resultado puede ser muy positivo
11
5. Modelo de Prototipo
5.1. Observaciones: No modifica el flujo del ciclo de vida Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios Reduce costos y aumenta la probabilidad de xito Exige disponer de las herramientas adecuadas No presenta calidad ni robustez Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniera. 5.2. PARA QUE SEA EFECTIVO: Debe ser un sistema con el que se pueda experimentar Debe ser comparativamente barato (< 10%) Debe desarrollarse rpidamente Enfasis en la interfaz de usuario Equipo de desarrollo reducido Herramientas y lenguajes adecuados
El prototipado es un medio excelente para recoger el feedback (realimentacin) del usuario final
12
5.3. PELIGROS DEL PROTOTIPO El cliente ve funcionando lo que para el es la primera versin del prototipo que ha sido construido con plastilina y alambres, y puede desilusionarse al decirle que el sistema aun no ha sido construido. El desarrollador puede caer en la tentacin de ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente. 6. Modelo Espiral
13
6.1. Observaciones Trata de mejorar los ciclos de vida clsicos y prototipos. Permite acomodar otros modelos Incorpora objetivos de calidad y gestin de riesgos Elimina errores y alternativas no atractivas al comienzo Permite iteraciones, vuelta atrs y finalizaciones rpidas Cada ciclo empieza identificando: Los objetivos de la porcin correspondiente Las alternativas Restricciones Cada ciclo se completa con una revisin que incluye todo el ciclo anterior y el plan para el siguiente 6.2. Diferencias entre modelo en espiral y modelos tradicionales Reconocimiento explcito de las diferentes alternativas. Identificacin de riesgos para cada alternativa desde el comienzo. Al dividir el proyecto en ciclos, al final de cada uno existe un acuerdo para los cambios que hay que realizar en el sistema. El modelo se adapta a cualquier tipo de actividad adicional 7. La Reutilizacin en el Ciclo de Vida
7.1. Principios de la reutilizacin:

14
Principios Existen similitudes entre distintos sistemas de un mismo dominio de aplicacin El software puede representarse como una combinacin de mdulos Disear aplicaciones = especificar mdulos + interrelaciones Los sistemas nuevos se pueden caracterizar por diferencias respecto a los antiguos
Reduce tiempos y costes de desarrollo Aumenta la fiabilidad Dificultad para reconocer los componentes potencialmente reutilizables Dificultad de catalogacin y recuperacin Problemas de motivacin Problemas de gestin de configuracin
Sntesis Automtica de Software
Se define el sistema utilizando un lenguaje formal La implementacin es automtica, asistida por el Ordenador La documentacin se genera de forma automtica El mantenimiento se realiza por sustitucin no mediante parches Dificultad en la participacin del usuario Diseos poco optimizados
15
METODOLOGAS DE DESARROLLO DE SOFTWARE

1. DEFINICIONES: Conjunto de pasos y procedimientos que deben seguirse para el desarrollo de software. Conjunto de filosofas, fases, procedimientos, reglas, tcnicas, herramientas, documentacin y aspectos de formacin para los desarrolladores de SI. Conjunto de procedimientos, tcnicas, herramientas y soporte documental que ayuda a los desarrolladores a realizar nuevo software Es como un libro de recetas de cocina, en el que se van indicando paso a paso todas las actividades a realizar para lograr el producto informtico deseado, indicando adems qu personas deben participar en el desarrollo de las actividades y qu papel deben de tener. 2. OBJETIVOS Una metodologa de desarrollo por lo tanto representa el camino a seguir para desarrollar software de manera sistemtica. 2.1. Objetivos: Mejores Aplicaciones Un mejor Proceso de Desarrollo que identifique salidas (o productos intermedios) de cada fase de forma que se pueda planificar y controlar el proyecto Un Proceso Estndar en la organizacin
3. CONCEPTOS GENERALES 3.1. Actividades y Tareas El Proceso se descompone hasta el nivel de Actividades y Tareas (actividades elementales) 3.2. Procedimientos Define la forma de llevar a cabo las Tareas
16
Vnculo de Comunicacin entre Usuarios y Desarrolladores 3.3. Productos Obtenidos como resultado de seguir un Procedimiento Pueden ser Intermedios o Finales 3.4. Tcnicas Se utilizan para aplicar un Procedimiento Pueden ser Grficas y/o Textuales Determinan el formato de los Productos resultantes en cada Tarea 3.5. Herramientas Software Proporcionan soporte a la aplicacin de las Tcnicas 4. Metodologa vs Ciclo de Vida 4.1. Diferencias Una Metodologa puede seguir uno o varios modelos de Ciclo de Vida Un Ciclo de Vida indica qu obtener, pero no cmo Una Metodologa es un concepto ms amplio que Mtodo Se puede considerar como un conjunto de mtodos. Una metodologa puede englobar un conjunto de mtodos (de anlisis, diseo, programacin, etc.) para abarcar el ciclo de vida completo 5. Caractersticas Deseables de una Metodologa Cobertura total del ciclo de desarrollo Verificaciones intermedias Planificacin y control Comunicacin efectiva Utilizacin sobre un abanico amplio de proyectos Fcil formacin Herramientas CASE Actividades que mejoren el proceso de desarrollo Soporte al mantenimiento Soporte de la reutilizacin de software
17
6. Clasificacin de las Metodologas
7. Qu metodologa debo usar para el desarrollo de un Software? Como arquitectos de Software, debemos tener un plano en que apoyarnos. Todo desarrollo de software es riesgoso y difcil de controlar, pero si no llevamos una metodologa de por medio, lo que obtenemos es clientes insatisfechos con el resultado y desarrolladores an ms insatisfechos. Por experiencia, muchas veces los usuarios finales, se dan cuenta de las cosas que dejaron de mencionar, recin en la etapa final del proyecto, pese a que se les mostr un prototipo del software en la etapa inicial del proyecto. 8. Algunas Metodologas de Desarrollo de Software 8.1. Rational Unified Process (RUP)
18
La metodologa RUP, llamada as por sus siglas en ingls Rational Unified Process, divide en 4 fases el desarrollo del software: Inicio: El Objetivo en esta etapa es determinar la visin del proyecto. Elaboracin: En esta etapa el objetivo es determinar la arquitectura ptima. Construccin: En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial. Transicin: El objetivo es llegar a obtener el release del proyecto. Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedentes. 8.1.1. DISCIPLINAS DE RUP Vale mencionar que el ciclo de vida que se desarrolla por cada iteracin, es llevada bajo dos disciplinas: Disciplina de Desarrollo Ingeniera de Negocios: Entendiendo las necesidades del negocio. Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado. Anlisis y Diseo: Trasladando los requerimientos dentro de la arquitectura de software. Implementacin: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado. Pruebas: Asegurndose que el comportamiento requerido es el correcto y que todo el solicitado est presente. Disciplina de Soporte Configuracin y administracin del cambio: Guardando todas las versiones del proyecto. Administrando el proyecto: Administrando horarios y recursos.
19
Ambiente: Administrando el ambiente de desarrollo. Distribucin: Hacer todo lo necesario para la salida del proyecto Es recomendable que a cada una de estas iteraciones se clasifiquen y ordenen segn su prioridad, y que cada una se convierte luego en un entregable al cliente. Esto trae como beneficio la retroalimentacin que se tendra en cada entregable o en cada iteracin. Una particularidad de esta metodologa es que, en cada ciclo de iteracin, se hace exigente el uso de artefactos, siendo por este motivo, una de las metodologas ms importantes para alcanzar un grado de certificacin en el desarrollo del software. 8.2. Extreme Programing (XP)
Es una de las metodologas de desarrollo de software ms exitosas en la actualidad utilizadas para proyectos de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La metodologa consiste en una programacin rpida o extrema, cuya particularidad es tener como parte del equipo, al usuario final, pues es uno de los requisitos para llegar al xito del proyecto.
20
8.2.1. Modelo de Desarrollo de XP
8.2.2. Caractersticas de XP Se basa en: Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal manera que adelantndonos en algo hacia el futuro, podamos hacer pruebas de las fallas que pudieran ocurrir. Es como si nos adelantramos a obtener los posibles errores. Refabricacin: se basa en la reutilizacin de cdigo, para lo cual se crean patrones o modelos estndares, siendo ms flexible al cambio. Programacin en pares: una particularidad de esta metodologa es que propone la programacin en pares, la cual consiste en que dos desarrolladores participen en un proyecto en una misma estacin de trabajo. Cada miembro lleva a cabo la accin que el otro no est haciendo en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el mapa. Modelo de Desarrollo de XP 8.2.3. Qu es lo que propone XP? Empieza en pequeo y aade funcionalidad con retroalimentacin continua
21
El manejo del cambio se convierte en parte sustantiva del proceso El costo del cambio no depende de la fase o etapa No introduce funcionalidades antes que sean necesarias El cliente o el usuario se convierte en miembro del equipo Derechos del Cliente Decidir que se implementa Saber el estado real y el progreso del proyecto Aadir, cambiar o quitar requerimientos en cualquier momento Obtener lo mximo de cada semana de trabajo Obtener un sistema funcionando cada 3 o 4 meses Derechos del Desarrollador Decidir cmo se implementan los procesos Crear el sistema con la mejor calidad posible Pedir al cliente en cualquier momento aclaraciones de los requerimientos Estimar el esfuerzo para implementar el sistema Cambiar los requerimientos en base a nuevos descubrimientos Lo fundamental de XP Lo fundamental en este tipo de metodologa es: La comunicacin, entre los usuarios y los desarrolladores La simplicidad, al desarrollar y codificar los mdulos del sistema La retroalimentacin, concreta y frecuente del equipo de desarrollo, el cliente y los usuarios finales 8.3. Microsoft Solution Framework (MSF)
22
Esta es una metodologa flexible e interrelacionada con una serie de conceptos, modelos y prcticas de uso, que controlan la planificacin, el desarrollo y la gestin de proyectos tecnolgicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnolgicas. 8.3.1. MSF : Caractersticas Adaptable: es parecido a un comps, usado en cualquier parte como un mapa, del cual su uso es limitado a un especfico lugar. Escalable: puede organizar equipos tan pequeos entre 3 o 4 personas, as como tambin, proyectos que requieren 50 personas a ms. Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente. Tecnologa Agnstica: porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnologa. 8.3.2. Modelo de MSF MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto: Diseado para acortar la planificacin del ciclo de vida. Este modelo define las pautas para construir proyectos empresariales a travs del lanzamiento de versiones. Modelo de Equipo: Este modelo ha sido diseado para mejorar el rendimiento del equipo de desarrollo. Proporciona una estructura flexible para organizar los equipos de un proyecto. Puede ser escalado dependiendo del tamao del proyecto y del equipo de personas disponibles. Modelo de Proceso: Diseado para mejorar el control del proyecto, minimizando el riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona una estructura de pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las actividades, la liberacin de versiones y explicando su relacin con el Modelo de equipo.
23
Modelo de Gestin del Riesgo: Diseado para ayudar al equipo a identificar las prioridades, tomar las decisiones estratgicas correctas y controlar las emergencias que puedan surgir. Este modelo proporciona un entorno estructurado para la toma de decisiones y acciones valorando los riesgos que puedan provocar. Modelo de Diseo del Proceso: Diseado para distinguir entre los objetivos empresariales y las necesidades del usuario. Proporciona un modelo centrado en el usuario para obtener un diseo eficiente y flexible a travs de un enfoque iterativo. Las fases de diseo conceptual, lgico y fsico proveen tres perspectivas diferentes para los tres tipos de roles: los usuarios, el equipo y los desarrolladores. Modelo de Aplicacin: Diseado para mejorar el desarrollo, el mantenimiento y el soporte, proporciona un modelo de tres niveles para disear y desarrollar aplicaciones software. Los servicios utilizados en este modelo son escalables, y pueden ser usados en un solo ordenador o incluso en varios servidores. 9. En Conclusin Qu Elegir ? La Metodologa RUP es mas adaptable para proyectos de largo plazo. La Metodologa XP en cambio, se recomienda para proyectos de corto plazo. La Metodologa MSF se adapta a proyectos de cualquier dimensin y de cualquier tecnologa. Podemos concluir adems, que lo ms importante antes de elegir la metodologa que usars para la implementacin de tu software, es determinar el alcance que tendr y luego de ah ver cual es la que ms se acomoda en tu aplicacin. 10. Otras Opciones Metodolgicas 10.1. WSDM: Web Site Design Method Define el sistema en base a los grupos de usuario. Su proceso de definicin de requisitos tiene por objetivo el detectar los perfiles de usuario mediante dos tareas. Clasificacin de usuarios mediante el estudio del entorno.
24
Descripcin de los grupos de usuario. 10.2. HFPM: Hypermedia Flexible Process Modeling HFPM define un proceso detallado que cubre todo el ciclo de vida y que est compuesto por 13 fases. En la primera de ellas, modelado de requisitos, propone las tareas siguientes: Descripcin breve del problema Descripcin de los requisitos funcionales Realizacin del modelo de datos Modelado de la interfaz de usuario Modelado de los requisitos no funcionales 10.3. UWE: UML-Based Web Engineering UWE es una propuesta basada en el proceso unificado y UML pero adaptados a la web. En requisitos separa las fases de captura, definicin y validacin. Hace adems una clasificacin y un tratamiento especial dependiendo del carcter de cada requisito.
25
TCNICAS E INSTRUMENTOS PARA LA RECOPILACIN DE INFORMACIN

El anlisis de sistema es el conocimiento de situaciones y no la solucin de los problemas. Los buenos analistas, por lo tanto, hacen hincapi en la investigacin y las preguntas para aprender cmo opera un sistema actualmente y para identificar los requerimientos que los usuarios tienen para uno nuevo o modificarlo. Solo despus de que los analistas han entendido por completo el sistema, son capaces de analizarlo y determinar las recomendaciones para el diseo de sistema. Estudiaremos el anlisis de sistemas y la determinacin de sus requerimientos y las preguntas que estos incluyen. Adems se examinan con detalle los mtodos para recabar datos en relacin con los requerimientos, lo que se conoce como tcnica para recopilar datos. 1. Determinacin de los Requerimientos. La determinacin de los requerimientos es el estudio del sistema actual del negocio a fin de encontrar como trabaja y donde debe mejorase. Los estudios del sistema son el resultado de una evaluacin para conocer cmo funcionan los mtodos actuales o si son necesarios o posibles algunos ajustes; elaborar preguntas en relacin con los sistemas manuales y los computarizados. Dado que los analistas de sistemas no trabajan como gerentes o empleados en los departamentos para usuarios (como mercadotecnia, contabilidad, venta, compra o produccin), no tienen los mismos conocimientos sobre hechos y datos que los gerentes y usuarios de esas reas; por lo tanto un paso inicial en la investigacin es entender la situacin. Existen ciertos tipos de requerimientos tan fundamentales que son comunes a todas las situaciones. Contestar los grupos especficos de
26
preguntas que analizan esta secciones, permitir comprender estos requerimientos bsicos. 2. Requerimientos bsicos Los analistas estructuran su investigacin y buscan respuestas a las siguientes 4 preguntas principales. Cul es el proceso bsico? Qu datos se utilizan o se producen durante este proceso? Cules son los lmites impuestos por el tiempo y cantidad de trabajo? Qu controles de rendimientos se utilizan? 2.1. Entender al Proceso. Se harn preguntas que proporcionaran un antecedente de los datos fundamentales y de la descripcin del sistema. Cul es el propsito de esta actividad? Cuales son los pasos que se realizan? Dnde se realizan? Quin los ejecuta? Cunto tiempo consume? Conque frecuencia se realizan? Quin utiliza la informacin resultante?
3. Tcnicas para Recopilar datos: Los analistas utilizan una variedad de mtodos a fin de recopilar los datos sobre una situacin existente, como entrevistas, cuestionarios, infeccin de registros (revisin en sitio) y observacin. Cada uno tiene ventajas y desventajas. Generalmente se utilizan dos o tres para complementar el trabajo de cada una y ayudar asegurar una investigacin completa. 3.1. La Entrevista La entrevista es una forma de conversacin, no de interrogacin, La entrevista para la recopilacin de la informacin es una conversacin dirigida con un propsito especfico, que se basa en un formato de preguntas y respuestas.
27
En la entrevista desea conocer tanto las opiniones como los sentimientos del entrevistado acerca del estado actual de los sistemas, sus metas personales, de la organizacin y de los procedimientos informales. 3.1.1. Planeacin de la Entrevista
3.1.2. Tipos de Entrevistas
Entrevistas no estructuradas: Si el objetivo de la entrevista radica en adquirir informacin general, es conveniente elaborar una serie de preguntas sin estructuras, con una sesin de preguntas y respuestas libres. Entrevistas estructuradas: Sin embargo cuando los analistas necesitan adquirir datos ms especficos sobre las operaciones o desean asegurar una alta confiabilidad en las respuestas a las preguntas que han
28
propuesto a su entrevistado, las entrevistas estructuradas son mejores
3.1.3. Estructuras de una Entrevista As como se reconocen dos maneras generales de razonamiento, el inductivo y el deductivo, hay dos formas similares de organizar sus entrevistas. Una tercera forma que combina ambos patrones, el inductivo y el deductivo. Estas son: Uso de una Estructura Piramidal Uso de una Estructura Embudo Uso de una Estructura en Forma de Diamante Se usa cuando crea que su entrevistado necesite una introduccin al tema de investigacin. Es til cuando el entrevista se niega a involucrarse al tema. Es til para encadenar preguntas cuando se
3.1.4. Estructura Piramidal
29
desea llegar a una conclusin final del tema. 3.1.5. Estructura Embudo Es til cuando si el entrevistado est involucrado con el tema y necesita cierta libertad para expresar sus emociones. 3.1.6. Estructura Diamante Combina la fortaleza de las dos anteriores pero necesito ms tiempo. Mantiene preguntas. Entrevista Estructurada vs No Estructuradas 3.1.7. Entrevista Estructurada vs No Estructuradas el inters mediante y la la atencin variedad de de su las entrevistado,
3.1.8. Tipos de Preguntas Preguntas Ejemplos: Cul es su opinin del funcionamiento actual del sistema? Cules son algunos de lo problemas que percibe respecto a recibir oportunamente la informacin? Preguntas Cerradas: Limitan las respuesta disponibles del entrevistado (nmero finito, tal como ninguno, uno o quince)
30
Abiertas:
En
la
entrevista
permiten
las
entrevistadas opciones abiertas para su respuesta.
Ejemplo: Cuntos informes genera en un mes? Quien recibe este reporte? Sondeo o Exploratoria: son preguntas que permiten ir ms all de la respuesta inicial para obtener un mayor significado y aclarar o ampliar los puntos del entrevistado. El sondeo puede realizarse mediante preguntas abiertas o cerradas. El sondeo ms slido y ms simple es la pregunta por qu?, otra sera Podra darme un ejemplo y Podra darme ms detalle?. 3.1.9. Atributos de las Preguntas Abiertas y Cerradas
3.2. CUESTIONARIOS Tcnica que permite a los analistas recoger opiniones, posturas, conductas y caractersticas de diversas personas claves de una organizacin, que se encuentran involucradas en la operacin de un sistema actual o en la implantacin de uno nuevo. Las respuestas que se obtienen de los cuestionarios pueden cuantificarse (preguntas cerradas) o analizarse e interpretarse de manera distinta (preguntas abiertas). 3.2.1. La Eleccin del Vocabulario
31
Use, en lo posible el lenguaje de quien contesta Mantenga una redaccin Sea especficos, sin embargo evite preguntas sumamente especficas. Use preguntas cortas. No sea condescendiente con los que contestan. Evite el uso de un lenguaje corriente. Evite la parcialidad en la redaccin. Esto tambin significa evitar preguntas censurables. Dirija las preguntas a las personas indicadas (esto es aquellas que sean capaces de responder) No suponga un conocimiento muy profundo.
Asegrese que las preguntas sean tcnicamente precisas, antes de incluirlas.
3.2.2. Seleccin de formas para cuestionarios. Existen dos formas de cuestionario para recabar datos: Cuestionarios abiertos y Cerrados y se aplican dependiendo de s los analistas conocen de antemano todas las posibles respuestas de las preguntas y pueden incluirlas Cuestionarios abiertos: Se aplica cuando se quieren conocer los sentimientos, opiniones y experiencias generales, son tiles cuando se quiere explorar el problema bsico, proporcionan una amplia posibilidad para quienes responden. Cuestionarios cerrados: Limita las respuestas posibles del interrogado por medio de un cuidadoso estilo de preguntas el analista puede controlar el marco de referencia. Es el mejor mtodo para obtener informacin sobre los hechos. 3.2.3. Uso de Escalas Escalar es el proceso de asignar nmeros u otros smbolos a un atributo o caracterstica con el fin de poder medirlo. Razones para Escalas Medir las actitudes o caractersticas de la gente que contesta un cuestionario.
32
contar con un elemento de juicio sobre los temas de un cuestionario.
Mediciones Nominal: se utiliza para classificar objetos Ejm: Cul es el tipo de programa que ms utiliza? l.- Procesador de textos 2.- Hoja de clculo 3.- Lenguajes visuales 4.- Graficadores Ordinal : permiten la clasificacin con un arreglo de categoras: Ejm: el personal del centro de Informacin es: l=Extremadamente til 2=Muy til 3=Moderadamente til 4=No muy til 5=Nada til De Intervalo: tienen la caracterstica que la diferencia que existe es la misma entre los intervalos de cada uno de los nmeros. Ejm: Qu tan til es el apoyo ofrecido por el persona del Centro de Informacin? Nada til til 1 2 3 4 5 Proporcional: son similares a la de intervalo, pero cuentan con un cero absoluto. Ejm: De manera aproximada Cunta horas dedica diariamente la computadora? 0 1 2 4 6 Extremadamente
3.2.4. Parmetros de Desempeo Validez: es el grado con el que la pregunta determina lo que el analista intenta medir.
33
Confiabilidad:
es un
parmetro
de
consistencia.
Si
el
cuestionario da el mismo resultado al repetirlo bajo las mismas condiciones, se dice que el instrumento cuenta con consistencia externa, si el cuestionario tiene interna. Ambas son importantes. 3.3. La Observacin Tcnica que permite a los analistas en profundizar en lo que hace y no solo lo que se dice o se tiene documentado. 3.3.1. Recopilacin de datos mediante observacin Ver es creer, Observar las operaciones les proporcionan al analista hechos que no podra obtener de otra forma. 3.3.2. Recuperacin de datos por medio de la Observacin. La observacin proporciona informacin de primera mano en relacin con la forma en se llevan a cabo las actividades. 3.4. La Observacin 3.4.1. Cuando Observar. La observacin es muy til cuando el analista necesita ver de primera mano como se manejan los documentos, como se l Siempre deben identificar las tareas problemticas que llevan a los empleados a cometer errores con frecuencias al completarlas as como aquellas que tienden a retardar el procedimiento llevan a cabo los procesos y si ocurren los pasos especificados. 3.5. Revisin de Registros Con frecuencia en muchas empresas la informacin ya se encuentra disponible para que los analistas conozcan la actividad u operaciones con las cuales no esta familiarizados. Los analistas examinan datos y descripciones que ya estn escritos o registradas en relacin con el sistema y departamento de usuarios. 3.5.1. Recuperacin de datos por medio de la inspeccin de registros. fragmentos, y estos generan resultados equivalentes, se dice que tiene una consistencia
34
El trmino de registro se refiere a los manuales escritos sobre poltica, regulaciones y procedimientos de operaciones estndares que la mayora de las empresas mantienen como gua para gerentes y empleados. Los manuales que documentan o describen las operaciones para los procesos de datos existentes, o sistemas de informacin que entran dentro del rea de investigacin, tambin proporcionan una visin sobre la forma en que el negocio debera conducirse. 3.5.2. Seleccin de los registros para revisin. En la mayor parte de las empresas los manuales y estndares sobre procedimientos de operacin usualmente son obsoletos, a menudo no se mantienen al corriente lo suficiente para sealar los procedimientos existentes. Los diagramas de organizacin muestran como as diferentes unidades deberan relacionarse con otras, pero muchas no reflejan las operaciones actuales. Al comparar las formas en blanco con el procedimiento y los manuales de operacin se muestra al analista como debe llenarse; por lo tanto recabar y comparar las formas ya completas y los informes permiten sealar cualquier variacin entre los usos de hechos y el prescrito en los documentos .
35
INGENIERA DE SOFTWARE ORIENTADO A OBJETOS

1. La Ingeniera de Software (IS) La IS es una disciplina que integra mtodos, herramientas y procedimientos para el desarrollo del software de computadoras. Se han propuesto varios paradigmas, entre ellos podemos mencionar: estructurado, orientado a objetos ,sala limpia, cliente/servidor, reutilizacin del software, reingeniera del software, software asistido por computadoras, etc. El software se ha convertido en el elemento clave de la evolucin de los sistemas y productos informticos 2. Importancia de la Ingeniera de Software En las pasadas cuatro dcadas, el software ha pasado de ser una resolucin de problemas especializados y una herramienta de anlisis de informacin, a ser una industria por si misma. Pero la temprana cultura e historia de la programacin ha creado un conjunto de programas que persisten hasta hoy. El software se ha convertido en un factor que limita la evolucin de los sistemas informticos. 3. La Ingeniera de software orientado a objetos (ISOO) La ISOO es una disciplina de la Ingeniera de Software bajo el enfoque paradigmtico de la orientacin a objetos. Esta rama de la Ingeniera de software trata de resolver el problema de la construccin de software complejo. Actualmente se esta usando esta disciplina para solucionar cualquier tipo de problema de construccin de software. 4. Paradigma Orientado a Objetos
36
Con frecuencia se alude a la Orientacin a Objetos como un nuevo paradigma (Paradigma de Objetos) y al trmino Orientado a Objeto ( OO ) como la aplicain de este paradigma al mundo de la computacin. El paradigma para los programadores, es la manera como se maneja la complejidad. Desde este punto de vista el paradigma es el modelo o la estructura dentro del software solucin de un problema. Superficialmente OO significa la organizacin del software como una coleccin de Objetos discretos que incorpora tanto la estructura de datos como su comportamiento. Para cada entidad del dominio, hay un objeto que representa ese concepto en el modelo. Finalmente, OO modela mirando en alguna parte realidad o dominio que es de inters, y busca las abstracciones claves y las relaciones entre esas abstracciones claves. La Orientacin a Objetos se aplica a otros disciplinas dentro del mundo de la computacin, tal como se aprecia en la siguiente ilustracin:
37
En resumen la Orientacin a Objetos:
4.1. Conceptos Bsicos Los conceptos bsicos en los que se fundamenta la OO, son muy variadas y dependen del punto de vista, pero entre las principales a considerar son las siguientes : Abstraccin Concepto Objeto Clase Concepto Un concepto es una idea o nocin compartida que se aplica a determinados objetos en forma consciente. Concepto es un conjunto compartido de proposiciones generales que podemos aplicar a los objetos de nuestra conciencia. Cada concepto tiene una intensidad y una extensin. Sabemos que tenemos un concepto cuando lo podemos aplicar con xito a las cosas que nos rodean. Objeto Definimos un objeto como un concepto, abstraccin, o cosa con significado dentro del dominio del problema. Estructura jerarqua Mtodo/operacin/ Servicio
38
Un objeto es sinnimo de instancia, tipo. Un objeto es cualquier cosa, real o abstracta, acerca de la cual se almacenan datos y mtodos que controlan dichos datos. El objeto sirve a dos propsito: ellos permiten comprender el mundo verdadero y proveen una base prctica para la implementacin en computadora. Clase Un nmero de personas o cosas agrupadas a causa de semejanzas en ciertas caractersticas comunes. Una Clase es una implementacin de un tipo de objeto. Especifica una estructura de datos y los mtodos operativos permisibles que se aplican a cada uno de sus objetos. Los objetos en la clase tienen los mismos modelos de comportamientos y atributos. Los objetos y clases suelen aparecer como sustantivos en las descripciones de problemas. Atributos Un atributo es un valor de un dato que est almacenado en los objetos de una clase. El nombre del atributo es nico dentro de la clase Las instancias distintas de un cierto objeto pueden tener el mismo valor o valores distintos para un atributo dado. El nombre del atributo es unico dentro de la clase. Los atributos deberan ser valores puros de datos y no objetos. Estructuras Jerrquicas Una Estructura es una manera de organizacin. La Estructura Jerrquica es una expresin de la complejidad de un problema, pertinente del sistema de responsabilidades. Este trmino se usa como un trmino total, describiendo la estructura Generalizacin-Especializacin (estructura de clasificacin) y estructura Todo-parte (estructura de ensamble o composicin). Agregacin La Composicin o agregacin es el acto o el resultado de formar un objeto configurado median te sus partes componentes.
39
Una agregacin es la relacin parte-todo o una-par te-de en la cual los objetos que representan los componentes de algo se asocian a un objeto que representan el ensamblaje completo. Un ensamblaje con muchas clases de componentes se corresponde con muchas relaciones de agregacin. Generalizacin La Generalizacin es el acto o el resultado de distinguir un concepto que es ms general que otro. La generalizacin y la herencia son potentes abstracciones para compartir similitudes entre clases al mismo tiempo que se mantienen sus diferencias. La generalizacin es la relacin entre una clase y una o ms versiones refinadas de esa misma clase. Mtodo/Operacin/Servicios Una operacin es un proceso que se puede solicitar como una unidad. Un mtodo es la especificacin de una operacin. Un servicio es un comportamiento especfico que un objeto se responsabiliza. Un objeto es entonces una cosa cuyas propiedades estn representadas por tipos de datos y su comportamiento por mtodos. 4.2. Principios Bsicos Los principios sobre el que se basa la OO, son muy variadas y dependen del punto de vista, pero entre las principales a considerar son las siguientes Abstraccin Encapsulamiento Herencia Polimorfismo Abstraccin La abstraccin es el principio de ignorar esos aspectos de un tema que no vienen al caso con el propsito actual a fin de
40
Mensaje Identidad Asociacin
concentrarse ms totalmente sobre el asunto de inters. Comprende dos aspectos: abstraccin de procesos y de datos. La abstraccin es el acto o resultado de eliminar diferencias entre los objetos, de modo que podamos ver los aspectos comunes. Encapsulamiento El Encapsulamiento (ocultamiento de la informacin) es un principio, usado cuando se desarrolla la estructura total de un programa, en el que cada componente de un programa debera encapsularse u ocultar una decisin nica de diseo. El modulo de interfaces se define de tal manera que se conoce tan poco como trabaja en su interior. Encapsulamiento es el resultado (o acto) de ocultar los detalles de implementacin de un objeto con respecto a su usuario. Herencia La herencia es un mecanismo para la similitud expresa entre las clase, simplificando la definicin de clases parecidas a uno anteriormente definido. Retrata la generalizacin y la especializacin, al hacer que atributos comunes atiendan en forma explcita dentro de una jerarqua de clases Existen dos tipos de Herencias: La Herencia Simple y La Herencia Mltiple Polimorfismo El termino polimorfismo proviene de la biologa y significa, literalmente, muchas formas. Los bilogos definen el polimorfismo como la variacin en forma y funcin que se encuentran entre los miembros de una especie comn. El Polimorfismo ocurre cuando mtodos distintos, llevan a cabo el mismo propsito operativo. Esta palabra se aplica a una operacin que adopta varias formas de implementacin Mensaje Para que un objeto haga algo, le enviamos una solicitud.Esta hace que se produzca una operacin.
41
La operacin ejecuta el mtodo apropiado, y de manera opcional, produce unas respuestas. El mensaje que constituye la solicitud contiene el nombre del objeto, el nombre de una operacin y, a veces, un grupo de parmetros Un mensaje es una solicitud para que se lleve a cabo la operacin indicada y se produzca el resultado. Identidad La identidad es la facilidad para que cada objeto (sin considerar su clase o el estado actual) puede identificarse y tratarse como una entidad distinta. La identidad de objetos, o clases, es cuando tiene identidades nicas a lo largo de sus vidas. El uso de la identidad hace singularmente la identificacin del objeto Asociacin Una asociacin describe un grupo de enlaces con estructuras y semnticas comunes. La asociacin define la forma en que se pueden enlazar o conectar los objetos de distintos tipos. Un enlace es una instancia de una asociacin. Las asociaciones son inherentemente bidireccionales. 4.3. Tecnologa Orientada a Objetos (TOO) La gnesis de la Tecnologa de Objetos o Tecnologa Orientada a Objetos ahora llamada por muchos Orientado a Objetos data de principios de los aos sesenta. Surgi de la necesidad de describir y simular fenmenos, como las redes neuronales, los sistemas de comunicacin, el flujo de trfico, los sistemas de produccin, los sistemas administrativos e, incluso, los sistemas sociales. 4.3.1. Definicin de TOO
42
La Tecnologa de Objetos (TO), una de las ms recientes tcnicas de desarrollo de sistemas y se basa en la OO; cuenta con cuatro bases fundamentales: Anlisis Orientado a Objetos (AOO). Diseo Orientado a Objetos (DOO). Programacin Orientada a Objetos (POO). Base de Datos Orientado a Objetos (BDOO). Anlisis Orientado a Objetos Con el Anlisis Orientado a Objetos, la forma de modelar la realidad difiere del anlisis convencional. Modelamos el mundo en trminos de objetos y lo que le ocurre a estos. Los modelos que construimos en anlisis OO refleja la realidad de modo ms natural que los del anlisis tradicional de sistemas. Anlisis OO es una fusin de disciplinas tal como se aprecia en la siguiente ilustracin:
Diseo Orientado a Objetos El Diseo Orientado a Objetos (DOO) presenta una posibilidad, en la cual los datos y los procedimientos se tratan simultneamente como pensamiento subsidiarios dentro de un concepto central, el objeto. El diseador construye un diseo, basado en el modelo de anlisis pero conteniendo detalle de implementacin.
43
En la siguiente figura se establece la influencia del A/DOO:
Programacin Orientada a Objetos La Programacin Orientada a Objetos es una forma de diseo modular en la que, con frecuencia, el mundo se piensa en trminos de objetos, operaciones, mtodos y mensajes que se transfieren entre tales objetos. La POO no consiste simplemente en unas cuantas caractersticas programacin. Ms bien es una nueva forma de pensar acerca del proceso de descomposicin de problemas y desarrollo de soluciones de programacin. nuevas aadidas a los lenguajes de
Base de Datos Orientada a Objetos Un base de datos tradicional solo almacena datos, sin procesarlos, de modo que resulten independiente de los procedimientos. Los datos son accesible a diferentes usuarios, con diversos propsitos. Por lo contrario, una Base de Datos Orientado a Objetos almacena Objetos. Los datos se almacenan junto con los mtodos que procesan dichos datos. La BDOO es producto de un conjunto de necesidades producidas por otras, tal como se aprecia en la siguiente ilustracin:
44
4.4. Situacin Actual en la TOO
4.5. Desarrollo de la Tecnologa Orientada a Objetos Con el universo de mtodos, se ha formado un cosmo dinmico con el mundo de objeto en el que un mtodo evoluciona en una estrella ntida u otra cesa para ser destacado y llega a ser un gigante rojo antes de desaparecer enteramente. De aqu en adelante, una organizacin debera primera comprender completamente qu significa para pensar desde el punto de vista de objetos.
45
4.6. Mtodo, Metodologa y Proceso en el desarrollo de software Un mtodo es la aplicacin particular de una metodologa de desarrollo de software pero que no abarca el ciclo de vida de desarrollo de software ni cuenta con herramientas tecnolgica de soporte. Una metodologa es una marco general basado en un paradigma que sirve de base para el desarrollo de software y que abarca todo el ciclo de vida. Un proceso de desarrollo de software est basado en una metodologa, abarca todo el ciclo de vida y provee herramientas tecnolgicas de soporte 4.7. Problemas en el desarrollo de software? Retrasos en los plazos Proyectos cancelados Rpido deterioro del sistema instalado Tasa de defectos o fallos Requisitos mal comprendidos Cambios frecuentes en el dominio del problema Muchas de las interesantes caractersticas del software no proporcionan beneficios al cliente Buenos programadores se cansan y dejan el equipo
46
INGENIERIA WEB
La World Wide Web e Internet han introducido a la poblacin en general en el mundo de la informtica. Compramos fondos de inversin colectivos y acciones, descargamos msica, vemos pelculas, obtenemos asesoramiento mdico, hacemos reservas de habitaciones en hoteles, vendemos artculos personales, planificamos vuelos en lneas areas, conocemos gente, hacemos gestiones bancarias, recibimos cursos universitarios, hacemos la compra -es decir, en el mundo virtual se puede hacer todo lo que se necesite. Se puede decir que Internet y la Web son los avances ms importantes en la historia de la informtica Los sistemas y aplicaciones (WebApps) basados en Web hacen posible que una poblacin extensa de usuarios finales dispongan de una gran variedad de contenido y funcionalidad La ingeniera Web no es un clnico perfecto de la ingeniera del software, pero toma prestado muchos de los conceptos y principios bsicos de la ingeniera del software, dando importancia a las mismas actividades tcnicas y de gestin. Existen diferencias sutiles en la forma en que se llevan a cabo estas actividades, pero la filosofa primordial es idntica dado que dicta un enfoque disciplinado para el desarrollo de un sistema basado en computadora. 1. Importancia: A medida que las WebApps se integran cada vez ms en grandes y pequeas compaas (por ejemplo, comercio electrnico), y cada vez es ms importante la necesidad de construir sistemas fiables, utilizables y adaptables. Esta es la razn por la que es necesario un enfoque disciplinado para el desarrollo de WebApps
47
2. Pasos a seguir en la Ingeniera Web Al igual que cualquier disciplina de ingeniera, la ingeniera Web aplica un enfoque genrico que se suaviza con estrategias, tcticas y mtodos especializados. El proceso de ingeniera Web comienza con una formulacin del problema que pasa a resolverse con las WebApps. Se planifica el proyecto y se analizan los requisitos de la WebApp, entonces se lleva a cabo el diseo de interfaces arquitectnico y del navegador. El sistema se implementa utilizando lenguajes y herramientas especializados asociados con la Web, y entonces comienzan las pruebas. Dado que las WebApps estn en constante evolucin, deben de estn los mecanismos para el control de configuraciones, garanta de calidad y soporte continuado. 3. Atributos de la WebApp 3.1. Intensivas de Red. Por su propia naturaleza, una WebApp es intensiva de red. Reside en una red y debe dar servicio a las necesidades de una comunidad diversa de clientes 3.2. Controlada por el contenido. En muchos casos, la funcin primaria de una WebApp es utilizar hipermedia para presentar al usuario el contenido de textos, grficos, sonido y vdeo 3.3. Evolucin continua. A diferencia del software de aplicaciones convencional, que evoluciona con una serie de versiones planificadas y cronolgicamente espaciadas, las aplicaciones Web estn en constante evolucin. 4. Caractersticas de WebApps 4.1. Inmediatez Los desarrolladores debern utilizar los mtodos de planificacin, anlisis, diseo, implementacin y comprobacin que se hayan adaptado a planificaciones apretadas en tiempo para el desarrollo de WebApps.
48
4.2. Seguridad Dado que las WebApps estn disponibles a travs del acceso por red, es difcil, si no imposible, limitar la poblacin de usuarios finales que pueden acceder a la aplicacin 4.3. Esttica Una parte innegable del atractivo de una WebApp es su apariencia e interaccin. 4.4. Categoras de las WebApp Informativa. Descarga. Personalizable. Interaccin. Entrada del usuario Orientada a transacciones Orientado a servicios Portal. Acceso a bases de datos
5. Caractersticas de calidad de una WebApp
49
50
CAPITULO II Metodologas Agiles de Desarrollo: Extreme Programming (XP)
Contenido:
ARQUITECTURA WEB METODOLOGIAS AGILES: EXTREME PROGRAMMING XP: FASE DE EXPLORACION o o o Gestin del Proyecto Historial de Usuario Lista de Tareas
51
ARQUITECTURA WEB
Hasta el da de hoy, lo ms importante en el desarrollo de aplicaciones Web han sido las herramientas. Poco se ha dicho sobre el proceso de desarrollo. La fcil creacin de hojas HTML y en general de sitios Web, usando herramientas simples, ha hecho que el desarrollo de este tipo de aplicaciones se haga sin un trabajo serio de anlisis y diseo. Cualquier sistema de complejidad no trivial, necesita ser analizado y modelado. Las aplicaciones Web, al igual que otras aplicaciones, necesitan mtodos formales de anlisis y diseo. Cul es la diferencia entre un sitio Web y una aplicacin Web? Una aplicacin Web es un sitio Web donde la navegacin a travs del sitio, y la entrada de datos por parte de un usuario, afectan el estado de la lgica del negocio. En esencia, una aplicacin Web usa un sitio Web como entrada (frontend) a una aplicacin tpica. ...Si no existe lgica del negocio en el servidor, el sistema no puede ser llamado aplicacin Web. [Conallen 99] La arquitectura de un sitio Web (desarrollo contenido) tiene tres componentes principales: Un servidor Web, una conexin de red, y uno o ms clientes (browsers).El servidor Web distribuye pginas de informacin formateada a los clientes que las solicitan. Los requerimientos son hechos a travs de una conexin de red, y para ello se usa el protocolo HTTP.
52
1. Arquitectura bsica de una aplicacin/sitio Web La informacin mostrada en las pginas est tpicamente almacenada en archivos. Sin embargo, muchas veces esta informacin est almacenada en una base de datos, y las pginas son creadas dinmicamente. Los sitios Web que usan este esquema, son llamados sitios dinmicos.
1.1. Aplicacin Web Extiende un Sitio Web, permitiendo al usuario invocar la lgica del negocio modificar el estado del negocio en el servidor 1.1.1. Componentes bsicos: Navegador del cliente (browser HTML/XML) Servidor Web (comunica con clientes va HTTP) Servidor de Aplicaciones (maneja lgica del negocio) (Servidor de Bases de Datos) 1.1.2. Componentes avanzados Scripts, applets, controles, objetos distribuidos,... 1.2. Patrn de Arquitectura Web Expresa esquemas de organizacin estructural bsica para sistemas software 1.2.1. Proporciona... Conjunto de subsistemas predefinidos Especificacin de responsabilidades de cada subsistema Reglas y guas para organizar las relaciones entre subsistemas 1.2.2. Patrones ms comunes: Thin Web Client Thick Web Client Web Delivery - Cliente Web Ligero - Cliente Web Pesado - Distribucin Web
53
Es posible aplicar varios patrones a una misma arquitectura 2. Cliente Web Ligero En este tipo de arquitectura, el cliente slo tiene capacidades servidor. El servidor soporta la mayor carga de procesamiento de los algoritmos principales requeridos para la lgica de negocio. 2.1. Aplicabilidad : til para aplicaciones basadas en Internet Mnimo control de la configuracin del cliente El cliente slo necesita un browser Web que realiza peticiones de pginas Lgica del negocio ejecutada en el servidor Usos Conocidos: Aplicaciones de comercio electrnico 2.2. Estructura Mnima arquitectura para una aplicacin Web Sus principales componentes estn en el servidor Componentes: de presentacin, pues toda la lgica del negocio tiene lugar en el lado del
Browser del cliente Servidor Web Conexin HTTP Pginas HTML Pginas del servidor Servidor de Aplicaciones 2.3. Elementos Opcionales Persistencia : Sistemas de Bases de Datos, etc. Integracin con sistemas heredados: Legacy Systems Integracin con sistemas de contabilidad de mercado
Caso de aplicaciones de comercio electrnico
54
2.4. Dinmica La lgica del negocio slo se ejecuta durante el procesamiento de las peticiones de pginas Web por el cliente Una vez satisfecha la peticin, se devuelve una pgina HTML al cliente y finaliza la conexin entre cliente y servidor 2.5. Consecuencias (del uso de esta arquitectura) 2.5.1. Tiempo de Respuesta: Adecuada para aplicaciones cuyas respuestas del servidor puedan ser completadas dentro del tiempo de respuesta aceptable esperado por el usuario y del valor de timeout permitido por el browser del cliente. No adecuada si la aplicacin necesita permitir al usuario iniciar y controlar un proceso del negocio duradero 2.5.2. Interfaz de usuario Capacidad de sofisticacin limitada a lo soportado por browser y la especificacin HTML 3. Cliente Web Pesado La mayor parte de la lgica del negocio se realiza en el cliente, el browser es ms que un contenedor de interfaces de usuario generalizado El Servidor de dedica casi exclusivamente a procesar las solicitudes de datos del cliente 3.1. Aplicabilidad
55
el
til para aplicaciones Web en las que pueda asumirse cierto control sobre la configuracin del cliente y la versin del browser, se desea una interfaz de usuario sofisticada, o el cliente puede ejecutar algo de lgica del negocio 3.2. Estructura Uso de capacidades del browser: Controles ActiveX, Applets Java Scripts del cliente Que slo pueden interactuar con objetos en el cliente comunicacin cliente - servidor va HTTP 3.3. Componentes: Los del patrn Cliente Web Ligero Scripts del Cliente Documentos XML Controles ActiveX Applets de Java JavaBeans
3.4. Dinmica Incluye la del Cliente Web Ligero: Comunicacin slo durante peticiones de pginas Parte de la lgica del negocio puede ejecutarse en el cliente: Scripts : validacin de campos, etc Pueden responder a eventos enviados por el browser
56
Applets y controles : independientes o guiados por scripts en la pgina, peticin/envo/recepcin/parsing de documentos XML
3.5. Consecuencias 3.5.1. Portabilidad No todos los browsers soportan JavaScript o VBScript, ActiveX slo soportado por clientes Ms-Windows y el usuario puede desactivar su uso Cada browser implementa su propia versin de Java 3.5.2. Pruebas Comprobar el comportamiento correcto de los scripts, controles o applets para cada browser y configuracin del cliente que deba ser soportada 4. Distribucin Web Sistema de objetos distribuidos basado en un sitio Web, Usa protocolos de comunicacin entre cliente y servidor diferentes a HTTP. Pueden ejecutarse objetos reales en el contexto del cliente o el browser, 4.1. Aplicabilidad Existe un control significativo sobre la configuracin de cliente y de la red No muy adecuado para aplicaciones basadas en Internet o cuando la red es poco fiable Ms adecuado para intranets (seguridad y rapidez) Comunicacin directa y persistente entre cliente y servidor 4.2. Usos Conocidos CNN Interactive Web Site acceso pblico va browsers y HTML3.2 tras el sitio Web est una red basada en CORBA de browsers, servidores y objetos distribuidos Compaa de software para el cuidado de la salud Aplicacin Cliente Web Pesado para gestin de pacientes e historiales Aplicacin Distribucin Web para facturacin
57
4.3. Estructura Comunicacin entre cliente y servidor mediante protocolos diferentes a HTTP Componentes: Los del patrn Cliente Web Ligero y DCOM IIOP y RMI
4.4. Dinmica El cliente participa en un sistema de objetos distribuidos Comunica directamente con objetos del servidor El Browser contiene: Interfaz del cliente y Objetos del negocio Descargados por el browser automticamente desde el servidor Comunicacin, asncrona e independiente, con objetos del servidor 4.5. Consecuencias Traslada parte de la carga del servidor al cliente Portabilidad (anlogo a Cliente Web Pesado) Requiere una red slida Conexiones cliente - servidor de larga duracin Una cada del servidor puede ser muy problemtica
5. Eleccin de la Arquitectura
58
Ya conocemos los tipos ms comunes de arquitecturas de aplicaciones Web. El equipo de desarrollo debe elegir el patrn (o patrones) ms adecuado(s) para el sistema bajo estudio. Es por tanto muy importante que se conozca a fondo dicho sistema y sus requisitos, es decir, que se haya analizado en detalle la descripcin de los casos de uso del sistema. Depende de... Tipo de aplicacin (intranet/internet) Necesidades de la aplicacin Experiencia del equipo de desarrollo con las tecnologas disponibles 5.1. Tipo de Aplicacin: Si la aplicacin estar dirigida a usuarios de una intranet, es mejor utilizar Distribucin Web Si est dirigida a usuarios genricos de Internet, mejor emplear una Cliente Web (Ligero o Pesado). 5.2. Las necesidades de la aplicacin: Tienen que ver, por ejemplo, con la funcionalidad que debe realizarse en el cliente. Normalmente, se elige Distribucin Web cuando las otras dos arquitecturas Web no son capaces de satisfacer los requisitos de funcionalidad o de eficiencia.
59
METODOLOGAS GILES: EXTREME PROGRAMMING

XP (eXtreme Programming), forma parte del conjunto de mtodos giles que centran sus prioridades en las personas, no en los procesos, en la actualidad Xp es un modelo de desarrollo comn, sencillo y adaptable a las caractersticas cambiantes y exigentes de empresas y clientes. XP es una Metodologa gil basada en cuatro principios: simplicidad, comunicacin, retroalimentacin y valor. Adems, orientada por pruebas y refactorizacin, se disea e implementan las pruebas antes de programar la funcionalidad, el programador crea sus propios tests de unidad 1. Qu es XP? Es una metodologa gil. Diseada para entornos dinmicos. Pensada para equipos pequeos (de 2 a 20 programadores). Orientada fuertemente hacia la codificacin nfasis en la comunicacin informal, verbal. Se basa en valores de simplicidad, comunicacin, realimentacin y animo (coraje). Relaja la pesada gestin en favor de mayor informalidad. Utilizacin de tecnologa orientada a objetos (uso de lenguajes modernos). El proceso se divide en 4 tipos de actividades (Planificacin, Diseo, Codificacin y Pruebas) 2. Principios de XP La simplicidad ayuda a que los desarrolladores de software encuentren soluciones ms simples a problemas, segn el cliente lo estipula. Los desarrolladores tambin crean caractersticas en el diseo que pudieran ayudar a resolver problemas en un futuro. La comunicacin prevalece en todas las prcticas de extreme programming. Comunicacin cara a cara es la mejor forma de comunicacin, entre los desarrolladores y el cliente. Mtodo muy gil. Gracias a esto el equipo esta pude realizar cambios que al cliente no
60
le gustaron. Tambin apoya agilidad con la extensin del conocimiento tcito dentro del equipo del desarrollo, evitando la necesidad de mantener la documentacin escrita. La Retroalimentacin continua del cliente permite a los desarrolladores llevar y dirigir el proyecto en una direccin correcta hacia donde el cliente quiera. El valor requiere que los desarrolladores vayan a la par con el cambio, por que sabemos que este cambio es inevitable, pero el estar preparado con una metodologa ayuda a ese cambio. Extreme programming promueve el trabajo del equipo. Cada integrante del proyecto (cliente, desarrolladores, etc.) forman parte integral del equipo encargado de desarrollar software de calidad. 3. Actividades de XP Codificar. Hacer pruebas. Escuchar. Disear.
Resumiendo las actividades de Xp: Tenemos que codificar porque sin cdigo no hay programas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos qu codificar ni probar, y tenemos que disear para poder codificar, probar y escuchar indefinidamente. 4. Prcticas en XP El Juego de la planificacin. Entregas pequeas Metfora Diseo simple Pruebas Refactoring Programacin en parejas Propiedad colectiva Integracin continua Semana de 40 horas Cliente in situ Estndares de programacin
61
5. Roles XP Programador (Programmer) Responsable de decisiones tcnicas Responsable de construir el sistema Sin distincin entre analistas, diseadores o codificadores En XP, los programadores disean, programan y realizan las pruebas Jefe de Proyecto (Manager) Organiza y gua las reuniones Asegura condiciones adecuadas para el proyecto Cliente (Customer) Es parte del equipo Determina qu construir y cundo Establece las pruebas funcionales Encargado de Pruebas (Tester) Ayuda al cliente con las pruebas funcionales Se asegura de que las pruebas funcionales se superan Rastreador (Tracker) Metric Man Observa sin molestar
62
Conserva datos histricos Entrenador (Coach) Responsable del proceso Tiende a estar en un segundo plano a medida que el equipo madura 6. El Proceso de XP
7. Ciclo de Vida de XP Fase de la 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 utilizarn en el proyecto. Fase del planeamiento: Se priorizan las historias de usuario y se acuerda el alcance del release. Los programadores estiman cunto esfuerzo requiere cada historia y a partir de all se define el cronograma. La duracin del cronograma del primer release no excede normalmente dos meses. Fase de produccin: Requiere prueba y comprobacin extra del funcionamiento del sistema antes de que ste se pueda liberar al cliente. En esta fase, los nuevos cambios pueden todava ser encontrados y debe tomarse la decisin de si se incluyen o no en el release actual. Durante esta fase, las iteraciones pueden ser aceleradas de una a tres semanas.
63
Fase 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. Fase de muerte: Es 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. 8. Modelo de Desarrollo de XP
64
XP: FASE DE EXPLORACION

1. GESTIN DEL PROYECTO WEB La gestin del proyecto describe el plan global usado para el desarrollo de sistemas. El detalle de las iteraciones individuales se describe en los planes de cada iteracin, documentos que se aportan en forma separada. Durante el proceso de desarrollo en el artefacto Visin se definen las caractersticas del producto a desarrollar, lo cual constituye la base para la planificacin de las iteraciones. Para la versin 1.0 del proyecto, se basa en la captura de requisitos por medio del stakeholder representante de la empresa para hacer una estimacin aproximada, una vez comenzado el proyecto y durante la fase de Inicio se generar la primera versin del artefacto Visin, el cual se utilizar para refinar este documento. Posteriormente, el avance del proyecto y el seguimiento en cada una de las iteraciones ocasionar el ajuste de este documento produciendo nuevas versiones actualizadas. En esta fase desarrollar los requisitos del producto desde la perspectiva del usuario, los cuales sern establecidos en el artefacto Visin. Los principales casos de uso sern identificados y se har un refinamiento del Plan de Desarrollo del Proyecto. La aceptacin del cliente / usuario del artefacto Visin y el Plan de Desarrollo marcan el final de esta fase. 2. HISTORIAL DE USUARIOS Las historias de usuario tienen el mismo propsito que los casos de uso. Las escriben los propios clientes, tal y como ven ellos las necesidades del sistema. Las historias de usuario son similares al empleo de escenarios, con la excepcin de que no se limitan a la descripcin de la interfaz de usuario. Tambin conducirn el proceso de creacin de los test de aceptacin (empleados para verificar que las historias de usuario han sido implementadas correctamente). Existen diferencias entre estas y la tradicional especificacin de requisitos. La principal diferencia es el nivel de detalle. Las historias de usuario
65
solamente proporcionaran los detalles sobre la estimacin del riesgo y cunto tiempo conllevar la implementacin de dicha historia de usuario.
66
2.1. MODELO DE HISTORIAL DE USUARIO

Historia de Usuario Nmero: Nombre Historia de Usuario: Usuario Prioridad en Negocio: (Alta / Media / Baja) Descripcin: Riesgo en Desarrollo: (Alto / Medio / Bajo)
Observaciones: Programador Responsable:
2.2. Anlisis de Tareas Inciales
67
CASO PRCTICO (Alojamientos Rurales)
La comunidad de Madrid desea informar sobre los alojamientos rurales que existen en dicha comunidad. Para ello decide crear un proyecto web que permita registrar las reservas de habitaciones realizadas a los alojamientos de la localidad, controlar la realizacin de las actividades tursticas y recoja las siguientes consideraciones: Un alojamiento rural se identifica por un nombre (Villar Aurora, Las Rosas, etc), tiene una direccin, un telfono y una persona de contacto que pertenece al personal del alojamiento. En cada alojamiento son administradas por una persona que se identifican por un cdigo de completo, la direccin y el DNI. Los alojamientos se alquilan por habitaciones y se desea conocer cuntas habitaciones componen el alojamiento, de qu tipo (individuales, dobles, triples) es cada una de estas habitaciones, si poseen cuarto de bao y el precio. En algunos de estos alojamientos se realizan actividades personal. Se requiere conocer el nombre
multiaventura organizadas para huspedes (senderismo, bicicleta de montaa, etc...). Estas actividades se identifican por un cdigo. Es de inters saber el nombre de la actividad, la descripcin y el nivel de dificultad de dicha actividad (1-10). Estas actividades se realizan un da a la semana, por ejemplo: en la casa Villa Aurora se practica senderismo los jueves y se desea guardar esta informacin. Pero puede haber algn da en el que no se practique ninguna actividad.
68
GESTIN DEL PROYECTO

1. Alcance de la Solucin : En el caso prctico definimos como nuestro objetivo implementar un proyecto Web para la Administracin de los alojamientos de la comunidad de Madrid controlando las reservas realizadas a los mismos. Las funcionalidades que tendr la solucin final se mencionan a continuacin:
N 1
Modulo de Administracin del Sitio Web. Modulo de Gestin de Reservas de Alojamiento y Actividades.
Nombre rea Comunidad de Madrid (Alcalde) Administracin de Alojamientos Prioridad Alta Riesgo Medio Interaccin X
Administracin del Sitio Web Gestin de Reservas de Alojamiento y Actividades
Alta
Alta
2. HISTORIAL DE USUARIO 2.1. Descripcin de la Historia de Usuario Historia de Usuario Nmero: 01 Nombre Historia de Usuario: Administracin del Sitio Web Usuario: Alcalde de la Comunidad Prioridad en Riesgo en Desarrollo: Negocio: (Alto / Medio / Bajo) (Alta / Media / Baja) Descripcin: El usuario, se encargar brindar la informacin necesaria para disear, implementar y editar el sitio web de acuerdo a las necesidades de informacin de la comunidad. El administrador de cada alojamiento registrara la informacin necesaria de su local y de las actividades que se realizan en la comunidad. Observaciones: Las actividades dependen de cada alojamiento y de acuerdo a la programacin vigente. Programador Responsable: xxxx
69
Historia de Usuario Nmero: 02 nombre historia de usuario: gestin de reserva de alojamiento y actividades Usuario: Cliente Prioridad en Riesgo en Desarrollo: Negocio: (Alto / Medio / Bajo) (Alta / Media / Baja) Descripcin: El usuario, visitara al web de la comunidad donde podr visualizar los alojamientos seleccionando uno, luego podr acceder a los servicios de reserva de habitaciones de acuerdo al tipo y servicio que ofrece el alojamiento si lo desea podr tambin programar una actividad durante su estada. La administracin del alojamiento se encarga de elaborar los reportes de las reservas recibidas el mismo que servir para programar las actividades y las habitaciones. Observaciones: Programador Responsable: xxxx
3. LISTA DE TAREAS Historial de Usuario. ADMINISTRACIN DEL SITIO WEB N 1 2 3 4 5 6 7 8 Tarea: Elaborar y Disear o Portada. Elaborar y Disear de la Turismo. Elaborar y Disear de la Organizacin poltica. Registrar Alojamientos Registrar de Administradores de Alojamiento. Registrar Actividades de los alojamientos. Registrar tipos de Habitaciones. Programacin de Actividades
70
Historial de Usuario. GESTIN DE RESERVA DE ALOJAMIENTO Y ACTIVIDADES
N 1 2 3 4 5 6
Tarea: Mostrar Alojamientos. Mostrar Habitaciones. Mostrar Actividades. Registrar Reserva de Habitaciones por Alojamiento. Registrar Reserva de Actividades de los alojamientos. Reportar Reservas
71
CAPITULO III PLANIFICANDO EL PROYECTO WEB
Contenido:
MODELADO DEL NEGOCIO o o o CASOS DE USO DEL NEGOCIO MODELO DE OBJETOS DEL NEGOCIO MODELO DEL DOMINIO DEL PROBLEMA
MODELO DE REQUERIMIENTOS o DIAGRAMA DE CASOS DE USOS DE REQUERIMIENTOS
72
MODELADO DEL NEGOCIO

1. Objetivos Entender la estructura y la dinmica de la organizacin en la cual el sistema ser implantado. Entender los problemas actuales de la organizacin e identificar las potenciales mejores. Asegurar que clientes, usuarios finales y desarrolladores tienen un entendimiento comn de la organizacin. Determinar los requerimientos del sistema necesarios para dar soporte a la organizacin. 2. Definicin Es una Tcnica para conocer los procesos de Negocio de una Organizacin cuyo objetivo principal es identificar los casos de uso software y las entidades de negocio relevantes que el software debe realizar. Desarrolla una Visin para alcanzar los objetivos y as definir los procesos, roles y las responsabilidades del sistema. La modelacin del negocio comprende 3 modelos: El Modelo de Casos de Uso del Negocio (MCUN) Modelo de Objetos del Negocio (MON) El Modelo del Dominio (MD)
3. Artefactos Claves 3.1. Modelo de Casos de Uso del Negocio: Identificar funciones, entradas, roles y entregables. 3.2. Modelo de Objetos: Describen la realizacin de los casos de uso del Negocio. 3.3. Modelo del Dominio: Identificar Arquitectura del negocio, .las clases y sus principales relaciones.
73
4. El Actor del Negocio Un actor es una entidad externa al sistema que realiza algn tipo de interaccin con el mismo. Se representa mediante una figura humana dibujada con palotes. Esta representacin sirve tanto para actores que son personas como para otro tipo de actores (otros
Actor del Negocio sistemas, sensores, etc.). Ejm: Clientes, Vendedores o

socios. 5. Casos de Uso del Negocio Un Modelo de Casos de Uso muestra la relacin entre los actores y los casos de uso del sistema. Los Casos de uso representa la funcionalidad que ofrece el sistema en lo que se refiere a su interaccin externa. Representan una abstraccin de alto nivel de las funciones que se realizan en la organizacin. Representados por: Casos de uso del Negocio Las Realizaciones de los casos de uso del negocio.
Caso de Uso
Realizacin de Casos de Uso del Negocio
6. Relaciones en el Modelado de Negocio Existen dos tipos de Relaciones en el Modelado del Negocio en especial en MCUN: Relacin de Asociacin o Comunicacin Relacin de Generalizacin
74
7. Modelo de Casos de Uso de Negocio Se describe mediante un diagrama de casos de Uso de Negocio: Ejemplo:
Atencin de Pedidos Cliente Gerente
Gestn de Produccin
Socio
No Socio
8. Modelo de Objetos del Negocio 8.1. Trabajador del negocio Los Roles que juegan las personas dentro de la organizacin representados por los Workers del Negocio. son
Worker del Negocio
75
8.2. Entidad del negocio Las Cosas que la organizacin maneja (administra), produce es representada por las entidades del negocio
Entidad del Negocio

9. Modelo de Objetos del Negocio Describe como cada caso de uso es llevado a cabo por parte de un conjunto de trabajadores que utilizan un conjunto de entidades de negocio y unidades de trabajo, se representa por un diagrama de objetos y se desarrollo un MON por cada CUN del modelo de CUN
Registra Clientes Cliente
(f rom Use-Case Model)
Vendedores
Verifica
Registra Productos
Gerente
(f rom Use-Case Model)
Emite reportes
Supervis or
Pedidos
76
10. Modelo del Dominio del Problema Es recomendable en el Modelo del Negocio elaborar un Modelo del Dominio con todas las Entidades del Negocio identificadas. Captura las ms importantes tipos de objetos en el contexto del sistema, es descrito por un diagrama de clase no detallado
Clientes 1 Registra 0..* Productos *
Realiza 0..*
Pedidos
77
MODELO DE REQUERIMIENTOS
1. Requerimientos 1.1. Objetivos Establecer y mantener los acuerdos con los clientes y otros stakeholders acerca de lo que el sistema debe hacer y porqu. Proporcionar a los desarrolladores del sistema un mejor entendimiento de los requerimientos del sistema Definir la delimitacin del sistema Proporcionar una base para la planificacin de los contenidos tcnicos de la iteraciones. Proporcionar una base para estimacin de costo y tiempo para desarrollar el sistema. Definir la interfaz de usuario (GUI), enfocndose sobre las necesidades y objetivos de los usuarios 1.2. Qu es un Requerimiento? Una condicin o capacidad la cual el sistema debe satisfacer Requerimientos Funcionales Pensar en lo que el sistema debe hacer a favor de los usuarios. Son las acciones que el sistema debe ser capaz de ejecutar. Expresar el comportamiento del sistema en funcin de las entradas y salidas que deben tener los resultados esperados. 1.3. Requerimientos No Funcionales Son caractersticas que el sistema debe tener, principalmente relacionado con la calidad. Tambin son todas las caractersticas que debe tener el sistema pero que no forman parte de los requerimientos funcionales. Podran ser requisitos de: Utilizacin: esttica, facilidad de uso, documento de Usuario, etc. Fiabilidad: torelancia a fallas, recuperacin, precisin, tiempo de respuesta, tiempo de recuperacin, cantidad de memoria. Soporte: pruebas, mantenimiento, actualizacin de versiones.
78
1.4. Tipos de Requerimientos Stakeholders: Requerimientos vs. Necesidades Caractersticas del sistema Requerimientos de software.
1.5. Captura y Administracin de Requerimientos Primero se recolecta los requerimientos de los stakeholders, lo cual abarca todos los requerimientos y deseos conseguidos de los usuarios finales, clientes, mercado y otros stakeholders. Se utiliza los requerimientos de los stakeholders para desarrollar el documento de visin contenido el conjunto de requerimientos clave de los stakeholders y usuarios y las caractersticas de alto nivel del sistema Las caractersticas del sistema expresan servicios que deben ser ejecutados por el sistema para satisfacer las necesidades stakeholders. Se debe traducir las caractersticas en requerimientos detallados de software a un nivel al cual se pueda disear y construir el sistema e identificar casos de prueba para evaluar el comportamiento del sistema.
79
Estos requerimientos se capturan en el Diagrama de Casos de Uso de Requerimientos (DCUR) y en el documento de especificaciones suplementarias, el que contiene todos los requerimientos no modelados en los casos de uso. 2. Diagrama de Casos de Uso de Requerimientos Describe cmo modelar la funcionalidad del sistema utilizando casos de uso. En el UML, los casos de uso son los principales medios para capturar la funcionalidad del sistema desde la perspectiva del usuario y muchas veces puede remplazar al documento "requisitos funcionales". La posicin o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organizacin, un conjunto de casos de uso coherente, consistente promueve una imagen fcil del comportamiento del sistema, un entendimiento comn entre el cliente/propietario/usuario y el equipo de desarrollo.
Los Casos de Uso son una tcnica para capturar informacin de cmo un sistema o negocio trabaja actualmente, o de cmo se desea que trabaje, estos diagramas no pertenecen realmente al enfoque orientado a objetos, ms bien es una tcnica para el modelado de escenarios en lo cual el sistema debe operar.
80
2.1. La Notacin del Diagrama Casos de Uso 2.1.1. Actor: Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organizacin, y que realiza algn tipo de interaccin con el sistema. Se represe nta mediante una figura humana <Actor Name> dibujada con palotes. Esta representacin sirve tanto para actores que son personas como para otro tipo de actores. 2.1.2. Caso de uso. Un caso de uso es una descripcin de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea especfica. El nombre del caso de uso debe reflejar la tarea especfica que el actor desea llevar a cabo usando el sistema. Cada una de las transacciones de los Workers del Negocio sobre las Entidades del Negocio se pueden transformar en un caso de uso 2.1.3. Relaciones entre Actores y Casos de Uso Unidireccional
Caso de Uso
Actor
Caso de Uso
Actor
Caso de Uso
81
Bidireccional
Actor
2.1.4. Relaciones entre Casos de Uso
Caso de Uso
Include: Cada vez que se ejecuta el caso de uso A, tambin se ejecuta el caso de uso B.
<<include>>
Extend: Cuando se ejecuta el caso de uso A, algunas veces se ejecuta el caso de uso B.
<<extend>>
A
Ejemplos:
82
2.1.5. Observaciones Entre actores No son vlidas las asociaciones entre actores Comentarios No deben quedar Casos de uso sin asociarse a algn actor u otro caso de uso. No es necesario que todos los casos de uso estn asociados entre si
83
REFERENCIAS BIBLIOGRAFICAS
1. Pressman Roger. Ingeniera de software: un enfoque prctico. 6ta.ed.Mxico. McGraw-Hill. 2005 2. Cubel Navarro, Jose M. eXtreme Programming Laboratorio de Sistemas de Informacin, Universidad Politcnica de Valencia. 3. J. MONZN, Anlisis y Diseo de Sistemas de Informacin, Editorial Gomez, Lima-Per, ao 1999, 377 pginas. 4. Cesar LIZA AVILA, Modelando con UML, Editorial imprenta RJ S.A Ltda., Trujillo Per, ao 2001, 236 pginas. 5. Santiago VALDERRAMA MENDOZA, Pasos para elaborar proyectos y tesis de investigacin cientfica, Editorial San Marcos. Per 2002, 310 pginas.
84
REFERENCIAS WEB
1. http://www.xp2003.org 2. http://www.extremeprogramming.org 3. http://www.monografias.com 4. http://www.apolosoftware.com/
85

Modulo Asoo

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Modulo Asoo

Încărcat de

Drepturi de autor:

Formate disponibile

ANALISIS

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

CAPITULO I Los Sistemas de Informacin y la Ingeniera Web

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

LOS SISTEMAS DE INFORMACIN

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

5. Elementos de los Sistemas de Informacin

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

CICLO DE VIDA DEL SOFTWARE

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

7.1. Principios de la reutilizacin:

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

Sntesis Automtica de Software

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

METODOLOGAS DE DESARROLLO DE SOFTWARE

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

6. Clasificacin de las Metodologas

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

8.2.1. Modelo de Desarrollo de XP

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

TCNICAS E INSTRUMENTOS PARA LA RECOPILACIN DE INFORMACIN

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

3.1.2. Tipos de Entrevistas

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

propuesto a su entrevistado, las entrevistas estructuradas son mejores

3.1.4. Estructura Piramidal

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

entrevistadas opciones abiertas para su respuesta.

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

Asegrese que las preguntas sean tcnicamente precisas, antes de incluirlas.

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

contar con un elemento de juicio sobre los temas de un cuestionario.

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

INGENIERA DE SOFTWARE ORIENTADO A OBJETOS

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

En resumen la Orientacin a Objetos:

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

Mensaje Identidad Asociacin

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

I.E.S.T.P Modern Systems Anlisis de Sistemas Orientado a Objetos

En la siguiente figura se establece la influencia del A/DOO: