TECNICAS DE DESARROLLOS DE SISTEMAS Se tiene buenos sistemas?

FALLO, muchos programas no cumplen con los requisitos de los usuarios y/o tienen fallos tcnicos. Las necesidades de los usuarios de pierden en la captura de requisitos, varan durante el desarrollo del sistema lo que hace que el sistema entregado no cumple con necesidades de los usuarios. La mayora de los usuarios esperan que las aplicaciones e incluso los sistemas operativos fallen, se cuelguen o funcionen mal con cierta regularidad. La falta de flexibilidad resulto evidente con el problema del milenio y la adecuacin de los procesos viejos a procesos de negocios cambiantes. La accesibilidad, se relaciona mucho con la fiabilidad y flexibilidad ya que el coste de ajuste de errores y el mantenimiento es el mayor coste en el que se incurre al buscar sistemas de alta calidad La satisfaccin expectativas con relacionan a un producto o servicio requerido.

CALIDAD La calidad es una herramienta bsica para una propiedad inherente a cualquier cosa. Propiedad o conjunto de un elemento que le dotan de una ventaja competitiva. Propiedad o conjunto de propiedades inherentes a una persona o cosa. Conjunto de caractersticas de un producto o servicio que confiere aptitud para satisfacer las necesidades de usuario cliente.

La calidad es la base del xito para los productos o servicios Promesas Todas las nuevas tecnologas prometen reducir los tiempos de desarrollo e incrementar los promedios de los xitos de los proyectos. Segn a Frederick P. Brooks mientras ms grande sea el proyecto, mayor ser la proporcin del costo y tiempo del proyecto gastado en la comunicacin entre la gente del proyecto, porque cada persona tiene ms gente con quien comunicarse, Cuando un proyecto empieza a quedarse atrs en el tiempo, el poner ms gente por lo general falla. El departamento de defensa de los EU, intento resolver la crisis de SW y comisin el diseo del lenguaje de programacin Ada, el cual se estandarizo en 1983, soportaba lo mejor de los conceptos de anlisis, diseo y programacin estructurados, la modularidad y la encapsulacin fueron conceptos clave en el diseo del lenguaje, pero aun esta enorme inversin ha fracasado. Mejorar las metodologas para la ingeniera del software.

Cmo son los buenos sistemas?

El problema fundamental para comprenderlos es: Hay un lmite de cuanto puede entender un humano en un momento dado. Los sistemas pequeos, son realizados mediante programacin heroica en la cual una sola persona pretende recordar todo lo relevante acerca del sistema. Pensar un sistema como un conjunto de mdulos e identificar dependencias entre mdulos. En sentido ms general, un mdulo puede ser cualquier elemento identificable de un sistema y que tiene sentido por si mismo los mdulos pueden ser: o Archivos o Subrutinas o Funciones de biblioteca o Clases, en un lenguaje orientado a objetos o Otras partes conocidas como mdulos o similares o Programas o subsistemas independientes o semi independientes Caractersticas de los mdulos para que el desarrollo y mantenimiento del sistema sea lo ms fcil, barato y confiable posible: o Dependencia o Acoplamiento Bajo o Cohesin Alta (agrupar procesos en un solo proceso bibliotecas) o Interface Definida o Encapsulacin Mdulos o Abstraccin Alta Cohesin (globalizar las caractersticas de un objeto) o Componente reusable (Mtodos reutilizables ) El modulo A depende del mdulo B si existe un cambio en el mdulo B significa que el modulo A tambin necesita ser modificado. La dependencia es conocida a veces como acoplamiento. Un sistema con muchas dependencias tiene un acoplamiento grande. Los sistemas buenos tiene un acoplamiento bajo, porque los cambios a una parte del sistema son menos propensos a propagarse a travs del sistemas.(poca dependencia) ACOPLAMIENTO Es una medida de la fuerza con una UNIDAD DE SOFTWARE, depende de otra El bajo acoplamiento es un principio que debe recordar durante las decisiones de diseo: es la meta principal que debe tener presente siempre. El bajo acoplamiento soporta el diseo de clases ms independientes que reduce el impacto de los cambios y tambin ms reutilizables que acrecientan la oportunidad de una mayor productividad Acoplamiento fuerte, la clase usuario 1 es una subclase de servicio 1

Las subclases estn expuestas a las implementaciones internas de la sper claseAcoplamiento la clase usuario 2 hace referencia directamente sobre la clase servicio 2 Abstracto bajo la clase usuario 4 hace referencia a la clase servicio 4 impl, a travs de una interface Sin acoplamiento la case usuario 3 no hace referencia a la clase servicio 3 El consejo general es que debe hacer bajo acoplamiento entre las unidades de software para lograr una buena programacin o un buen diseo Que las clases se comuniquen a travs de pequeas interfaces bien definidas. O sea mientras menos dependientes sean entre si las partes que constituyen un sistema informtico, mejor ser el resultado. ENCAPSULACION

Queremos minimizar el nmero de casos en los cuales un cambio a un mdulo genera un cambio otro modulo. Tenemos que conocer cuales cambios dentro de un mdulo pueden afectar el resto del sistema Para tomar ventaja del acoplamiento bajo de un sistema Una vez que las fronteras de los mdulos de nuestro sistema estn definidas hay dos clases de informacin que pueden ser tiles. o Qu suposiciones de un mdulo dado pueden los clientes hacer acerca de l? o Cules mdulos son clientes de un mdulo dado? INGENIERIA DEL SOFTWARE

EL PROCESO DE SOFTWARE Es un conjunto de actividades y resultados asociados que producen un producto software. Es uno de los componentes de un mtodo de desarrollo de software. Existen 4 actividades fundamentales de proceso, comunes para todos los procesos de software. o Especificacin requisitos del software o Desarrollo del software o Validacin del software o Evolucin del software Distintos procesos de software organizan las actividades de diferentes formas, y las describen con diferente nivel de detalle. o El tiempo de cada actividad vari, as como los resultados. o Organizacin de diferentes usan procesos diferentes para producir el mismo producto. Sin embargo, para algunos tipos de aplicacin, algunos procesos son ms convenientes que otros.

CICLO DE VIDA

Alternativamente, a veces se usan los trminos o Ciclo de vida o Modelo de ciclo de vida Sucesin de etapas por las cuales atraviesa un producto sw a largo de existencia (durante su desarrollo y explotacin) Ciclo de vida Toda la vida del sistema desde la concepcin hasta el fin de uso Ciclo de desarrollo Desde el anlisis hasta la entrega ESTANDARES EN INGENIERIA DE SOFTWARE

