martes, 5 de marzo de 2013

Calidad de Software y Modelos de Madurez del Proceso

Link para descargar el documento en Word  http://search.4shared.com/postDownload/D9iVbvBD/calidad_software.html

Mejora del proceso de software y determinación de la capacidad
(ISO-15504 / SPICE)
El modelo de mejora del proceso de software y determinación de capacidad es un modelo de evaluación o determinación de la capacidad de los procesos, conocido también como la norma iso-15504.es una familia de normas internacionales que tiene como objetivo el desarrollo de sistemas de calidad en el software. Combina los enfoques de cmm con los de ISO-9000, incorporando al marco de referencia de ISO-9000 con la evolución de capacidad y madurez de proceso cmm.
Modelo de madurez de ingeniería de desempeño
El modelo de madurez de ingeniería de desempeño sirve para evaluar los niveles de integración, aplicación, ejecución y diseño, de la ingeniería de desempeño como modelo de mejora de procesos. El modelo sirve tanto para evaluar una organización como para mejorar los propios procesos de desarrollo. Sirve también para definir el criterio con el que se debe escoger a un proveedor de software para los productos críticos o semicritocs de la empresa.


Proceso de software en equipos (TSP)
El proceso de software en equipos extiende el modelo de psp e integra los aspectos del desarrollo de software realizados por equipos de trabajo, definiendo aspectos como la asignación y control de tareas para los diversos miembros del equipo. Tsp define un marco de trabajo en equipos con los objetivos de:
1.- Desarrollar productos en varios ciclos.
2.- Proporcionar métricas para equipos
3.- Evaluar roles y equipos
4.- Ofrecer guías para la solución de problemas en equipos.
Proceso unificado (UP)
Se enfoca en la especificación de requerimientos de un sistema mediante casos de uso. El proceso integra diferentes aspectos, como los ciclos, fases, flujos de trabajo, mitigación de riesgo, control de calidad, administración de proyecto y control de configuración, también considera los 4 aspectos fundamentales del desarrollo como: personas, proyecto, producto y proceso.
El proceso unificado se basa en las siguientes creencias:
- para construir un sistema exitoso se debe de conocer que quieren y necesitan los usuarios
- Construir un sistema se deba visualizar desde múltiples perspectivas
- el desarrollo de un producto puede significar un gran esfuerzo de trabajo de días, meses y hasta años. Es práctico dividir el trabajo en etapas, donde cada iteración resulta en un incremento del proyecto.
Calidad del software y modelos de madurez del proceso.
Para el Instituto de Ingenieros Eléctricos y Electrónicos es el grado en que un sistema, componente o proceso cumple con los requerimientos especificados y las necesidades del cliente o usuario.
En la definición de la norma ISO.9000 de la organización internacional para la estandarización la calidad del software es el grado en que un conjunto de características inherentes del software cumple con los requisitos del sistema.
La calidad del desarrollo de software está ligada con su proceso de desarrollo, los factores que más afectan la obtención de un producto de calidad son los siguientes:
- el cliente es el participante primordial en el proceso de desarrollo y es el responsable de definir los requisitos del producto final
- el desarrollador es el responsable del proceso de producción y garantizar la calidad del producto
- el proceso seguido para el desarrollo del producto final
-el producto correspondido al sistema al ser desarrollado
La evaluación de los procesos evita especificaciones anómalas o incompletas, aplicación correcta de metodologías, etc. Con el objetivo de calificar a los productos de una manera eficientes surge el Modelo de Madurez del proceso de producción de software, este modelo no solo apoya al desarrollo de software, también a la estandarización de la producción en toda la organización. Los modelos de madurez no se deben aplicar sin antes establecer y definir completamente los procesos de desarrollo.
Descargar en documento de Word

lunes, 4 de marzo de 2013

RELACIONES ENTRE ÁREAS DE PROCESO

Link para descargar ppt http://www.4shared.com/file/DVQDqUqX/Presentation1.html

RELACIONES ENTRE ÁREAS DE PROCESO
Relaciones clave que hay entre las
áreas de proceso Áreas de proceso de Gestión de Procesos

•  Definición de Procesos de la Organización (OPD).
•  Enfoque en Procesos de la Organización (OPF).
•  Gestión del Rendimiento de la Organización (OPM).
•  Rendimiento de Procesos de la Organización (OPP).
•  Formación en la Organización (OT).

