CAPITULO I. Ingeniería de Software INF EL PROCESO. Resumen preparado por Miguel Cotaña

Transcripción

1 CAPITULO I Ingeniería de Software INF EL PROCESO Resumen preparado por Miguel Cotaña

2 La construcción del software de ordenador es un proceso iterativo de aprendizaje y el resultado es una materialización del conocimiento recolectado, depurado y organizado conforme el proceso estuvo en ejecución

3 Existen mecanismos de evaluación del proceso de software que permiten a las organizaciones determinar la madurez del proceso de software. No obstante, la calidad, el tiempo requerido, la viabilidad a largo plazo del producto que se construye son los mejores indicadores de la eficacia del proceso que se utiliza.

4 Que es un proceso? Una secuencia de pasos desarrollados para un propósito dado, por ejemplo, el proceso de desarrollo de software (IEEE-STD-610). Curso de acción o manera de proceder (diccionario Oxford) Un sistema de operaciones para producir algo Un conjunto de acciones, cambios o funciones que logran un resultado final (diccionario Webmaster) Conjunto de actividades relacionadas que son ejecutadas en respuesta a necesidades previamente determinadas y consumiendo recursos para producir un producto (J. Moore)

5 Tres aspectos del proceso 1.- Definición del proceso Un proceso debe estar definido (documento que especifica actividades y procedimientos del proceso) 2.- Aprendizaje del proceso El conocimiento del proceso debe ser transferido a las personas (agentes) que lo ejecutarán 3.- Resultados del proceso Manifestación de los productos, como resultado de la ejecución de las actividades definidas por el proceso

6 Consideraciones acerca de los procesos Los comportamientos, actividades y tareas que desempeñamos para lograr un objetivo representan la ejecución del proceso para alcanzar dicho objetivo. Un proceso disciplinado se manifestará en patrones ordenados y consistentes de comportamiento individual o grupal Por tanto, un proceso da forma a las acciones y reacciones y tomamos frente a una determinada situación.

7 Proceso internalizado y proceso institucionalizado Cuando un proceso es desarrollado profesional y naturalmente por una persona, se dice que el proceso esta internalizado por la persona. En las organizaciones los procesos son comunes a grupos de personas. Para obtener disciplina en los procesos, estos deben ser establecidos como institucionalizados en la organización.

8 Completitud y disciplina en los procesos Un proceso es incompleto si: a) El documento de definición existe pero no todos saben de su existencia b) El documento de definición existe, pero no hay capacitación en el proceso. Se deja a iniciativa del equipo aprender el proceso c) El documento de definición existe, existe capacitación, pero no hay monitoreo y el proceso NO es forzado a su cumplimiento. Algunos lo siguen y otros no

9 Un proceso es disciplinado solo si se cumplen las siguientes condiciones: a) El proceso esta debidamente documentado b) Existe y se realiza capacitación formal sobre el proceso c) Las personas siguen lo establecido por el proceso como una manera natural de desempeñar sus actividades d) El proceso es monitoreado y su cumplimiento es obligatorio.

10 Ingenieria del software Definicion teoria practica [Ingeniería de software es] el establecimiento y uso de principios de ingeniería adecuados para obtener económicamente software que sea confiable y trabaje eficientemente en máquinas reales (Fritz Bauer) Pruebas y control de calidad Resolucion de problemas Administracion y gestion

11 La ingeniería de software no es ciencia informática. Un científico construye con el objetivo de aprender, un ingeniero aprende con el objetivo de construir La distinción entre ingeniería y ciencia en el software es el mismo que en otras disciplinas Los científicos aprenden lo que es verdadero y cómo extender el conocimiento en su campo Los ingenieros aprenden lo que es verdadero, lo que es útil y cómo aplicar conocimiento bién entendido para resolver problemas prácticos

12 Científicos Conocimientos enfocados y especializados Reportan básicamente a sus colegas científicos No necesitan licencia Ingenieros Conocimientos comprobados, efectivos y confiables de ámbito más general Se necesita un amplio entendimiento de todos los factores que intervienen en el desarrollo del producto. Responsabilidad con el publico Generalmente necesitan licencia para ejercer