Estndares conjunto de criterios aprobados, documentados y disponibles para determinar la adecuacin de la accin (estndares de procesos o de un objeto (estndar de producto) Gua conjunto de criterios bien definidos y documentados que encaminan una actividad o tarea. o Es ms flexible que un estndar

Porque usar estndares en ingeniera del software Segn SOMMERVILLE, los estndares son tiles o Agrupan lo mejor y ms apropiado de las buenas prcticas y usos del desarrollo de software. o Engloban los conocimientos que son patrimonio de una organizacin o Proporcionan un marco para implementar procedimientos de aseguramiento de la calidad o Proporcionan continuidad entre trabajo de distintas personas

TIPOS DE ESTANDARES EN INGENIERIA DE SOFTWARE Estndares para software Desde asignar nombres a los datos y especificar longitud y tipo hasta los relacionados con BBDD Estndares de codificacin Abreviaturas y designaciones formales para describir actividades dentro de la organizacin Estndares estructurales Polticas de divisin del software en mdulos Estndares documentacin Estndares de proceso software Estndares para otras actividades EJEMPLOS DE ESTANDARES EN INGENIERIA DEL SOFTWARE

IEEE estndar 830-1993 Recomendad Practice for Software requerimientos especificaciones IEEE standars 1074-1997 Standard for developing sw life Cycle Ptroceses 1233-1998 Gua de requisitos de software 2001-2002 recomendaciones para la prctica de internet y pagina web

PROSESO SOFTWARE EFECTIVO Habilita a la organizacin a incrementar su productividad al desarrollar software Permite estandarizar esfuerzos, promover reus, repeticin y consistencia entre proyectos. Provee la oportunidad de introducir mejores prcticas de la industria. Permite entender que las herramientas deben ser utilizar para soportar un proceso. Establece la base para una mayor consistencia y mejoras futuras.

Mejora mantenimiento y soporte Define como manejar los cambios y liberaciones a sistemas de software existentes Define como lograr la transicin del software a la operacin, y como ejecutar los esfuerzos de operacin y soporte

Necesitamos un proceso de sw cuya funcionalidad este probado en la practica ELEMENTOS TIPICOS PS Actividad Flujo de trabajo Definir los proceso que debo llevar acabo en un momento dado del desarrollo de sw Coleccin estructurada de actividades y elementos asociados(artefactos y roles)que producen un resultado de valor Son responsables por llevar acabo las actividades del proceso pueden ser personas o herramientas Son las entradas y salidas de las actividades pueden ser de diferentes tipos como documentos, modelos, componentes, planes reportes Conjunto integrado por actividades relativas a una rama particular de conocimiento Anlisis y diseo

Rol

Productos o Artefactos

Disciplina

MODELOS DE PS

Modelos genricos CMM modelo de madurez de capacidades CMMI modelo integrado IOS/ESC Nos dice que debemos hacer Se deben usar como referencia para definir procesos en una organizacin y para autoevaluacin Medios para evaluar que tan bien y que tan mal esta la organizacin

Modelos especficos Up Rup Psp Nos dicen el cmo hacer las cosas Se usan como gua para ejecutar procesos

CMM (Capability Maturity Model) Creado por Software Engineering Institute (SEI) en conjunto con Carnegie Mellon University, proporciona una medida de la eficacia global de las prcticas de ingeniera del sw de una compaa y establece para ello 5 niveles Planeacin Ingeniera Administracin Desarrollo Mantenimiento 1. Inicial el xito depende de esfuerzos heroicos y personales ms que de procesos adecuadamente definidos 2. Repetible se establecen polticas y procedimientos para llevar a cabo un proyecto. Una funcin de calidad asegura que se cumplen dichos procedimientos se obtienen niveles de calidad parecidos a proyectos anteriores. 3. Definido se adopta un proceso de sw, estndar, y se adapta a cada proyecto. 4. Gestionado la calidad del producto y del proceso es medida predecible y cuantificable. Se puede usar dichas medidas (mtricas del software)para detectar situaciones excepcionales y corregirlas. 5. Optimizado el proceso es continuamente mejorado usando las medidas obtenidas de procesos anteriores Niveles de madurez Nivel INICIAL REPETIBLE rea clave del proceso

Administracin de requerimientos Planificacin de proyectos Seguimiento y control proyecto Administracin subcontratos sw Aseguramiento de calidad de sw

 DEFINIDO

Administracin de la configuracin de sw Enfoque en procesos de informacin Definicin de procesos de informacin Programas de capacitacin Administracin integral de sw Ingeniera productos sw Revisiones sw Administracin cuantificado de procesos Administracin de cambios de sw Administracin de cambios Programacin de defectos

ADMINISTRADO OPTIMIZADO

ISO 9001-2000(international standards organizacion) En 1998 crea la norma ISO 9000 un conjunto de estndares que establecen los requerimientos para gestin de sistemas de calidad ISO 9000:2000 o o o ISO 9000 fundamentos y vocabulario ISO 9001 requisitos ISO 9004 recomendaciones

La parte de requisitos ISO 9001 -2000 est estructurado en 8 secciones 1. Alcance 2. Normas para consulta 3. Trminos y definiciones 4. Sistema de gestin de calidad 5. Responsabilidad de la direccin 6. Gestin de los recursos 7. Realizacin del producto 8. Medida, anlisis, mejora Aunque ISO 9001:2000 no otorga un estndar especio para sistemas de desarrollo de software, es decir, no abarca todos los procesos relacionados CMMI

Est formado por 5 niveles de capacidad del proceso 0. Incompleto 1. Desempeado 2. Administrado

3. Definido 4. Administrado Cuantitativamente 5. Optimizado Y por cuatro categoras de reas de procesos: Administracin de procesos, ingeniera y soporte Estndares relacionados con el proceso software. Procesos estndares IEEE 1074-1998 ciclo de vida de procesos de software ISO/IEC 12207:1995(E) ciclo de vida de procesos ESTANDAR DE CALIDAD: ISO 9000 PARA LA PRODUCCION DE SW ISO 9001 o o o o o o Describe el sistema de calidad utilizando para mantener el desarrollo de un producto que implique diseo. Aplicable a cualquier proceso de produccin: cojines, automviles. Se est convirtindose en el ppal. Medio con el que los clientes pueden juzgar la competencia de un desarrollador de sw. Se han desarrollado varios documentos que relacionan el estndar con la industria de sw pero no entran en detalles No impone ciclo de vida Pueden adoptarse por contrato o voluntariamente.

ISO 9001 (diseo, proceso, produccin, instalacin y servicio) Presmman o o o El control de calidad se debe realizar en todas las fases de desarrollo, adquisicin y mantenimiento de software. El comprador debe c debe cooperar estrechamente con el suministrador del software. El suministrador debe definir su sistema de calidad, y asegurar que todo sistema comprende e implementa dicho sistema de calidad.

1. 2. 3. 4. 5. 6. 7. 8.

ISO 9001(impone 20 requisitos) Responsabilidad de la gestin Inspeccin, medicin y equipo de pruebas Sistemas de calidad Inspeccin y estado de las pruebas Revisin de contrato Accin correctiva Control de producto no aceptado Control de documento

9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.

Tratamiento, almacenamiento empaquetamiento y entrega. Compras Producto proporcionado al comprador Registro de calidad Identificacin y posibilidad de seguimiento del producto Auditoras internas de calidad Formacin control de proceso Servicios Inspeccin y estado de pruebas Tcnicas estadsticas ISO 9000-3 o Contiene directrices que interpretan ISO 9001 ISO 9000 o Contiene guas para proporcionar IEEE1074-1998 DEFINE: Las actividades que constituyen los procesos necesarios para el desarrollo y el mantenimiento de sw ya se parte de su sistema mayor o un autnomo Procesos de gestin y soporte de todo el ciclo de vida del sistema. Ciclo de vida una aproximacin lgica a la adquisicin, suministro, el desarrollo, la explotacin y el mantenimiento de sw El estndar requiere la definicin de un ciclo de vida -> pero no implica ninguno determinado Cada organizacin debe asociar las actividades definidas en el estndar a su propio ciclo de vida del sw. -> si no lo ha definido debe hacerlo El seguimiento del estndar no implica el uso de ningn mtodo especfico, ni la creacin de determinado proceso. Procesos divididos en actividades(obligatorias y opcionales) o Informacin de entrada o Descripcin o Informacin de salida IEEE/EIA (ISO/IEC) 12207 estndar relacionados con el proceso de sw(ciclo de vida) Establece un marco comn para los procesos de ciclo de vida Emplea trminos bien definidos Describe el ciclo de vida o Desde la definicin de requisitos hasta el fin de uso, y contiene procesos para adquirir y suministrar productos y servicios sw.

Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, explotacin y el mantenimiento del producto de sw, abarca la vida del sistema desde la definicin de los requisitos hasta la finalizacin de uso Proceso: conjunto de actividades Actividades: conjunto de tareas Tareas: accin que transforma entradas en salidas Indica los proceso, actividades y tareas que necesitan durante la adquisicin de o Un sistemas que contiene sw o Un producto sw autnomo un servicio sw o Un servicio de sw Y durante el suministro, desarrollo, operacin y mantenimiento de producto sw Tambin proporciona procesos para definir controlar y mejorar los procesos de ciclo de vida sw El marco descrito por el estndar eta diseado para ser adaptado a cada organizacin y proyecto El proceso adaptacin cosiste en la eliminacin de proceso, actividades y tareas no aplicables (tb. se puede aadir)
PROCESOS PRINCIPALES
ADQUISICIN SUMINISTRO EXPLOTACIN DESARROLLO MANTENIMIENTO

PROCESOS DE SOPORTE
DOCUMENTACIN GESTIN DE CONFIGURACIN ASEGURAMIENTO DE CALIDAD VERIFICACIN VALIDACIN

PROCESOS DE LA ORGANIZACIN
GESTIN MEJORA INFRAESTRUCTURA FORMACIN REVISIN CONJUNTA AUDITORA

RESOLUCIN DE PROBLEMAS

PROCESO DE ADAPTACIN

PROCESO PRINCIPALES tiles a las personas que inician o realizan el desarrollo, la explotacin o el mantenimiento del software durante su ciclo de vida o compradores, suministradores, personal de desarrollo, operadores y personal de mantenimiento del software

PROCESOS DE SOPORTE Sirven de apoyo al resto. Contribuyen al xito y calidad del proyecto sw. Se aplica en cualquier momento del ciclo de vida.

PROCESOS DE LA ORGANIZACON Objetivo: establecer, implementar y mejorar la organizacin o (gestin, formacin del personal, mejora de proceso, etc.) Se realiza fuera de proyectos especficos a nivel organizativo.

PROCESOS DE ADAPTACION Permite adaptar el estndar se adapta para cualquier proyecto y organizacin. Permite adaptar el estndar a cada proyecto y organizacin Factores que influencian la forma de adquirir, desarrollar, explotar o mantener un sistema: o Tamao y complejidad del proyecto. o Requisitos de sistema. o Mtodos de desarrollo. o Variaciones en las polticas y procedimientos de la organizacin. PROCESOS PRINCIPALES: PROCESOS DE ADQUISICION Actividades y tareas que el comprador, el cliente o el usuario realizan para adquirir un sistema o producto (servicio) sw o o o Preparacin y publicacin de una solicitud de ofertas. Seleccin del suministrador del sw. Gestin de los procesos desde la adquisicin hasta la aceptacin del producto.

PROCESO DE SUMINITRO Actividades y tareas que realiza el suministrador Se inicia al preparar la propuesta para atender una peticin de un comprador, o por la firma de un contrato con el comprador para proporcionar un producto sw. o Identificacin de procedimientos y recursos para gestionar bien el proyecto o Desarrollo de los planes de proyecto o Ejecucin de los planes del proyecto hasta la entrega del producto sw al comprador.

PROCESO DE DESARROLLO Contiene las actividades y tareas realizadas por el desarrollador Integrar las siguientes actividades o Implementacin del proceso. o Anlisis de requisitos del sistema. o Diseo de la arquitectura del sistema. o Anlisis de los requisitos del software. o Diseo de la arquitectura del software. o Codificacin y prueba del software. o Integracin del software. o Prueba del software. o Integracin del sistema. o Prueba del sistema. o Instalacin de software. o Soporte del proceso de aceptacin del software.

PROCESOS DE DESARROLLO. IMPLEMENTACION DEL PROCESO Si no est especificado en el contrato, el desarrollar definir un modelo de ciclo de vida. o Apropiado al mbito, magnitud y complejidad del proyecto. Las actividades y tareas del proceso de desarrollo sern seleccionadas y relacionadas con el modelo del ciclo de vida. Si no estn indicados en el contrato el desarrollador deber: o Seleccionar, adaptar y utilizar aquellos estndares, mtodos, herramientas y lenguajes de programacin que son apropiadas (y estn documentadas) para realizar las actividades del proceso de desarrollo y de los procesos de soporte.

PROCESO DE DESARROLLO. ANALISIS DE REQUISITOS DEL SISTEMAS Los requisitos del sistema incluyen: o Funciones y capacidades. o Requisitos de seguridad. o Requisitos de interaccin hombre-mquina. o Interfaces del sistema. o Restricciones aplicables al diseo. o Requisitos de aceptacin.

PROCESO DE DESARROLLO. DISEO DE LA ARQUITECTURA DEL SISTEMA Se identifica la arquitectura de alto nivel del sistema: Se determinan los principales componentes hw, sw y las operaciones manuales. Se asignan los requisitos del sistema a dichos componentes.

PROCESO DE DESARROLLO. ANALISIS DE LOS REQUISITOS DEL SOFTWARE Se identifican y documentan los requisitos del sw incluyendo: o Especificaciones funcionales y de capacidades (rendimientos de la aplicacin, etc.). o Interfaces externas. o Seguridad y proteccin (de la informacin, daos personales, etc.). o Datos que se van a manejar y requisitos de la BD. o Requisitos de instalacin y de aceptacin. o Requisitos de mantenimiento.. Varios estndares definidos para esta fase: o IEEE 830- 1998. Recommended Practice for Software Requirements Specifications. o DI-IPSC- 81433. Software Requirements Specification (estndar del DoD).

PROCESO DE DESARROLLO. DISEO DE LA ARQUITECTURA DEL SOFTWARE Componentes principales de software. Versin preliminar de los manuales de usuario. Requisitos de prueba. Planificacin e integracin del software. Diseo detallado de cada componente sw. Diseo detallado de las interfaces. Diseo detallado de las bases de datos. Actualizar manuales de usuario. Definir y documentar los requisitos de pruebas Actualizar requisitos de prueba para la integracin de sw. Evaluar todo lo anterior. Reuniones de revisin.

PROCESO DE DESARROLLO. CODIFICACIN Y PRUEBAS DE SW Se desarrolla los componentes sw y BD Se prueban los componentes Se actualizan manuales de usuario

PROCESO DE DESARROLLO. ACTIVIDADES FINALES INTEGRACION DEL SOFTWARE Se integra los componentes del sw y se prueban segn sea necesario.

PRUEBA DE SOFTWARE De acuerdo con los requisitos de cualificacin (validacin) especificados para el sw.

INTEGRACION DEL SISTEMA Se integra hardware, software y operaciones manuales.

PRUEBAS DEL SISTEMA Anloga a la del sw, pero de acuerdo con los requisitos de la cualificacin especificados para el sistema.

INSTALACION DEL SOFTWARE En el entorno donde vaya a funcionar. Cuando reemplace a otros sistemas, el estndar recomienda mantener funcionamiento paralelo un tiempo.

SOPORTE DEL PROCESO DE ACEPTACION DEL SW Finalmente, se debe dar apoyo de aceptacin a la revisin y aceptacin a la prueba del sw por el comprador.

PROCESO DE EXPLOTACION Tambin llamado de operacin. Explotacin del sw y del soporte del mismo. La explotacin del software est integrado con el del sistema por lo que las actividades y tareas de este proceso se aplica con al sistema completo. El sistema debe ser operado de acuerdo con la documentacin de usuario en su entorno previsto. En otra actividades el operador deber: o Desarrollar un plan para llevar a cabo las actividades y tareas de este proceso. o Procedimientos para comprobar el producto sw en su entorno de operacin, enviando informes de problemas y peticiones de modificacin al proceso de mantenimiento El operador debe proporcionar asistencia a los usuarios.

PROCESOS DE MANTENIMIENTO El sw o la documentacin necesita de ser modificado, debido a problemas o a necesidades o mejorar o adaptacin. o o o o o o Nuevos errores detectados. Cambios en la legislacin. Cambios en el entorno. Necesidades de mejoras. Migracin a un nuevo entorno operativo. Se va a terminar con su uso.

modificar el software existe manteniendo su consistencia PROCESOS DE SOPORTE Sirven de apoyo al resto de procesos Se aplican en cualquier momento del ciclo de vida o Documentacin o Gestin de configuracin o Aseguramiento de la calidad o Verificacin o Validacin o Revisin conjunta o Auditoria o Resolucin de problemas

PROCESO DE DOCUMENTACION registrar la informacin producida gestionar documentos necesarios para todas las personas involucradas

PROCESO DE GESTION DE LA CONFIGURACION Detectar errores y conocer donde esta mediante la documentacin actualizada CONFIGURACION DEL SOFTWARE Configuracin del software o Programas o Documentacin o Datos En aplicaciones grandes, la gestin de la configuracin del sw se convierte en un problema

PROCESOS DE GESTION DE LA CONFICURACION Se encarga Registrar e informar sobre el estado de los elementos y las peticiones de modificacin Asegurar la completitud, consistencia y correccin de los elementos Controlar el almacenamiento, manipulacin y entrega de los elementos

PROCESOS DE ASEGURACION DE LA CALIDAD

Aporta confianza en que los procesos y los productos software del ciclo de vidad cumplen con los requisitos especificaciones y se ajustan a los planes establecidos Aseguramiento de la calidad Interno Externo Usa resultados de otros procesos de apoyo

PROCESOS DE SOPORTE: Proceso de verificacin Indica si los procesos de sistema o del sw estn bien recogidos en cada modelo

Verificacin horizontal Si los productos sw de cada fase del ciclo de vida cumple con los requisitos impuestos sobre ellos en las faces previas

Verificacin vertical ESTAMOS CONSTRUYENDO EL PRODUCTO PROCESOS DE SOPORTE: Proceso de validacin Indica si el sistema o sw final cumple con las necesidades del usuario

PROCESOS DE SOPORTE: Proceso de revisin conjunta Evaluar el estado de sw

PROCESOS DE SOPORTE: Proceso de auditoria Permite determinar si se cumples los requisitos los planes y el contrato El conjunto de tcnicas, mtodos y procedimientos empleados para la evaluacin de proyectos Control de la adecuacin de los sistemas a los requisitos del usuario Produce un documento de recomendaciones El objetivo de una auditoria reproducir un documento de recomendaciones para enmendar o s realizar una evaluacin exhaustiva y enmendar y mejorar errores La auditoria informtica ayudar a detectar o o Fraudes y delitos producidos por la empresa Probabilidades en la privacidad y seguridad informtica

PROCESOS DE SOPORTE: Proceso de resolucin de problemas Analizar y eliminar los problemas

PROCESOS DE GENERALES Establecer implementar y mejorar la gestin consiguiendo una organizacin efectiva PROCESOS DE GENERALES: Procesos de gestin Planificacin Seguimiento

PROCESOS DE GENERALES: procesos de infraestructura Hardware Sw normas instalaciones

PROCESOS DE GENERALES: proceso de mejoras Sirve para establecer, valorar, medir, controlar y mejorar los procesos de ciclo de vida

PROCESOS DE informacin Sirve para mantener el personal formado, desarrollando un plan de formacin, junto con materiales adecuados

SEGUNDO PARCIAL
PPROCESO DE CICLO DE VIDA Definicin.- tiene varias fases por las que debe pasas un proceso sw. Sistemas de informacin o sw Es un proceso por el cual los analistas de sistemas. Los ingenieros de sw, los programadores y los usuarios finales elaboran sistemas de informacin y aplicaciones informticas. Ciclo de vida = Ciclo de desarrollo + mantenimiento

Metodologas 1. Estructurada. 2. Orientada a objetos. MODELOS PARA EL CICLO DE VIDA DE DESARROLLO DE SW CASCADA Anlisis de requerimientos Especificaciones Diseo Implementacin Prueba Manteniendo

Estructurado Encuesta Anlisis Implantacin Pruebas Control de calidad Procedimientos Conversin bd Instalacin

Espiral Requerimientos Anlisis de riesgos Prototipos 1,2 Req. Sw Validacin de req. Anlisis de riesgos Prototipo 3 Diseo de sw Validacin de diseo Integracin y pruebas

Prototipo Requerimientos bsicos Desarrollo Prototipos operacionales Uso de prototipos Usuario satisfecho? o Si. Aceptar o No. Revisar y mejorar CICLO DE VIDA TRADICIONAL Los sistemas de informacin PRODUCTOS Definicin del proyecto Estudio de sistemas Diseo Programacin Instalacin Pos-implantacin Propuesta Propuesta sistema Especificaciones Cdigo Pruebas Auditorias Laudon y Laudon

El CICLO DE VIDA SEGN BIBLIOGRAFIA Fabregas 1. 2. 3. 4. 5. Requerimientos Anlisis diseo Construccin Pruebas Produccin / mantenimiento

SENN 1. 2. 3. 4. 5. Investigacin Preliminar Determinar los requerimientos Diseo del sistema Desarrollo del sistema Pruebas del sistema

CARACTERISTICAS DEL CICLO DE VIDA CLASICO Implantacin Ascendente Las faces debes sucederse de manera secuencial El usuario no ve resultados, sino hasta el final El usuario o el ambiente pueden cambiar las especificaciones originales del sistema Presenta numerosos problemas Analista-Usuario Manejable como proyecto

La experiencia demuestra que no siempre se definen los requerimientos de forma Completa Concreta y Consistente Ciclos de vida tradicionales Los sistemas de informacin 1. 2. 3. 4. Anlisis Diseo Implementacin Mantenimiento

1. Anlisis 1. 2. 3. 4. 5. 6. 7. Estudio preliminar. Levantamiento de informacin. Definicin del problema. Elaboracin del modelo funcional del sistema actual. Determinacin de requerimientos. Descripcin y evaluacin de alternativas. Aprobacin de alternativas

2. Diseo 1. 2. 3. 4. Elaborar el modelo funcional del sistema propuesto Diseo lgico Elaboracin y presentacin del prototipo del sistema Aprobacin del sistema propuesto

3. Implementacin 1. Desarrollo de sw 2. Pruebas del sistema (con la participacin del usuario) 3. Puesta en marcha Qu significa poner en marcha el sistema? Actividad de traslado de una aplicacin probada a un ambiente de produccin. Acondicionamientos de locales Organizacin del cliente o Quienes van a trabajar con la aplicacin. o De acuerdo a las especificaciones Entregar aplicacin probada. Elaborar datos en vivo. o Roles. o Perfiles. Adiestramiento. Carga de datos en vivo Entrega de documentos o Manuales de usuario o Fuentes si lo especifica en el contrato. Asignar Responsabilidades Determinar FIN de instalacin

Mantenimiento del sistema Es la nica fase del ciclo de vida de desarrollo de sistemas en donde los sistemas de informacin son sistemticamente mejorados

Por definicin el proceso de mantenimiento de un SI es un proceso de devolucin al principio del ciclo de vida y de repeticin. Las 4 actividades ms importantes que ocurren dentro del mantenimiento son: Obtencin de los requerimientos de mantenimiento. Transformacin de los requerimientos en cambio Diseo de los cambios Implementacin de los cambios

Tipos de mantenimiento Correctivo.- pera reparar fallas en el diseo codificacin o implementacin del sistema Adaptivo.- Para que las funciones del sistema evolucionen a la par de los cambios del negocio de las tecnologas Perfectivo.- para agregar nuevas funciones al sistema o para mejorar su desempeo Preventivo.- para evitar posibles problemas futuros del sistema. MODELO DE PROCESO La ingeniera de sw establece y se vale de una serie de modelos que instauran y muestran las distintas etapas y estados por los que pasa el producto sw

Modelos de proceso Modelo tradicional Formados por un conjunto de faces o actividades en las que se tienen en cuenta la naturalesa evolutiva del sw Calsico lineal o en cascada

Estructurado Basado en prototipos Desarrollo rpido de aplicaciones

Modelo evolutivo Son los modelos que se adaptan a laevolucion que sufren los requisitos del sietema en funcin del tiempo Espiral Evolutivo Incremental Modelo de desarrollo concurrente Modelos orientados a la reutilizacin Basado en componentes Proceso unificado

Modelo para sistemas orientados a objetos Con alto grado de interactividad y solapamiento entre faces De agrupamiento Fuente Basado en componentes Proceso unificado

Procesos agiles Programacin extrema (xp) Desarrollo de sw adaptativo Scrum crystal

Modelos para sistemas web Uml based web enginneering

MODELO CLASICO LINEAL O EN CASCADA Es el modelo ms antiguo, propuesto por Winston Royce en 1970 Basado en la mentalidad de lnea de ensamblaje cartesiano Es ms sencillo y fcil de entender El proyecto pasa por una serie de faces Al final de cada fase se revisan las tareas de trabajo y productos Para poder pasar a la siguiente fase se tiene que haber conseguido todos los objetivos y metas de la fase anterior No hay apenas comunicacin entre las faces Modelo lineal o en cascada FASES Requisitos Diseo Implementacin Pruebas Mantenimiento

Modelo lineal o en cascada Ventajas Puede ser apropiado en general para proyectos estables con requisitos no cambiantes y donde es posible y probable que los diseadores predigan totalmente reas de problema del sistema y produzcan un diseo concreto antes de que empiece la implementacin Funciona bien para proyectos pequeos donde los requisitos estn bien entendidos Es un modelo en el que todo estn bien organizado y no se mezclan las faces es simple y fcil de usar Debido a la rigidez es fcil de gestionar ya que cada faz tiene entregables especficos y un proceso de revisin. Las faces son procesadas y completadas de una vez Modelo lineal o en cascada inconvenientes

En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin del modelo, lo cual hace que lo lleve al fracaso Difcilmente un cliente va a establecer al principio de todos los requisitos necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que es muy restrictivo y no permite movilizarse entre fases Los resultados y o mejoras no son visibles progresivamente, el producto se ve cuando ya est finalizado lo cual provoca una gran inseguridad por parte del cliente que quiere ir viendo los avances en el producto. MODELO EN V El modelo en v se desarrollo para terminar con algunos de los problemas que se vieron utilizados el enfoque de cascada tradicional Dice que las pruebas necesitan lo ms pronto posible en el ciclo de vida Es un modelo que ilustra como las actividades de prueba (validacin y verificacin)se pueden integrar en cada fase del ciclo de vida. Dentro del modelo en v las pruebas de validacin tienen un lugar especialmente durante las etapas tempranas Describe las actividades y resultados que han de ser producidas durante el desarrollo de produccin La parte izquierda de la v representa faces La parte derecha representa pruebas V significa validacin y verificacin

Faces

Modelo en v Ventajas Es un modelo simple y fcil de utilizar En cada una de las faces hay entregables especficos Tiene alta oportunidad de xito sobre el modelo en cascada debidoa la desarrollo de planes en etapas tempranas del cil ciclo de vida Es un modelo que funciona correctamente en proyectos pequeos donde los requisitos son entendidos fcilmente

Modelo en v inconvenientes es un modelo muy rigido como el modelo en cascada Tiene poca flexibilidad y ajustar el alcance es difcil y claro El sw se desarrolla durante la face de implementacin por lo que no se producen prototipos del sw El modelo no proporciona caminos claros para los problemas encontrados en la face de pruebas

MODELO INCREMENTAL Derivado del ciclo de vida en cascada Ese modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos en la etapa de recogida de requisitos Consiste en la iteracin de varios ciclos de vida en cascada Al final de cada iteracin se le entrega a l usuario una versin mejorada o con mayores funcionalidades del producto u lo corrige o propone mejoras. Estas iteraciones se repetirn hasta obtener un producto que satisfaga las necesidades del cliente Ese modelo se suele utilizar en proyectos donde los requisitos no estn claros por el usuario por lo que se hace la necesaria la creacin de distintos prototipos para presentar y corregir la conformidad del cliente FACES Anlisis Diseo Programacin Pruebas

--------------------

MODELO INCREMENTAL ventajas No hace falta que los requisitos estn completamente definidos al inicio del desarrollo sino que se puede ir refinado en cada una de las iteraciones

Realiza el desarrollo en pequeos ciclos lo que permite gestionar mejor los riesgos gestionar mejor as entregas MODELO INCREMENTAL desventajas Problemas desarrollados con la arquitectura debido a no estar claros desde el principio de los requisitos

MODELO DE CICLO DE VIDA EN ESPIRAL Desarrollado por barry boehm en 1985 Consiste en una serie de ciclos que se repiten cada uno tiene las mismas faces y cuando termina da un producto ampliado con respecto al ciclo anterior En este sentido es parecido la modelo incremental la diferencia importante es que tiene en cuenta el concepto de riesgos Un riesgo puede ser muchas cosas: no comprendidos, mal diseo, errores en la implementacin, etc. Al terminar la iteracin comprueba que lo que ha hecho efectivamente cumple con los requisitos establecidos tambin se verifica que funciona correctamente, El propio cliente evala el producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento cuando hay que hacer un cambio este puede consistir en un nuevo ciclo Este modelo de desarrollo combina las caractersticas del modelo de prototipos y el modelo en cascada el modelo en espiral esta para proyectos largos caros y complicados Este modelo no fue el primero en tratar el desarrollo iterativo, pero fue el primer modelo en explicar las iteraciones Este modelo fue propuesto por Boehm en 1988 en su articulo A Spiral Model of Software Development and Enhancement Basicamente consiste en una serie de ciclos que se representen en forma de espiral comienza desde el centro. Se puedes interpretar como que dentro de cada ciclo en espiral que sigue un modelo en cascada, pero no necesariamente ha de ser as. Este sistema es muy utilizado en proyectos grandes y complejos como puede ser por ejemplo la creacin de un sistema operativo MODELO DE CICLO DE VIDA EN ESPIRAL FACES

MODELO DE CICLO DE VIDA EN ESPIRAL VENTAJAS

El anlisis de riesgos se hace de forma explcita y clara une los mejores elementos de los restantes modelos entre ellos: Reduce riesgos del proyecto Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper el modelo ya que el ciclo de ida no es rgido y esttico Mediante este modelo se produce sw en etapas de ciclo de vida MODELO DE CICLO DE VIDA EN ESPIRAL inconvenientes Modelo que genera mucho trabajo adicional al ser el anlisis de riesgos una de las tareas principales exige un alto nivel de experiencia y cierta habilidad en los analistas de riesgos (es bastante difcil) Esto puede llevar a que sea un modelo costoso adems no es un modelo que funcione bien para proyectos pequeos COMPARACION CON OTROS MODELOS Tarea explicita de Evaluacin de riesgos No hay faces fijadas para la evaluacin de requisitos Se puede usar prototipos para definir los requisitos Diferencia con el incremental Comienza con un alto grado de requisitos Gestiona la incertidumbre

MODELO DE PROTOTIPOS Cuando un cliente no da los requisitos de una manera detallada de entrada proceso o salida. El responsable del desarrollo de sw no est seguro de la eficiencia de un algoritmo, de la calidad de adaptacin de un sistema operativo. O de la forma en la que debera tomarse la interaccin hombre-mquina. Se usa un prototipo para dar al usuario una idea concreta de los que va a hacer el sistema. Se aplica cada vez ms cuando la rapidez de desarrollo es esencial.

Prototipo evolutivo.- inicia se refina progresivamente hasta convertirse en versin final Prototipo desechable.- de cada prototipo se extraen ideas nuevas para hacer el siguiente. Faces Escuchar al cliente Construir revisar la maqueta El cliente prueba la maqueta

Ventajas Ofrece visibilidad del producto desde el inicio del ciclo de vida con el primer prototipo. Esto puede ayudar al cliente a definir mejor los requisitos a ver las necesidades reales del producto. Permite introducir cambios en las iteraciones siguientes del ciclo.

Requerimientos

Accin o efecto de requerir

Requisitos
Definicin (IEEE) a) Una condicin o capacidad que un usuario necesita para resolver un problema o lograr un objetivo. b) Una condicin o capacidad que debe tener un sistema o un componente de un sistema para satisfacer un contrato, una norma, una especificacin u otro documento formal. c) Una representacin en forma de documentacin de una condicin o capacidad como las expresadas en (a) o (b). 2-DoD 1994 Caracterstica del sistema que es una condicin para su aceptacin 3-Gogue 1994 Propiedad que un sistema debera tener para tener xito en el entorno en el que se usara. Por qu importan los requerimientos? La parte ms difcil de construir un sistema es precisamente saber que construir, Ninguna otra parte del trabajo conceptual es tan difcil como establecer requerimientos tcnicos detallados, incluyendo todas las interfaces con gente, mquina y otros sistemas. Ninguna otra parte del trabajo afecta tanto al sistema si es hecha mal. Ninguna es tan difcil de corregir ms adelante Los requerimientos deben descubrir antes de empezar a construir el producto, y que puede ser algo que el producto debe hacer o una cualidad que el producto debe tener Un requerimiento existe ya sea porque el tipo de producto demanda ciertas funciones o cualidades, o porque el cliente quiere que sea requerimiento sea parte del producto final. As que si no se tiene requerimientos correctos, no se puede disear o construir el producto correcto y, consecuentemente el producto no permitir realizar su trabajo. Requerimientos funcionales Definen que hace el sistema (describe entradas y salidas), es decir, las funciones del sistema. Requerimientos no funcionales Definen los atributos que le indican al sistema como realizar su trabajo (eficiencia, hardware, software interface, usabilidad) es como del cundo del que. Dificultades