Definición de Procesos de la Organización

establece y mantiene el conjunto de procesos estándar de la organización

Formación en la Organización

Identifica las necesidades estratégicas de formación en la organización

Áreas de proceso básicas de Gestión de Procesos

proporcionan a la organización la capacidad para documentar y compartir las buenas prácticas, los activos de proceso de la organización y el aprendizaje en toda la organización.

Áreas de proceso avanzadas de Gestión de Procesos

Las áreas de proceso avanzadas de Gestión de Procesos proporcionan a la organización una capacidad mejorada para lograr sus objetivos cuantitativos de calidad y de rendimiento del proceso.

Gestión del Rendimiento de la Organización

Las líneas base y los modelos de rendimiento de los procesos se analizan para comprender la capacidad de la organización para cumplir sus objetivos de negocio e inferir objetivos de calidad y de rendimiento del proceso.

Gestión De Proyectos
Cubre las actividades relacionadas con la planificación, monitorización, y control del proyecto
Siete áreas de gestión de proyectos:

Gestión Integrada del proyecto
Monitorización y control del proyecto
Planificación del proyecto
Gestión cuantitativa de proyecto
Gestión de Requisitos
Gestión de Riesgos
Gestión de acuerdos con los proveedores
Áreas de proceso básicas de Gestión de Proyectos

Tratan las actividades relacionadas con el establecimiento y mantenimiento del plan de proyecto
Establecen compromisos y los mantienen
Monitorizan el progreso del plan
Realiza acciones correctivas
Gestiona los acuerdos con los proveedores
Proceso de Planificación del Proyecto
Incluye :
 El desarrollo del plan del proyecto
Compromiso con el plan y el mantenimiento del mismo
 Comienza con los requisitos define el producto y el proyecto
El plan produce las actividades de gestión y desarrollo
Área de monitorización y control
Especifica la frecuencia de las revisiones del progreso
El progreso se determina con la comparación de proyecto con el plan.
Cuando el estado real se desvía significativamente de los valores esperados se toman acciones correctivas
Se toman acciones como re-planificación

Gestión de Requisitos
Controla los cambios y asegura que los planes estén actualizados
Asegura que los cambios se reflejen en los planes, actividades y productos del trabajo
Proporciona la actualización de los requisitos del cliente, producto y componentes del producto
Gestión de Acuerdos con Proveedores
Aborda la necesidad del proyecto de adquirir aquellas partes de trabajo que son realizadas por los proveedores
Se selecciona un proveedor y se establece un acuerdo para su gestión
El progreso y el rendimiento del proveedor se siguen según está especificado en el acuerdo con el proveedor y éste se modifica según sea necesario
Las revisiones y pruebas de aceptación se realizan sobre el componente de producto realizado por el proveedor.
Ingeniería

Problemas que
SOPORTE
Las áreas de proceso de Soporte cubren las actividades que dan soporte al desarrollo y al mantenimiento del producto.
Las cinco áreas de proceso de Soporte de CMMI-DEV son las siguientes:

Análisis Causal y Resolución (CAR).
Gestión de Configuración (CM).
Análisis de Decisiones y Resolución (DAR).
Medición y Análisis (MA).
Aseguramiento de la Calidad del Proceso y del Producto (PPQA).
Áreas de proceso básicas de Soporte


Las áreas de proceso básicas de Soporte tratan las funciones de soporte fundamentales que se usan por todas las áreas de proceso. Aunque todas las áreas de proceso de Soporte usan como entrada otras áreas de proceso, las áreas de proceso básicas de Soporte proporcionan funciones de soporte que también ayudan a implementar varias prácticas genéricas.

Áreas de proceso avanzadas de Soporte
Las áreas de proceso avanzadas de Soporte proporcionan a los proyectos y a la organización una capacidad de soporte mejorada. Cada una de estas áreas de proceso se apoya en las entradas o prácticas específicas de otras áreas de proceso.

Fallas en Desarrollo de Software



 Fallas en Desarrollo de Software