13 Peculiaridades de la I.S. El producto software es enteramente conceptual. No tiene propiedades físicas como peso, color o voltaje, y en consecuencia no está sujeto a leyes físicas o eléctricas. Su naturaleza conceptual crea una distancia intelectual entre el software y el problema que el software resuelve Dificil para una persona que entiende el problema, entender el sistema software que lo resuleve. Para probar es necesario de un sistema físico.

14 Areas del conocimiento En el ámbito académico, existen 5 áreas de conocimiento y capacidades necesarias para el ingeniero de software: Ciencias de la computación, ingeniería de sistemas y de software. Plataformas específicas de hardware Dominio de conocimiento de la aplicación Habilidades personales, interpersonales y ética. Cultura empresarial.

15 Fases genericas de la I.S. Definición (Qué?) Desarrollo (Cómo?) Soporte (cambios) Corrección Adaptación Mejora Prevención

16 Relacion con otras disciplinas Gestion de proyectos Gestion de la calidad Informatica y tecnologia Ingeniería de software Dominios de las aplicaciones Confiabilidad Seguridad

17 Ingenieria del software: tecnologia estratificada Definicion segun el IEEE La ingenieria de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software

18 La I.S. es una tecnología estratificada Cualquier enfoque de la ingeniería debe estar sustentado en un compromiso con la calidad. La gestión de la calidad Total, Sigma Seis y enfoques similares fomentan una cultura de mejora continua del proceso, y es esta cultura la que al final conduce al desarrollo de enfoques muy efectivos para la I.S.

19 El enfoque de calidad soporta a la I.S. Ingeniería Software Engineering de Software herramientas métodos modelo de proceso enfoque de calidad

20 Modelo de proceso La base de la I.S. es el estrato del proceso. El proceso es el elemento que mantiene juntos los estratos de la tecnologia y que permite el desarrollo racional y a tiempo del software.

21 El proceso del software forma la base para el control de la gestión de los proyectos de software y establece el contexto en el cual se aplican los métodos técnicos, se generan los productos del trabajo (modelos, documentos, datos, reportes, formatos), se establecen los fundamentos, se asegura la calidad, y el cambio se maneja de manera apropiada.

22 Métodos Los métodos de la I.S., proporcionan los cómo técnicos para construir software. Abarcan un amplio espectro de tareas que incluyen la: Comunicación, El análisis de requisitos, El modelado del diseño, La construccion del programa, La realizacion de pruebas, El soporte Los métodos se basan en un conjunto de principios básicos que gobierna cada área de la tecnologia.

23 Herramientas Las herramientas de la I.S., proporcionan el soporte automatizado o semiautomatizado para el proceso y los métodos. Cuando las herramientas se integran de forma que la información que cree una de ellas pueda usarla otra, se dice que se ha establecido un sistema para el soporte del desarrollo del software, que con frecuencia se denomina ingeniería del software asistida por ordenador

24 MARCO DE TRABAJO PARA EL PROCESO Un marco de trabajo establece la base para un proceso de software completo al identificar un numero pequeño de actividades del marco de trabajo aplicables a todos los proyectos de software, sin importar su tamaño y complejidad. Abarca un conjunto de actividades sombrilla aplicables a lo largo del proceso del software.

25 Cada actividad dentro del marco de trabajo contiene un conjunto de acciones de ingeniería del software; es decir, una serie de tareas relacionadas que produce un producto del trabajo en la I.S. (por ejemplo, el diseño es una acción de la I.S.). Cada acción la forman tareas de trabajo individuales que completan alguna parte del trabajo implicado por la acción.

26 Marco de trabajo del proceso de software Marco de trabajo del proceso Actividades sombrilla Actividad del marco de trabajo #1 Accion de la ingenieria de software # 1.1 Conjunto de tareas. Tareas del trabajo Productos del trabajo Puntos de aseguramiento Fundamentos del proyecto Accion de la ingenieria de software # 1.k Conjunto de tareas.. Tareas del trabajo Productos del trabajo Puntos de aseguramiento Fundamentos del proyecto Actividad del marco de trabajo #n Accion de la ingenieria de software # n.1 Tareas del trabajo Conjunto Productos del trabajo de tareas Puntos de aseguramiento. Fundamentos del proyecto Accion de la ingenieria de software # n.m Conjunto Tareas del trabajo Productos del trabajo de tareas Puntos de aseguramiento. Fundamentos del proyecto.