La dificultad de establecer los requerimientos tcnicos se acenta ya que estamos posicionando al analista frente a un dominio que desconoce, y planteamos un cliente que no tiene claramente estructurados los procesos del negocio(incluyendo metas y objetivos) por lo que el analista puede enfrentarse a objetivos ambiguos o no operacionales; objetivos operacionales pero en conflicto entre si

INGENIERIA DE REQUISITOS Proceso de estudio de las necesidades de los usuarios con el objeto de llegar a una definicin del sistema (IEEE) Proceso de describir, analizar, documentar y validar los servicios y restricciones del sistema (Somerville) Conjunto de actividades en las cuales utilizando tcnicas y herramientas, se analiza un problema y se concluye con la especificacin de una solucin (a veces ms de una).(Ortas)

QUE ES LA INGENIERIA DE REQUERIMIENTOS Se utiliza para definir todas las actividades involucradas en el descubrimiento, documentacin y mantenimiento de los requerimientos para un producto determinado. Coste de errores etapa Requisitos Diseo Codificacin Pruebas unitarias Pruebas del sistema Explotacin /mantenimiento Coste de reparacin 1-2 5 10 20 50 200

Para que sirven los requisitos Para mostrar los resultados que los interesados (stakeholders) quieren. Para dar a los interesados la oportunidad de describir lo que quieren. Para representar distintos puntos de vista Para revisar el diseo Medir el progreso Para aceptar productos respecto a un criterio preciso

