jueves, 22 de octubre de 2009
Síntesis modelos del proceso del software
MODELOS DEL PROCESO DEL SOFTWARE
Es importante definir antes que nada, lo que es un proceso y mas específicamente un modelo de proceso de software, un proceso es un conjunto estructurado de actividades para especificar, diseñar, implementar y probar Sistemas de software. El modelo de proceso de software es una representación abstracta de un proceso. Este representa una descripción de un proceso desde una perspectiva particular.
Se selecciona un modelo de proceso según la naturaleza del proyecto, de la aplicación, los métodos, las herramientas a utilizar, los controles y las entregas que se requieren. Cada modelo ayuda al control y coordinación de un proyecto de software real.
MODELO EN CASCADA
El modelo en cascada original se desarrollo entre las décadas de los sesenta y setenta y se define como una secuencia de actividades, donde la estrategia principal es seguir el proceso del desarrollo de software hacia puntos de revisión bien definidos mediante entregas calendarizadas.
Este modelo ordena rigurosamente las etapas del ciclo de vida del software, de tal forma que el inicio de una etapa debe esperar a la finalización de la etapa inmediatamente anterior.
Algunas de las características más importantes de este modelo son:
Es el más utilizado
Todas las etapas deben desarrollarse para que el proyecto tenga éxito
Las fases continúan hasta que el objetivo es cumplido
Si se cambia el orden de las fases, el producto será de menor calidad
Las fases del modelo en cascada son:
Análisis de requisitos: En esta etapa se analizan los requerimientos de los usuarios finales para determinar los objetivos que deseamos alcanzar.
Diseño: En esta fase se realizan los algoritmos necesarios para que se cumplan los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Programación.
Programación: Aquí se implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores.
Pruebas: Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos. Muchas veces se realizan pruebas con algunos de los futuros usuarios del sistema para verificar que el mismo sea fácil de entender y utilizar por ellos.
Implantación: El software obtenido se pone en producción. Se implantan los niveles software y hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto.
Mantenimiento: El software necesitará cambios después de la entrega. Los tipos de mantenimiento son:
Mantenimiento Preventivo y Perfectivo
Mantenimiento Correctivo
Mantenimiento Evolutivo
Ventajas del modelo en cascada
Ayuda a minimizar los gastos de la planificación porque permite realizarla sin problemas
Evita una fuente común de errores importantes
Se utiliza correctamente para ciclos en los que se tiene una definición estable del producto.
Desventajas del modelo en cascada
No existe un proyecto “enseñable” hasta el final del proyecto
Se tarda mucho tiempo en pasar por todo el ciclo
Dificultad para especificar claramente los requerimientos al comienzo del proyecto(no permite flexibilidad en los cambios)
Este es una ejemplificación grafica del modelo en cascada
MODELO EN ESPIRAL
Las actividades de este modelo se conforman en una espiral, en la que cada iteración representa a un conjunto de actividades.
Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las últimas iteraciones se producen versiones cada vez mas completas del sistema diseñado.
Se dice que el modelo en espiral mejora al modelo en cascada enfatizando la naturaleza iterativa del proceso de diseño.
Este modelo sigue algunos principios básicos como por ejemplo:
Definir el problema que se requiere resolver
Examinar las distintas alternativas de acción y elegir la mas conveniente
Conocer los niveles de riesgo
En cada iteración del modelo debemos tomar en cuenta:
Los objetivos: Que es lo que debe resolver nuestro producto
Alternativas: Son las distintas formas que tenemos para conseguir los objetivos de forma exitosa
Desarrollo y Verificación: Programar y probar el software
Para cada ciclo del modelo en espiral hay cuatro actividades:
· Determinar o fijar objetivos: Determinar que producto deseamos obtener, los requerimientos y la especificación.
· Análisis del riesgo: Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos.
· Desarrollar, verificar y validar (probar)
· Planificar: Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.
Ventajas del modelo en espiral
Reduce riesgos del proyecto
Integra el desarrollo con el mantenimiento
Utiliza las fases de modelos tradicionales. Se centra en la eliminación de errores y alternativas poco atractivas.
Desventajas del modelo en espiral
Consume muchos recursos
Genera mucho tiempo en el desarrollo del sistema
Costoso
Requiere experiencia en la identificación de riesgos
MODELO INCREMENTAL
El modelo incremental es un desarrollo inicial de la arquitectura completa del sistema, seguido de incrementos y versiones parciales del mismo. Cada incremento tiene su propio ciclo de vida. Cada incremento agrega funcionalidad adicional o mejorada sobre el sistema. Conforme se completa cada etapa, se verifica e integra la versión con las demás versiones ya completadas del sistema.
En una visión genérica, el proceso se divide en cuatro partes: Análisis, Diseño, Código, Prueba. En este método se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluyo o desecha elementos al final de cada incremento con la finalidad de que el software se adapte mejor a sus necesidades reales.
Algunas características de este modelo son:
El primer incremento es a menudo un producto esencial
A partir de la evaluación se planea el siguiente incremento y así sucesivamente
Es iterativo por naturaleza
Es útil cuando el personal no es suficiente
La administración de proyectos es más fácil de lograr en incrementos más pequeños
En lugar de entregar el sistema en una sola entrega, el desarrollo y la entrega están facturados bajo incrementos, con cada incremento se entrega parte de la funcionalidad requerida.
Ventajas del modelo incremental
Algunas de las ventajas de este modelo son:
El usuario se involucra mas
Se evitan proyectos largos y se entrega “Algo de valor” a los usuarios con cierta frecuencia
Se puede financiar el proyecto por partes
Es apropiado para proyectos grandes, de larga duración
No se necesita tanto personal al principio como para una implementación completa
Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
Desventajas del modelo incremental
Estas son algunas de las desventajas de este modelo:
Hay costos ocultos en su implementación, ya que se incorporan varias actividades a realizar por el equipo, y hay que saber medir ese impacto para no fracasar en el intento.
Representación grafica del modelo incremental:
MODELO RUP
El proceso unificado racional es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar mas utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
Consiste en un conjunto de actividades necesarias para transformar los requerimientos del usuario en el sistema de software. Esta especializado para diversos tipos de software de sistemas, diversas áreas de aplicación, diferentes tipos de organizaciones y diferentes tamaños de proyectos.
El modelo RUP es una guía de cómo usar UML de la forma más efectiva.
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades.
El ciclo de vida del modelo RUP son:
Inicio: Define el alcance y objetivos del proyecto
Elaboración: Plan de proyecto, especificación de características y arquitectura base.
Construcción: Construir y operar el producto
Transición: garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.
Algunas de las principales características de este modelo son:
Tiene una forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
Es iterativo
Esta guiado por los casos de uso
Incluye artefactos (que son los productos tangibles del proceso)
Incluye roles (es el papel que desempeña una persona en un determinado momento)
Dirigido por casos de uso
Las fases del modelo RUP son:
Establecer oportunidad y alcance
Identificar las entidades externas o actores con los que se trata
Identificar los casos de uso
Ventajas del modelo RUP
Estas son algunas de las ventajas del modelo RUP:
Mitigacion temprana de posibles riesgos altos
Progreso visible en las etapas tempranas
El conocimiento adquirido en una iteración puede aplicarse de iteración a iteración
Los usuarios están involucrados continuamente
Desventajas del modelo RUP
Estas son algunas de las desventajas del modelo RUP:
Por el grado de complejidad puede no resultar muy adecuado.
El RUP es generalmente mal aplicado en el estilo cascada.
Requiere conocimientos del proceso y de UML.
Es importante definir antes que nada, lo que es un proceso y mas específicamente un modelo de proceso de software, un proceso es un conjunto estructurado de actividades para especificar, diseñar, implementar y probar Sistemas de software. El modelo de proceso de software es una representación abstracta de un proceso. Este representa una descripción de un proceso desde una perspectiva particular.
Se selecciona un modelo de proceso según la naturaleza del proyecto, de la aplicación, los métodos, las herramientas a utilizar, los controles y las entregas que se requieren. Cada modelo ayuda al control y coordinación de un proyecto de software real.
MODELO EN CASCADA
El modelo en cascada original se desarrollo entre las décadas de los sesenta y setenta y se define como una secuencia de actividades, donde la estrategia principal es seguir el proceso del desarrollo de software hacia puntos de revisión bien definidos mediante entregas calendarizadas.
Este modelo ordena rigurosamente las etapas del ciclo de vida del software, de tal forma que el inicio de una etapa debe esperar a la finalización de la etapa inmediatamente anterior.
Algunas de las características más importantes de este modelo son:
Es el más utilizado
Todas las etapas deben desarrollarse para que el proyecto tenga éxito
Las fases continúan hasta que el objetivo es cumplido
Si se cambia el orden de las fases, el producto será de menor calidad
Las fases del modelo en cascada son:
Análisis de requisitos: En esta etapa se analizan los requerimientos de los usuarios finales para determinar los objetivos que deseamos alcanzar.
Diseño: En esta fase se realizan los algoritmos necesarios para que se cumplan los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Programación.
Programación: Aquí se implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores.
Pruebas: Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos. Muchas veces se realizan pruebas con algunos de los futuros usuarios del sistema para verificar que el mismo sea fácil de entender y utilizar por ellos.
Implantación: El software obtenido se pone en producción. Se implantan los niveles software y hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto.
Mantenimiento: El software necesitará cambios después de la entrega. Los tipos de mantenimiento son:
Mantenimiento Preventivo y Perfectivo
Mantenimiento Correctivo
Mantenimiento Evolutivo
Ventajas del modelo en cascada
Ayuda a minimizar los gastos de la planificación porque permite realizarla sin problemas
Evita una fuente común de errores importantes
Se utiliza correctamente para ciclos en los que se tiene una definición estable del producto.
Desventajas del modelo en cascada
No existe un proyecto “enseñable” hasta el final del proyecto
Se tarda mucho tiempo en pasar por todo el ciclo
Dificultad para especificar claramente los requerimientos al comienzo del proyecto(no permite flexibilidad en los cambios)
Este es una ejemplificación grafica del modelo en cascada
MODELO EN ESPIRAL
Las actividades de este modelo se conforman en una espiral, en la que cada iteración representa a un conjunto de actividades.
Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las últimas iteraciones se producen versiones cada vez mas completas del sistema diseñado.
Se dice que el modelo en espiral mejora al modelo en cascada enfatizando la naturaleza iterativa del proceso de diseño.
Este modelo sigue algunos principios básicos como por ejemplo:
Definir el problema que se requiere resolver
Examinar las distintas alternativas de acción y elegir la mas conveniente
Conocer los niveles de riesgo
En cada iteración del modelo debemos tomar en cuenta:
Los objetivos: Que es lo que debe resolver nuestro producto
Alternativas: Son las distintas formas que tenemos para conseguir los objetivos de forma exitosa
Desarrollo y Verificación: Programar y probar el software
Para cada ciclo del modelo en espiral hay cuatro actividades:
· Determinar o fijar objetivos: Determinar que producto deseamos obtener, los requerimientos y la especificación.
· Análisis del riesgo: Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos.
· Desarrollar, verificar y validar (probar)
· Planificar: Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.
Ventajas del modelo en espiral
Reduce riesgos del proyecto
Integra el desarrollo con el mantenimiento
Utiliza las fases de modelos tradicionales. Se centra en la eliminación de errores y alternativas poco atractivas.
Desventajas del modelo en espiral
Consume muchos recursos
Genera mucho tiempo en el desarrollo del sistema
Costoso
Requiere experiencia en la identificación de riesgos
MODELO INCREMENTAL
El modelo incremental es un desarrollo inicial de la arquitectura completa del sistema, seguido de incrementos y versiones parciales del mismo. Cada incremento tiene su propio ciclo de vida. Cada incremento agrega funcionalidad adicional o mejorada sobre el sistema. Conforme se completa cada etapa, se verifica e integra la versión con las demás versiones ya completadas del sistema.
En una visión genérica, el proceso se divide en cuatro partes: Análisis, Diseño, Código, Prueba. En este método se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluyo o desecha elementos al final de cada incremento con la finalidad de que el software se adapte mejor a sus necesidades reales.
Algunas características de este modelo son:
El primer incremento es a menudo un producto esencial
A partir de la evaluación se planea el siguiente incremento y así sucesivamente
Es iterativo por naturaleza
Es útil cuando el personal no es suficiente
La administración de proyectos es más fácil de lograr en incrementos más pequeños
En lugar de entregar el sistema en una sola entrega, el desarrollo y la entrega están facturados bajo incrementos, con cada incremento se entrega parte de la funcionalidad requerida.
Ventajas del modelo incremental
Algunas de las ventajas de este modelo son:
El usuario se involucra mas
Se evitan proyectos largos y se entrega “Algo de valor” a los usuarios con cierta frecuencia
Se puede financiar el proyecto por partes
Es apropiado para proyectos grandes, de larga duración
No se necesita tanto personal al principio como para una implementación completa
Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
Desventajas del modelo incremental
Estas son algunas de las desventajas de este modelo:
Hay costos ocultos en su implementación, ya que se incorporan varias actividades a realizar por el equipo, y hay que saber medir ese impacto para no fracasar en el intento.
Representación grafica del modelo incremental:
MODELO RUP
El proceso unificado racional es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar mas utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
Consiste en un conjunto de actividades necesarias para transformar los requerimientos del usuario en el sistema de software. Esta especializado para diversos tipos de software de sistemas, diversas áreas de aplicación, diferentes tipos de organizaciones y diferentes tamaños de proyectos.
El modelo RUP es una guía de cómo usar UML de la forma más efectiva.
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades.
El ciclo de vida del modelo RUP son:
Inicio: Define el alcance y objetivos del proyecto
Elaboración: Plan de proyecto, especificación de características y arquitectura base.
Construcción: Construir y operar el producto
Transición: garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.
Algunas de las principales características de este modelo son:
Tiene una forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
Es iterativo
Esta guiado por los casos de uso
Incluye artefactos (que son los productos tangibles del proceso)
Incluye roles (es el papel que desempeña una persona en un determinado momento)
Dirigido por casos de uso
Las fases del modelo RUP son:
Establecer oportunidad y alcance
Identificar las entidades externas o actores con los que se trata
Identificar los casos de uso
Ventajas del modelo RUP
Estas son algunas de las ventajas del modelo RUP:
Mitigacion temprana de posibles riesgos altos
Progreso visible en las etapas tempranas
El conocimiento adquirido en una iteración puede aplicarse de iteración a iteración
Los usuarios están involucrados continuamente
Desventajas del modelo RUP
Estas son algunas de las desventajas del modelo RUP:
Por el grado de complejidad puede no resultar muy adecuado.
El RUP es generalmente mal aplicado en el estilo cascada.
Requiere conocimientos del proceso y de UML.
Unidad 2 cont
2.7 Software de Alta Calidad
La calidad del software es un objetivo al que se dedican muchos esfuerzos. Es muy difícil poder crear software perfecto. Pero todo proyecto tiene como objetivo producir software de la mejor calidad posible.
Antes de adentrarnos de lleno a este tema, seria bueno definir el concepto de calidad.
Calidad: La calidad es la aptitud de un producto para satisfacer las necesidades del usuario. Algunos de los aspectos que se pueden tomar en cuenta para evaluar la calidad del software son:
Funcionalidad
Confiabilidad
Usabilidad
Eficiencia
Mantenibilidad
Portabilidad
Para poder asegurar la calidad del software, debemos tener un conjunto de actividades planificadas y sistematizadas, que son necesarias para aportar la confianza en que el producto satisface los requisitos de calidad.
No podemos certificar la calidad del software, pero lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en función de la normalización (ISO 9000, CMMI, etc.).
ISO 9000: Las normas ISO 9000, son normas de calidad y gestión continua de calidad, establecidas por la Organización Internacional para la Estandarización (ISO). Se pueden aplicar en cualquier tipo de organización o actividad sistemática orientada a la producción de bienes o servicios. Se componen de estándares y guías relacionados con sistemas de gestión y de herramientas específicas, como los métodos de auditoria.
En cuanto al software, pone a disposición de un auditor o certificador los procesos internos, de forma que este indique si cumple o no la normativa al 100%. Audita al sistema. Si los resultados son positivos emite la certificación, y cada cierto tiempo se tiene que renovar. La certificación es un proceso costoso.
El nacimiento de CMM-CMMI
El departamento de defensa de los estados unidos tenía muchos problemas con el software que encargaba desarrollar a otras empresas.
Convocó un comité de expertos para que solucionase estos problemas, en el año 1983 dicho comité concluyó "Tienen que crear un instituto de la ingeniería del software, dedicado exclusivamente a los problemas del software, y a ayudar al Departamento de Defensa".
Convocaron un concurso público en el que dijeron: "Cualquiera que quiera enviar una solicitud tiene que explicar como van a resolver estos problemas", se presentaron diversas solicitudes y la Universidad Carnegie Mellon ganó el concurso en 1985, creando el SEI. El SEI (Software Engineering Institute) es el instituto que creó y mantiene el modelo de calidad CMM – CMMI.
CMM-CMMI: El CMM (Capability Maturity Model) – CMMI (Capability Maturity Model Integration) es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software.
Las siglas CMM significan Modelo de capacidad y madurez, y CMMI seria en español algo como integración del modelo de madurez de capacidad.
El modelo CMM establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser:
Definidas en un proceso documentado
Provistas de los medios y formación necesarios
Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)
Medidas
Verificadas
A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.
La implantación de un modelo de estas características es un proceso largo y costoso que puede costar varios años de esfuerzo. Aun así el beneficio obtenido para la empresa es mucho mayor que lo invertido.
Nivel Inicial o Nivel Uno: Este es el nivel en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, te tienes que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco, no sabes lo que pasa en él.
El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos.
Si no sabes el tamaño del proyecto y no sabes cuanto llevas hecho, nunca sabrás cuando vas a terminar.
Nivel Repetible o Nivel Dos: En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.
Quiere decir que el éxito de los resultados obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento.
Los procesos que hay que implantar para alcanzar este nivel son:
Gestión de requisitos
Planificación de proyectos
Seguimiento y control de proyectos
Gestión de proveedores
Aseguramiento de la calidad
Gestión de la configuración
Nivel Definido o Nivel Tres: Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detallada y un nivel más avanzado de métricas en los procesos. Se implementan técnicas de revisión por pares (peer reviews).
Resumiéndolo mucho, alcanzar este nivel significa que la forma de desarrollar proyectos esta establecida, documentada y que existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos.
Los procesos que hay que implantar para alcanzar este nivel son:
Desarrollo de requisitos
Solución Técnica
Integración del producto
Verificación
Validación
Desarrollo y mejora de los procesos de la organización
Definición de los procesos de la organización
Planificación de la formación
Gestión de riesgos
Análisis y resolución de toma de decisiones
La mayoría de las empresas que llegan al nivel 3 paran aquí, ya que es un nivel que proporciona muchos beneficios y no ven la necesidad de ir más allá porque tienen cubiertas la mayoría de sus necesidades.
Nivel Gestionado o Nivel Cuatro: Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización.
Los procesos que hay que implantar para alcanzar este nivel son:
Gestión cuantitativa de proyectos
Mejora de los procesos de la organización
Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad.
Nivel Optimizado o Nivel Cinco: La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.
Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante métricas son identificadas, evaluadas y puestas en práctica.
Los procesos que hay que implantar para alcanzar este nivel son:
Innovación organizacional
Análisis y resolución de las causas
Normalmente las empresas que intentan alcanzar los niveles 4 y 5 lo realizan simultáneamente ya que están muy relacionados.
2.8 Factores de calidad y productividad
En los modelos de calidad, la calidad se define de forma jerárquica. Es un concepto que se deriva de un conjunto de sub-conceptos, cada uno los cuales se van a evaluar a través de un conjunto de indicadores o métricas.
Tienen una estructura, por lo general, en tres niveles:
Factores de Calidad
Criterios de calidad del Producto
Métricas del Producto
En el nivel más alto de la jerarquía se encuentran los factores de calidad, que representan la calidad desde el punto de vista del usuario.
Cada uno de los factores se descompone en un conjunto de criterios de calidad. Son atributos que, cuando están presentes, contribuyen al aspecto de la calidad que el factor asociado representa. Se trata de una visión de la calidad desde el punto de vista del producto software.
Para cada uno de los criterios de calidad se definen entonces un conjunto de métricas, que son medidas cuantitativas de ciertas características del producto que dan una indicación del grado en que dicho producto posee un determinado atributo de calidad.
Factores de calidad del software de McCall
Este modelo es considerado por primera vez en 1977 por McCall. Destinado a ser utilizado durante el proceso de desarrollo de sistemas, sirvió desde muy temprano como puente entre los usuarios y los desarrolladores, concilia los puntos de la vista de los usuarios con las prioridades de los desarrolladores. Con una perspectiva de visión basada en los criterios de la evaluación de la calidad.
El modelo de calidad de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto.
Operación del producto
Revisión del producto
Transición del producto
Este modelo se basa en 11 factores de calidad, que se organizan en torno a los tres ejes de la siguiente manera:
v Operación de producto ó Características operacionales
§ Facilidad de uso (¿Puedo ejecutarlo?)
§ Integridad (¿Es seguro?)
§ Corrección (¿Hace el software lo que yo quiero?)
§ Fiabilidad (¿Lo hace de forma exacta todo el T?)
§ Eficiencia (¿Se ejecutará sobre mi HW lo mejor posible?)
v Revisión del producto ó Capacidad de soportar cambios
§ Facilidad de mantenimiento (¿Puedo arreglarlo?)
§ Facilidad de prueba (¿Puedo probarlo?)
§ Flexibilidad (¿Puedo modificarlo?)
v Transición del producto ó Adaptabilidad de nuevos entornos
§ Facilidad de reutilización (¿Podré reutilizar parte del software?)
§ Interoperabilidad (¿Podré comunicarlo con otros sistemas?)
§ Portabilidad (¿Podré utilizarlo en otra máquina?)
Los criterios pueden ser evaluados mediante un conjunto de métricas. Para cada criterio deben fijarse unos valores máximo y mínimo aceptables para cada criterio. Generalmente estas métricas definidas por MacCall solo pueden ser medidas en forma subjetiva.
Ahora se enlistan algunas de estas métricas:
Facilidad de Auditoria: La facilidad con que se puede comprobar la conformidad con los estándares
Exactitud: La precisión de los cálculos y el control
Normalización de las Comunicaciones: El grado en que se usan el ancho de banda, los protocolos y las interfaces estándar
Completitud: El grado en que se ha conseguido la total implementación de las funciones requeridas
Concisión: Lo compacto que es el programa en términos de líneas de código
Consistencia: El uso de un diseño uniforme de técnicas de documentación a los largo del proyecto de desarrollo de software
Estandarización en los datos: El uso de estructuras de datos de tipos estándar a lo largo de todo el programa
Tolerancia de Errores: El daño que se produce cuando el programa encuentra un error
Eficiencia en la Ejecución: El rendimiento en tiempo de ejecución de un programa
Facilidad de expansión: El grado en que se puede ampliar el diseño arquitectónico de datos o procedural
Generalidad: La amplitud de aplicación potencial de los componentes del programa
Independencia del Hardware: El grado en que el software es independiente del hardware en que opera
Instrumentación: El grado en que el programa muestra su propio funcionamiento e identifica errores que aparecen
Modularidad: La independencia funcional de los componentes del programa
Facilidad de Operación: La facilidad de operación de un programa
Seguridad: La disponibilidad de mecanismos que controlen o protejan los programas o datos
Auto-Documentación: El grado en que el código fuente proporciona documentación significativa.
La siguiente imagen muestra la relación que existe entre los factores, criterios y métricas en el modelo de McCall:
La calidad del software es un objetivo al que se dedican muchos esfuerzos. Es muy difícil poder crear software perfecto. Pero todo proyecto tiene como objetivo producir software de la mejor calidad posible.
Antes de adentrarnos de lleno a este tema, seria bueno definir el concepto de calidad.
Calidad: La calidad es la aptitud de un producto para satisfacer las necesidades del usuario. Algunos de los aspectos que se pueden tomar en cuenta para evaluar la calidad del software son:
Funcionalidad
Confiabilidad
Usabilidad
Eficiencia
Mantenibilidad
Portabilidad
Para poder asegurar la calidad del software, debemos tener un conjunto de actividades planificadas y sistematizadas, que son necesarias para aportar la confianza en que el producto satisface los requisitos de calidad.
No podemos certificar la calidad del software, pero lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en función de la normalización (ISO 9000, CMMI, etc.).
ISO 9000: Las normas ISO 9000, son normas de calidad y gestión continua de calidad, establecidas por la Organización Internacional para la Estandarización (ISO). Se pueden aplicar en cualquier tipo de organización o actividad sistemática orientada a la producción de bienes o servicios. Se componen de estándares y guías relacionados con sistemas de gestión y de herramientas específicas, como los métodos de auditoria.
En cuanto al software, pone a disposición de un auditor o certificador los procesos internos, de forma que este indique si cumple o no la normativa al 100%. Audita al sistema. Si los resultados son positivos emite la certificación, y cada cierto tiempo se tiene que renovar. La certificación es un proceso costoso.
El nacimiento de CMM-CMMI
El departamento de defensa de los estados unidos tenía muchos problemas con el software que encargaba desarrollar a otras empresas.
Convocó un comité de expertos para que solucionase estos problemas, en el año 1983 dicho comité concluyó "Tienen que crear un instituto de la ingeniería del software, dedicado exclusivamente a los problemas del software, y a ayudar al Departamento de Defensa".
Convocaron un concurso público en el que dijeron: "Cualquiera que quiera enviar una solicitud tiene que explicar como van a resolver estos problemas", se presentaron diversas solicitudes y la Universidad Carnegie Mellon ganó el concurso en 1985, creando el SEI. El SEI (Software Engineering Institute) es el instituto que creó y mantiene el modelo de calidad CMM – CMMI.
CMM-CMMI: El CMM (Capability Maturity Model) – CMMI (Capability Maturity Model Integration) es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software.
Las siglas CMM significan Modelo de capacidad y madurez, y CMMI seria en español algo como integración del modelo de madurez de capacidad.
El modelo CMM establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser:
Definidas en un proceso documentado
Provistas de los medios y formación necesarios
Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)
Medidas
Verificadas
A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.
La implantación de un modelo de estas características es un proceso largo y costoso que puede costar varios años de esfuerzo. Aun así el beneficio obtenido para la empresa es mucho mayor que lo invertido.
Nivel Inicial o Nivel Uno: Este es el nivel en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, te tienes que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco, no sabes lo que pasa en él.
El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos.
Si no sabes el tamaño del proyecto y no sabes cuanto llevas hecho, nunca sabrás cuando vas a terminar.
Nivel Repetible o Nivel Dos: En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.
Quiere decir que el éxito de los resultados obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento.
Los procesos que hay que implantar para alcanzar este nivel son:
Gestión de requisitos
Planificación de proyectos
Seguimiento y control de proyectos
Gestión de proveedores
Aseguramiento de la calidad
Gestión de la configuración
Nivel Definido o Nivel Tres: Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detallada y un nivel más avanzado de métricas en los procesos. Se implementan técnicas de revisión por pares (peer reviews).
Resumiéndolo mucho, alcanzar este nivel significa que la forma de desarrollar proyectos esta establecida, documentada y que existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos.
Los procesos que hay que implantar para alcanzar este nivel son:
Desarrollo de requisitos
Solución Técnica
Integración del producto
Verificación
Validación
Desarrollo y mejora de los procesos de la organización
Definición de los procesos de la organización
Planificación de la formación
Gestión de riesgos
Análisis y resolución de toma de decisiones
La mayoría de las empresas que llegan al nivel 3 paran aquí, ya que es un nivel que proporciona muchos beneficios y no ven la necesidad de ir más allá porque tienen cubiertas la mayoría de sus necesidades.
Nivel Gestionado o Nivel Cuatro: Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización.
Los procesos que hay que implantar para alcanzar este nivel son:
Gestión cuantitativa de proyectos
Mejora de los procesos de la organización
Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad.
Nivel Optimizado o Nivel Cinco: La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.
Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante métricas son identificadas, evaluadas y puestas en práctica.
Los procesos que hay que implantar para alcanzar este nivel son:
Innovación organizacional
Análisis y resolución de las causas
Normalmente las empresas que intentan alcanzar los niveles 4 y 5 lo realizan simultáneamente ya que están muy relacionados.
2.8 Factores de calidad y productividad
En los modelos de calidad, la calidad se define de forma jerárquica. Es un concepto que se deriva de un conjunto de sub-conceptos, cada uno los cuales se van a evaluar a través de un conjunto de indicadores o métricas.
Tienen una estructura, por lo general, en tres niveles:
Factores de Calidad
Criterios de calidad del Producto
Métricas del Producto
En el nivel más alto de la jerarquía se encuentran los factores de calidad, que representan la calidad desde el punto de vista del usuario.
Cada uno de los factores se descompone en un conjunto de criterios de calidad. Son atributos que, cuando están presentes, contribuyen al aspecto de la calidad que el factor asociado representa. Se trata de una visión de la calidad desde el punto de vista del producto software.
Para cada uno de los criterios de calidad se definen entonces un conjunto de métricas, que son medidas cuantitativas de ciertas características del producto que dan una indicación del grado en que dicho producto posee un determinado atributo de calidad.
Factores de calidad del software de McCall
Este modelo es considerado por primera vez en 1977 por McCall. Destinado a ser utilizado durante el proceso de desarrollo de sistemas, sirvió desde muy temprano como puente entre los usuarios y los desarrolladores, concilia los puntos de la vista de los usuarios con las prioridades de los desarrolladores. Con una perspectiva de visión basada en los criterios de la evaluación de la calidad.
El modelo de calidad de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto.
Operación del producto
Revisión del producto
Transición del producto
Este modelo se basa en 11 factores de calidad, que se organizan en torno a los tres ejes de la siguiente manera:
v Operación de producto ó Características operacionales
§ Facilidad de uso (¿Puedo ejecutarlo?)
§ Integridad (¿Es seguro?)
§ Corrección (¿Hace el software lo que yo quiero?)
§ Fiabilidad (¿Lo hace de forma exacta todo el T?)
§ Eficiencia (¿Se ejecutará sobre mi HW lo mejor posible?)
v Revisión del producto ó Capacidad de soportar cambios
§ Facilidad de mantenimiento (¿Puedo arreglarlo?)
§ Facilidad de prueba (¿Puedo probarlo?)
§ Flexibilidad (¿Puedo modificarlo?)
v Transición del producto ó Adaptabilidad de nuevos entornos
§ Facilidad de reutilización (¿Podré reutilizar parte del software?)
§ Interoperabilidad (¿Podré comunicarlo con otros sistemas?)
§ Portabilidad (¿Podré utilizarlo en otra máquina?)
Los criterios pueden ser evaluados mediante un conjunto de métricas. Para cada criterio deben fijarse unos valores máximo y mínimo aceptables para cada criterio. Generalmente estas métricas definidas por MacCall solo pueden ser medidas en forma subjetiva.
Ahora se enlistan algunas de estas métricas:
Facilidad de Auditoria: La facilidad con que se puede comprobar la conformidad con los estándares
Exactitud: La precisión de los cálculos y el control
Normalización de las Comunicaciones: El grado en que se usan el ancho de banda, los protocolos y las interfaces estándar
Completitud: El grado en que se ha conseguido la total implementación de las funciones requeridas
Concisión: Lo compacto que es el programa en términos de líneas de código
Consistencia: El uso de un diseño uniforme de técnicas de documentación a los largo del proyecto de desarrollo de software
Estandarización en los datos: El uso de estructuras de datos de tipos estándar a lo largo de todo el programa
Tolerancia de Errores: El daño que se produce cuando el programa encuentra un error
Eficiencia en la Ejecución: El rendimiento en tiempo de ejecución de un programa
Facilidad de expansión: El grado en que se puede ampliar el diseño arquitectónico de datos o procedural
Generalidad: La amplitud de aplicación potencial de los componentes del programa
Independencia del Hardware: El grado en que el software es independiente del hardware en que opera
Instrumentación: El grado en que el programa muestra su propio funcionamiento e identifica errores que aparecen
Modularidad: La independencia funcional de los componentes del programa
Facilidad de Operación: La facilidad de operación de un programa
Seguridad: La disponibilidad de mecanismos que controlen o protejan los programas o datos
Auto-Documentación: El grado en que el código fuente proporciona documentación significativa.
La siguiente imagen muestra la relación que existe entre los factores, criterios y métricas en el modelo de McCall:
Unidad 2
2.1 Definición de ingeniería del software
“El establecimiento y uso de principios de ingeniería robustos, orientados a obtener software económico que sea flexible y funcione de manera eficiente sobre maquinas reales “
Fritz Barner
La ingeniería de software es una disiplina de la ingeniería que comprende todos los aspectos de la producción de software desde las etapas iníciales de la especificación del sistema, hasta el mantenimiento de este después de que ya se utiliza.
2.2 Historia de la ingeniería del software
La ingeniería en software es una rama muy joven de la ingeniería y por eso se encuentra en un estado de cambio rápido. La British Computer Society, por ejemplo, la primera ocasión en que ofreció el certificado Chartered Engineer a los ingenieros en software, fue al principio de la década de los 90’. En 1998 por primera vez fue posible registrarse como ingeniero de software profesional en un lugar en Estados Unidos.
De cualquier manera al inicio del siglo XXI se reconoce ampliamente que falta una disciplina a la forma en que las organizaciones desarrollan sus aplicaciones de software. Una estimación coloca al 75% de las organizaciones en un nivel primitivo.
2.3 Características del Software
1.- El software se desarrolla, no se fabrica en un sentido clásico
En esta actividad la buena calidad se adquiere mediante un buen diseño, el cual depende de las personas. Los costes de software se encuentran en la ingeniería, esto significa, que los proyectos de software no se pueden gestionar como si fueran proyectos de fabricación.
2.- El software no se estropea
El software no es susceptible a los mates del entorno que hacen que el hardware se estropee, por tanto la curva de fallos para el software al inicio puede tener un máximo pero después se minimiza y estabiliza.
3.- La mayoría del software se construye a la medida en vez de ensamblar componentes existentes
Con pocas excepciones no existen catálogos de componentes de software, se puede comprar software ya desarrollado pero solo como una unidad completa, no como componentes que pueden ser ensamblables en nuevos programas. Aunque se ha escrito mucho sobre reusabilidad del software solo estamos comenzando a ver las primeras implementaciones con éxito de este concepto.
2.4 Mitos del software
Mitos de Gestión
- Se cuenta con documentación y procedimientos para construir cualquier software.
- Tener computadoras muy potentes garantiza el desarrollo del software a través de desarrollo de herramientas CASE.
- Horda mongoliana
Mitos de Gestión
- Solo los objetivos generales importan para empezar a desarrollar
- Que el software es flexible y pueden hacerse cambios fácilmente.
Mitos de los desarrolladores
- Solo con hacer funcionar los programas es suficiente
- Solo se ve la calidad del software ejecutando el programa
- Solo se entrega el programa al terminar el proyecto
2.5 Capas de la ingeniería del Software
Independientemente da la complejidad del sistema la ingeniería de software puede considerarse una tecnología multicapa donde la primera capa enfatiza los cimientos de la ingeniería de software está orientada a la calidad.
Donde el proceso es el conjunto de actividades, métodos, práctica y tecnologías aplicables a todos los proyectos de software.
Los métodos o modelos de la ingeniería de software indica cómo realizar los pasos necesarios del ciclo de vida.
Las herramientas ayudan a organizar tareas de trabajo, controlar y supervisar los procesos y administrar la calidad técnica. Su objetivo principal es proporcionar un soporte automático o semiautomático, para los métodos y para los procesos.
2.6 El proceso del software
Un proceso del software es u conjunto de actividades y resultados asociados que producen un producto de software.
Existen cuatro actividades fundamentales del proceso que son comunes para todos los proceso del software:
1.- Especificación del software: Donde los clientes e ingenieros definen el software a producir y las restricciones sobre su operación.
2.- Desarrollo del software: Donde el Software se diseña y se programa
3.- Validación del Software: Donde el software se valida para asegurar que es lo que el cliente requiere.
4.- Evaluación del Software: Donde el software se modifica para adaptarlo a los cambios requeridos por el cliente y el mercado.
“El establecimiento y uso de principios de ingeniería robustos, orientados a obtener software económico que sea flexible y funcione de manera eficiente sobre maquinas reales “
Fritz Barner
La ingeniería de software es una disiplina de la ingeniería que comprende todos los aspectos de la producción de software desde las etapas iníciales de la especificación del sistema, hasta el mantenimiento de este después de que ya se utiliza.
2.2 Historia de la ingeniería del software
La ingeniería en software es una rama muy joven de la ingeniería y por eso se encuentra en un estado de cambio rápido. La British Computer Society, por ejemplo, la primera ocasión en que ofreció el certificado Chartered Engineer a los ingenieros en software, fue al principio de la década de los 90’. En 1998 por primera vez fue posible registrarse como ingeniero de software profesional en un lugar en Estados Unidos.
De cualquier manera al inicio del siglo XXI se reconoce ampliamente que falta una disciplina a la forma en que las organizaciones desarrollan sus aplicaciones de software. Una estimación coloca al 75% de las organizaciones en un nivel primitivo.
2.3 Características del Software
1.- El software se desarrolla, no se fabrica en un sentido clásico
En esta actividad la buena calidad se adquiere mediante un buen diseño, el cual depende de las personas. Los costes de software se encuentran en la ingeniería, esto significa, que los proyectos de software no se pueden gestionar como si fueran proyectos de fabricación.
2.- El software no se estropea
El software no es susceptible a los mates del entorno que hacen que el hardware se estropee, por tanto la curva de fallos para el software al inicio puede tener un máximo pero después se minimiza y estabiliza.
3.- La mayoría del software se construye a la medida en vez de ensamblar componentes existentes
Con pocas excepciones no existen catálogos de componentes de software, se puede comprar software ya desarrollado pero solo como una unidad completa, no como componentes que pueden ser ensamblables en nuevos programas. Aunque se ha escrito mucho sobre reusabilidad del software solo estamos comenzando a ver las primeras implementaciones con éxito de este concepto.
2.4 Mitos del software
Mitos de Gestión
- Se cuenta con documentación y procedimientos para construir cualquier software.
- Tener computadoras muy potentes garantiza el desarrollo del software a través de desarrollo de herramientas CASE.
- Horda mongoliana
Mitos de Gestión
- Solo los objetivos generales importan para empezar a desarrollar
- Que el software es flexible y pueden hacerse cambios fácilmente.
Mitos de los desarrolladores
- Solo con hacer funcionar los programas es suficiente
- Solo se ve la calidad del software ejecutando el programa
- Solo se entrega el programa al terminar el proyecto
2.5 Capas de la ingeniería del Software
Independientemente da la complejidad del sistema la ingeniería de software puede considerarse una tecnología multicapa donde la primera capa enfatiza los cimientos de la ingeniería de software está orientada a la calidad.
Donde el proceso es el conjunto de actividades, métodos, práctica y tecnologías aplicables a todos los proyectos de software.
Los métodos o modelos de la ingeniería de software indica cómo realizar los pasos necesarios del ciclo de vida.
Las herramientas ayudan a organizar tareas de trabajo, controlar y supervisar los procesos y administrar la calidad técnica. Su objetivo principal es proporcionar un soporte automático o semiautomático, para los métodos y para los procesos.
2.6 El proceso del software
Un proceso del software es u conjunto de actividades y resultados asociados que producen un producto de software.
Existen cuatro actividades fundamentales del proceso que son comunes para todos los proceso del software:
1.- Especificación del software: Donde los clientes e ingenieros definen el software a producir y las restricciones sobre su operación.
2.- Desarrollo del software: Donde el Software se diseña y se programa
3.- Validación del Software: Donde el software se valida para asegurar que es lo que el cliente requiere.
4.- Evaluación del Software: Donde el software se modifica para adaptarlo a los cambios requeridos por el cliente y el mercado.
Suscribirse a:
Entradas (Atom)