27 Aplicacion del marco de trabajo en proyectos Comunicación. Esta actividad del marco de trabajo implica una intensa colaboración y comunicación con los clientes; además, abarca la investigación de requisitos y otras actividades relacionadas. Planeación. Esta actividad establece un plan para el trabajo de la ingeniería del software. Describe las tareas técnicas que deben realizarse, los riesgos probables, los recursos que serán requeridos, los productos del trabajo que han de producirse y un programa de trabajo. Modelado. Abarca la creación de modelos que permiten al desarrollador y al cliente entender mejor los requisitos del software y el diseño que logrará satisfacerlos.

28 Construcción. Esta actividad combina la generación del codigo (ya sea manual o automatizado) y la realización de pruebas necesarias para descubrir errores en el código. Despliegue. El software (como una entidad completa o un incremento completado de manera parcial) se entrega al cliente, quién evalua el producto recibido y proporciona información basada en su evaluación.

29 Recopilacion de requisitos Ocurre durante la actividad de comunicación, y puede ser: Hacer una lista de los clientes para el proyecto. Invitar a todos los clientes a una reunión informal. Pedir a cada cliente que haga una lista de características y funciones requeridas. Establecer un debate sobre los requisitos y elaborar una lista final. Priorizar los requisitos. Advertir las áreas de incertidumbre.

30 Recopilacion de requisitos para proyecto complejo Hacer una lista de los clientes para el proyecto. Entrevistar a c/u de los clientes, por separado, para determinar de manera general sus deseos y necesidades Elaborar una lista preliminar de las funciones y características basadas en la información que ofrezcan los clientes. Hacer un programa de reuniones para recopilar los requisitos. Conducir las reuniones Producir escenarios informales de los usuarios como parte de cada reunión.

31 Refinar escenarios de los usuarios con base en el intercambio de información con los clientes. Elaborar una lista revisada de los requisitos de los clientes Utilizar técnicas de despliegue de funciones de calidad para jerarquizar los requisitos. Empaquetar los requisitos para que puedan entregarse de manera incremental. Observar las restricciones que serán puestas en el sistema Debatir métodos para validar el sistema.

32 Actividades sombrilla Seguimiento y control del proyecto de software: permite que el equipo de software evalue el progreso comparandolo con el plan del proyecto y así tomar las acciones necesarias para mantener el programa. Gestión de riesgos: evalua los riesgos que pudiera afectar los resultados del proyecto o la calidad del producto. Aseguramiento de la calidad del software: define y conduce las actividades requeridas para asegurar la calidad del software. Revisiones técnicas formales: evalua los productos del trabajo de la I.S., en un esfuerzo encaminado a descubrir y eliminar los errores antes de que éstos se propaguen.

33 Medición: define y recolecta mediciones del proceso, el proyecto y el producto para ayudar al equipo a entregar software que satisfaga las necesidades del cliente. Gestión de la configuración del software: maneja los efectos del cambio a través del proceso del software. Gestión de la reutilización: define los criterios para la reutilización de productos del trabajo (se incluyen componentes del software) y establece mecanismos para la creación de componentes reutilizables. Preparación y producción: abarca las actividades requeridas para crear productos del trabajo como modelos, documentos, registros.

34 INTEGRACION DEL MODELO DE CAPACIDAD DE MADUREZ El instituto de Ingeniería del Software (SEI) ha desarrollado un modelo completo de un amplio proceso basado en un conjunto de capacidades de software y de sistemas que deben estar presentes conforme las organizaciones alcanzan diferentes grados de capacidad y madurez del proceso. Una organización debe crear un modelo de proceso que se ajuste a las directrices establecidas por la integración del modelo de capacidad de madurez (IMCM)

35 El modelo IMCM (integración del modelo de capacidad de madurez), es el modelo más utilizado en la industria del software. Mide la capacidad del proceso para desarrollar software con calidad ad. (predictibilidad en costos, duración, y niveles de calidad previstos)

36 La IMCM representa un modelo completo de proceso en dos formas diferentes: 1.- Como un modelo continuo 2.- Como un modelo discreto PP Planeación del proyecto GR Gestión de requisitos MA Medición y análisis GC Gestión de configuración ACPP Aseguramiento de la calidad del producto y el proceso PP GR MA GC ACPP otros