Para quienes son los requisitos Usuarios Desarrolladores Ingeniero de stakeholders cliente

Alguien que est involucrado en el uso del sistema cuando estn trabajando

Alguien involucrado en el desarrollo del sistema que satisfaga los requerimientos del cliente

requerimientos Alguien que ayuda a formular y entender los requerimientos de los usuarios

Alguien que tiene una justificacin para que se le permita influir sobre los requerimientos

Alguien que paga para que el sistema sea desarrollado

Tipos de requisitos Requisitos de negocio

Da una descripcin a alto nivel de lo que el sistema debe hacer. Representan los objetivos, la base del negocio, las estrategias, visin, alcance y el valor esperado del desarrollo de software. Requisitos de usuario

Son una descripcin de las tareas que el sistema a de ejecutar cuando el usuario opera con l. Requisitos de sistema/software

Define las funciones y caractersticas que debe tener el sistema para satisfacer tanto los requerimientos del negocio como los de usuario. Van a servir como la base para llevar a cabo la arquitectura, diseo y planes de prueba del sistema Restricciones

Son condiciones que limitan las elecciones disponibles al diseador o programador. Pueden ser restricciones del propio proyecto o del propio producto. Tipos de requisitos Tcnicos

Funcionales Describen las transformaciones que el sistema realiza sobre las entradas para producir errores No funcionales Restricciones de los servicios funcionales que debe proveer el sistema(rendimientos , herramientas) No tcnicos o externas sobre el producto o su provisin (legales costos

Restricciones organizacionales tiempos)

