Resumen swebok original
Upcoming SlideShare
Loading in...5
×
 

Resumen swebok original

on

  • 18,700 views

Un Resumen de la propuesta de la IEEE sobre la ingeniería del software y sus áreas de conocimiento.

Un Resumen de la propuesta de la IEEE sobre la ingeniería del software y sus áreas de conocimiento.

Statistics

Views

Total Views
18,700
Slideshare-icon Views on SlideShare
18,667
Embed Views
33

Actions

Likes
8
Downloads
1,380
Comments
0

4 Embeds 33

http://faccilearn.uleam.edu.ec 24
http://isumanizales.wikispaces.com 6
https://twitter.com 2
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Resumen swebok original Resumen swebok original Document Transcript

    • 1 GUIA DE LA INGENIERIA DEL SOFTWARE CUERPO DE CONOCIMIENTO VERSION 2004 EDICION IEEE CAROLINA HENAO ACOSTA JUAN PABLO ORTIZ VILLEGAS UNIVERSIDAD CATOLICA POPULAR DEL RISARALDA FACULTAD DE CIENCIAS BASICAS E INGENIERIA PEREIRA NOVIEMBRE 24 DE 2009
    • 2 CAPITULO 1 INTRODUCCION A LA GUIA Esta guía inicia con una amplia y completa introducción sobre el concepto de Ingeniería del Software, desde la óptica de los miembros de la IEEE. La definen como una ciencia relativamente nueva y con reconocimiento en el área de Ingeniería. La reconoce como una disciplina crucial para la evolución de la industria de software a nivel mundial y la define como la aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento de software. Una profesión para ser reconocida como tal debe cumplir con un cuerpo de conocimiento basado en tres aspectos, desde el punto de vista académico, moral y cognitivo: 1. Que el conocimiento y las competencias de la profesión, sean validadas por profesionales de la misma área. 2. Que el conocimiento sea validado desde la base racional y con fundamento científico 3. Que el juicio del profesional se enfoque hacia el asesoramiento en el área de estudio Esta guía no debe ser confundida con el cuerpo de conocimiento de la Ingeniería del Software. La finalidad de SWEBOK (Guía de la Ingeniería del Software Cuerpo de Conocimiento) es describir que parte de éste es aceptado de manera general y se estableció con el fin de cumplir cinco objetivos: 1. Promover una vista general y consistente de la ingeniería del software a nivel mundial. 2. Dar claridad del contexto en el que se aplica la ingeniería del software con respecto a otras disciplinas, como la ingeniería de sistemas, la ciencia de los computadores, la administración de proyectos y las matemáticas. 3. Caracterizar los contenidos de esta disciplina. 4. Proveer acceso temático al cuerpo de conocimiento de la ingeniería del software. 5. Proveer la fundación de un ente para apoyar el desarrollo, certificación y licenciamiento de material de calidad, relacionado con la disciplina. Está estructurada en 12 capítulos completamente divididos en subcapítulos, que explican todos los componentes del cuerpo de conocimiento de la ingeniería del software, basados en áreas del conocimiento, esquematizadas en los siguientes gráficos:
    • 3
    • 4
    • 5 CAPITULO 2 REQUERIMIENTOS DE SOFTWARE El área del conocimiento de los requisitos de software (KA), se refiere al análisis, especificación y validación de los requisitos de software. Se ha demostrado ampliamente que el hecho de no realizar bien este proceso trae consecuencias fatales en el desarrollo de cualquier producto de software. 1. Fundamentos Un requisito de software es una característica que se debe exhibir para solucionar un cierto problema en el mundo real. Se convierte en una combinación compleja de requisitos entregados por parte de los usuarios implicados dentro del desarrollo de la solución, teniendo en cuenta que pueden corresponder a diferentes niveles jerárquicos, ambientes e intereses. Es importante también que cada requisito sea comprobable, pensando también en las implicaciones que esto puede conllevar. Se pueden clasificar de la siguiente manera:  Requisitos de Producto Se refiere a generar los parámetros del problema a solucionar para ser traducido a un software.  Requisitos de Proceso Se refiere ya a la parte técnica y a lo que voy a utilizar para realizar el software (lenguaje de programación, por ejemplo).  Requisitos Funcionales Son las capacidades o funciones del software.  Requisitos No Funcionales Son los que actúan para obligar a llegar a la solución pero no son parte integral del software.  Características Inesperadas Son requisitos que se toman pero no pueden comprobarse hasta que esté funcionando el software en condiciones reales.  Requisitos del Sistema y de Software
    • 6 Se refiere a todo lo que necesita el software para funcionar desde el punto de vista de hardware, software, recurso humano, información, instalaciones, servicios, etc. Los requisitos de software se derivan de los del sistema. 2. Proceso de los requisitos Inicia de manera aislada y se va refinando con el modelo de ciclo de vida del software y necesita ser adaptado a la organización y al contexto del proyecto.  Agentes de Proceso Incluye a todas las personas, usuarias o no, que participan en el desarrollo del proyecto. Es un grupo interdisciplinario que aporta información para la construcción del software. Pueden ser usuarios, clientes, analistas de mercado, reguladores, ingenieros de software, etc.  Ayuda y Gerencia de Proceso Se refiere a toda la parte presupuestal y de gerencia para llevar a cabo el proyecto.  Calidad y Mejora de Proceso Se refiere al coste generado por control de calidad y a los niveles de cumplimiento para lograr el objetivo principal y por ende, la satisfacción del cliente. 3. Captura de los Requisitos Se refiere al “cómo” se van a recolectar los requisitos por parte del ingeniero de software. Es aquí donde es clave la comunicación con el cliente y con todas las personas implicadas en el proceso.  Fuentes de los Requisitos Deben ser confiables y sometidas a verificación para confirmar que la persona que suministra la información es idónea para hacerlo y que se tomó el tiempo para analizar su conveniencia. No solo por idoneidad sino porque en ocasiones los usuarios no son buenos escribiendo y no son claros a la hora de hacer una solicitud.  Técnicas de Captura de Requisitos A menudo, el ingeniero de software utiliza técnicas de captura de requisitos, tales como: • Entrevistas • Prototipos
    • 7 • Reuniones • Observación 4. Análisis de Requisitos Es una auditoría a todo lo que se recopiló. De aquí salen los requisitos del sistema y por ende los de software. Permite establecer limitaciones y viabilidad del proyecto.  Clasificación de los requisitos Pueden clasificarse en: • Funcionales o no funcionales • De producto o de proceso • Derivado • Prioritario • Estable o Volátil  Modelo Conceptual Se debe elegir un modelo conceptual que ayude a entender de una mejor manera el problema. Es una habilidad con la que debe contar el ingeniero de software, apoyado en herramientas que le ayuden a contextualizar el software, como el caso de UML o el uso de la matemática discreta. La IEEE tiene tres estándares para el modelado. Estos son: IEEE Std 1320.1 (conceptual) IDEF0 (funcional) IEE Std 1320.2, IDEF1X97 (de información)  Asignación Arquitectónica del Diseño y los Requisitos
    • 8 Es la fusión de toda la parte de requisitos con la parte de diseño. Es inseparable esta combinación; una es parte integral de la otra y es fácil su comprensión, apoyándose en el modelo conceptual. El estándar IEEE Std 1471-2000 puede servir de apoyo en esta práctica.  Negociación de los requisitos Se llega a esta etapa cuando hay incompatibilidad en dos o más requisitos y los solicitantes son distintos. El ingeniero de software debe reunirlos y tomar la decisión más conveniente para el correcto funcionamiento de la solución. 5. Especificación de Requisitos Se refiere a plasmar en un documento todos los requisitos aprobados. Someterlos a verificación por parte de los actores del proyecto. Es usual que se hagan tres documentos: • Definición del sistema o documento de exigencias • Requisitos de sistema • Requisitos de software Es importante esta parte porque sin aprobar alguno o todos los documentos, es imposible pasar a la etapa de diseño. El estándar IEEE Std 830 [IEEE830-98], apoya este proceso de especificación de requisitos. 6. Validación de los Requisitos Su objetivo es determinar que los documentos realizados sean comprensibles y de acuerdo a los estándares determinados. Por esto, deben someterse a una auditoría final realizada por todo el personal implicado en el desarrollo del software (cliente), para asegurarse de que lo plasmado allí es lo que se solicitó.  Revisiones de los requisitos Se nombra un comité revisor, que incluye a un representante del cliente, con el fin de evaluar los documentos ya mencionados. El estándar IEEE Std 1028 proporciona ayuda valiosa en la tarea de revisión.  Prototipado
    • 9 Es un medio que utiliza el ingeniero de software para manifestar lo que entendió y para facilitar la corrección, eliminación o adición de requisitos. Como se evidencia, la ventaja de hacerlo es grande pero el costo puede ser alto.  Pruebas de Aceptación Son aquellas que se le aplican a cada requisito para determinar si el producto final lo satisface o no. Debe haber total planeación para aplicar estas pruebas y hacerlo de manera cuantitativa. Como conclusión para este capítulo puede afirmarse que los requisitos de software deben tomarse como una práctica seria, asignándole el tiempo y los recursos necesarios que permitan continuar con un proceso ordenado para llegar a obtener un software de calidad.
    • 10 CAPITULO 3 DISEÑO DE SOFTWARE Es definido por la IEEE como el proceso para definir la arquitectura, los componentes, las interfaces y otras características de un sistema. Visto como proceso, el diseño del software es la actividad del ciclo de vida en la cual se analizan los requisitos del software para producir una descripción de su estructura interna que servirá como base para su construcción. 1. Fundamentos  Proceso de diseño de software Se divide en dos etapas: • Diseño Arquitectónico Descompone el software en componentes y describe sus partes a nivel general, de estructura. • Diseño Detallado Describe el comportamiento específico de estos componentes. Existen técnicas permisibles que permiten hacer un acercamiento al diseño de software. Estas son algunas: • Abstracción Es el proceso de olvidarse de la información para poder tratar las cosas que son diferentes como si fueran iguales. • Acoplador y Cohesión
    • 11 El acoplador es la fuerza de las relaciones entre los módulos y la cohesión se refiere a la relación que existe entre estos módulos. • Descomposición y Modularización Esta técnica se utiliza para poner diversas funcionalidades en componentes más pequeños. • Encapsulación Permite empaquetar información y hacerla invisible. El éxito está en darle una buena función a esa información. El siguiente gráfico muestra la descomposición del proceso de diseño de software. • Separación de la interfaz y de la puesta en práctica Define un componente a través de su interfaz gráfica. • Desahogo Asegura que la abstracción se hizo de manera correcta y que sólo se tomó lo relevante del componente.
    • 12 2. Cuestiones claves del diseño de software Contribuye a entender cómo dividir, organizar y constituir los paquetes de software. Se ayuda con las siguientes llaves:  Concurrencia Se refiere a cómo descomponer el software en procesos, tareas, hilos de reparto y que conserve la sincronización en los procesos.  Distribución de Componentes Como integrar cada parte del software con el hardware necesario para su funcionamiento.  Dirección del Error y de Excepción y Tolerancia a Fallos Define las técnicas para prevenir y tolerar fallos en el momento en que se presenten.  Interacción y Presentación Se refiere a la forma de mostrar y organizar las interacciones con los usuarios y la forma de documentarlas. 3. Estructura y Arquitectura de Software Es una descripción de los subsistemas y de los componentes de un sistema de software y de las relaciones entre ellos. 4. Análisis y Evaluación de la Calidad del Diseño de Software Esta parte es importante porque asegura la calidad del proceso de diseño. Se utilizan métricas que permiten estimar de manera cuantitativa varios aspectos del tamaño, estructura o de la misma calidad del software. Estas pueden ser estructuradas u orientadas a objetos. 5. Notaciones del Diseño de Software Generalmente son gráficas y permiten modelar en un diagrama la propuesta de diseño. Entre ellos están los diagramas de clases y objetos, de componentes, de despliegue, de entidad-relación, de estructura de Jackson, de estructura de cartas y diferentes lenguajes que permiten describir la arquitectura del software y sus componentes.
    • 13 También existe la notación para las descripciones de comportamiento dinámico del software, en las cuales también se usan diagramas y lenguajes textuales. Entre ellos están los diagramas de actividad, de colaboración, organigrama de datos, tablas y diagramas de decisión, de secuencia, de transición de estado y diagramas de estado de carta, lenguajes de diseño en pseudocódigo, etc. 6. Estrategias y Métodos del Diseño de Software Permiten dirigir el proceso de diseño. La estrategia está en términos generales y los métodos deben ser específicos. Aquí se inicia la aplicación del paradigma Divide y Vencerás y el proceso de refinamiento. Se define también si se va a utilizar el diseño estructurado u orientado a objetos o basado en componentes. CAPITULO 4 CONSTRUCCION DEL SOFTWARE Este capítulo hace referencia a la creación detallada de software operativo y significativo, por medio de una combinación de codificación, verificación, pruebas unitarias, pruebas de integración y depuración. El Área de Conocimiento de la Construcción del Software está vinculada a todas las otras KAs (Áreas de Conocimiento), más fuertemente al Diseño del Software y a las Pruebas del Software. Esto se debe a que el proceso mismo de construcción del software cubre tanto el diseño significativo de software como las actividades de pruebas. En síntesis, esta es la etapa de creación del código fuente que tendrá el software. 1. Fundamentos La construcción del software tiene como objetivos los siguientes: Minimizar la complejidad Anticiparse a los cambios Construir para verificar Aplicación de estándares en la construcción La descomposición de los temas de Construcción del Software se detallan en el siguiente gráfico:
    • 14 2. Gestión de la Construcción  Modelos de Construcción Los más conocidos y utilizados son los modelos de ciclo de vida en cascada y de entrega por etapas. Estos modelos son robustos pero solo son eficientes si se ha hecho un buen trabajo en la etapa de requisitos y de diseño. Por el contrario, los modelos prototipado evolucionista, programación extrema y “Scrum”, son más flexibles en este tema, dado que son iterativos y permiten, de manera cíclica, realizar cambios, al combinar las tres etapas iniciales del desarrollo de un proyecto de software.  Planificación de la Construcción En todo proyecto, la planificación es vital. Es aquí donde se delimita la aplicación de requisitos, en qué orden se irán tomando y que grado de cumplimiento tienen, con respecto al objetivo principal del proyecto. De ahí la importancia de elegir un modelo de ciclo de vida acorde a los requerimientos.  Medición de la Construcción Se refiere a los procedimientos utilizados para medir la eficiencia del código fuente, en lo que se refiere a extensión, código reutilizado, código destruido, complejidad de código, estadísticas de inspección de código, tasas de rectificación y corrección de errores y los horarios. Esto asegura el control de la calidad. 3. Consideraciones Prácticas
    • 15 Para solucionar un problema de la vida real a través de un software, es totalmente necesario utilizar un lenguaje de programación. Aquí radica el éxito del proyecto de software, dado que es el ingeniero de software el encargado de aprobar el lenguaje a través de los argumentos dados por los encargados de la elaboración del código fuente.  Lenguajes de Construcción Son todos los tipos de comunicación mediante los cuales un ser humano puede especificar una solución ejecutable para un problema de un ordenador. Pueden ser de configuración, de herramientas y de programación. Estos últimos, a su vez, están divididos en lingüísticos, formales y visuales.  Pruebas de Construcción Generalmente son realizadas por el profesional que realizó el código. Pueden ser unitarias o de integración. Su propósito es reducir el tiempo entre el ingreso de fallas en el código y el tiempo que se puede demorar su detección. Para tal fin, las normas estándar IEEE Std 829-1998 para documentación de pruebas y la IEE Std 1008-1987 para pruebas unitarias, pueden ser de gran utilidad.  Reutilización Definir de manera objetiva, que parte del código puede ser eficientemente reutilizado para minimizar tiempos de entrega, además debe ser reportado a las personas que lideran el proyecto, por qué y para que se va a reutilizar, ya que esto puede modificar el valor del proyecto, por ejemplo.  Calidad de la Construcción Existen varias técnicas para evaluar la calidad en la construcción del código fuente de un proyecto de software. Entre ellas tenemos:  Las pruebas unitarias y de integración El código paso a paso Utilización de aserciones Depuración Revisiones técnicas Análisis estático  Integración Una parte clave del proceso de construcción es la integración de las clases, componentes, rutinas, subsistemas que han sido construidos por separado, sobre todo si hay implicaciones técnicas de software o hardware.
    • 16 CAPITULO 5 PRUEBAS DEL SOFTWARE Es una actividad que permite evaluar y mejorar la calidad del producto con el fin de detectar fallas y corregir errores. Las pruebas del software consisten en verificar el comportamiento de un programa dinámicamente a través de un grupo finito de casos de prueba, debidamente seleccionados. Se ha ido cambiando la percepción de que las pruebas de software se realizan únicamente al final del proceso de creación de código fuente, siendo muy útil hacerlo en todas las etapas del desarrollo del software; esto permite corregir errores y detectar fallas de fondo, a tiempo. En la figura que sigue se pueden apreciar las partes que intervienen en le proceso de pruebas de software.
    • 17 CAPITULO 6 MANTENIMIENTO DE SOFTWARE INTRODUCCION El proceso de desarrollo de software debe satisfacer los requerimientos planteados, una vez en operación el proceso de cubrimiento de defectos, operación y cambio de ambiente debe darse en esta etapa, la fase de mantenimiento empieza con un periodo de garantía y de soporte post- implementación pero el mantenimiento del software ocurre mucho antes. Aunque la etapa de mantenimiento del software no ha tenido el grado de atención que se debe este tipo de desarrollo de software ya esta empezando a cambiar ya que muchos errores graves han ocurrido por no prestarle la atención que se merece.
    • 18 El mantenimiento de software se ha definido como el número total de actividades requeridas para proveer soporte efectivo al software, esto incluye un planeamiento efectivo antes. Durante y después de la implementación del software. 1. Aspectos Fundamentales en el mantenimiento del software: Aquí se introduce a los aspectos fundamentales del mantenimiento del software: 1.1 Definiciones y terminología: Está definido en el estándar de la IEEE 1219 como la modificación del producto de software después de la entrega para corregir las faltas, también se encarga de direccionar las actividades de mantenimiento para darle prioridad a la entrega del producto. El estándar IEEE/EIA 12207 define el mantenimiento como uno de los procesos principales en el ciclo de vida del software, el objetivo es modificar el software existente preservando su integridad también lo hacen en estos mismos términos la ISO/IEC 14764 este enfatiza en las entregas previas para la planeación del mantenimiento del software. 1.2 Naturaleza del mantenimiento: El mantenimiento de software debe estar dentro del ciclo de vida operacional, un mantenimiento esta definido por la IEEE/EIA 12207 como las actividades de mantenimiento que permiten el desempeño correcto. Identifica las actividades de mantenimiento como un proceso de implementación y modificación y análisis del problema, estas actividades son discutidas en el tópico 3.2 Actividades de Mantenimiento.
    • 19 Figura 1. Tópicos a tener en cuenta en el mantenimiento del software 1.3 Necesidad de mantenimiento: La necesidad de mantenimiento se da para garantizar que el software cumple satisfactoriamente con los requerimientos solicitados, este se aplica a cualquier desarrollo independiente del modelo de ciclo de vida utilizado, el mantenimiento se da en orden de alcanzar el desempeño adecuado y en el orden de: • Corregir fallas. • Improvisar el diseño. • Implementar correcciones. • Interfaces con otros sistemas.
    • 20 • Adaptar programas a diferentes tipos de hardware, software, configuración del sistema y facilidad de uso de telecomunicaciones. • Migración legal de software. • Retiro de software. 1.4 Costos Mayoritarios de mantenimiento: Los costos de mantenimiento de software son los mas costosos en todo el ciclo de vida del software, estudios recientes han demostrado que más del 80% del mantenimiento de software es usado para acciones correctivas hay que entender la categoría del mantenimiento del software para entender la estructura del costo de mantenimiento, entendiendo los factores que influyen en el costo se puede ayudar a contener dichos costos, a continuación se presentan algunos aspectos técnicos y no técnicos que afectan los costos de mantenimiento: • Tipo de Aplicación. • Disponibilidad del mantenimiento de software. • Ciclo de vida del software. • Características de hardware. • Calidad del diseño de software, construcción, documentación y pruebas. 1.5 Evolución del software: En 1969 Lehman direcciono el mantenimiento del software y la evolución de los sistemas, durante 20 años se mantuvo su idea de la formulación de ocho “Leyes de la evolución” donde se mantuvo la idea de la evolución en el mantenimiento del software para continuar con el desarrollo. Lientz y Swanson inicializaron la definición de tres categorías de mantenimiento: correctivo, adaptativo y perfectivo.
    • 21 2. Factores claves en el mantenimiento del software: Un numero de factores claves debemos tener presentes para asegurar el mantenimiento efectivo del software, es importante comprender que el mantenimiento de software nos proporciona una técnica única en los desafíos de administración para los ingenieros de software, podemos apreciar como se planean las liberaciones posteriores así como los parches generados para las versiones anteriores, lo que sigue a continuación nos presenta una manera de cómo se nos presentan algunos factores de administración y técnicos para el mantenimiento de software, estos se agrupan según los tópicos siguientes: • Factores técnicos. • Factores administrativos. • Estimación de costos. • Medidas. 3. Proceso de mantenimiento: Provee referencias y estándares utilizados para implementar el proceso de mantenimiento de software. Las actividades de mantenimiento son diferenciadas por el desarrollo mostrado en la relación a las actividades de ingeniería de otro software.
    • 22 Figura 2. Actividades en el proceso del mantenimiento En la figura planteada por la ISO/IEC se puede apreciar que es muy parecida a la anterior que es IEEE pero en esta se agrega una pequeña diferencia: Cada actividad de mantenimiento primario de software ISO/IEC 14764 es desglosada en los siguientes términos: • Proceso de implementación. • Análisis del problema y modificaciones. • Implementación y modificación. • Mantenimiento Aceptación/Revisión.
    • 23 • Migración. • Retiro de Software. Técnicas para el mantenimiento: Esta subárea nos introduce a algunas generalidades aceptadas por las técnicas del mantenimiento de software: 3.1 Comprensión del programa Los programadores gastan tiempo considerable leyendo y entendiendo programas para poder implementar cambios existen distintas herramientas que nos ayudan con este proceso. 3.2 Reingeniería Esta definida como el examen de de la alteración del software para reconstituir una nueva forma, la reingeniería es la mas radical y expansiva forma de la alteración otros creen que la reingeniería puede ser usada para cambios menores, siempre está enfocada en mantener la legalidad del software asi como sus técnicas, casos de estudio y sus riesgos y beneficios. 3.3 Ingeniería inversa Es el proceso de analizar el software para identificar los componentes y sus relaciones para crear representaciones del software dicho de otra forma desde un nivel mas alto de abstracción, es pasiva, y no hace cambios al software o resulta en otro software. Produce gráficas asi como control de flujo y del código fuente, un tipo de reingeniería puede ser la redocumentación, otro tipo es la reparación del diseño. Finalmente la reingeniería ha sido de gran importancia en los últimos años ya que gracias a sus esquemas lógicos a podido restaurar bases de datos físicas. CAPITULO 7 ADMINISTRACION DE LA CONFIGURACION DEL SOFTWARE
    • 24 Un sistema puede ser definido como un conjunto de componentes organizados con el propósito de cumplir una función o conjunto de funciones específicas. En este sentido la configuración de un software y sus características funcionales de hardware, software, firmware o la combinación de estas son un conjunto de características técnicas que se deben cumplir para garantizar su correcto funcionamiento. La administración de configuración es la disciplina encargada de identificar la configuración general de un sistema para así mantener su confiabilidad, adaptabilidad y configuración a los diferentes ciclos de vida. Está formalmente definida por la IEEE610.12-90 como “Disciplina aplicada de manera técnica y administrativa para la dirección y supervivencia para: Identificar y documentar las características físicas y funcionales de la configuración de los elementos, control en el cambio de sus características grabar y reportar cambios en el proceso de implementación así como su estado y verificación del cumplimiento de sus requerimientos específicos”. 1. Administración de los procesos SCM
    • 25 La SCM administra y controla la evolución e integridad del software así como su verificación, control, reportes y configuración de la información. Una implementación exitosa del SCM requiere un cuidado especial y planeación y administración. 1.1 Contexto Organizacional del SCM Para desarrollar un plan SCM es necesario conocer detalladamente los procesos de la organización ya que el SCM interactúa directamente con todos los elementos y actividades organizacionales. 1.2 Constantes y guía para el proceso SCM Esto proviene de un gran numero de fuentes tiene que ver con las políticas de la organización y su influencia en la administración de los procesos. 1.3 Planeación del SCM El proceso de planeación debe ser consistente con el contexto organizacional, y la naturaleza del proyecto (por ejemplo el tamaño y su crítica) las actividades más importantes en este contexto son: control de configuración, control de estado, control de auditoría, control de liberaciones y entregas así como las herramientas de configuración y control y sus interfaces consideradas. 1.4 Plan de la SCM Los resultados de planeación del proyecto son guardados en un plan de gestión y configuración del software, el documento se mantiene y se actualiza o aprueba según sea necesario a lo largo del ciclo de vida del software. También es muy útil hacer mediciones constantes a los procesos para hacer los cambios y/o actualizaciones correspondientes.
    • 26 1.5 Seguimiento de la gestión de la configuración del software Después del cumplimiento del proceso de la SCM puede ser necesario un cierto nivel de seguimiento para asegurarse que los procesos SCM se llevan a cabo adecuadamente, este seguimiento puede hacer parte de un proceso de auditoría para garantizar la calidad del software. El uso de herramientas integradas en la SCM facilita el proceso de seguimiento. 1.5.1 Medidas y mediciones de la SCM Proporcionan un buen medio para monitorizar la efectividad de las actividades SCM de una manera continuada, son útiles para caracterizar el estado actual del proceso y para proporcionar una base para hacer comparaciones con el tiempo. Las bibliotecas de software y las diferentes herramientas proporcionan fuentes para extraer la información acerca de las características de los procesos SCM. 2. Identificación de la configuración del software Identifica los elementos a ser controlados, establece e identifica esquemas y sus versiones, establece herramientas y técnicas utilizadas para administrar y controlar dichos elementos. 2.1 Identificar elementos a ser controlados Un primer paso sería identificar cambios en los elementos de software que serán controlados para entender la configuración del software en el contexto del sistema.
    • 27 2.2 Biblioteca de software Colección controlada de software así como de sus documentos relacionados y está relacionada para ayudar en el desarrollo de software, ahí diferentes tipos y nos pueden ayudar en diferentes etapas, son también una fuente importante de información para mediciones del trabajo realizado y del progreso. 3. Control de la configuración del software Le concierne la gestión de cambios durante el ciclo de vida, cubre los procesos que determinan los cambios a realizar, la autoridad para hacerlos y el soporte para la implementación de dichos cambios. La información derivada de estas actividades es útil para medir el tráfico de cambios y ruptura de aspectos por rehacer. 3.1 Petición, evaluación y aprobación de cambios del software El primer paso es determinar los cambios a realizar, se evalúa el coste e impacto del cambio propuesto se acepta o rechaza dicho cambio, este se origina en cualquier momento del ciclo de vida y puede incluir una solución propuesta y una prioridad. 3.2 Implementando cambios en el software Se implementan utilizando los procesos de software definidos de acuerdo con los requerimientos de planificación aplicables. Podrían sufrir auditorías de configuración y verificación de la calidad del software. Esta soportada por las herramientas de la biblioteca que proporcionan gestión de versiones y soporte para el almacenamiento de código.
    • 28 3.3 Desviaciones y Remisiones Las limitaciones que se imponen al esfuerzo de la ingeniería del software podrían contener necesidades que no pueden ser satisfechas en el punto designado del ciclo de vida. Una remisión es una autorización para abandonar una necesidad antes del desarrollo del elemento. 4. Registro del estado de la configuración del Software La contabilidad del estado de la configuración del software (SCSA) es la actividad de registrar y proporcionar la información necesaria para una gestión efectiva de la configuración del software. 4.1 Información del estado de la configuración del software Genera un conjunto de informes durante el ciclo de vida, se encarga de recoger y mantener la información del estado de la configuración que se ha de gestionar según las configuraciones evolucionan. Es necesario algún tipo de soporte de herramientas automáticas para llevar a cabo las tareas de recogida de datos y generación de informes de la SCSA. 4.2 Reportes del estado de la configuración del software Los reportes pueden ser usados para los elementos del proyecto de la organización, incluyendo el equipo de desarrollo, administración de proyectos y actividades de calidad del software. También sirve para responder algunas preguntas específicas de la etapa de producción.
    • 29 5. Auditoría de la configuración de software Es una actividad desarrollada independientemente para evaluar la conformidad de los productos de software, se encarga de aplicar regulaciones, estándares, planes de guía y procedimientos. Deben ser cuidadosamente planeadas, existen herramientas que apoyan la planeación y conducción de las auditorías para facilitar su proceso. Determina la extensibilidad de los elementos y sus características físicas, los informes pueden ser orientados como puntos clave en el ciclo de vida, las auditorias pueden ser un requisito para las líneas base. 5.1 Auditoria funcional de la configuración del software El propósito es asegurar la consistencia en los elementos de software auditados. La salida de la verificación y validación del software es la clave de entrada de este tipo de auditoría. 5.2 Auditoría de la configuración física del software El propósito es asegurar que el diseño y la documentación de referencia es consistente con la construcción del producto de software. 5.3 Auditoría durante el proceso de una línea base de software Como lo mencionado puede ser llevado durante el proceso de desarrollo para investigar el estado actual de los elementos específicos de la configuración. La auditoría es aplicada a los elementos de la línea base para asegurar el desempeño que sea consistente con las especificaciones. 6. Administración de las entregas y liberaciones de software
    • 30 El término “liberación” es usado en este contexto para referirnos a las distribuciones de software y los elementos en las actividades de desarrollo. Eso incluye liberaciones internas y correcciones a las variantes de estos elementos. La información y documentación entregada en las liberaciones es conocida como el documento descriptivo, este incluye los contenidos de instalación y instrucciones de actualización. CAPITULO 8 GESTION DE LA INGENIERIA DEL SOFTWARE Puede ser definida como las actividades de gestión de la aplicación, planeación, coordinación, medición, monitorización, control y reportes para asegurar el desarrollo y mantenimiento del software como sistemático, disciplinado y cuantificable. Es un aspecto muy importante en la administración y medición de la ingeniería del software. En estas actividades se destacan tres niveles: Gestión y organización de la infraestructura, gestión de proyectos, y control y planeación del programa de medidas. Los aspectos de la gestión de la organización son importantes en términos del impacto en la ingeniería del software y en las políticas de gestión, esas políticas pueden ser influenciadas por los requerimientos de un software efectivo, mantenimiento y desarrollo. Un número de políticas específicas deben ser establecidos para una efectiva gestión en la ingeniería del software y el nivel organizacional.
    • 31 Haciendo gestión con énfasis en la medición y un principio de presupuesto en cualquier disciplina de verdadera ingeniería puede ayudar a darle la vuelta a esta percepción. Una gestión eficaz requiere la combinación tanto de números como de experiencia. La gestión en la ingeniería del software se descompone en seis subáreas principales a continuación se da un espacio detallado de cada una.
    • 32 1. Iniciación y Alcance Se centra en la determinación eficaz de los requisitos del software por medio de varios métodos de inducción y la valoración de la viabilidad del proyecto desde distintos puntos de vista, una vez establecida la viabilidad, la tarea pendiente es la especificación de la validación de requisitos y del cambio de procedimientos.
    • 33 2. Planificación de un Proyecto de Software Esta regulado por los alcances y los requisitos y por la viabilidad del proyecto, se evalúan los procesos de ciclo de vida y se selecciona el más apropiado. Se debe realizar una descomposición jerárquica de tareas, y la realización de un calendario y una estimación de costos. Más adelante se le da un presupuesto a las tareas y la imposición de horarios y uso de materiales, se debe llegar a la determinación de procesos y responsabilidades para asegurar la calidad del software, verificación, validación y revisiones de auditorías. 2.1 Planificación de un Proceso La selección de un modelo de ciclo de vida o la adaptación de un despliegue de ciclos se emprenden a la luz del alcance particular y de los requisitos del proyecto. También se seleccionan métodos y herramientas pertinentes. 2.2 Determinar los entregables Se especifica y caracteriza los productos de cada tarea, se evalúa la posibilidad de reutilizar componentes de desarrollos anteriores y se planifica la utilización de terceras personas y del software obtenido y se seleccionan los proveedores. 2.3 Esfuerzo, calendario y cálculo del coste Se determina el rango de esfuerzo esperado, utilizando un modelo de estimación calibrado, basado en datos históricos sobre el esfuerzo empleado. Cuando sea posible se solucionan cuellos de botella, y se elabora el esperado cuadro de tareas con los horarios de inicio, duraciones y horarios de finalización bien planificados. Los requisitos de recursos (personas, herramientas) se traducen en estimaciones de costo.
    • 34 2.4 Reparto de recursos Los equipos, medios y personas se asocian a las tareas programadas, esta actividad está regulada y limitada por la disponibilidad de los recursos y su uso óptimo bajo estas circunstancias. 2.5 Gestión de Riesgos Se completa el análisis de riesgos, la valoración crítica de riesgos, la mitigación de riesgos y la planificación de contingencias. Los métodos para la valoración del riesgo deben utilizarse para resaltar y evaluar riesgos, en esta etapa se deben evaluar las posibilidades de abandono del proyecto en conversaciones con todos los contratistas. 2.6 Gestión de calidad Se define en términos de atributos pertinentes del proyecto y en los de cualquier producto asociado a él, tanto en términos cualitativos como cuantitativos. Los límites de adhesión de calidad se colocan de acuerdo a las expectativas que tenga el contratista sobre el software en cuestión así como los procedimientos de verificación y validación del producto entregable. 2.7 Gestión de planes Los informes, la supervisión y el control del proyecto deben encajar en el proyecto de ingeniería del software seleccionado y en las realidades del proyecto y deben reflejarse los artefactos que lo gestionarán. Los cambios a otros procesos de soporte ejemplo: gestión documental, resolución de problemas también deben gestionarse de la misma manera. 3. Promulgación del proyecto de Software
    • 35 Se ejecutan los planes y se divulgan los procesos incluidos en los planes, en este proceso hay total expectativa de la adhesión plena de los requisitos del contratista y el logro de los objetivos del proyecto, son actividades fundamentales para la promulgación la gestión, medición, supervisión, control e información del proyecto. 4. Revisión y Evaluación Se evalúa el proceso global hacia el logro de los objetivos y satisfacción de los requisitos del contratista y se llevan a cabo valoraciones sobre la efectividad del proceso global hasta la fecha, del personal involucrado y de las herramientas y métodos utilizados. 4.1 Determinar la satisfacción de los requisitos Determinar que el objetivo principal se está cumpliendo es primordial ya que lo que nos interesa es la satisfacción del usuario o contratista esto se debe hacer periódicamente. Se deben identificar las variaciones a las expectativas para llevar a cabo las acciones adecuadas. También se debe gestionar el control de cambios a los procedimientos y a la configuración del software. 4.2 Revisar y Evaluar la Ejecución Las revisiones periódicas a lo realizado nos proporcionan detalles sobre la probabilidad de ser fiel a los planes, así como las posibles áreas de dificultad, aquí se evalúan los diferentes métodos, herramientas y técnicas empleadas para ver su eficacia y adecuación y se evalúa constantemente la eficacia de los procesos para ver su utilidad en el contexto del proyecto, cuando sea necesario se gestionan y se llevan a cabo los cambios.
    • 36 5. Cierre El proyecto llega a su fin cuando todos los planes y procesos implicados se han promulgado y completado, en esta fase se repasan ciertos criterios para el éxito del proyecto. Se han entregado los procesos tal como se habían especificado y todos los productos planificados han sido entregados con características aceptables. 5.1 Determinar el cierre Se logran los objetivos del proyecto y estos procesos por lo general involucran a los contratistas y acaban con la documentación y de los informes de cualquier otro problema pendiente conocido. 5.2 Actividades de cierre Se archivan los materiales del proyecto y la base de datos de medición de la organización se pone al día con los datos finales del proyecto y se emprende el análisis post-proyecto. Se hace con el fin de identificar temas. Problemas y oportunidades encontrados durante el proceso, se sacan las lecciones del proceso y luego se alimentan los conocimientos de la organización y los intentos de mejora. 6. Medidas de la ingeniería del software Aquí abordamos el tema de la medición en la ingeniería del software y su importancia para esto se sigue unas métricas y normas establecidas por entidades como la ISO y la IEEE. 6.1 Establecer y sostener el compromiso de medir
    • 37 Se deben tener ciertos compromisos de medición establecidos, además de requisitos que midan los factores que contribuyen a un objetivo en particular para así gestionar los proyectos y hacerle frente a este objetivo. Se debe establecer una unidad u objetivo a medir en la organización, además se debe adquirir un compromiso que se debe comunicar y apoyar en los recursos de la organización. Se deben asignar recursos para llevar a cabo el proceso de medición además de dar la financiación y herramientas adecuadas para dirigir este proceso. 6.2 Planificar el proceso de medición Para esto es necesario identificar la unidad funcional a la cuál se le está aplicando para que sea caracterizada y así identificar las necesidades de información para proceder con los objetivos primordiales y sus respectivas prioridades. Se deben seleccionar las mediciones a realizar además como las muestras de información que serán tomadas para su posterior análisis, verificación e información a ser dada. El plan de medición también debe ser revisado y aprobado por los contratistas adecuados además de mantener disponibles los recursos para dicho plan. Se deben comunicar los resultados además de documentarse publicarse. 6.3 Evaluar las mediciones Este proceso se debe llevar a cabo con un criterio de evaluación específico para determinar las fuerzas y debilidades de los productos, se puede hacer por medio de un proceso de auditoría interna o externa y debe incluir una retroalimentación a los usuarios. Se deben identificar las mejoras potenciales y costos y beneficios de estas, comunicarlas a la persona encargada para su revisión y aprobación.
    • 38 CAPITULO 9 PROCESO DE INGENIERÍA DEL SOFTWARE
    • 39 Se puede examinar en dos niveles desde lo técnico y desde el meta-nivel o nivel de implementación, valoración, medición y gestión. Existen varios significados sobre el proceso de la ingeniería del software puede verse como una sola manera de realizar el proceso o como muchas maneras que es lo que se quiere y se debe llegar a hacer ya que el proceso de la ingeniería abarca muchos factores, finalmente un tercer significado se refiere al conjunto actual de actividades realizadas dentro de una organización que se puede ver como un solo proceso. Los procesos de ingeniería del software son considerados de gran importancia, el objetivo es gestionar nuevos y mejores procesos. 1. Proceso de implementación y cambios Se centra en los cambios organizacionales, describe la infraestructura, actividades, modelos y consideraciones prácticas de un proceso de implementación y cambios: También es denominado el proceso de evaluación, hay que tener cuidado con las modificaciones ya que puede que también sean necesarios cambios en la cultura organizacional. 1.1 Infraestructura del proceso Es necesario que la infraestructura este en su lugar, es decir que los recursos estén al alcance de la mano y que se hayan asignado responsabilidades, es posible que se tengan que establecer comités para supervisar el esfuerzo del proceso de ingeniería del software. Con un grupo de proceso de la ingeniería del software se pretende ser el foco central en el proceso de mejoras y tiene cierto número de responsabiidades en la inicialización y el mantenimiento. El concepto de creadora de experiencias (EF) se centra en el proceso de mejoramiento de los procesos de la ingeniería del software.
    • 40 2. Definición de procesos Pueden ser unos lineamientos, políticas o estándares se definen para facilitar el entendimiento en la comunicación humana, apoyar y mejorar procesos , se deben considerar algunas variaciones como la naturaleza del trabajo, el dominio de la aplicación, el modelo de ciclo de vida y la madurez de la organización. 3. Valoración del proceso Se lleva a cabo utilizando un método y un modelo de valoración que en algunos casos es visto como un modelo de apreciación y muchas veces una evaluación de capabilidad cuando es para la adjudicación de algún contrato. 3.1 Modelos de valoración del proceso Recoge lo que se conoce como las buenas prácticas en el proceso de gestión de la ingeniería del software, la ISO define un modelo ejemplo de valoración y de requisitos, se han desarrollado también un modelo de madurez para sistemas de ingeniería que resulta útil cuando un proceso está implicado en el desarrollo y mantenimiento de un sistema incluyendo el software. Existen dos arquitecturas generales para un modelo de valoración: continua y escalonadamente, son muy diferentes entre ellas y se deben evaluar para conocer cuál es la que mejor se adapta a mis necesidades y objetivos. 3.2 Métodos de valoración del proceso Es garantizar un método cuantitativo que evaluara los procesos, existen de varios tipos dónde se valoran distintos tópicos todos pensados en las mejoras de los procesos y la eficacia en la organización.
    • 41 4. Medición de los procesos y los productos Aunque puede resultar compleja la medición a la ingeniería del software existen varios aspectos que son fundamentales para la medición y análisis, estas mediciones se pueden realizar para apoyar los procesos de implementación y cambio o evaluar consecuencias de estos. 4.1 Medición del proceso Se recoge, analiza e interpreta información cuantitativa sobre el proceso, se utiliza para identificar la fuerza y debilidad en ellos y así mismo evaluarlos después de haber sido implementados o cambiados.
    • 42 La medición de un producto software incluye principalmente, la medición del tamaño del producto, la estructura del producto y la calidad del producto. También es importante tener en cuenta la medición del tamaño, de la estructura y de la calidad. Para garantizar la calidad en los resultados de la medición es necesaria la medición efectiva de los programas para proveer resultados exitosos. CAPITULO 10 INSTRUMENTOS Y MÉTODOS DE LA INGENIERÍA DEL SOFTWARE Son los instrumentos asistidos por ordenador que son requeridos para ayudar a los procesos de ciclo de vida del software, nos ayuda a reducir la carga cognoscitiva enfocándonos más en los aspectos creativos del proceso. Los métodos imponen la estructura a la actividad de la ingeniería del software con el objetivo de hacerla sistemática, por lo general proporcionan notación y vocabulario para comprobar tanto el proceso como el producto, aunque existen numerosos materiales sobre los instrumentos de apoyo en la ingeniería del software, los textos sobre las técnicas sobre estos instrumentos son relativamente escasos, una dificultad es el alto costo que representa un cambio de instrumento de
    • 43 software en general, los instrumentos y métodos cubren ciclos de vida completos por esto es tan complicado hacer un cambio. Estudio de las herramientas y métodos de la ingeniería de software 1. Las herramientas de ingeniería de Software Estás corresponden a las cinco primeras áreas de conocimiento de la guía, Exigencias de software, diseño de software, construcción de software, pruebas de software y mantenimiento de software. Los cuatro siguientes asuntos corresponden a las áreas de conocimiento restantes: La dirección de configuración de software, la dirección de ingeniería de software, el proceso de ingeniería de software, y la calidad del software. 1.1 Las Herramientas de exigencias de Software Han sido clasificados en dos categorías: modelado e instrumentos de capacidad de rastreo. • Exigencias de los instrumentos de modelado: Son usados para la obtención, análisis, especificación y validez de las exigencias de software. • Exigencias de los instrumentos de capacidad de Rastreo: Se hacen cada vez más importantes debido a que la complejidad del software crece, son presentados separadamente de los instrumentos de modelado. 1.2 Las Herramientas de Diseño de Software Cubre los instrumentos para crear y comprobar diseños de software, existe gran variedad de estos gracias a la diversidad en las notaciones de diseño de software y métodos, a pesar de esta variedad no se ha encontrado una división convincente.
    • 44 1.3 Las Herramientas de Construcción de Software Son instrumentos usados para producir y traducir la representación de programa máquina, se utilizan los redactores de programa, compiladores y generadores de código, intérpretes y depuradores. 1.4 Herramientas de Pruebas de Software Se incluyen: Generadores de Pruebas, marcos de ejecución de pruebas, herramientas de evaluación de pruebas, herramientas de dirección de pruebas y de análisis y de funcionamiento, todas estas están enfocadas a la prueba del software construido así como de su funcionalidad, versatilidad y calidad. 1.5 Herramientas de Mantenimiento de Software Abarca los instrumentos utilizados para el mantenimiento de software, dos categorías son identificadas: instrumentos de comprensión y instrumentos de reingeniería. Herramientas de comprensión: Ayudan a la comprensión humana de programas, se incluyen instrumentos como animadores o rebanadores. Herramientas de reingeniería: Es definido como el examen y la alteración del software sustancial para reconstruirlo de una nueva forma. 1.6 Las herramientas de dirección de configuración de Software Han sido dividas en tres categorías: rastreo, dirección de versión e instrumentos de liberación. • Rastreo: Son elementos utilizados en la conexión con las cuestiones que rastrean problemas asociados con un producto de software particular. • Herramientas de dirección de versión: Están implicados en la dirección de múltiples versiones de un producto.
    • 45 • Herramientas de liberación y construcción: Son usados para las tareas de liberación y construcción de un software incluye instrumentos de instalación que son extensamente utilizados para configurar la instalación de un producto software. 1.7 Herramientas de dirección en la Ingeniería de Software Esta subdivido en tres categorías: planificación de proyecto y rastreo, manejo arriesgado, y medida. En la primera se busca una medida de esfuerzo en el proyecto y cuenta la valoración así como la planificación del proyecto, en la segunda se identifican la estimación y riesgos de supervisión, finalmente en la medida se asiste la realización de actividades relacionadas con el programa de medida de software. 1.8 Las Herramientas de proceso de ingeniería de Software Está divida en instrumentos que modelan, instrumentos de dirección y ambientes de desarrollo de software. 1.9 Las herramientas de Calidad de Software Dividas en dos categorías: inspección e instrumentos de análisis. En las herramientas de revisión de auditoria se apoyan en revisión y revisiones de cuenta y en las de análisis estáticos se analizan artefactos de software como analizadores sintácticos y semánticos así como datos, el flujo de control y analizadores de dependencia. 1.10Cuestiones de Instrumento Compuestas Cubre el tema aplicable a todas las clases de instrumentos, tres categorías identificadas: técnicas de integración de instrumentos, meta-instrumentos, y evaluación de instrumento.
    • 46 2. Los Métodos de la Ingeniería del Software Esta divido en tres temas: Métodos heurísticos que tratan con accesos matemáticamente basados, y métodos de prototipazo que tratan con software que trama accesos basados en varias formas de prototipazo, cada tema trata sus preocupaciones distintas no quiere decir que no tengan que ver el uno con el otro. 2.1 Métodos Heurísticos Este tema contiene cuatro categorías: estructurado, orientado a datos, orientado a objetos, y específico de dominio. La última incluye métodos especializados para desarrollar los sistemas que implican en tiempo real aspectos relacionados con la seguridad. En el método estructurado se ve desde un punto de vista funcional para refinarlo y hacerlo cada vez más detallado. En el orientado a datos se estructura el programa y se manipula. En el orientado a objetos el sistema es visto como una colección de objetos más que de funciones. 2.2 Métodos Formales Aquí se describe como el software se basa en métodos de ingeniería basado matemáticamente y se subdivide según varios aspectos de métodos formales entre ellos: Especificación del lenguaje y notaciones: Aquí se especifica la lengua usada y se clasifica según la orientación del modelo las características o el comportamiento. Refinamiento: Aquí se trata como de refinar o transformar las especificaciones en una forma más cercana a la deseable en un programa finalmente ejecutable. Propiedades de Verificación/Confirmación: Aquí se incluyen confirmaciones de teorema y la comprobación del modelo.
    • 47 2.3 Métodos de Prototipado Cubre métodos que implican el prototipazo de software y es subdivida en estilos de prototipazo, objetivos y técnicas de evaluación. Se deben incluir aspectos como: Estilos de prototipazo, objetivos del prototipazo, y las técnicas para la evaluación del prototipo propuesto.
    • 48 CAPITULO 11 CALIDAD DEL SOFTWARE ¿Porque es tan importante la calidad del software que está en todos los aspectos de la guía SWEBOK?
    • 49 Muchos autores le han dado varias definiciones a este término pero citaré la que le da la ISO 9001-00 la cuál la define como “el grado en el que un conjunto de características inherentes cumple requisitos”. En este capítulo se abordan los aspectos relativos a la calidad del software los cuales trascienden en cualquier ciclo de vida, en esta guía se describen un conjunto de métodos para alcanzar la calidad, en este caso se trataran las técnicas estáticas es decir aquellas que no requieren la ejecución del software para su evaluación mientras las dinámicas cubren los aspectos de calidad en las pruebas del software. 1. Fundamentos de Calidad del Software Aquí se definen formalmente los aspectos a tratar y la manera como un ingeniero de software debería entender y adoptar los conceptos y características de calidad y su relevancia en el desarrollo o mantenimiento de software. Los aspectos de calidad deben estar inherentes desde el momento mismo de los requerimientos así como la medición y criterios de aceptación que evalúan estas características. 1.1 Modelos y Características de Calidad La terminología usada en las características difiere de una taxonomía a otra ya que cada una posee niveles jerárquicos diferentes, la ISO ha definido tres modelos relacionados con la calidad en un producto de software (la calidad interna, la calidad externa y la calidad en el empleo). 1.2 Mejora de Calidad La tarea de la calidad puede ser mejorada cada vez más gracias a un proceso iterativo de mejora continua que requiere control de dirección, control y retroalimentación de muchos procesos
    • 50 simultáneos: (1) los procesos de ciclo de vida del software, (2) el proceso de detección de error/defecto, retirada de los mismos y prevención y (3) el proceso de mejora de calidad, estos procesos han sido probados y certificados por expertos en calidad que afirman que la calidad de un producto está directamente relacionada con la calidad del proceso empleado para crearlo. Existen varios instrumentos que nos permiten conocer los objetivos de la calidad como por ejemplo el Total Quality Management (TQM), process of plan, Do, Check and Act (PDCA) con estos podemos identificar fallas, desarrollar acciones detalladas y gestionar el apoyo a la gerencia y a los recursos asignados para el proyecto para trabajar la calidad en la ingeniería del software. 2. Procesos de Gestión de Calidad del Software La gestión de calidad del software (SQM) es de gran importancia y aplicación a todas las perspectivas de procesos de software, productos y recursos, estos consisten en numerosas actividades, algunos de ellos pueden encontrar errores diariamente mientras que otros pueden resultar mas bien en valiosas revisiones. El SQM puede ser utilizado para evaluar productos intermedios así como el producto final. Algunos de los procesos específicos están definidos por la IEEE: • Procesos de aseguramiento de calidad • Procesos de Verificación • Procesos de Validación • Procesos de Revisión • Procesos de Auditoría
    • 51 Estos procesos incentivan la calidad y también permiten encontrar posibles problemas. Todos los procesos SQM están enfocados a cumplir tareas y técnicas para asegurar una calidad de software óptima en un proyecto dado, estos procesos están estrechamente relacionados, pueden solaparse y hasta en ocasiones estar combinados. También es importante tener en cuenta la gestión de riesgo ya que está juega un papel importante en la entrega de software de calidad. Revisiones de Gestión: El objetivo es supervisar el progreso, determinando el estado de los planes y programas, requerimientos confirmados y su sistema de localización o evaluar la efectividad de los enfoques de gestión empleados. Con esto se determina la idoneidad de los proyectos, programas y requerimientos y supervisan su progreso o inconsistencias. Revisiones Técnicas: El propósito es evaluar el producto software para determinar si es idóneo para su correspondiente uso, deben establecerse los roles específicos, una revisión técnica requiere que las entradas obligatorias estén en su lugar con el objeto de proceder a: exposición de objetivos, un producto software específico, el plan específico de gestión del proyecto, la lista de cuestiones claves asociadas al producto y el procedimiento de revisión técnica. Inspecciones: Detecta e identifica anomalías en los productos de software, existen dos importantes elementos diferenciadores entre inspección y revisión y son los siguientes: un individuo que mantiene una posición de dirección sobre cualquier miembro del equipo de inspección; la inspección ha de ser llevada por un inspector con formación en inspecciones técnicas. Las inspecciones por lo general requieren el autor de un producto intermedio y también a un líder de inspección, generalmente son hechas sobre una pequeña sección del producto a la vez, las anomalías encontradas deben ser documentadas y enviadas al responsable de la inspección, también es recomendable manejar listas de chequeo durante la inspección de esta manera se clasifican las anomalías y se determinan su exactitud e integridad.
    • 52 Walk-throughs: El objetivo es evaluar el producto software, los objetivos principales son: Encontrar anomalías, mejorar el producto software, considerar implementaciones alternativas, evaluar la conformidad con estándares y especificaciones. Es similar a una inspección pero su desarrollo por lo general es menos formal, generalmente es desarrollado por el ingeniero de software para darle una oportunidad a su equipo de repasar el trabajo como una técnica de aseguramiento. Auditorías: El objetivo es realizar una evaluación independiente de la conformidad de productos de software y procesos a regulaciones aplicables, estándares, directrices, planes y procedimientos, está formalmente organizada con participantes que cumplen roles específicos contando con un representante de la organización auditada. Puede realizarse sobre casi cualquier proceso o producto en cualquier etapa de mantenimiento o desarrollo. 3. Consideraciones Prácticas: 3.1 Requerimientos de calidad del software: Aquí influyen varios factores como la planificación la gestión y selección de actividades SQM y técnicas incluyendo: Donde residirá el software , requerimientos del sistema y del software, los componentes comerciales, estándares , métodos y herramientas de software, el presupuesto y los usuarios implicados como también el nivel de integridad del sistema. Las técnicas dinámicas son ejecutadas durante todo el desarrollo y el mantenimiento de software, generalmente son técnicas de testeo o simulación. Las pruebas examinan todos los output de la especificación de requerimientos de software con el objeto de asegurar su trazabilidad, consistencia, completitud, corrección y ejecución.
    • 53 Existen muchos tipos de pruebas entre ellos la de terceros ya que es la de un facilitador independiente por lo general acreditado por alguna autoridad su objetivo es probar el producto respecto a su conformidad con un conjunto de exigencias.
    • 54 CAPITULO 12 DISCIPLINAS RELACIONADAS CON LA INGENIERIA DEL SOFTWARE Este capítulo se centra en relacionar cada una de las disciplinas de la figura 1 con la Ingeniería del Software. Es específico en lo que respecta a determinar las temáticas de cada una de ellas con respecto a otras.
    • 55