37 Clasificación de acuerdo con niveles de capacidad Nivel Mejorado Gestionado Definido Características La mejora de procesos es una actividad consistente y establecida en la organización. Se adapta y mejora mediante el uso de medios cuantitativos (estadísticos) Los procesos están estabilizados y existe una gestión cuántitativa. El área de proceso se controla y mejora mediante mediciones y evaluacion cuantitativa. Procesos organizativos, tanto técnicos como de gestión, están claramente definidos. Administrado Realizado incompleto Todos los criterios del nivel han sido satisfechos. Todas las tareas de trabajo y productos estan monitoreados, controlados y revisados y son evaluados. Todas las metas específicas del área del proceso han sido satisfechas. Las tareas de trabajo requeridas han sido realizadas El área de proceso aún no se realiza o todavia no alcanza todas las metas y objetivos definidos para el nivel 1 de capacidad

38 La IMCM define cada área del proceso en función de metas especificas (ME)y de las prácticas especificas (PE) requeridas para alcanzar dichas metas. Las ME establecen las características que deben existir para que las actividades implicadas por un área de proceso sean efectivas. Las PE convierten una meta en un conjunto de actividades relacionadas con el proceso.

39 El modelo discreto de la IMCM define las mismas áreas, metas y prácticas del proceso que el modelo continuo. La principal diferencia es que el modelo discreto establece cinco niveles de madurez, en vez de cinco niveles de capacidad. Para lograr un nivel de madurez se deben conseguir metas y prácticas especificas relacionadas con un conjunto de áreas del proceso.

40 Relacion entre niveles de madurez y las areas del proceso NIVEL De optimizacion Gestionado de modo cuantitativo definido Gestionado Ejecutado ENFOQUE Mejora continua del Proceso Gestion Cuantitativa Estandarizacion Del proceso Gestion basica del Proyecto AREAS DEL PROCESO Innovacion organizacional y despliegue Analisis causal y resolucion Eejecucion del proceso organizacional Gestion cuantitativa del proyecto Desarrollo de requisitos Solucion tecnica Integracion del producto Verificacion Validacion Enfoque del proceso organizacional Capacitacion organizacional Gestion de riesgos Gestion de requisitos Planeacion del proyecto Monitoreo y control del proyecto Gestion de acuerdos del proveedor Medicion y analisis Aseguramiento de calidad del producto y proceso Gestion de la configuracion

41 PATRONES DEL PROCESO El proceso de software puede definirse como una colección de patrones que definen un conjunto de actividades, acciones, tareas de trabajo o comportamientos relacionados que requiere el desarrollo de un software para ordenador. Un patrón de proceso ofrece una plantilla: un método consistente para describir una característica importante del proceso de software. Mediante la combinación de patrones, un equipo de software puede construir un proceso que satisfaga las necesidades de un proyecto.

42 Los patrones pueden definirse en cualquier grado de abstracción. En algunos casos se puede utilizar un patrón para describir un proceso completo (prototipo). En otras situaciones se utilizan los patrones para describir una actividad del marco de trabajo importante (como la plantación) o una tarea dentro de una actividad del marco de trabajo (por ejemplo, la estimación de un proyecto)

43 Plantilla para describir un patron de proceso Nombre del patrón. Al patrón se le asigna un nombre significativo (comunicación con el cliente). Propósito. Se describe con brevedad el objetivo del patrón. Por ejemplo, el objetivo de la comunicación con el cliente es establecer una relación de colaboración con el cliente en un esfuerzo encaminado a definir el alcance del proyecto y requisitos del negocio.