Relacionados con la descripcin del comportamiento fundamental de los componentes del sw.

Funcionales Las funciones son especificadas en trminos de entradas, procesos y salidas

Una vista dinmica podra considerar aspectos como el control, el tiempo de las funciones(de comienzo a fin) y su comportamiento en situaciones excepcionales

Ejemplo El sistema deber permitir localizar un cliente para registrarle el cobro utilizando criterios de bsqueda adecuados (ambiguo) El sistema deber permitir localizar un cliente para registrar el cobro, presionando un botn que le permita buscar por nombre del cliente y el identificador del cliente.(incluyendo detalles de implementacin) El sistema deber permitir localizar un cliente para registrarle el cobro, utilizando como criterios de bsqueda el nombre del cliente el identificador del cliente

Caractersticas Completitud: todos los servicios solicitados por el usuario deben estar definidos. Consistencia: los requerimientos no deben tener definiciones contradictorias. No funcionales Suelen llamarse Juega un papel crucial tambin en el diseo y requerimientos de desarrollo del sistema calidad no de informacin comportamentales en contraste con los comportamentales

Pueden definirse como consideraciones o restricciones asociadas a un servicio del sistema

Pueden ser a veces ms crticos que los funcionales. Una falla en un requerimiento no funcional podra inutilizar el sistema