Múltiples eventos desafortunados por no darse a la tarea de probar su desarrollo exhaustivamente con costos ocultos que les generaron grandes cantidades de dinero, mala reputación e incluso hasta pérdidas de vidas.
Podemos remontarnos bastante tiempo atrás para descubrir errores ya causados por computadoras. La primera misión del programa Mariner (con costo total de la misión Mariner 1 hasta Mariner 10 de 554 millones de dólares) fracasó por culpa de un caracter incorrecto ('?') en la especificación del programa de control para el cohete de propulsión Atlas lo cual causó finalmente que el vehículo se saliera de curso. Ambos, el cohete y el vehículo espacial tuvieron que ser destruidos poco después del lanzamiento.Adicionalmente, se cree que un error de computadora también fue la causa del fracaso del Mariner 8 en 1971
En Noviembre de 1985, el Banco de New York (BoNY) tuvoaccidentalmente un sobregiro de $32 billones de dólares (¡una buena suma si consideramos que esto fue hace 15años!) por culpa de un contador de 16 bits (la mayoría de los demás contadores eran de 32 bits) que se activó ocasionando un "overflow" del contador que nunca fue verificado. BoNY no pudo procesar nuevos créditos de transferencias de "securities", mientras que la Reserva Federal de New York automáticamente hizo un traspasode $24 billones de dólares al BoNY para cubrir sus gastos por un día, por lo cual el banco tuvo que pagar $5millones de dólares por los intereses diarios, hasta que el software fue arreglado.
En Abril 1986 un avión de combate F-18 se estrelló por culpa de un giro descontrolado ("un recoverable spin") atribuido a una expresión "IF-THEN" para la cual no había una instrucción "ELSE" porque se pensó que era innecesaria, resultando en una transferencia fuera de control del programa.
El acelerador lineal médico, Therac-25, producido por AECL (AtomicEnergy of Canada Limited), fue diseñado para tratamiento a pacientes por medio de radiación de Rayos X dedos tipos: (i) tratamiento de rayo directo de bajo poder, y (ii) tratamiento de rayo indirecto reflejado de alto poder. Entre 1985 y 1987 este sistema ocasionó la muerte de varios pacientes en diferentes hospitales de USA y Canadá por culpa de radiaciones de alto poder aplicadas de manera incontrolada. La probable causa de los accidentes consistía en que para ciertas secuencias de comandos del operador de la máquina, los controles de la computadora llevaban la máquina a un estado interno erróneo y muy peligroso, generando una sobre dosis masiva de radiación al paciente. Después de amplia publicidad de estos accidentes se descubrió que la FDA(Federal Drug Agency) no especificaba requisitos, y no hacía revisiones sobre prácticas de desarrollo de software o control de calidad de software en dispositivos médicos. El FDA informó en Septiembre de 1987 que comenzaría a requerir controles de software integrados a ciertas clases de dispositivos médicos.
En julio de 1988 la fragata USS Vincennes estaba asignada al golfo pérsico. Después de repetidos intentos de comunicación por radio, el USS Vincennes disparó un misil (por error) derribando un avión Airbus comercial Iraní matando a todos los 290 pasajeros y tripulantes. Esto ocurrió mientras el Airbus ganaba altura, bajo la suposición incorrecta de que era un avión de combate F-14 que descendería sobre el barco de manera hostil. Aunque la orden de disparo fue dada por el comandante del navío,se culpa como causa contribuyente del incidente al sistema de radar AEGIS, el cual con su sistema de interface de usuario mostraba únicamente un punto junto a un dato textual representando al avión, en lugar del eco real del radar sobre el avión. Posteriormente se supuso que en algún momento la aerolínea Iraní estuvo en la proximidad de un F-14, probablemente durante el despegue del aeropuerto, confundiendo al sistema AEGIS y asociando de manera incorrecta la información transmitida por los "transponders" aire-tierra del F-14 a la aerolínea. Cuando el avión despegó, éste quedó asociado con los datos del F-14 sobre la pantalla. Un despliegue inconveniente y posiblemente confuso de la información de altitud del avión posiblemente confundió aún más a los oficiales del barco, los cuales supusieron que el F-14 estaba descendiendo, aunque en realidad estaba ganando altura. La inclusión de un eco real del radar sobre la pantalla hubiera hecho posible determinar que el eco del radar del avión era del tamaño incorrecto para un avión de combate.
El 15 de enero de 1990, AT&T (American Telegraph and Telephone) la compañía que controla las redes del mayor sistema de comunicación en el mundo, experimentó una falla masiva que dejó fuera de servicio su sistema de comunicaciones de larga distancia. La falla duró alrededor de nueve horas e interrumpió millones de llamadas de larga distancia. Un error en el software de manejo de excepciones de un tipo particular de sistema de switching telefónico resultó en una falla de switching , que a su vez causó otras fallas de switching
en un efecto cascada. Según Neuman, se reportó que la última causa del problema tuvo  origen en un programa en el lenguaje “C” que contenía una instrucción "BREAK" dentro de una cláusula "IF"dentro de una cláusula "SWITCH"
En abril de 1998 por un error de un equipo de ruteo de Cisco en uso por “AT&T” se propagó por cientos de equipo de ruteo en su red de alta velocidad, dejando fuera de servicio miles de cajeros automáticos y lectores de tarjetas de crédito.
En las primeras etapas de la guerra del golfo pérsico de 1991,el sistema Patriot fue descrito como altamente exitoso. En análisis posteriores, los estimados de su efectividad fueron disminuidos seriamente de 95% a 13% o incluso menos. El sistema fue diseñado para trabajar en un ambiente mucho más limitado y menos hostil que el que había en Arabia Saudita. Según reportó posteriormente el New York Times, una falla en la computadora de tierra del misil Patriot fue responsable de evitar la peor baja americana durante la guerra. Esto resultó en su inoperabilidad, permitiendo que un misil "scud" destruyera unas barracas militares americanas en Dhahran, Arabia Saudita, causando 29 muertos y 97 heridos. Aparentemente el sistema de radar del Patriot nunca vio al misil Scud. Según oficiales del ejército "una combinación imprevista de docenas de variables - incluyendo la velocidad, altura y trayectoria del Scud - causaron la falla del sistema del radar…[este caso fue] una anomalía que nunca apareció durante las horas de pruebas." El error se atribuye auna acumulación de inexactitudes en el manejo interno del tiempo de la computadora del sistema. Aunque el sistema ejecutaba según las especificaciones, éste debía ser apagado y prendido con la suficiente frecuencia para que el error acumulado nunca fuera peligroso. Como el sistema se usó de manera no planeada, una pequeña inexactitud significó un serio error. Después de 8 horas de uso se detectó el problema del reloj acumulado. La corrección sólo se logró al día siguiente de la catástrofe (Mellor, 1994; Schach 1997)
En 1990 un error de software ocasionó que un banco en el Reino Unido duplicara cada solicitud de transferencia de pago por un periodo de media hora,acumulando 2 billones de libras esterlinas adicionales. Aunque el banco expresó haber recuperado todos los fondos, se especuló que los posibles intereses perdidos pudieran haber llegado a medio millón de libras por día.
El 25 de Abril de 1990 se puso en órbita el famoso telescopio espacial Hubble desde el vehículo espacial Discovery. Al poco tiempo, NASA descubrió que el componente más crítico del telescopio de $4 billones de dólares, su espejo principal, tenía una gran falla,imposibilitando producir imágenes altamente enfocadas. El problema en su lente es técnicamente conocido como una "aberración esférica". Una investigación de la NASA reveló que el espejo se había construido con la forma incorrecta siendo 2 micrones (1 micrón = 10-6 metros) más plano a los lados de lo estipulado en el diseño original, un error bastante grande según los estándares de precisión de la óptica moderna. Este fue el error principal encontrado en el telescopio, considerando que hubo otros problemas adicionales, como en sus paneles solares, sus giroscopios, y contactos eléctricos. El problema del lente radicó en que nunca fue realmente probado antes de ser enviado al espacio. En su lugar, una simulación de computadora se usó como método de menor costo para validar el rendimiento del espejo. Por desgracia, malos datos de entrada se utilizaron en la simulación, significando resultados despreciables. Para corregir el error final en el espacio, se agregó al telescopio óptica correctiva a un costo muchas veces mayor que una prueba en tierra del espejo, significando además que el espejo nunca funcionaría tan bien como se planeó. Por lo pronto, la NASA no planea otro telescopio de la magnitud del Hubble, por lo cual los astrónomos tendrán que limitarse a las restricciones actuales del Hubble, con el cual sólo se pueden ver objetos aproximadamente 20 veces más grandes de lo original.