44 Tipo. Se especifica el tipo de patrón. (Ambler) sugiere tres tipos: Los patrones de tarea definen una acción de la I.S., o una tarea de trabajo que es parte del proceso y relevante para una práctica exitosa de la I.S. (por ejemplo, la recopilación de requisitos es un patrón de tarea. Los patrones de escenario, incorpora multiples patrones de tarea relevantes. Un ejemplo, es la comunicación. Los patrones de fase definen la secuencia de actividades del marco de trabajo. Un ejemplo, modelo en espiral o de construcción de prototipos.

45 Contexto inicial. Se describen las condiciones en las cuales se aplica el patrón. Problema. Se describe el problema que debe resolver el patrón. Solución. Se describe la implentacion del patrón. Contexto reultante. Se describen las condiciones que habra una vez que el patrón haya sido implementado con éxito.

46 Patrones relacionados. Se proporciona una lista de todos los patrones de proceso directamente relacionados con este, en forma jerárquica o de alguna otra forma. Usos conocidos/ejemplos. Se indican los ejemplos específicos en los cuales el patron es aplicable.

47 EVALUACION DEL PROCESO La existencia de un proceso de software no es garantía de que este será entregado a tiempo, de que satisfará las necesidades del cliente, o de que mostrara las características técnicas que conducirán a características de calidad a largo plazo. Los patrones de proceso deben ir acompañados de una practica sólida de la I.S.

48 Relacion entre proceso y métodos aplicado para evaluación Proceso del Sw Identifica modificaciones a Es examinado por Evaluacion del Proceso de SW Identifica capacidades y riesgos de Mejoramiento del Conduce a Conduce a Determinacion Proceso de Sw motiva de la capacidad

49 MODELOS DE PROCESO PERSONALES Y EN EQUIPO El mejor proceso de software es el que esta cerca de la gente que realizará el trabajo. Si un modelo de proceso de software ha sido desarrollado en un ámbito corporativo, puede ser efectivo sólo si es en gran medida adaptable para satisfacer las necesidades del equipo del proyecto, que es el que en realidad lleva a cabo el trabajo de I.S.

50 En un escenario ideal, cada ingeniero de software crearía un proceso que llene lo mejor posible sus propias necesidades y al mismo tiempo satisfaga las amplias necesidades del equipo y la organización. De modo alternativo, el equipo mismo crearía su propio proceso, y al mismo tiempo cubriría las necesidades mas reducidas de los individuos y las necesidades amplias de la organización.

51 PROCESO DE SOFTWARE PERSONAL (PSP) El modelo PSP define 5 actividades del marco de trabajo: Planeación. Esta actividad selecciona requisitos y, con base en estos, desarrolla el tamaño y la estimación de recursos. Además, se estiman los defectos. Todas las mediciones se registran en hojas de trabajo o en plantillas. Diseño de alto nivel. Se construyen prototipos. Todos los elementos se registran y rastrean.

52 Revisión del diseño de alto nivel. Los métodos formales de verificación se aplican a errores descubiertos en el diseño. Las mediciones se mantienen para todas las tareas importantes. Desarrollo. El diseño al nivel de componente se refina y revisa. Se genera, revisa, compila y prueba el código. Las mediciones de mantienen. Análisis de resultados. Mediante las mediciones y medidas recolectadas se determina la efectividad del proceso.

53 PROCESO DE SOFTWARE EN EQUIPO (PSE) La meta del PSE es construir un equipo de proyecto autodirigido que se organice para producir software de alta calidad. Humphrey define los siguientes objetivos: Construir equipos autodirigidos que planeen y tengan un seguimiento de su trabajo, establezcan metas y posean sus procesos y planes. Mostrar a los jefes como preparar y motivar a sus equipos y como ayudarlos a sostener un alto desempeño.

54 Acelerar el mejoramiento del proceso de software al realizar, con el comportamiento normal y esperado. Ofrecer una guía de mejoramiento a organizaciones de alta madurez. Facilitar la enseñanza de habilidades de equipo de calidad.

55 El PSE define las siguientes actividades del marco de trabajo: Lanzamiento Diseño de alto nivel Implementación Integración y prueba Análisis de resultados

56 El PSE reconoce que los mejores equipos de software son autodirigidos. Los miembros del equipo plantean los objetivos del proyecto, adaptan el proceso para cubrir sus necesidades, controlan el programa y la medición y el análisis de las medidas recolectadas; además, trabajan de manera continua para mejorar el enfoque del equipo respecto de la I.S.

57 Si el proceso es debil, el producto final sufrira las consecuencias Un profesional del software creativo debe sentir tanta satisfacción del proceso como del producto terminado. El trabajo que realiza la gente de software cambiara en los años que siguen. La dualidad del producto y el proceso es un elemento importante para mantener a la gente creativa comprometida mientras finaliza la transición desde la programación hasta la Ingeniería de Software.