tecnica de desarrollo de sistemas
TRANSCRIPT
TECNICAS DE DESARROLLOS DE SISTEMAS
¿Se tiene buenos sistemas?
FALLO, muchos programas no cumplen con los requisitos de los usuarios y/o tienen fallos técnicos.
Las necesidades de los usuarios de pierden en la captura de requisitos, varían durante el desarrollo del sistema lo que hace que el sistema entregado no cumple con necesidades de los usuarios.
La mayoría 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 adecuación 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 satisfacción expectativas con relacionan a un producto o servicio requerido”.
CALIDAD
La calidad es una herramienta básica 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 características 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 tecnologías prometen reducir los tiempos de desarrollo e incrementar los promedios de los éxitos de los proyectos.
Según a Frederick P. Brooks mientras más grande sea el proyecto, mayor será la proporción del costo y tiempo del proyecto gastado en la comunicación entre la gente del proyecto, porque cada persona tiene más gente con quien comunicarse, Cuando un proyecto empieza a quedarse atrás en el tiempo, el poner más gente por lo general falla.
El departamento de defensa de los EU, intento resolver la crisis de SW y comisión el diseño del lenguaje de programación Ada, el cual se estandarizo en 1983, soportaba lo mejor de los conceptos de análisis, diseño y programación estructurados, la modularidad y la encapsulación fueron conceptos clave en el diseño del lenguaje, pero aun esta enorme inversión ha fracasado.
Mejorar las metodologías para la ingeniería del software.
¿Cómo son los buenos sistemas?
El problema fundamental para comprenderlos es:
Hay un límite de cuanto puede entender un humano en un momento dado. Los sistemas pequeños, son realizados mediante “programación heroica” en la cual una sola
persona pretende recordar todo lo relevante acerca del sistema. Pensar un sistema como un conjunto de módulos e identificar dependencias entre módulos.
En sentido más general, un módulo puede ser cualquier elemento identificable de un sistema y que tiene sentido por si mismo los módulos pueden ser:
o Archivoso Subrutinaso Funciones de bibliotecao Clases, en un lenguaje orientado a objetoso Otras partes conocidas como módulos o similares o Programas o subsistemas independientes o semi independientes
Características de los módulos para que el desarrollo y mantenimiento del sistema sea lo más fácil, barato y confiable posible:
o Dependenciao Acoplamiento Bajoo Cohesión Alta (agrupar procesos en un solo proceso bibliotecas)o Interface Definidao Encapsulación Móduloso Abstracción Alta Cohesión (globalizar las características de un objeto)o Componente reusable (Métodos reutilizables )
El modulo A depende del módulo B si existe un cambio en el módulo B significa que el modulo A también 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 través 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 diseño: es la
meta principal que debe tener presente siempre. El bajo acoplamiento soporta el diseño de clases más independientes que reduce el impacto
de los cambios y también más reutilizables que acrecientan la oportunidad de una mayor productividad
Acoplamiento fuerte, la clase usuario 1 es una subclase de servicio 1 Las subclases están expuestas a las implementaciones internas de la súper 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 través 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 programación o un buen diseño Que las clases se comuniquen a través de pequeñas interfaces bien definidas. O sea mientras menos dependientes sean entre si las partes que constituyen un sistema
informático, mejor será el resultado.
ENCAPSULACION
Queremos minimizar el número de casos en los cuales un cambio a un módulo genera un cambio otro modulo.
Tenemos que conocer cuales cambios dentro de un módulo pueden afectar el resto del sistema
Para tomar ventaja del acoplamiento bajo de un sistema Una vez que las fronteras de los módulos de nuestro sistema están definidas hay dos clases de
información que pueden ser útiles.o ¿Qué suposiciones de un módulo dado pueden los clientes hacer acerca de Él? o ¿Cuáles módulos son clientes de un módulo 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 método de desarrollo de software. Existen 4 actividades fundamentales de proceso, comunes para todos los procesos de
software.o Especificación requisitos del softwareo Desarrollo del softwareo Validación del software o Evolución 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 Organización de diferentes usan procesos diferentes para producir el mismo producto.
Sin embargo, para algunos tipos de aplicación, algunos procesos son más convenientes que otros.
CICLO DE VIDA
Alternativamente, a veces se usan los términoso Ciclo de vida
o Modelo de ciclo de vida Sucesión de etapas por las cuales atraviesa un producto sw a largo de
existencia (durante su desarrollo y explotación)
Ciclo de vida
Toda la vida del sistema desde la concepción hasta el fin de uso
Ciclo de desarrollo
Desde el análisis hasta la entrega
ESTANDARES EN INGENIERIA DE SOFTWARE
Estándares conjunto de criterios aprobados, documentados y disponibles para determinar la adecuación de la acción (estándares de procesos o de un objeto (estándar de producto)
Guía conjunto de criterios bien definidos y documentados que encaminan una actividad o tarea.
o Es más flexible que un estándar
Porque usar estándares en ingeniería del software
Según SOMMERVILLE, los estándares son útileso Agrupan lo mejor y más apropiado de las buenas prácticas y usos del desarrollo de
software.o Engloban los conocimientos que son patrimonio de una organizacióno Proporcionan un marco para implementar procedimientos de aseguramiento de la
calidado Proporcionan continuidad entre trabajo de distintas personas
TIPOS DE ESTANDARES EN INGENIERIA DE SOFTWARE
Estándares para softwareDesde asignar nombres a los datos y especificar longitud y tipo hasta los relacionados con BBDD Estándares de codificaciónAbreviaturas y designaciones formales para describir actividades dentro de la organización Estándares estructuralesPolíticas de división del software en módulos Estándares documentación Estándares de proceso software Estándares para otras actividades
EJEMPLOS DE ESTANDARES EN INGENIERIA DEL SOFTWARE IEEE estándar 830-1993 Recomendad Practice for Software requerimientos especificaciones IEEE standars 1074-1997 Standard for developing sw life Cycle Ptroceses
1233-1998 Guía de requisitos de software 2001-2002 recomendaciones para la práctica de internet y pagina web
PROSESO SOFTWARE EFECTIVO
Habilita a la organización a incrementar su productividad al desarrollar software
Permite estandarizar esfuerzos, promover reusó, repetición y consistencia entre proyectos.
Provee la oportunidad de introducir mejores prácticas 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 transición del software a la operación, y como ejecutar los esfuerzos
de operación y soporte
Necesitamos un proceso de sw cuya funcionalidad este probado en la practica
ELEMENTOS TIPICOS PS
Actividad Definir los proceso que debo llevar acabo en un momento dado del desarrollo de sw
Flujo de trabajo Colección estructurada de actividades y elementos asociados(artefactos y roles)que producen un resultado de valor
Rol Son responsables por llevar acabo las actividades del proceso pueden ser personas o herramientas
Productos o Artefactos Son las entradas y salidas de las actividades pueden ser de diferentes tipos como documentos, modelos, componentes, planes reportes
Disciplina Conjunto integrado por actividades relativas a una rama particular de conocimiento Análisis y diseño
MODELOS DE PS
Modelos genéricos Modelos específicosCMM modelo de madurez de capacidadesCMMI modelo integrado
UpRup
IOS/ESC Psp Nos dice que debemos hacer Se deben usar como referencia para definir
procesos en una organización y para autoevaluación
Medios para evaluar que tan bien y que tan mal esta la organización
Nos dicen el cómo hacer las cosas Se usan como guía 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 prácticas de ingeniería del sw de una compañía y establece para ello 5 niveles
Planeación Ingeniería Administración Desarrollo Mantenimiento
1. Inicial el éxito depende de esfuerzos heroicos y personales más que de procesos adecuadamente definidos
2. Repetible se establecen políticas y procedimientos para llevar a cabo un proyecto. Una función 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, estándar, 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 (métricas del software)para detectar situaciones excepcionales y corregirlas.
5. Optimizado el proceso es continuamente mejorado usando las medidas obtenidas de procesos anteriores
Niveles de madurezNivel
Área clave del proceso
INICIALREPETIBLE Administración de requerimientos
Planificación de proyectos Seguimiento y control proyecto Administración subcontratos sw Aseguramiento de calidad de sw Administración de la configuración de sw
DEFINIDO Enfoque en procesos de información Definición de procesos de información
Programas de capacitación Administración integral de sw Ingeniería productos sw Revisiones sw
ADMINISTRADO Administración cuantificado de procesos Administración de cambios de sw
OPTIMIZADO Administración de cambios Programación de defectos
ISO 9001-2000(international standards organizacion)
En 1998 crea la norma ISO 9000 un conjunto de estándares que establecen los requerimientos para gestión de sistemas de calidad
ISO 9000:2000
o ISO 9000 fundamentos y vocabularioo ISO 9001 requisitoso ISO 9004 recomendaciones
La parte de requisitos ISO 9001 -2000 está estructurado en 8 secciones
1. Alcance 2. Normas para consulta3. Términos y definiciones4. Sistema de gestión de calidad 5. Responsabilidad de la dirección6. Gestión de los recursos7. Realización del producto8. Medida, análisis, mejora
Aunque ISO 9001:2000 no otorga un estándar 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. Incompleto1. Desempeñado2. Administrado3. Definido4. Administrado Cuantitativamente5. Optimizado
Y por cuatro categorías de áreas de procesos: Administración de procesos, ingeniería y soporteEstándares relacionados con el proceso software. Procesos estándares
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 Describe el sistema de calidad utilizando para mantener el desarrollo de un producto que implique diseño.
o Aplicable a cualquier proceso de producción: cojines, automóviles.o Se está convirtiéndose en el ppal. Medio con el que los clientes pueden juzgar la
competencia de un desarrollador de sw.o Se han desarrollado varios documentos que relacionan el estándar con la industria de
sw pero no entran en detalleso No impone ciclo de vidao Pueden adoptarse por contrato o voluntariamente.
ISO 9001 (diseño, proceso, producción, instalación y servicio) Presmman
o El control de calidad se debe realizar en todas las fases de desarrollo, adquisición y mantenimiento de software.
o El comprador debe c debe cooperar estrechamente con el suministrador del software.o El suministrador debe definir su sistema de calidad, y asegurar que todo sistema
comprende e implementa dicho sistema de calidad.
ISO 9001(impone 20 requisitos)
1. Responsabilidad de la gestión2. Inspección, medición y equipo de pruebas3. Sistemas de calidad4. Inspección y estado de las pruebas5. Revisión de contrato6. Acción correctiva7. Control de producto no aceptado8. Control de documento9. Tratamiento, almacenamiento empaquetamiento y entrega.10. Compras11. Producto proporcionado al comprador
12. Registro de calidad13. Identificación y posibilidad de seguimiento del producto14. Auditorías internas de calidad15. Formación 16. control de proceso17. Servicios18. Inspección y estado de pruebas 19. Técnicas estadísticas ISO 9000-3
o Contiene directrices que interpretan ISO 9001 ISO 9000
o Contiene guías para proporcionar
IEEE1074-1998DEFINE:
Las actividades que constituyen los procesos necesarios para el desarrollo y el mantenimiento de sw ya se parte de su sistema mayor o un autónomo
Procesos de gestión y soporte de todo el ciclo de vida del sistema. Ciclo de vida “una aproximación lógica a la adquisición, suministro, el desarrollo, la
explotación y el mantenimiento de sw” El estándar requiere la definición de un ciclo de vida -> pero no implica ninguno
determinado Cada organización debe asociar las actividades definidas en el estándar a su propio
ciclo de vida del sw. -> si no lo ha definido debe hacerlo El seguimiento del estándar no implica el uso de ningún método específico, ni la
creación de determinado proceso. Procesos divididos en actividades(obligatorias y opcionales)
o Información de entradao Descripcióno Información de salida
IEEE/EIA (ISO/IEC) 12207 estándar relacionados con el proceso de sw(ciclo de vida)
Establece un marco común para los procesos de ciclo de vida Emplea términos bien definidos Describe el ciclo de vida
o Desde la definición 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, explotación y el mantenimiento del producto de sw, abarca la vida del sistema desde la definición de los requisitos hasta la finalización de uso Proceso: conjunto de actividades Actividades: conjunto de tareas Tareas: acción que transforma entradas en salidas
Indica los proceso, actividades y tareas que necesitan durante la adquisición de o Un sistemas que contiene swo Un producto sw autónomo un servicio swo Un servicio de sw
Y durante el suministro, desarrollo, operación y mantenimiento de producto sw También proporciona procesos para definir controlar y mejorar los procesos de ciclo de
vida sw El marco descrito por el estándar eta diseñado para ser adaptado a cada organización y
proyecto El proceso adaptación cosiste en la eliminación de proceso, actividades y tareas no
aplicables (tb. se puede añadir)
PROCESO PRINCIPALES
Útiles a las personas que inician o realizan el desarrollo, la explotación o el mantenimiento del software durante su ciclo de vida
PROCESOS DE LA ORGANIZACIÓN
GESTIÓN
MEJORA
INFRAESTRUCTURA
FORMACIÓN
ADQUISICIÓN
SUMINISTRO
EXPLOTACIÓN
MANTENIMIENTODESARROLLO
PROCESOS PRINCIPALES
DOCUMENTACIÓN
GESTIÓN DE CONFIGURACIÓN
PROCESOS DE SOPORTE
ASEGURAMIENTO DE CALIDAD
VERIFICACIÓN
VALIDACIÓN
REVISIÓN CONJUNTA
AUDITORÍA
RESOLUCIÓN DE PROBLEMASPROCESO DE ADAPTACIÓN
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 organizacióno (gestión, formación del personal, mejora de proceso, etc.)
Se realiza fuera de proyectos específicos a nivel organizativo.
PROCESOS DE ADAPTACION
Permite adaptar el estándar se adapta para cualquier proyecto y organización. Permite adaptar el estándar a cada proyecto y organización Factores que influencian la forma de adquirir, desarrollar, explotar o mantener un sistema:
o Tamaño y complejidad del proyecto.o Requisitos de sistema.o Métodos de desarrollo.o Variaciones en las políticas y procedimientos de la organización.
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 Preparación y publicación de una solicitud de ofertas.o Selección del suministrador del sw.o Gestión de los procesos desde la adquisición hasta la aceptación del producto.
PROCESO DE SUMINITRO
Actividades y tareas que realiza el suministrador
Se inicia al preparar la propuesta para atender una petición de un comprador, o por la firma de un contrato con el comprador para proporcionar un producto sw.
o Identificación de procedimientos y recursos para gestionar bien el proyectoo Desarrollo de los planes de proyectoo Ejecución 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 actividadeso Implementación del proceso.o Análisis de requisitos del sistema.o Diseño de la arquitectura del sistema.o Análisis de los requisitos del software.o Diseño de la arquitectura del software.o Codificación y prueba del software.o Integración del software.o Prueba del software.o Integración del sistema.o Prueba del sistema.o Instalación de software.o Soporte del proceso de aceptación 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 serán seleccionadas y relacionadas con el modelo del ciclo de vida.
Si no están indicados en el contrato el desarrollador deberá:o Seleccionar, adaptar y utilizar aquellos estándares, métodos, herramientas y
lenguajes de programación que son apropiadas (y están 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 interacción hombre-máquina.o Interfaces del sistema.o Restricciones aplicables al diseño.o Requisitos de aceptación.
PROCESO DE DESARROLLO. DISEÑO 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 aplicación, etc.).o Interfaces externas.o Seguridad y protección (de la información, daños personales, etc.).o Datos que se van a manejar y requisitos de la BD.o Requisitos de instalación y de aceptación.o Requisitos de mantenimiento..
Varios estándares definidos para esta fase:o IEEE 830- 1998. Recommended Practice for Software Requirements Specifications.o DI-IPSC- 81433. Software Requirements Specification (estándar del DoD).
PROCESO DE DESARROLLO. DISEÑO DE LA ARQUITECTURA DEL SOFTWARE
Componentes principales de software. Versión preliminar de los manuales de usuario. Requisitos de prueba. Planificación e integración del software. Diseño detallado de cada componente sw. Diseño detallado de las interfaces. Diseño detallado de las bases de datos. Actualizar manuales de usuario. Definir y documentar los requisitos de pruebas Actualizar requisitos de prueba para la integración de sw. Evaluar todo lo anterior. Reuniones de revisión.
PROCESO DE DESARROLLO. CODIFICACIÓN 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 según sea necesario.
PRUEBA DE SOFTWARE
De acuerdo con los requisitos de cualificación (validación) especificados para el sw.
INTEGRACION DEL SISTEMA
Se integra hardware, software y operaciones manuales.
PRUEBAS DEL SISTEMA
Análoga a la del sw, pero de acuerdo con los requisitos de la cualificación especificados para el sistema.
INSTALACION DEL SOFTWARE
En el entorno donde vaya a funcionar. Cuando reemplace a otros sistemas, el estándar recomienda mantener funcionamiento
paralelo un tiempo.
SOPORTE DEL PROCESO DE ACEPTACION DEL SW
Finalmente, se debe dar apoyo de aceptación a la revisión y aceptación a la prueba del sw por el comprador.
PROCESO DE EXPLOTACION
También llamado de operación. Explotación del sw y del soporte del mismo. La explotación 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 documentación 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 operación,
enviando informes de problemas y peticiones de modificación al proceso de mantenimiento
El operador debe proporcionar asistencia a los usuarios.
PROCESOS DE MANTENIMIENTO
El sw o la documentación necesita de ser modificado, debido a problemas o a necesidades o mejorar o adaptación.
o Nuevos errores detectados.o Cambios en la legislación.
o Cambios en el entorno.o Necesidades de mejoras.o Migración a un nuevo entorno operativo.o 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 Documentacióno Gestión de configuracióno Aseguramiento de la calidado Verificacióno Validacióno Revisión conjuntao Auditoriao Resolución de problemas
PROCESO DE DOCUMENTACION
registrar la información producida gestionar documentos necesarios para todas las personas involucradas
PROCESO DE GESTION DE LA CONFIGURACION
Detectar errores y conocer donde esta mediante la documentación actualizada
CONFIGURACION DEL SOFTWARE
Configuración del softwareo Programaso Documentacióno Datos
En aplicaciones grandes, la gestión de la configuración 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 modificación Asegurar la completitud, consistencia y corrección de los elementos
Controlar el almacenamiento, manipulación 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 verificación
Indica si los procesos de sistema o del sw están bien recogidos en cada modelo
Verificación horizontal
Si los productos sw de cada fase del ciclo de vida cumple con los requisitos impuestos sobre ellos en las faces previas
Verificación vertical
ESTAMOS CONSTRUYENDO EL PRODUCTO
PROCESOS DE SOPORTE: Proceso de validación
Indica si el sistema o sw final cumple con las necesidades del usuario
PROCESOS DE SOPORTE: Proceso de revisión 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 técnicas, métodos y procedimientos empleados para la evaluación de
proyectos Control de la adecuación 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 evaluación exhaustiva y enmendar y mejorar errores La auditoria informática ayudar a detectar
o Fraudes y delitos producidos por la empresao Probabilidades en la privacidad y seguridad informática
PROCESOS DE SOPORTE: Proceso de resolución de problemas
Analizar y eliminar los problemas
PROCESOS DE GENERALES
Establecer implementar y mejorar la gestión consiguiendo una organización efectiva
PROCESOS DE GENERALES: Procesos de gestión
Planificación 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 información
Sirve para mantener el personal formado, desarrollando un plan de formación, junto con materiales adecuados
SEGUNDO PARCIAL
PPROCESO DE CICLO DE VIDA
Definición.- tiene varias fases por las que debe pasas un proceso sw.
Sistemas de información 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 información y aplicaciones informáticas.
Ciclo de vida = Ciclo de desarrollo + mantenimiento
Metodologías
1. Estructurada. 2. Orientada a objetos.
MODELOS PARA EL CICLO DE VIDA DE DESARROLLO DE SW
CASCADA
Análisis de requerimientos Especificaciones Diseño Implementación Prueba Manteniendo
Estructurado
Encuesta Análisis Implantación Pruebas Control de calidad Procedimientos Conversión bd Instalación
Espiral
Requerimientos Análisis de riesgos Prototipos 1,2 Req. Sw Validación de req. Análisis de riesgos Prototipo 3 Diseño de sw Validación de diseño Integración y pruebas
Prototipo
Requerimientos básicos Desarrollo Prototipos operacionales Uso de prototipos ¿Usuario satisfecho?
o Si. Aceptar o No. Revisar y mejorar
CICLO DE VIDA TRADICIONAL
Los sistemas de información
PRODUCTOS
Definición del proyecto Propuesta
Estudio de sistemas Propuesta sistema
Diseño Especificaciones
Programación Código
Instalación Pruebas
Pos-implantación Auditorias
Laudon y Laudon
El CICLO DE VIDA SEGÚN BIBLIOGRAFIA
Fabregas
1. Requerimientos 2. Análisis diseño3. Construcción4. Pruebas5. Producción / mantenimiento
SENN
1. Investigación Preliminar2. Determinar los requerimientos 3. Diseño del sistema4. Desarrollo del sistema 5. Pruebas del sistema
CARACTERISTICAS DEL CICLO DE VIDA CLASICO
Implantación 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 información
1. Análisis2. Diseño3. Implementación 4. Mantenimiento
1. Análisis
1. Estudio preliminar.
2. Levantamiento de información.3. Definición del problema.4. Elaboración del modelo funcional del sistema actual.5. Determinación de requerimientos. 6. Descripción y evaluación de alternativas.7. Aprobación de alternativas
2. Diseño
1. Elaborar el modelo funcional del sistema propuesto2. Diseño lógico 3. Elaboración y presentación del prototipo del sistema 4. Aprobación del sistema propuesto
3. Implementación
1. Desarrollo de sw 2. Pruebas del sistema (con la participación del usuario)3. Puesta en marcha
¿Qué significa poner en marcha el sistema?
Actividad de traslado de una aplicación probada a un ambiente de producción.
Acondicionamientos de locales Organización del cliente
o Quienes van a trabajar con la aplicación. o De acuerdo a las especificaciones
Entregar aplicación probada. Elaborar datos en vivo.
o Roles. o Perfiles.
Adiestramiento. Carga de datos en vivo Entrega de documentos
o Manuales de usuarioo Fuentes si lo especifica en el contrato.
Asignar Responsabilidades Determinar FIN de instalación
Mantenimiento del sistema
Es la única fase del ciclo de vida de desarrollo de sistemas en donde los sistemas de información son sistemáticamente mejorados
Por definición el proceso de mantenimiento de un SI es un proceso de devolución al principio del ciclo de vida y de repetición.
Las 4 actividades más importantes que ocurren dentro del mantenimiento son:
Obtención de los requerimientos de mantenimiento. Transformación de los requerimientos en cambio Diseño de los cambios Implementación de los cambios
Tipos de mantenimiento
Correctivo.- pera reparar fallas en el diseño codificación o implementación del sistema
Adaptivo.- Para que las funciones del sistema evolucionen a la par de los cambios del negocio de las tecnologías
Perfectivo.- para agregar nuevas funciones al sistema o para mejorar su desempeño
Preventivo.- para evitar posibles problemas futuros del sistema.
MODELO DE PROCESO
La ingeniería 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 rápido de aplicaciones
Modelo evolutivo
Son los modelos que se adaptan a laevolucion que sufren los requisitos del sietema en función del tiempo
Espiral
Evolutivo
Incremental
Modelo de desarrollo concurrente
Modelos orientados a la reutilización
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
Programación 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 más antiguo, propuesto por Winston Royce en 1970
Basado en la mentalidad de línea de ensamblaje cartesiano
Es más sencillo y fácil 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 comunicación entre las faces
Modelo lineal o en cascada FASES
Requisitos Diseño Implementación 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 diseñadores predigan totalmente áreas de problema del sistema y produzcan un diseño concreto antes de que empiece la implementación
Funciona bien para proyectos pequeños donde los requisitos estén bien entendidos
Es un modelo en el que todo están bien organizado y no se mezclan las faces es simple y fácil de usar
Debido a la rigidez es fácil de gestionar ya que cada faz tiene entregables específicos y un proceso de revisión. 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 implementación del modelo, lo cual hace que lo lleve al fracaso
Difícilmente 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 más pronto posible en el ciclo de vida
Es un modelo que ilustra como las actividades de prueba (validación y verificación)se pueden integrar en cada fase del ciclo de vida. Dentro del modelo en v las pruebas de validación tienen un lugar especialmente durante las etapas tempranas
Describe las actividades y resultados que han de ser producidas durante el desarrollo de producción
La parte izquierda de la v representa faces
La parte derecha representa pruebas
V significa validación y verificación
Faces
Modelo en v Ventajas
Es un modelo simple y fácil de utilizar
En cada una de las faces hay entregables específicos
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 pequeños donde los requisitos son entendidos fácilmente
Modelo en v inconvenientes
es un modelo muy rigido como el modelo en cascada
Tiene poca flexibilidad y ajustar el alcance es difícil y claro
El sw se desarrolla durante la face de implementación 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 iteración de varios ciclos de vida en cascada Al final de cada iteración se le entrega a l usuario una versión mejorada o con mayores funcionalidades del producto u lo corrige o propone mejoras. Estas iteraciones se repetirán hasta obtener un producto que satisfaga las necesidades del cliente
Ese modelo se suele utilizar en proyectos donde los requisitos no están claros por el usuario por lo que se hace la necesaria la creación de distintos prototipos para presentar y corregir la conformidad del cliente
FACES
Análisis Diseño Programación Pruebas
--------------------
MODELO INCREMENTAL ventajas
No hace falta que los requisitos estén completamente definidos al inicio del desarrollo sino que se puede ir refinado en cada una de las iteraciones
Realiza el desarrollo en pequeños 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 diseño, errores en la implementación, etc.
Al terminar la iteración comprueba que lo que ha hecho efectivamente cumple con los requisitos establecidos también se verifica que funciona correctamente, El propio cliente evalúa 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 características 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 creación de un sistema operativo
MODELO DE CICLO DE VIDA EN ESPIRAL FACES
MODELO DE CICLO DE VIDA EN ESPIRAL VENTAJAS
El análisis de riesgos se hace de forma explícita 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
Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper el modelo ya que el ciclo de ida no es rígido y estático
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 análisis de riesgos una de las tareas principales exige un alto nivel de experiencia y cierta habilidad en los analistas de riesgos (es bastante difícil)
Esto puede llevar a que sea un modelo costoso además no es un modelo que funcione bien para proyectos pequeños
COMPARACION CON OTROS MODELOS
Tarea explicita de Evaluación de riesgos
No hay faces fijadas para la evaluación 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 adaptación de un sistema operativo. O de la forma en la que debería tomarse la interacción hombre-máquina.
Se usa un prototipo para dar al usuario una idea concreta de los que va a hacer el sistema.
Se aplica cada vez más cuando la rapidez de desarrollo es esencial.
Prototipo evolutivo.- inicia se refina progresivamente hasta convertirse en versión 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
Acción o efecto de requerir
Requisitos
Definición (IEEE)
a) Una condición o capacidad que un usuario necesita para resolver un problema o lograr un objetivo.
b) Una condición o capacidad que debe tener un sistema o un componente de un sistema para satisfacer un contrato, una norma, una especificación u otro documento formal.
c) Una representación en forma de documentación de una condición o capacidad como las expresadas en (a) o (b).
2-DoD 1994
Característica del sistema que es una condición para su aceptación
3-Gogue 1994
Propiedad que un sistema debería tener para tener éxito en el entorno en el que se usara.
¿Por qué importan los requerimientos?
La parte más difícil de construir un sistema es precisamente saber que construir, Ninguna otra parte del trabajo conceptual es tan difícil como establecer requerimientos técnicos detallados, incluyendo todas las interfaces con gente, máquina y otros sistemas. Ninguna otra parte del trabajo afecta tanto al sistema si es hecha mal. Ninguna es tan difícil de corregir más 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 diseñar 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 cuándo del que.
Dificultades
La dificultad de establecer los requerimientos técnicos se acentúa 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 definición del sistema (IEEE)
Proceso de describir, analizar, documentar y validar los servicios y restricciones del sistema (Somerville)
Conjunto de actividades en las cuales utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución (a veces más de una).(Ortas)
QUE ES LA INGENIERIA DE REQUERIMIENTOS
Se utiliza para definir todas las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos para un producto determinado.
Coste de errores
etapa Coste de reparaciónRequisitos 1-2Diseño 5Codificación 10Pruebas unitarias 20Pruebas del sistema 50Explotación /mantenimiento 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 diseño Medir el progreso Para aceptar productos respecto a un criterio preciso
Para quienes son los requisitos
Usuarios Desarrolladores Ingeniero de requerimientos
stakeholders cliente
Alguien que está involucrado en el uso del sistema
Alguien involucrado en el
desarrollo del
Alguien que ayuda a formular
y entender los
Alguien que tiene una justificación
para que se le
Alguien que paga para que el sistema sea
cuando están trabajando
sistema que satisfaga los
requerimientos del cliente
requerimientos de los usuarios
permita influir sobre los
requerimientos
desarrollado
Tipos de requisitos
Requisitos de negocio
Da una descripción a alto nivel de lo que el sistema debe hacer. Representan los objetivos, la base del negocio, las estrategias, visión, alcance y el valor esperado del desarrollo de software.
Requisitos de usuario
Son una descripción de las tareas que el sistema a de ejecutar cuando el usuario opera con él.
Requisitos de sistema/software
Define las funciones y características 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, diseño y planes de prueba del sistema
Restricciones
Son condiciones que limitan las elecciones disponibles al diseñador o programador. Pueden ser restricciones del propio proyecto o del propio producto.
Tipos de requisitos
Técnicos
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 técnicos
Restricciones organizacionales o externas sobre el producto o su provisión (legales costos tiempos)
FuncionalesRelacionados con la
descripción del comportamiento fundamental de los componentes del sw.
Las funciones son especificadas en términos de entradas, procesos y salidas
Una vista dinámica podría 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 búsqueda adecuados (ambiguo)
El sistema deberá permitir localizar un cliente para registrar el cobro, presionando un botón que le permita buscar por nombre del cliente y el identificador del cliente.(incluyendo detalles de implementación)
El sistema deberá permitir localizar un cliente para registrarle el cobro, utilizando como criterios de búsqueda el nombre del cliente el identificador del cliente
Características
Completitud: todos los servicios solicitados por el usuario deben estar definidos.
Consistencia: los requerimientos no deben tener definiciones contradictorias.
No funcionalesPueden definirse
como consideraciones o restricciones asociadas a un
servicio del sistema
Suelen llamarse también
requerimientos de calidad no
comportamentales en contraste con los
comportamentales
Juega un papel crucial en el diseño y
desarrollo del sistema de información
Pueden ser a veces más críticos que los
funcionales. Una falla en un requerimiento no funcional podría inutilizar el sistema
Dificultades asociadas a los requerimientos no funcionalesNo hay reglas ni lineamientos
para determinar cuándo se obtuvo una solución optima
Tiene buenas y malas soluciones, no soluciones
correctas e incorrectas
Deben expresarse de forma tal que pueden ser verificados
Tipos de requerimientos no funcionales
Requerimientos de productoEspecifican el comportamiento del producto, como por ejemplo la velocidad de ejecución o la tasa de fallas (usabilidad, eficiencia (preforma, espacio), confiabilidad, portabilidad)Requerimientos organizacionalesSe derivan de las políticas y procedimientos existentes en la organización del cliente (empresa, implementación, estándares)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 máxima de almacenamiento de 4MB Organizacionales: el proceso de desarrollo utilizado deberá apegarse a los estándares
definidos en la organización Externos: el sistema no deberá revelar a sus operadores información personal de los
clientes excepto su nombre y su número de referencia.
MODELO DE PROCESOS: SWEBOK (1/5)
E licitación 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 garantías 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 licitación 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: además del entorno operacional, el sistema afectara al entorno organizacional, que es necesario conocer para evitar que surgan
MODELO DE PROCESOS: SWEBOK (3/5)
Análisis y negociación de requisitos
En esta actividad se pretende detectar y resolver los conflictos entre los requisitos determinar los límites 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 continuación
CLASIFICACION DE REQUISITOS
Los autores consideran importante clasificar los requisitos para ayudar en las labores de negociación. Los criterios de clasificación son: capacidad/restricción, 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)
Negociación de requisitos
También se denomina resolución 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 realización 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 añadir que los autores asumen que los conflictos pueden aparecer no solo durante el análisis, sino también durante la validación
Documentación de requisitos
Los documentos de requisitos son el medio habitual para el registro y la comunicación de los requisitos. Dentro de las relaciones con la documentación, los autores se remiten a la gestión de requisitos para el control de versiones debido a los cambios de los requisitos.
MODELO DE PROCESOS: SWEBOK (5/5)
Validación de requisitos
En esta actividad se debe comprobar los documentos de requisitos para detectar conflictos y ambigüedades no detectadas en el análisis y también se deben comprobar que los requisitos siguen las normas establecidas. En otras palabras validación y verificación en un solo paso.
Gestión de requisitos
La gestión de requisitos, se realiza durante todas las actividades de ingeniería 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 LICITACIÓN DE REQUISITOS
La interacción con el negocio o el usuario no es la actividad trivial… es compleja
Visión general de la actividad de e licitación con sus principales características
Considerar la e licitación o educción de requerimientos como una actividad de la ingeniería en la que los ingenieros de requisitos interactúan 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 licitación de requisitos
Los problemas a los que se enfrenta la e licitación de requisitos son múltiples
1. Problemas de articulación2. Problemas de Comunicación3. Problemas de Laminaciones cognitivas4. Problemas de Conducta humana y técnicos
1. Problemas de articulaciónLos problemas de articulación están relacionados con la expresión de sus necesidades por parte de cliente y usuario y la compresión de dichas necesidades por parte de los desarrolladores. Algunos de estos problemas son los siguientes
Problema de Articulación 1/5 Los clientes y usuarios pueden ser consistentes de sus necesidades pero no ser capaces de expresarlas apropiadamenteEs lo que en sociología se denomina el problema de decir-hacer y en filosofía se denomina conocimiento tácito: las personas saben cómo hacer muchas cosas que no saben describirEjemplo: Tener hambre y no saber qué comer
Problema de Articulación 2/5Los clientes y usuarios pueden no ser consistentes de sus necesidades y pueden que no entiendan como la tecnología pueden ayudarles.Ejemplo: Utilización de operadores portátiles con teléfonos móviles para poder enviar los pedidos inmediatamente en lugar de esperar a que termine sus desplazamientos.
Problema de Articulación 3/5Algunos usuarios pueden no expresar sus necesidades por miedo a parecer incompetentes antes los demás o porque los desarrolladores juegan un papel excesivamente dominante en el proceso. provocando que la falta de conocimiento tecnológico de los usuarios les haga sentir en inferioridad de condiciones.
Problema de Articulación 4/5
Los clientes pueden no llegar a tomar decisiones porque no pueden prever las consecuencias de su decisión 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 visión global, por lo que puede haber varios puntos de vista que tenga que integrarse.
Problema de Articulación 5/5
Algunos desarrolladores no escuchan apropiadamente a los clientes y usuarios, bien porque creen haber entendido sus necesidades rápidamente, bien porque se dedican a pensar inmediatamente sobre aspectos de implementación y no se ponen en el lugar de clientes usuarios.
2. Problemas de Comunicación
Problemas de Comunicación 1/4
Los clientes usuarios y los desarrolladores tienen culturas y vocabularios diferentes, con la posibilidad de que los mismos términos 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 información está fuertemente contextualizada (glosario de términos)
Problemas de Comunicación 2/4
No solo la cultura y el vocabulario son distintos, las preocupaciones sobre el sistema a desarrollar también 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 utilización de recursos, algoritmos, etc.
Nunca deben perderse de vista porque se desarrolla el software: para satisfacer necesidades reales, para resolver problemas reales.
Problemas de Comunicación 3/4
El medio de comunicación que se utilice debe ser entendible por todos los participantes. Se suele utilizar lenguaje natural porque es el único medio de comunicación común a todos los participantes, a pesar de su inherente ambigüedad. La utilización de otro tipo de técnicas como diagramas o lenguajes artificiales puede presentar problemas de compresión
El concreto, lenguaje natural para la audiencia de clientes y usuarios (requisitos-C) y modelos conceptuales (requisitos -D) para la audiencia Desarrolladores.
Problemas de Comunicación 4/4
La comunicación puede verse afectada también 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 políticos
Tercer parcial
E licitación de requisitos
Técnicas de e licitación / 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:
Partición -> Agregando conocimiento relacionado
Abstracción -> Reconocimiento generalidades
Proyección -> organizándolo de acuerdo a una perspectiva
Ejemplos:
Talleres de discusión Entrevistas(gerentes) Cuestionarios, fichas Tormenta de ideas Flujos de trabajos Prototipos Escenarios (casos de uso)
Entrevistas Las entrevistas son técnicas de e licitación más utilizada, y de hecho son prácticamente inevitables en cualquier desarrollo ya que son una de las formas de comunicación más naturales entre personas.
En las entrevistas se pueden identificar tres fases preparación, realización y análisis.Fase 1 – Preparación de entrevistas
Las entrevistas no deben improvisarse, por lo que conviene realizar las siguientes tareas previas.
1. Estudiar el dominio del problema2. Seleccionar a las personas a las que se va a entrevistar3. Determinar el objetivo(el cómo cuando y porque) y contenido de las entrevistas(al usuario
al producto)4. Planificar las entrevistas(cronograma de actividades)
Preparación de entrevistas- Estudiar el domino
Conocer las categorías 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 problemasPara conocer el dominio del problema se puede recurrir a:
Técnicas de estudio de documentación Bibliografía sobre el tema Documentación de proyectos similares realizados anteriormente La inmersión dentro de la organización para la que se va a desarrollar Periodo de aprendizaje por partes de los ingenieros
Preparación de entrevistas- Seleccionar a la persona a entrevistar
1. Se debe minimizar el número 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 visión global, y se continúa con los futuros usuarios que pueden aportar información más detallada, y con el personal técnico, que aporta detalles sobre el entorno operacional de la organización.
3. Conviene también estudiar el perfil de los entrevistados buscando puntos en común con el entrevistador que ayuda a romper el hielo
Preparación 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 pequeño documento de introducción al proyecto de desarrollo, de forma que el entrevistado conozca los temas que se va a tratar y el entrevistado recoja información para preparar la entrevista
Hay que saberQue decir
Como decirloA quien decirloCuando 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
Preparación de entrevistas- Planificar las entrevistas
La fecha, hora, lugar y duración de las entrevistas deben fijarse teniendo en cuenta siempre la agenda del entrevistadoEn general, se deben buscar sitios agradables donde no se produzcan interrupciones y que resulten naturales a los entrevistados
Fase 2 – Realización de la entrevista
1. Apertura 2. Desarrollo3. Terminación
Realización de la entrevista- Apertura
El entrevistador debe presentar e informar al entrevistado sobre la razón de la entrevista que se espera conseguir, como se utilizara la información, la mecánica de las preguntas
Si se va a utilizar algún tipo de notación grafica o matemática que el entrevistado no conozca debe explicarse antes de utilizarse Es fundamental causar buena impresión en los primero minutos
Realización de la entrevista- Desarrollo
La entrevista en si no debería durar más de dos horas, distribuyendo el tiempo en u 20% para el entrevistador y un 80% para el entrevistado.
Se deben evitar los monólogos 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 acuerdoSe considera el tiempo de duración de las entrevistas, evitar monólogos
Técnicas 1. Preguntas Abiertas
También denominadas de libre contexto estas preguntas no pueden responderse con un “si” o un “no”, permiten una mayor comunicación y evitar la sensación de interrogatorio
Por ejemplo¿Qué se hace para registrar un pedido?Dígame que se debe hacer cuando un cliente pide una facturaComo se rellena un albarán
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 comunicación
3. Mostrar interés en todo momento
Comunicación no verbal durante la entrevista: tono de voz, movimientos, expresión 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 atención Debe evitarse bostezar, reclinarse en el sillón, mirar hacia otro lado
Realización de la entrevista- Terminación
Al terminar la entrevista se debe recapitular para confirmar que no ha habido confusiones en la información recogida, agradecer el entrevistado su colaboración 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 información o al contrastarla con otros entrevistados
Fase 3 – Análisis de la entrevista
1. Una vez realizada la entrevista es necesario leer las notas tomadas, pasarlas a limpio (minutas), reorganizar la información, contrastarlas con otras entrevistas o fuentes de información.
2. Una vez el elaborada la información, se puede enviar al entrevistado para confirmar los contenidos. También es importante evaluar la propia entrevista para determinar los aspectos mejorables
Resumen entrevista
Preparación
Investigar la situación Identificar las personas a entrevistar Preparación del objetivo y contenido Planificar lugar y hora
Conducción / realización
Apertura Desarrollo Tiempos: entrevistado 80% Terminación
Análisis
Pasar a limpio las notas Organizar la información
¿Qué es JAD?
La técnica 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 días.
En estas reuniones sea ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrados y haciéndoles participes del desarrollo.
JAD-PRINCIPIOS
1. Dinámica de grupo2. Uso de ayudas visuales para mejorar la comunicación (diagramas, transparencias,
multimedia, herramientas CASE, etc.)3. Mantener un proceso organizado y racional.4. Filosofía de documentación 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 diseño del software.
JAD-Ventajas/Desventajas
VENTAJAS DESVENTAJASAhorra tiempo al evitar que las opiniones de los clientes se contrasten por separado
No suele adaptarse a los horarios de trabajo de los clientes y usuario.
Todo el grupo, incluyendo los clientes y los futuros usuarios, revisa la documentación generada, no solo los ingenieros de requisitos.
No suele emplearse con frecuencia.
Implica más a los clientes y usuarios en el desarrollo.
A muchos les parece una técnica difícil.
JAD - PARTICIPANTES
Jefe del JAD Analista
Patrocinador ejecutivo
Representantes de sistemas de
información
EspecialistasRepresentantes de los usuarios
JEFE DEL JAD
Es el responsable de todo el proceso y asume el control durante las reuniones. Debe tener dotes de comunicación y liderazgo.
Algunas habilidades importantes que debe tener son:
1. Entender y promover la dinámica de grupo.2. Iniciar y centrar discusiones.3. Reconocer cuando la reunión se está desviando del tema y reconducirla.4. Manejar las distintas personalidades y formas de ser de los participantes.5. Evitar que decaiga la reunión aunque sea larga y difícil.
ANALISTA
Es el responsable de la producción 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 decisión final de que se lleve a cabo el desarrollo. Debe proporcionar a los demás participantes información 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 información que deben ayudar a los usuarios a comprender que es o no factible con la tecnología actual y el esfuerzo que implica.
REPRESENTANTES DE LOS USUARIOS
Durante el JAD/Plan, suelen ser directivos con una visión global del sistema.
Durante el JAD/Design suelen incorporarse futuros usuarios finales.
ESPECIALISTAS
Son personas que pueden proporcionar información detallada sobre aspectos muy concretos.
Desde el punto de vista de los usuarios porque conocen muy bien el funcionamiento de una parte de la organización.
Desde el punto de vista de los desarrolladores porque conocen perfectamente ciertos aspectos técnicos de la instalación hardware de la organización.
JAD-FASES
JAD-Fase de Adaptación
El jefe del JAD es quien debe adaptar la sesión a las características propias del proyecto en curso. Para ello debe:
Adaptacion Sesiones
1. Documentarse sobre la organización y el proyecto.2. Decidir cuestiones organizativas sobre las sesiones JAD: Numero y duración, lugar (mejor si
es fuera de la empresa para evitar interrupciones), fechas, etc.3. Seleccionar a los participantes adecuados para cada reunión.
JAD-Fase de Sesiones
Está dividida en una serie de pasos:
Presentación: 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 mecánica de la reunión.
Definición 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?”, “ ¿Cómo puede beneficiar a la organización 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 algún 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 información, 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 sesión y asignar una persona responsable de su solución, para lo cual puede utilizarse la plantilla de conflictos.
Concluir sesión: El jefe del JAD hace un repaso de la información obtenida con los participantes.
Se da la oportunidad a todos los participantes de expresar cualquier consideración adicional, fomentando por parte …
JAD-CONCLUSIÓN
Se trata de producir un documento con a información recabada en la fase anterior. Hay tres partes que se siguen secuencialmente.
1. Compilar la documentación: La documentación recogida se redacta en un documento normalizado.
2. Revisar la documentación: Se envía la documentación a los participantes para que efectúen correcciones.
3. Validar la documentación: El patrocinado ejecutivo da si aprobación. Una vez aprobado e documento se envían copias definitivas a cada uno de los participantes.
Brainstorming
El brainstormig o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios [Gause y Weinberg 1989,Raghavan et añ.1994].
Las sesiones de brainstorming suelen estar formadas por un número de cuatro a diez participantes, uno de los cuales es el jefe de la sesión, encargado más de comenzar la sesión 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 todavía muy difusos.
Ventaja:
Frente al JAD, el brainstorming tiene la ventaja de que es muy fácil de aprender y requiere poca organización, de h echo, hay propuestas de realización de brainstorming por video-conferencia a través de Internet.
Desventaja:
Al ser un proceso poco estructurado, puede no producir resultados con la misma calidad o nivel de detalle que otras técnicas.
BRAINSTORMING-FASES
PREPARACIÓN
La preparación para una sesión de brainstorming requiere que se seleccione a los participantes y al jefe de sesión, citarlos y preparar la sala donde se lleve a cabo la sesión.
Los participantes en una sesión de brainstorming para elicitacion de requisitos son normalmente clientes, usuarios, ingenieros de requisitos, desarrolladores y , si es necesario , algún experto en temas relevantes para el proyecto.
GENERACIÓN
El jefe abre la sesión 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 sesión, bien aleatoriamente.
El jefe es siempre el responsable de dar la palabra a un participante. Este proceso continúa hasta que el jefe decide parar, bien porque no se están generando suficientes ideas, en cuyo caso la reunión se pospone, bien porque el número de ideas sea suficiente para pasar la siguiente fase.
Durante esta fase se debe observar las siguientes reglas:
Se prohíbe la crítica de ideas, de forma que los participantes se sientan libres de formular cualquier idea.
Se fomentan las ideas más avanzadas, que aunque no sean factibles, estimulan a los demás participantes a explorar nuevas soluciones más creativas.}
Se debe generar un gran número de ideas, ya que cuantas más ideas se presenten más 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 técnica del JAD que todas las ideas generadas estén visibles para todos los participantes en todo momento.
Una posibilidad es utilizar como semilla objetivos del sistema e ir identificando requisitos.
CONSOLIDACIONSe 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 estarían bien pero que no son esenciales y las que podrían ser apropiadas para una próxima versión del sistema a desarrollar.
DOCUMENTACIONDespués de la sesión, el jefe produce la documentación oportuna conteniendo las ideas priorizadas y comentarios generados durante la consolidación.