Dificultades asociadas a los requerimientos no funcionales No hay reglas ni lineamientos Tiene buenas y malas Deben expresarse de forma tal para determinar cundo se soluciones, no soluciones que pueden ser verificados obtuvo una solucin optima correctas e incorrectas

Tipos de requerimientos no funcionales Requerimientos de producto Especifican el comportamiento del producto, como por ejemplo la velocidad de ejecucin o la tasa de fallas (usabilidad, eficiencia (preforma, espacio), confiabilidad, portabilidad) Requerimientos organizacionales

Se derivan de las polticas y procedimientos existentes en la organizacin del cliente (empresa, implementacin, estndares) Requerimientos externos Derivan de los factores externos al sistema y de su proceso de desarrollo, como por ejemplo los requerimientos legales (interoperabilidad, ticos, legales (privacidad y seguridad)) Ejemplo Del producto: la capacidad mxima de almacenamiento de 4MB Organizacionales: el proceso de desarrollo utilizado deber apegarse a los estndares definidos en la organizacin Externos: el sistema no deber revelar a sus operadores informacin personal de los clientes excepto su nombre y su nmero de referencia.

MODELO DE PROCESOS: SWEBOK (1/5) E licitacin de requisitos Esta actividad se considera como la primera que necesario realizar para lograr entender los problemas que hay que resolver, y es fundamentalmente una actividad huma. Para acometerla con ciertas garantas es necesario tener en cuenta los siguientes puntos: Los objetivos: pueden considerarse como los requisitos de alto nivel que deber cumplir el sistema a desarrollar , por lo que es

MODELO DE PROCESOS: SWEBOK (2/5) E licitacin de requisitos

Entorno operacional: el sistema a desarrollar deber funcionar en un entorno que es necesario conocer para poder identificar las necesidades de interoperabilidad con otros sistemas ya existentes. Entorno organizacional: adems del entorno operacional, el organizacional, que es necesario conocer para evitar que surgan sistema afectara al entorno

MODELO DE PROCESOS: SWEBOK (3/5) Anlisis y negociacin de requisitos En esta actividad se pretende detectar y resolver los conflictos entre los requisitos determinar los lmites del sistema y como interactuar con su entorno y transformarlos en requisitos de usuario en requisitos de software en este modelo se propone que en esta actividad se clasifiquen los requisitos, se realicen modelos conceptuales y se negocien los conflictos detectados, tareas que se describen a continuacin CLASIFICACION DE REQUISITOS Los autores consideran importante clasificar los requisitos para ayudar en las labores de negociacin. Los criterios de clasificacin son: capacidad/restriccin, prioridad, coste/impacto, volatilidad/estabilidad y requisito de producto, requisito de proceso MODELADO CONCEPTUAL El objetivo del modelo conceptual MODELO DE PROCESOS: SWEBOK (4/5) Negociacin de requisitos Tambin se denomina resolucin de conflictos, se ocupa de resolver los problemas que pueden surgir en los requisitos, bien porque haya peticiones por parte de clientes y usuarios que sean incompatibles, bien porque no se disponga de los recursos necesarios para la realizacin de ciertos aspectos del sistemas Para resolver estos conflictos es necesario consultar con todos los participantes afectados y registrar las decisiones tomadas y quien las tomo. Es necesario aadir que los autores asumen que los conflictos pueden aparecer no solo durante el anlisis, sino tambin durante la validacin Documentacin de requisitos Los documentos de requisitos son el medio habitual para el registro y la comunicacin de los requisitos. Dentro de las relaciones con la documentacin, los autores se remiten a la gestin de requisitos para el control de versiones debido a los cambios de los requisitos. MODELO DE PROCESOS: SWEBOK (5/5) Validacin de requisitos En esta actividad se debe comprobar los documentos de requisitos para detectar conflictos y ambigedades no detectadas en el anlisis y tambin se deben comprobar que los requisitos siguen las normas establecidas. En otras palabras validacin y verificacin en un solo paso.

Gestin de requisitos La gestin de requisitos, se realiza durante todas las actividades de ingeniera de requisitos. Su objetivo es gestionar los cambios y el mantenimiento de los requisitos para que representen el sistema que va a desarrollar o que se ha desarrollado

E LICITACIN DE REQUISITOS La interaccin con el negocio o el usuario no es la actividad trivial es compleja Visin general de la actividad de e licitacin con sus principales caractersticas Considerar la e licitacin o educcin de requerimientos como una actividad de la ingeniera en la que los ingenieros de requisitos interactan con el resto de participantes para obtener, registrar, y si es necesario negociar los requisitos que deber satisfacer el sistema a desarrollar desde el punto de visto de clientes y usuarios , es decir ,los requisitos C Problemas de la e licitacin de requisitos Los problemas a los que se enfrenta la e licitacin de requisitos son mltiples 1. 2. 3. 4. Problemas de articulacin Problemas de Comunicacin Problemas de Laminaciones cognitivas Problemas de Conducta humana y tcnicos

1. Problemas de articulacin Los problemas de articulacin estn relacionados con la expresin de sus necesidades por parte de cliente y usuario y la compresin de dichas necesidades por parte de los desarrolladores. Algunos de estos problemas son los siguientes Problema de Articulacin 1/5 Los clientes y usuarios pueden ser consistentes de sus necesidades pero no ser capaces de expresarlas apropiadamente Es lo que en sociologa se denomina el problema de decir-hacer y en filosofa se denomina conocimiento tcito: las personas saben cmo hacer muchas cosas que no saben describir Ejemplo: Tener hambre y no saber qu comer Problema de Articulacin 2/5 Los clientes y usuarios pueden no ser consistentes de sus necesidades y pueden que no entiendan como la tecnologa pueden ayudarles.

Ejemplo: Utilizacin de operadores porttiles con telfonos mviles para poder enviar los pedidos inmediatamente en lugar de esperar a que termine sus desplazamientos. Problema de Articulacin 3/5 Algunos usuarios pueden no expresar sus necesidades por miedo a parecer incompetentes antes los dems o porque los desarrolladores juegan un papel excesivamente dominante en el proceso. provocando que la falta de conocimiento tecnolgico de los usuarios les haga sentir en inferioridad de condiciones. Problema de Articulacin 4/5

Los clientes pueden no llegar a tomar decisiones porque no pueden prever las consecuencias de su decisin o porque no entienden las alternativas que se les plantea. Ejemplo: En otras ocasiones no se toman decisiones porque no haya una sola persona que tenga una visin global, por lo que puede haber varios puntos de vista que tenga que integrarse. Problema de Articulacin 5/5

Algunos desarrolladores no escuchan apropiadamente a los clientes y usuarios, bien porque creen haber entendido sus necesidades rpidamente, bien porque se dedican a pensar inmediatamente sobre aspectos de implementacin y no se ponen en el lugar de clientes usuarios. 2. Problemas de Comunicacin Problemas de Comunicacin 1/4

Los clientes usuarios y los desarrolladores tienen culturas y vocabularios diferentes, con la posibilidad de que los mismos trminos tengan significados distintos en los distintos vocabularios, o que su significado se vea enormemente afectado por el contexto, ya que en estos momentos del desarrollo la informacin est fuertemente contextualizada (glosario de trminos) Problemas de Comunicacin 2/4

No solo la cultura y el vocabulario son distintos, las preocupaciones sobre el sistema a desarrollar tambin suelen serlo Mientras los clientes y usuarios suelen preocuparse por los aspectos de alto nivel como facilidad de uso o fiabilidad, los desarrolladores suelen preocuparse por aspectos de bajo nivel como utilizacin de recursos, algoritmos, etc.

Nunca deben perderse de vista porque se desarrolla el software: para satisfacer necesidades reales, para resolver problemas reales. Problemas de Comunicacin 3/4

El medio de comunicacin que se utilice debe ser entendible por todos los participantes. Se suele utilizar lenguaje natural porque es el nico medio de comunicacin comn a todos los participantes, a pesar de su inherente ambigedad. La utilizacin de otro tipo de tcnicas como diagramas o lenguajes artificiales puede presentar problemas de compresin

El concreto, lenguaje natural para la audiencia de clientes y usuarios (requisitos-C) y modelos conceptuales (requisitos -D) para la audiencia Desarrolladores. Problemas de Comunicacin 4/4

La comunicacin puede verse afectada tambin por sus aspectos puramente sociales El ingeniero de requisitos debe ser capaz de comunicarse y tratar con todo tipo de personas y ser capaz de manejar conflictos personales y polticos Tercer parcial E licitacin de requisitos Tcnicas de e licitacin / captura de requisitos Sirve para Conseguir que los interesados humanos articulen sus requisitos Recopilar el conocimiento sobre los requisitos del sistema

Este conocimiento debe estar estructurado: Particin -> Agregando conocimiento relacionado Abstraccin -> Reconocimiento generalidades Proyeccin -> organizndolo de acuerdo a una perspectiva Ejemplos: Talleres de discusin Entrevistas(gerentes) Cuestionarios, fichas Tormenta de ideas Flujos de trabajos Prototipos Escenarios (casos de uso)

Entrevistas Las entrevistas son tcnicas de e licitacin ms utilizada, y de hecho son prcticamente inevitables en cualquier desarrollo ya que son una de las formas de comunicacin ms naturales entre personas. En las entrevistas se pueden identificar tres fases preparacin, realizacin y anlisis. Fase 1 Preparacin de entrevistas Las entrevistas no deben improvisarse, por lo que conviene realizar las siguientes tareas previas. 1. Estudiar el dominio del problema 2. Seleccionar a las personas a las que se va a entrevistar 3. Determinar el objetivo(el cmo cuando y porque) y contenido de las entrevistas(al usuario al producto) 4. Planificar las entrevistas(cronograma de actividades) Preparacin de entrevistas- Estudiar el domino Conocer las categoras y conceptos de la comunidad de clientes y usuarios es fundamental para poder entender las necesidades de dicha comunidad y su forma de expresarlas para generar en los clientes y usuarios la confianza de que el ingeniero de requisitos sus problemas Para conocer el dominio del problema se puede recurrir a: Tcnicas de estudio de documentacin Bibliografa sobre el tema Documentacin de proyectos similares realizados anteriormente La inmersin dentro de la organizacin para la que se va a desarrollar Periodo de aprendizaje por partes de los ingenieros

Preparacin de entrevistas- Seleccionar a la persona a entrevistar 1. Se debe minimizar el nmero de entrevistas a realizar, por lo que fundamental seleccionar a las personas a entrevistar 2. Normalmente se comienza por los directivos que pueden ofrecer una visin global, y se contina con los futuros usuarios que pueden aportar informacin ms detallada, y con el personal tcnico, que aporta detalles sobre el entorno operacional de la organizacin. 3. Conviene tambin estudiar el perfil de los entrevistados buscando puntos en comn con el entrevistador que ayuda a romper el hielo

Preparacin de entrevistas- Determinar el objetivo y contenido de las entrevistas Para minimizar el tiempo de las entrevistas es fundamental fijar el objetivo que se pretende alcanzar y determinar previamente su contenido Se puede anticipadamente enviar cuestionarios que los futuros entrevistados deben rellenar y devolver, y un pequeo documento de introduccin al proyecto de desarrollo, de forma que el entrevistado conozca los temas que se va a tratar y el entrevistado recoja informacin para preparar la entrevista Hay que saber Que decir Como decirlo A quien decirlo Cuando decirlo Es importante que los cuestionarios, si se usan, se preparen cuidadosamente teniendo en cuenta quien los va a responder y no incluir conceptos que asuman conocidos cuando puedan no serlo Preparacin de entrevistas- Planificar las entrevistas La fecha, hora, lugar y duracin de las entrevistas deben fijarse teniendo en cuenta siempre la agenda del entrevistado En general, se deben buscar sitios agradables donde no se produzcan interrupciones y que resulten naturales a los entrevistados Fase 2 Realizacin de la entrevista 1. Apertura 2. Desarrollo 3. Terminacin Realizacin de la entrevista- Apertura El entrevistador debe presentar e informar al entrevistado sobre la razn de la entrevista que se espera conseguir, como se utilizara la informacin, la mecnica de las preguntas Si se va a utilizar algn tipo de notacin grafica o matemtica que el entrevistado no conozca debe explicarse antes de utilizarse Es fundamental causar buena impresin en los primero minutos Realizacin de la entrevista- Desarrollo

La entrevista en si no debera durar ms de dos horas, distribuyendo el tiempo en u 20% para el entrevistador y un 80% para el entrevistado. Se deben evitar los monlogos y mantener el control por parte del entrevistador, contemplando la posibilidad de que una tercera persona tome notas durante la entrevista o grabar la entrevista en cinta de video o audio, siempre que el entrevistado este de acuerdo Se considera el tiempo de duracin de las entrevistas, evitar monlogos Tcnicas 1. Preguntas Abiertas Tambin denominadas de libre contexto estas preguntas no pueden responderse con un si o un no, permiten una mayor comunicacin y evitar la sensacin de interrogatorio Por ejemplo Qu se hace para registrar un pedido? Dgame que se debe hacer cuando un cliente pide una factura Como se rellena un albarn Estas preguntas se suelen utilizar al comienzo de la entrevista, pasando posteriormente a preguntas mas concretas 2. Utilizar palabras apropiadas Se debe evitar tecnicismos que no conozca el entrevistado y palabras o frases que puedan perturbar emocionalmente la comunicacin 3. Mostrar inters en todo momento Comunicacin no verbal durante la entrevista: tono de voz, movimientos, expresin facial. Por ejemplo, para animar a alguien a hablar puede asentirse con la cabeza, decir ya entiendo, si, repetir algunas respuestas dadas, hacer pausas poner una postura de atencin Debe evitarse bostezar, reclinarse en el silln, mirar hacia otro lado Realizacin de la entrevista- Terminacin Al terminar la entrevista se debe recapitular para confirmar que no ha habido confusiones en la informacin recogida, agradecer el entrevistado su colaboracin y citarle para una nueva entrevista si fuera necesario, dejando siempre abierta la posibilidad de volver a contactar para aclarar dudas que surjan al estudiar la informacin o al contrastarla con otros entrevistados Fase 3 Anlisis de la entrevista

1.

Una vez realizada la entrevista es necesario leer las notas tomadas, pasarlas a limpio (minutas), reorganizar la informacin, contrastarlas con otras entrevistas o fuentes de informacin. 2. Una vez el elaborada la informacin, se puede enviar al entrevistado para confirmar los contenidos. Tambin es importante evaluar la propia entrevista para determinar los aspectos mejorables Resumen entrevista Preparacin Investigar la situacin Identificar las personas a entrevistar Preparacin del objetivo y contenido Planificar lugar y hora

Conduccin / realizacin Anlisis Pasar a limpio las notas Organizar la informacin Apertura Desarrollo Tiempos: entrevistado 80% Terminacin

Qu es JAD?
La tcnica denominada JAD (Join Application Development, Desarrollo conjunto de Aplicaciones), desarrollada por IBM en 1977, es una alternativa a las entrevistas individuales que se desarrolla a lo largo de u n conjunto de reuniones en grupo durante un periodo de 2 a 4 das. En estas reuniones sea ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrados y hacindoles participes del desarrollo.

JAD-PRINCIPIOS
1. Dinmica de grupo 2. Uso de ayudas visuales para mejorar la comunicacin (diagramas, transparencias, multimedia, herramientas CASE, etc.) 3. Mantener un proceso organizado y racional.

4. Filosofa de documentacin WYSYWYG (What You See Is What You Get, lo que se ve es lo q se obtiene), por lo que durante las reuniones se trabaja directamente sobre los documentos a generar.

JAD-PASOS
1. JAD/Plan cuyo objetivo es elicitar y especificar requisitos. 2. JAD/Design, en el que se aborda el diseo del software.

JAD-Ventajas/Desventajas
VENTAJAS DESVENTAJAS Ahorra tiempo al evitar que las opiniones de No suele adaptarse a los horarios de trabajo de los clientes se contrasten por separado los clientes y usuario. Todo el grupo, incluyendo los clientes y los No suele emplearse con frecuencia. futuros usuarios, revisa la documentacin generada, no solo los ingenieros de requisitos. Implica ms a los clientes y usuarios en el A muchos les parece una tcnica difcil. desarrollo.

JAD - PARTICIPANTES

Jefe del JAD

Analista

Patrocinador ejecutivo

Representantes de sistemas de informacin

Representantes de los usuarios

Especialistas

JEFE DEL JAD

Es el responsable de todo el proceso y asume el control durante las reuniones. Debe tener dotes de comunicacin y liderazgo. Algunas habilidades importantes que debe tener son: 1. 2. 3. 4. 5. Entender y promover la dinmica de grupo. Iniciar y centrar discusiones. Reconocer cuando la reunin se est desviando del tema y reconducirla. Manejar las distintas personalidades y formas de ser de los participantes. Evitar que decaiga la reunin aunque sea larga y difcil.

ANALISTA
Es el responsable de la produccin de los documentos que se deben generar durante las sesiones JAD. Debe tener la habilidad de organizar bien las ideas y expresarlas claramente por escrito. En caso de que se utilizan herramientas software durante las sesiones, debe ser capaz de manejarlas eficientemente.

PATROCINADOR EJEJUCTIVO

Es el que tiene la decisin final de que se lleve a cabo el desarrollo. Debe proporcionar a los dems participantes informacin sobre la necesidad del nuevo sistema y los beneficios que se espera obtener de l.

REPRESENTANES DE SISTEMAS DE INFORMACION

Son personas expertos en sistemas de informacin que deben ayudar a los usuarios a comprender que es o no factible con la tecnologa actual y el esfuerzo que implica. REPRESENTANTES DE LOS USUARIOS Durante el JAD/Plan, suelen ser directivos con una visin global del sistema. Durante el JAD/Design suelen incorporarse futuros usuarios finales.

ESPECIALISTAS
Son personas que pueden proporcionar informacin detallada sobre aspectos muy concretos. Desde el punto de vista de los usuarios porque conocen muy bien el funcionamiento de una parte de la organizacin. Desde el punto de vista de los desarrolladores porque conocen perfectamente ciertos aspectos tcnicos de la instalacin hardware de la organizacin.

JAD-FASES

Adaptacion

Sesiones

JAD-Fase de Adaptacin
El jefe del JAD es quien debe adaptar la sesin a las caractersticas propias del proyecto en curso. Para ello debe: 1. Documentarse sobre la organizacin y el proyecto. 2. Decidir cuestiones organizativas sobre las sesiones JAD: Numero y duracin, lugar (mejor si es fuera de la empresa para evitar interrupciones), fechas, etc. 3. Seleccionar a los participantes adecuados para cada reunin.

JAD-Fase de Sesiones Est dividida en una serie de pasos: Presentacin: Al igual que en la entrevista individual, el jefe de JAD y el patrocinador ejecutivo se presentan. El patrocinador explica los motivos del proyecto. El jefe del JAD explica la mecnica de la reunin. Definicin de requisitos de alto nivel: Esto ya es parte del trabajo productivo. El jefe del JAD hace preguntas del tipo Por qu se construye el sistema?, Qu beneficios se esperan del nuevo sistema?, Cmo puede beneficiar a la organizacin en el futuro?, Qu restricciones de recursos disponibles, normas o leyes afectan al proyecto?, Es importante la seguridad de los datos?....

A medida que se van elicitando requisitos, el analista los escribe en transparencias en algn otro medio .

Delimitar el mbito del sistema: cuando se ha reunido un conjunto de requisitos lo suficientemente grande se les puede organizar y decidir el mbito del sistema. En casi de los sistemas de informacin, es til identificar a los usuarios potenciales (actores) y determinar que tareas les ayudara a realizar (casos de uso). Documentar temas abiertos: Si un tema queda sin resolver se debe documentar para otra sesin y asignar una persona responsable de su solucin, para lo cual puede utilizarse la plantilla de conflictos. Concluir sesin: El jefe del JAD hace un repaso de la informacin obtenida con los participantes. Se da la oportunidad a todos los participantes de expresar cualquier consideracin adicional, fomentando por parte

JAD-CONCLUSIN Se trata de producir un documento con a informacin recabada en la fase anterior. Hay tres partes que se siguen secuencialmente.

1. Compilar la documentacin: La documentacin recogida se redacta en un documento normalizado. 2. Revisar la documentacin: Se enva la documentacin a los participantes para que efecten correcciones. 3. Validar la documentacin: El patrocinado ejecutivo da si aprobacin. Una vez aprobado e documento se envan copias definitivas a cada uno de los participantes.

Brainstorming
El brainstormig o tormenta de ideas es una tcnica de reuniones en grupo cuyo objetivo es la generacin de ideas en un ambiente libre de crticas o juicios [Gause y Weinberg 1989,Raghavan et a.1994]. Las sesiones de brainstorming suelen estar formadas por un nmero de cuatro a diez participantes, uno de los cuales es el jefe de la sesin, encargado ms de comenzar la sesin que de controlarla.

El brainstorming puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas sobre todo al comienzo del proceso de elicitacion, cuando los requisitos son todava muy difusos. Ventaja: Frente al JAD, el brainstorming tiene la ventaja de que es muy fcil de aprender y requiere poca organizacin, de h echo, hay propuestas de realizacin de brainstorming por video-conferencia a travs de Internet. Desventaja: Al ser un proceso poco estructurado, puede no producir resultados con la misma calidad o nivel de detalle que otras tcnicas.

BRAINSTORMING-FASES

PREPARACIN
La preparacin para una sesin de brainstorming requiere que se seleccione a los participantes y al jefe de sesin, citarlos y preparar la sala donde se lleve a cabo la sesin. Los participantes en una sesin de brainstorming para elicitacion de requisitos son normalmente clientes, usuarios, ingenieros de requisitos, desarrolladores y , si es necesario , algn experto en temas relevantes para el proyecto.

GENERACIN
El jefe abre la sesin exponiendo un enunciado general del problema a tratar, que hace de semilla para que se vayan generando ideas. Los participantes aportan libremente nuevas ideas sobre el problema semilla, bien por un orden establecido por el jefe de la sesin, bien aleatoriamente. El jefe es siempre el responsable de dar la palabra a un participante. Este proceso contina hasta que el jefe decide parar, bien porque no se estn generando suficientes ideas, en cuyo caso la reunin se pospone, bien porque el nmero de ideas sea suficiente para pasar la siguiente fase.

Durante esta fase se debe observar las siguientes reglas: Se prohbe la crtica de ideas, de forma que los participantes se sientan libres de formular cualquier idea. Se fomentan las ideas ms avanzadas, que aunque no sean factibles, estimulan a los dems participantes a explorar nuevas soluciones ms creativas.} Se debe generar un gran nmero de ideas, ya que cuantas ms ideas se presenten ms probable ser que se generen mejores ideas. Se debe alentar a los participantes a combinar o completar las ideas de otros participantes. Para ello, es necesario, al igual que en la tcnica del JAD que todas las ideas generadas estn visibles para todos los participantes en todo momento. Una posibilidad es utilizar como semilla objetivos del sistema e ir identificando requisitos. CONSOLIDACION Se deben organizar y evaluar las ideas generadas durante la fase anterior. Se suelen seguir tres pasos: Revisar ideas: Se revisan las ideas generadas para calificarlas. Es habitual identificar ideas similares, en cuyo caso se unifican en un solo enunciado. Descartar ideas: aquellas ideas que los participantes consideran excesivamente avanzadas se descartan. Priorizar ideas: se priorizan las ideas restantes identificando las absolutamente esenciales, las que estaran bien pero que no son esenciales y las que podran ser apropiadas para una prxima versin del sistema a desarrollar. DOCUMENTACION Despus de la sesin, el jefe produce la documentacin oportuna conteniendo las ideas priorizadas y comentarios generados durante la consolidacin.