PDF- -Calidad del software - Calidad en El Desarrollo de Software

Description

CALIDAD EN EL DESARROLLO DE SOFTWARE Guillermo Pantaleo

CALIDAD EN EL DESARROLLO DE SOFTWARE Guillermo Pantaleo

Pantaleo,

Guillermo Calidad en el desarrollo de software

- 1a ed

23x17 cm

ISBN 978-987-1609-23-9 1

Informática

Programación

Título CDD 005

Guillermo Queda prohibida la reproducción total o parcial de esta obra,

su tratamiento informático y/o la transmisión por cualquier otra forma o medio sin autorización escrita de Alfaomega Grupo Editor Argentino S

Revisión de estilo: Romina Yael Ryzenberg Diagramación: Melina S

Daffunchio Internet: http://www

mx Todos los derechos reservados © 2011,

por Alfaomega Grupo Editor Argentino S

Paraguay 1307,

oficina 11 ISBN: 978-987-1609-23-9 Queda hecho el depósito que prevé la ley 11723 NOTA IMPORTANTE: la información contenida en esta obra tiene un fin exclusivamente didáctico y,

no está previsto su aprovechamiento a nivel profesional o industrial

Las indicaciones técnicas y programas incluidos han sido elaborados con gran cuidado por el autor y reproducidos bajo estrictas normas de control

Alfaomega Grupo Editor Argentino S

no será jurídicamente responsable por: errores u omisiones

daños y perjuicios que se pudieran atribuir al uso de la información comprendida en este libro,

ni por la utilización indebida que pudiera dársele

Los nombres comerciales que aparecen en este libro son marcas registradas de sus propietarios y se mencionan únicamente con fines didácticos,

por lo que Alfaomega Grupo Editor Argentino S

no asume ninguna responsa bilidad por el uso que se dé a esta información,

ya que no infringe ningún derecho de registro de marca

Los datos de ejemplos y pantallas son ficticios,

a no ser que se especifique lo contrario

Los hipervínculos a los que se hace referencia no necesariamente son administrados por la editorial,

por lo que no somos responsables de sus contenidos o de su disponibilidad en línea

Empresas del grupo: Argentina: Alfaomega Grupo Editor Argentino,

Paraguay 1307 P

Buenos Aires,

Argentina,

1057 Tel

Pitágoras 1139,

Del Valle,

México,

México,

03100 Tel

Sin costo: 01-800-020-4396 E-mail: [email protected] Colombia: Alfaomega Colombiana S

Carrera 15 No

64 A 29,

Bogotá,

Colombia PBX (57-1) 2100122

La Sierra 1437,

Providencia,

Santiago,

Chile Tel

Agradecimientos Gracias a mi familia por apoyarme siempre en mi postura de trabajar sólo en los proyectos que me gustan,

los que me hacen crecer como profesional y que permiten expresarme con honestidad

Gracias a mis alumnos por obligarme a mantenerme siempre actualizado y despierto para responder consultas e inquietudes de futuros profesionales que no se conforman con respuestas superficiales

Gracias a mis colegas,

clientes y empleadores porque de ellos aprendí lo que se debe y a veces lo que no se debe hacer en las más diversas situaciones

Gracias a mi amigo Juan D

Rogers por las innumerables y acaloradas charlas,

de allí aprendí los conceptos de administración del cambio en los procesos de mejoras

Gracias a la Ingeniera Patricia Forradellas por el tiempo compartido en it-Mentor,

empresa que fundamos juntos en la que analizamos y dicutimos muchos de los conceptos expuestos en este libro

Gracias a Guillermo Rugillo,

Diego Montaldo y Patricia Forradellas por las revisiones de los borradores y los muchos comentarios útiles que contribuyeron a que las ideas expuestas en este texto tengan más claridad y hayan sido expresadas de forma más inteligente

Gracias a mis alumnos Maia Naftali,

Israel Diego Lalo y Germán Castignani por el aporte de los casos de estudio de empresas a mejorar presentados en este libro

Gracias a los responsables de la editorial por la confianza dispensada y la apuesta a esta publicación

Gracias al editor ya que con sus revisiones y análisis hizo de mis escritos un libro

El autor IngenIero guIllermo Pantaleo El autor,

Guillermo Pantaleo,

es ingeniero en Telecomunicaciones recibido en la Universidad Nacional de La Plata,

Argentina

Su experiencia de treinta años en el desarrollo de software comenzó en el Instituto de Ingeniería Biomédica de la UBA (Universidad de Buenos Aires) haciendo docencia e investigación en procesamiento digital de señales

Participó en numerosos seminarios,

congresos y es autor de publicaciones científicas nacionales e internacionales

Fue miembro del Comité Organizador de la Primera y Segunda Reunión de Trabajo en Procesamiento de la Información e integró el Centro de Informática,

Computadoras y Procesamiento de la Información de la UBA donde trabajó en el desarrollo de un sistema autónomo de procesamiento de señales de perfiles de pozos petroleros

Como programador independiente desarrolló software para el mercado de instrumentación y telefonía

Fue contratado por empresas nacionales e internacionales como programador senior y formador de recursos humanos

Participó en proyectos de desarrollo en las áreas de telecomunicaciones y finanzas

Como líder de proyectos y miembro del SEPG (Software Engineering Process Group) participó en el proceso de certificación CMM3 de un software factory

En la actualidad,

como socio fundador de it-Mentor,

empresa dedicada a la capacitación y acompañamiento para el desarrollo de software,

diseña y desarrolla procesos de mejoras orientados a actualizaciones tecnológicas y a certificaciones CMMI e ITIL

Se desempeña como docente en cursos de actualización y especialización en temas relacionados a procesos de desarrollo,

relevamiento e ingeniería de requerimientos así como análisis y diseño de software

Es profesor de las materias: Técnicas de Diseño,

Arquitectura de Software y Calidad en el Desarrollo de Sistemas en la Facultad de Ingeniería de la UBA (Universidad de Buenos Aires)

Prólogo La economía moderna está completamente permeada por sistemas de software

Una proporción cada vez mayor de los productos industriales contiene algún elemento electrónico gobernado por un programa de complejidad cada vez mayor: desde los sistemas administrativos,

dispositivos de consumo y hasta los artefactos para el hogar

El papel del software en toda la gama de bienes y servicios de la economía crece sin detenerse,

y con este crecimiento viene aparejada la importancia de la calidad del software,

la que también se brindará a todos esos bienes y servicios en los que se encuentra instalado

Muchos usuarios de computadoras reconocerán la experiencia de la pantalla azul,

con un mensaje críptico que señala un error incomprensible,

seguida de la pérdida de su trabajo

Cada vez más artefactos y procesos están expuestos a circunstancias parecidas

Si ocurre en un sistema de control de un automóvil,

el resultado puede ser que este detenga su marcha o,

que tome una marcha incontrolable

En resumidas cuentas,

debido al papel creciente del software las demandas sobre su calidad también han aumentado

La complejidad del software y del proceso de su producción agrega urgencia a este tema porque los factores que inciden en su calidad son muchos y muy variados

El software generalmente se produce en el contexto de una organización poblada de especialistas en toda una gama de actividades técnicas,

La especialización de los participantes a menudo desafía la intuición y convierte a la gestión de calidad de software en una tarea muy difícil sin procedimientos fácilmente convertibles en rutinas de acción

Tal como se desprende claramente de esta obra,

hay una combinación de factores técnicos y no técnicos que afectan la calidad del software que no está comprendida en la descripción de tareas de un grupo especialista en particular

Por este motivo,

no se puede aglutinar la mayor parte de la responsabilidad del control de calidad a una división de la organización,

ya que está diseminada y difundida por toda la operación sin límites claros en las responsabilidades de sus distintos miembros

El desafío de liderazgo en la gestión de organizaciones productoras de software es muy complejo pues muchos proyectos de gran envergadura tienen suficientes diferencias entre sí que demandan una reorientación de la organización para encarar cada uno si desea mantener los más altos niveles de calidad en forma sostenida

Requiere no sólo vigilancia constante para lograrlo,

sino también una capacidad de

CALIDAD EN EL DESARROLLO DE SOFTWARE

aprendizaje y una adaptación continua para superar y aprender de los inevitables errores que ocurren en proyectos de gran complejidad

Una manera clásica de enfrentar la complejidad de una tarea es aplicar la división del trabajo

Se trata de dividirla en pedazos más pequeños,

y delegar cada parte a distintos ejecutores

Si bien se aplican principios de la división del trabajo en la producción de software,

como son los sistemas modulares,

el diseño apropiado de arquitecturas de sistemas,

la producción de software no admite una compartamentalización muy profunda de la gestión de calidad

Un principio conocido como la “ley de Conway” en la producción de software señala que la dinámica de comunicación de los equipos entre los que se dividieron las tareas del sistema se trasladará casi directamente a la operación con sus beneficios y sus fallas

Lo más importante es destacar que muy a menudo el fenómeno pasa completamente desapercibido por los diseñadores,

En este contexto frecuentemente se generan situaciones conflictivas dentro de las organizaciones productoras de software pues la cadena de interdependencias de los sistemas propaga los efectos de los problemas en forma impredecible y sus fuentes son difíciles de aislar cuando provienen de combinaciones de factores distribuidos

Aun cuando el diagnóstico de la operación de una organización sea recibido en forma consensuada,

la implementación de un proceso de mejoras necesario para elevar los niveles de calidad del software producido se vive como una profunda crisis organizacional que requiere de una altísima destreza de gestión

Las mejoras de proceso casi siempre conllevan cambios en la organización

La gestión de cambio organizacional es la misión más difícil para la cual la gran mayoría de los gestores no está preparada

Toda la economía moderna en su orientación reciente al valor del conocimiento en todas las actividades ha acrecentado la necesidad de la atención a los detalles para mantener la competitividad de los productos en mercados cada vez más exigentes

El caso del software no sólo no es una excepción sino que está en el centro de esta dinámica económica global

Como dijimos antes,

de la calidad del software depende la calidad de una gama virtualmente omnipresente de otros productos y procesos

A esto se agrega la dificultad especial del problema de la calidad de software y no puede evitarse la conclusión de su importancia crítica

Esta obra de mi colega y amigo,

el Ingeniero Guillermo Pantaleo,

es una contribución clave en este contexto

Sin duda tendrá un efecto educativo para estudiantes,

principiantes y experimentados,

pero también un efecto indirecto económico: es el único camino hacia un negocio de software con rentabilidad sustentable

Rogers Georgia Institute of Technology

Alfaomega

Calidad en el desarrollo de software

Prefacio Este libro fue concebido como una guía de estudio para los estudiantes de las disciplinas Ingeniería Informática y Análisis de Sistemas,

y una referencia de consulta para los profesionales que desarrollan sus actividades desempeñando roles asociados a tareas de gestión y técnicas en proyectos de desarrollo de software

Los estudiantes encontrarán un medio de relacionar conocimientos adquiridos a veces como entidades aisladas cuando en realidad forman parte de un todo en cuyas relaciones se fundamenta su comprensión

Los profesionales encontrarán respuesta a muchos de los problemas que se les presentan a diario,

un análisis de estos y una propuesta de solución

El objetivo es cubrir aspectos del desarrollo de software que son claves y en los cuales se debe trabajar bien a efectos de garantizar la calidad de los productos generados en los proyectos de desarrollo

Este manual fue escrito pensando en los obstáculos que se presentan a la hora de llevar adelante un proyecto de desarrollo

Busca las causas de dichos problemas y guía al lector en la búsqueda de las soluciones a los problemas mencionados a partir de la formación de criterios elaborados en función de la experiencia que como desarrollador de software recogí a lo largo de 30 años en los escenarios más diversos

Al igual que las materias a mi cargo en la Facultad,

el sesgo que presenta este libro es aportar soluciones a los diferentes problemas a partir del análisis de cómo estos se presentan

Por esta razón cuando se presentan los temas asumo que el lector los conoce por haber estudiado y trabajado

También que,

se le presentan dificultades para garantizar la calidad de los productos de sus proyectos mientras desarrolla las tareas de su especialidad

Para enfocarnos en este escenario,

este no podría ser un libro en el cual teoricemos acerca del significado de algunas de las palabras claves del tema,

sino que analizaremos cada tema en un contexto teórico introductorio y estableceremos criterios y un conjunto de buenas prácticas como solución

Hay excelentes libros que tratan los conceptos teóricos,

los que recomendaré a lo largo de los distintos capítulos

También hay muy buenas referencias para cada uno de los temas de gestión y técnicos que asumo,

conocidos por los lectores y que referenciaré en todos los párrafos donde trate los temas relacionados

Las fuentes de los problemas claves y críticos que atentan contra la calidad en el desarrollo de software se encuentran en el trabajo realizado con los requerimientos,

en la gestión de los proyectos,

en la forma de trabajo utilizada para realizar el diseño,

la codificación y las pruebas y en la estructura y dinámica de la organización

Por lo tanto nos ocuparemos de ellos poniendo énfasis en las cuestiones esenciales que hacen al deterioro de la calidad

Analizaremos los aspectos de cada uno de estos temas y cuáles son los puntos críticos a tener en cuenta

CALIDAD EN EL DESARROLLO DE SOFTWARE

No trataremos cómo escribir casos de uso,

para qué serán utilizados y de qué manera

Sí trataremos acerca de los atributos de calidad que los casos de uso deben contar

No trataremos cada uno de los temas asociados a la gestión de los proyectos,

sino aquellos en los que los líderes fallan y después de analizar estos errores elaboraremos una guía acerca de cómo conducir los diferentes aspectos del desarrollo

Trataremos la falta de estrategias para la gestión de proyectos y recomendaremos formas de resolver esta falencia

Presentaremos una forma de trabajo para llevar adelante las tareas técnicas de los proyectos,

conocida como Integración Continua,

la cual es propuesta como la solución al problema de contar en cada momento del proyecto con un producto que muestre con precisión y realismo lo realizado hasta entonces

Todas y cada una de las soluciones propuestas necesitan del contexto apropiado para ser llevadas adelante

Por esta razón analizamos las empresas cuyo negocio es el desarrollo de software desde la perspectiva de una organización que debe generar las condiciones para las soluciones propuestas

En estos temas hemos incluido aspectos relacionados a la mejora de procesos,

liderazgo y conocimiento organizacional

Como puede verse de esta presentación resumida,

éste no es un libro dedicado solo a los roles de gestión,

tampoco está orientado a los roles técnicos

Este libro está dirigido a todos los involucrados en el proceso de desarrollo de software que participan en un proyecto llevando adelante las diferentes tareas

Mucha gente no entiende un punto fundamental,

éste es un negocio en el cual se debe trabajar en forma interdisciplinaria

Cuesta mucho esfuerzo que la gente lo entienda y mucho más que se mantenga convencida a lo largo del tiempo

Por esta razón incluimos una sección donde analizamos la forma de trabajo para mantener este equilibrio inestable

Analizamos metodologías conducidas por los planes y ágiles,

los aspectos positivos y negativos de las mismas y el impacto de su selección

Este es un libro dedicado a todos los roles,

miembros de QA (Quality Asurance),

Puede parecer demasiado ambicioso este objetivo,

sin embargo los mayores problemas que deterioran la calidad en este negocio se deben a que estos roles consideran que poseen actividades tan específicas que no pueden compartir con el resto y que por ello se hace casi necesario trabajar cada uno en su hábitat

Esta falta de comunicación y ausencia de criterios comunes son las que se busca resolver a partir de una visión unificada y compartida

Los temas serán presentados de la forma que lo fueron hecho a lo largo de años de docencia en diferentes materias relacionadas al desarrollo de software y son el resultado de mi presentación como docente y del análisis,

Además son el producto de conclusiones elaboradas con mis alumnos y de conclusiones elaboradas a partir de mi experiencia y están presentadas de manera abierta y sin prejuicio ninguno

Es seguro que los promotores de modelos de tipo CMMi nos critiquen por falta de formalidad y los adeptos a las metodologías ágiles lo hagan porque nos vean burocráticos

Bienvenidas todas las opiniones,

nos ayudarán a aprender y quizás a mejorar nuestros razonamientos para futuras exposiciones

El autor

Alfaomega

Calidad en el desarrollo de software

Contenido Agradecimientos

5 Autor

7 Prólogo

9 Prefacio

3 Madurez

2 Modelos

y canal de comunicación entre ellas

con los miembros de las áreas

73 Caso 1

7 3 Caso 2

74 Caso 3

2 Nivel

3 Vista

2 Paquetes

Alfaomega

CALIDAD EN EL DESARROLLO DE SOFTWARE

1 Problema

4 Fases,

1 Visión

4 Riesgos

1 Roles

Calidad en el desarrollo de software

de proyectos para cubrir sus responsabilidades

6 Acciones

4 Pruebas

1 Pasos

Guillermo Pantaleo

- CMMI 7

4 |Madurez

Alfaomega

Apéndice Apéndice

Alfaomega

CALIDAD EN EL DESARROLLO DE SOFTWARE

Procedimiento de trabajo con código compartido (cc) en ambiente de Ic

205 Roles

206 Salida

Calidad en el desarrollo de software

Capítulo 1: Calidad en el software 1

3 Madurez

… … … … … … … 25 1

2 Modelos

Lo hacemos desde una perspectiva histórica porque pensamos que la mejor forma de aprenderlo es a partir de los sucesos que lo afectaron a lo largo del tiempo

En definitiva,

observaremos de qué manera y frente a qué acontecimientos se fue dando forma al concepto de calidad en el software como lo conocemos al día de hoy

como el que se muestra en la figura 1

Narraremos los sucesos más importantes y los hitos que constituyeron un cambio en la evolución que nos ocupa

Para aquellos que deseen leer acerca de esta secuencia de hechos en forma detallada y analizados con mayor profundidad pueden consultar el libro de Michael Cusumano1

Michael

The Business of Software: What Every Manager,

Programmer,

and Entrepreneur Must Know to Thrive and Survive in Good Times and Bad

Reed Business Information

Alfaomega

Calidad en el desarrollo de software

CAPÍTULO 1

CALIDAD EN EL DESARROLLO DE SOFTWARE

En la figura anterior se puede ver que nuestra historia comienza en la década del 50

Después de la Segunda Guerra Mundial los importantes avances en el desarrollo de software tuvieron lugar en los Estados Unidos de América (EE

) y se generaron en el ámbito de la insdustria militar

Controles de tiro y de navegación aérea fueron las áreas en las cuales se trabajó con mayor dedicación y recursos

En aquella etapa de la evolución del software las aplicaciones eran desarrolladas para un hardware dedicado,

para sistemas que contaban al software como una de sus partes

La bondad (calidad) asociada a estos sistemas se lograba con pruebas exaustivas una vez terminado de construir

Entre los participantes se pueden mencionar Digital Equipment Corporation (DEC) e IBM

No existen registros públicos acerca de las fallas detectadas y los errores cometidos

Una de las características salientes de estos sistemas era la estabilidad de los requerimientos,

lo que los diferencia de manera importante de los desarrollos de hoy día

Con los avances en la tecnología electrónica (hardware) y la aparición de lenguajes de alto nivel se estableció una nueva tendencia en el desarrollo,

se comenzaron a producir sistemas no militares e independientes del hardware

Entre estos tipos de sistemas podemos citar a los de reservación de pasajes para aerolíneas (SABRE) como uno de los primeros y más importantes desarrollos comerciales

En la década siguiente,

los avances fueron muy importantes y estuvieron conducidos por grandes inversiones en universidades y en la industria,

y orientados a producir sistemas de propósito general

Estos avances en las plataformas y lenguajes hicieron que estos nuevos desarrollos crecieran en sofisticación

Ya para esta época empresas de todas partes del mundo desarrollaban productos que buscaban la compatibilidad con IBM

Se trabajaba,

Fujitsu y Hitachi

A su vez vieron la luz otros sistemas propietarios ofrecidos por Honeywell,

Bull y Nec

Además,

ya había cincuenta empresas grandes abocadas al desarrollo de software y unas tres mil pequeñas

En esta etapa,

los sistemas resolvían problemas Alfaomega

Calidad en el desarrollo de software

en las áreas de explotación de petróleo,

compañías de seguros y ventas en grandes mercados minoristas

Entre 1963 y 1966 ocurrió un suceso que marcó un punto de cambio en esta evolución

Este evento surgió a partir de los inconvenientes de sobrepresupuesto y tiempo adicional necesarios en la terminación del proyecto de desarrollo del sistema operativo OS/360 de IBM

Este fue uno de los mayores proyectos de la época y generó un alerta en el sentido de la necesidad de contar con métodos de desarrollo que garantizaran la calidad de los productos de software

Como resultado de esto,

Frederick Phillips Brooks Jr

que hasta el día de hoy es un best seller2,

donde volcó la experiencia recogida en el proyecto

Estos acontecimientos fueron nombrados como la “crisis del software”

Pero esta alerta generó,

además de la aparición del libro citado,

el convencimiento de la necesidad y los primeros esfuerzos en la creación de una nueva disciplina llamada Ingeniería de Software (1980)

En estos años ya se trabajaba en la modalidad de software factory en Japón,

como Cusumano indica: “con buenos resultados en lo referente a la calidad de sus productos aunque a entender de algunos autores con capacidad de innovación limitada”

En 1987 se creó el SEI (Software Engineering Institute) a instancias del Department of Defense de EE

En este instituto trabajaron personas como W

Humphrey3,

miembro de IBM y mentor junto a otros del modelo Capability Maturity Por ese entonces estaba claro que el desarrollo de software consistía en administrar el proceso de construir un producto o un sistema que cubriera las necesidades de los usuarios,

instalarlo en el ambiente productivo,

mantenerlo y hacerlo evolucionar con los cambios del negocio

Por lo tanto un aspecto de la calidad vinculado al software consistía en llevar adelante este proceso de forma que permitiera al proyecto asociado terminar en el tiempo planificado y dentro del presupuesto asignado

Model (CMM)

Estos fueron los primeros pasos en la dirección de dar forma al concepto de calidad tal cual lo conocemos

En relación con esto,

en el capítulo cuatro nos ocuparemos del trabajo con los requerimientos vinculados a las necesidades mencionadas

En el capítulo cinco analizaremos los aspectos claves de la administración de los proyectos de desarrollo y en el capítulo seis presentaremos una propuesta de solución al problema de las pruebas utilizando integración continua

Mientras esto sucedía,

la tecnología seguía avanzando y se contaba con plataformas de bajo volumen y bajo costo que ofrecían la posibilidad de desarrollar software como una oportunidad de negocio a gran escala

Entonces apareció la Personal Computer (PC) como consecuencia del avance alcanzado en el desarrollo 2|Brooks,

Frederick

The Mythical Man-Month: Essays on Software Engineering

Addison Wesley

Managing the Software Process

Reading,

MA: Addison-Wesley

Guillermo Pantaleo

Alfaomega

CAPÍTULO 1

CALIDAD EN EL SOFTWARE

También asomaba al mundo una empresa llamada Microsoft,

productora del sistema operativo para estas plataformas llamado DOS

Por aquellos días volvió a trabajar a su país,

Demming,

quien había ayudado a dar sustento estadístico a la tradición de trabajo para generar productos de calidad en el Japón4

En ese entonces acuñó una frase que se hizo famosa y que de alguna manera sustancia la esencia del concepto de calidad: “The quality of a product is directly related to the quality of the process used A partir de esta aseveración,

en una organización se definió como mejora de procesos en el software (SPI-Software Process Improvement) al conjunto de tareas llevadas adelante con el objetivo de generar productos de mejor calidad a partir de la revisión y adaptación de sus procesos y la incorporación de nuevos

lo que significa que “la calidad de un producto está directamente relacionada al proceso utilizado para crearlo”

Estos temas los trataremos en el capítulo tres,

en el que analizaremos las mejoras y el impacto en las organizaciones

En el capítulo siete utilizaremos el modelo CMMi (ver Modelos de calidad de software en este capítulo)

También deseamos enfatizar un aspecto clave de la instalación en las organizaciones del concepto de calidad a partir de otra referencia a W

Demming,

quien en una conferencia dijo: “If Japan can… Why Can´t We

cuya traducción es: “Si los japonese pueden… ¿Por qué no podemos nosotros

En aquel reportaje explicó de qué forma el respeto de las organizaciones por sus miembros constituía la clave en la asimilación de procesos que generaban productos de excelente calidad

En la década de 1990,

el crecimiento de los sistemas se acentuó,

con protagonistas como Microsoft,

ya convertida en líder mundial,

Netscape,

Oracle y otros

Se desarrollaron sistemas como el operativo NT,

uno de los más importantes del momento

Además se consolidaron las metodologías de desarrollo de tipo iterativas las cuales van suplantando a las conocidas como cascada

Aparecieron algunas metodologías llamadas ágiles y el concepto de integración continua,

y también se sigue trabajando en IVV (Independ Verification Validation),

temas que trataremos en el capítulo seis

Estas formas de trabajo tienen una fuerte influencia en la calidad del software

En 1994 fue publicado el informe del Standish Group llamado Caos Report6,

el cual analizaremos en profundidad en el próximo capítulo,

para miles de proyectos de desarrollo,

las causas que atentan contra la calidad del software

También debemos mencionar el nacimiento y crecimiento del software libre como uno de los impulsores de importantes avances en esta época

Nuestra historia arriba entonces a los años 2000-2010 donde el escenario 4| Deming,

Out of the Crisis

Cambridge

MA: MIT Center for Advanced Engineering Study

Mary & Tom

Implementing Lean Software Development

Addison Wesley

Standish Group

Alfaomega

Calidad en el desarrollo de software

establecido para el desarrollo de software está determinado por un hardware cada vez más poderoso,

software de última generación (lenguajes orientados a objetos,

arquitecturas orientadas a servicios),

ITIL) y metodologías ágiles (XP,

Arribamos a este estado de cosas luego de que en 1995 se implementara Este escenario es propicio para destacar el otro aspecto vinculado a la calidad del software,

el relacionado a los atributos de calidad de los productos generados

En los sistemas enterprise de hoy algunos de los más representativos son confiabilidad,

mantenibilidad y tiempo de salida al mercado7

Internet a nivel global,

lo cual generó la utilización masiva de productos y servicios de software que condujo a la aparición de innumerables oportunidades de negocio

La degradación de estos atributos de calidad harán que la empresa pierda credibilidad,

con las consecuencias que ello implica en un mercado transparente

A mediados de la década del 90 se destacaron desarrollos como los navegadores de Netscape y Microsoft,

en los cuales se ensayaron las mejores prácticas de la época

Esto hizo que actualmente existan cientos de miles de empresas dedicadas a este negocio,

lo que condiciona el desarrollo a una dinámica sin precedentes

Esta velocidad creciente impuesta por el mercado de productos de software tiene un impacto importantísimo en la calidad de los productos y servicios ofrecidos

Es de notar que estos cambios en la evolución de esta industria hicieron que la preparación de los desarrolladores de hoy día sea muy distinta a la que tenían aquellos programadores de sistemas integrados a un hardware dedicado y con requerimientos estables de los años cincuenta

durante su corta vida ha atravesado diferentes etapas de las cuales aprendió la lección: la calidad es un valor en sí mismo y no un gasto que las empresas deben realizar para que su negocio prospere

Sin embargo,

esta ingeniería es como una dama de la cual todos alguna vez se enamoran pero que muy pocos están dispuestos a desposar

Digo esto porque es muy común encontrarse con proyectos que generan productos de dudosa calidad debido a que los responsables decidieron no realizar tareas de revisión de diseño y código o determinadas pruebas porque dilatan el tiempo de salida al mercado,

cuestan dinero y además no habrá diferencia entre uno y otro producto cuando el proyecto termine

En mi opinión estas lecciones no aprendidas se deben a la falta de madurez de conceptos aprendidos de forma cruenta y en escenarios continuamente cambiantes

En este punto,

haremos referencia otra vez a W

Demming,

quien en su libro Out of the Crisis,

para definir su visión del concepto de calidad,

expresó: “Provide for the long range needs of the company

don´t focus on short term profitability

The goal 7| Offutt,

Quality Attributes of Web Software Applications

IEEE Software

Guillermo Pantaleo

Alfaomega

CAPÍTULO 1

CALIDAD EN EL SOFTWARE

is to stay in business and provide jobs”,

lo que significa que es mejor “proveer para las necesidades de largo plazo de las empresas y no focalizarse en las ganancias inmediatas

el objetivo es perdurar en el negocio generando trabajo”

Si bien estas definiciones son conocidas desde hace mucho tiempo y además compartidas por la comunidad informática,

un porcentaje importante de las empresas continuan funcionando de manera exactamente opuesta,

es decir acortando cada vez más los presupuestos orientados a garantizar la calidad y priorizando los objetivos de cortísimo plazo

Las consecuencias de percibir la calidad como un gasto del cual se puede prescindir genera el estado de situación en relación con el desarrollo de software que analizaremos en el próximo capítulo,

en el que mostraremos diversos casos en los cuales se relegaron la validación y verificación de los sistemas

Una causa de falta de sistematización y automatización que contribuye a la baja calidad es el no acuerdo entre los participantes de los grupos de desarrollo acerca de las mejores prácticas a aplicar en los proyectos

Este es un síntoma observado con frecuencia en la comunidad infomática,

en la que el gerente tiene una opinión,

el líder técnico otra y el líder del proyecto una tercera

En general este fenómeno se produce cuando hay miembros que tienen una visión diferente acerca de si lo que se hace en la empresa es investigación,

Un error común en los programadores es creer que están haciendo investigación cuando en realidad la mayor parte de las empresas ligadas al negocio del software hacen desarrollo

Es verdad que los tiempos han cambiado y hoy la calidad parece tener otro valor que en los días de Demming

Sin embargo pensamos que sus afirmaciones siguen vigentes

Así fue que todo aquello que permitiera ser reutilizado fue adoptado como un elemento de valor por ser predecible y además bajar los costos

De este modo se generaron activos y procedimientos para su construcción en disciplinas como el trabajo con requerimientos,

Estos estándares fueron propuestos como una forma de garantizar la calidad de procesos y productos

Por ese motivo los tiempos de salida al mercado y de estabilidad de los requerimientos se acortaron de una manera impensada

Por esta razón se comenzó a cuestionar los estándares,

ya que estos proponían una forma de trabajo Alfaomega

Calidad en el desarrollo de software

cuya estabilidad contrastaba con la dinámica de la nueva etapa

Así fue que nacieron la metodologías ágiles (Mary and Tom Poppendiek),

a partir de que la comunidad comenzó a ponderar la creatividad y velocidad de adaptación a los nuevos escenarios por sobre el control y la predicibilidad en los proyectos

Este fenómeno de estabilidad de procesos versus creatividad ya se había percibido décadas atrás entre las software factory de Japón y la industria del software norteamericana,

cuando se analizó la calidad de excelencia de los productos orientales a expensas de la ausencia de nuevos productos,

los cuales eran ofrecidos por las empresas de EE

que trabajaban en un ambiente mucho menos controlado (Michael Cusumano)

hace algunos años se instaló una idea de moda

Esta vez consite en pensar que cuanto menos estructuradas sean las empresas,

mejor estarán posicionadas para enfrentar cambios y ganar nuevos negocios

Sin embargo,

como Cosummano muestra en su libro,

también están en condiciones mucho más vulnerables para perder todo lo realizado en solo unos meses

La razón de esto la explica W

Demming en su frase acerca de cuál es el objetivo de las empresas

Actualmente,

el desafío con respecto a garantizar la calidad en las organizaciones dedicadas al desarrollo de software es organizarse para que sus proyectos sean ordenados y predecibles

aunque deben a su vez tener la capacidad de dejar de lado estos procesos rápidamente para reorganizarse adaptándose a los cambios

Para esto es muy importante lograr madurez en estos procesos de manera de seguirlos cómodamente para que no se constituyan en una carga que aumente los costos e impida contar con agilidad para cambiar

Nos dedicaremos a tratar este tema en relación con los modelos de referencia como CMMi en el capítulo siete

con el objetivo de establecer formas estándares en las prácticas y activos de desarrollo aparecieron a lo largo de los años distintas normas y modelos de referencia

Los llamamos así porque constituyen la referencia al momento de implementar una mejora de procesos en una organización con el objetivo de aumentar la calidad de procesos y productos generados

Un fin para el cual se ha utilizado estos modelos ha sido la calificación,

clasificación y comparación de empresas por parte de los compradores de productos de software

El ejemplo más notorio,

es el del DoD y el modelo CMM,

Básicamente,

con ellos se buscó establecer estándares de organizaciones

La utilización inteligente de estos modelos contribuyó a mejorar los productos de software,

mientras que el mal uso generó frustraciones y despilfarro de recursos,

como analizaremos en el capítulo siete

En la década de 1990 el modelo CMM (Capability Maturity Model) se convirtió en el estándar de hecho a nivel global

Más tarde,

Guillermo Pantaleo

Alfaomega

CAPÍTULO 1

CALIDAD EN EL SOFTWARE

por su versión mejorada CMMi (Capability Maturity Model Integration)

Aquellos lectores interesados en alguno de ellos podrá encontrar también una referencia de dónde se puede encontrar información detallada

En el capítulo siete desarrollaremos en detalle el modelo CMMi por considerarlo el más focalizado al desarrollo de software

Los otros modelos mencionados si bien son más abarcativos,

porque incluyen procesos relacionados a aspectos administrativos y de formación de recursos humanos,

no tratan en detalle aspectos del desarrollo que se desean enfatizar por considerarlos críticos y claves

El modelo ITIL (Information Technology Infrastructure Library),

presenta entre sus componentes importantes el software como parte integrante de los servicios de IT (Information Technology)

▐ cmm (capability maturity model),

• Organización: SEI (Software Engineering Institute) • Información: http://www

Niveles Inicial Repetible Definido Gestionado Optimizado Áreas de proceso

▐ cmmi (capability maturity model Integration),

• Organización: SEI (Software Engineering Institute) • Información: http://www

Vistas por niveles y capacidades

Áreas de proceso

Grupos de áreas de procesos Ingeniería (7 áreas de procesos)

Alfaomega

Calidad en el desarrollo de software

Proyectos (5 áreas de procesos) Organizativas (6 áreas de procesos) ▐ tsP (team software Process) • Organización: SEI (Software Engineering Institute) • Información: http://www

edu/library/abstracts/ books/201731134

cfm ▐ Iso/Iec 15504 – Information technology – Process assessment,

• Organización: ISO (International Standard Organization) • Información: http://www

com/ • Características salientes ○

Establece un marco y los requisitos para cualquier proceso de evaluación de procesos y proporciona requisitos para los modelos de evaluación a ser utilizados

Proporciona también requisitos para cualquier modelo de evaluación de organizaciones

Proporciona guías para la definición de las competencias de un evaluador de procesos

Actualmente tiene 10 partes: 1-7 completadas y 8-10 en fase de desarrollo

Comprende: evaluación y mejora de procesos,

Proporciona en su parte 5 un modelo de evaluación de procesos para los procesos de ciclo de vida del software definidos en el estándar ISO/IEC 12207 que define los procesos del ciclo de vida del desarrollo,

mantenimiento y operación de los sistemas de software

▐ Iso/Iec 12207 Information technology / software life cycle Processes,

1995-2008

• Organización: ISO (International Standard Organization) • Información: http://www

Procesos principales Adquisición Suministro Desarrollo

Guillermo Pantaleo

Alfaomega

CAPÍTULO 1

CALIDAD EN EL SOFTWARE

Operación Mantenimiento ○

Procesos de soporte Documentación Gestión de la configuración Aseguramiento de calidad Verificación Validación Revisión conjunta Auditoría Resolución de problemas

Procesos de la organización Gestión Infraestructura Mejora Recursos Humanos

▐ PsP (Personal software Process),

Humphrey • Información: http://www

edu/tsp/ • Estructura nIveles ○

Nivel 2

Planeación de los proyectos

Nivel 3

Ingeniería del producto de software

Manejo integrado del software

Definición del proceso de software

Foco del proceso de software

Nivel 4

Control de calidad

Administración cuantitativa del proyecto

Nivel 5

Administración del cambio tecnológico

Prevención de defectos

PSP0: proceso base,

propuesta de mejoramiento del proceso(PIP)

PSP1: estimación del tiempo,

[Proceso personal de administración

[Proceso personal de administración

PSP2: revisión de codificación,

PSP3: desarrollo en ciclos

▐ ItIl (Information technology Infrastructure library),

• Organización: United Kingdom’s Office of Government Commerce (OGC) • Información: http://www

com/home/ • Estructura áreas de aPlIcacIón (versIón 1) ○

Administración de Servicios 1

Service Support

Service Delivery

Guías Operacionales

Guillermo Pantaleo

ICT Infrastructure Management

Security Management

The Business Perspective Alfaomega

CAPÍTULO 1

CALIDAD EN EL SOFTWARE

Application Management

Software Asset Management

Guías de Implementación 8

Planning to Implement Service Management

ITIL Small-Scale Implementation

ITIL Service Strategy

ITIL Service Design

ITIL Service Transition

ITIL Service Operation

ITIL Continual Service Improvement

Con el tiempo y por diferentes razones surgieron otros modelos inspirados en los anteriores que buscaron cubrir necesidades puntuales

Como por ejemplo el MOPROSOFT (Modelo de Procesos para la Industria del Software),

con el objetivo de ser aplicado a las pequeñas y medianas empresas dedicadas al desarrollo de software

Está inspirado en los niveles 2 y 3 del modelo CMM y en las normas ISO/IEC 15504

Algunos de los criterios con los que fue elaborado este modelo son los siguientes: •

Procesos estratificados según el organigrama típico de este tipo de organizaciones (gerencia alta,

La gerencia alta tiene como actividades centrales la de definir las estrategias de la organización y promover las mejoras continuas

La gerencia media es la encargada de proveer los recursos para los proyectos y monitorear el cumplimiento de las planificaciones orientadas a cumplir con los objetivos estratégicos

La operación es la encargada de llevar adelante los proyectos

Los procesos deben ser definidos de tal forma que mantengan entre ellos una relación integradora

El proceso de administración de proyectos es atómico

La ingeniería de productos es desarrollada con el soporte de otros procesos orientados a garantizar y controlar la calidad de los mismos (verificación,

documentación y control de la documentación)

Se le asigna especial atención a la administración de los recursos que apor-

Alfaomega

Calidad en el desarrollo de software

tan al conocimiento de la organización: productos generados por proyectos,

documentación de procesos y datos relevados de su implementación en los proyectos así como lecciones aprendidas

▐ moProsoft (modelo de Procesos para la Industria del software),

• Organización: Asociación Mexicana para la Calidad en Ingeniería de Software • Información: http://www

mx/ • Estructura categoría alta dIreccIón (dIr) Comprende la definición de las políticas,

los objetivos de negocio y las estrategias para su logro incorporando la información de la evolución de la organización a efectos de promover la mejora continua

Gestión de Negocio: establecer la visión y los objetivos de negocio que fijen el contexto para las actividades de la gerencia media y los proyectos

categoría gerencIa (ger) Comprende la gestión de los procesos,

proyectos y recursos de la organización de manera alineada con las políticas definidas por la gerencia alta

Informa a la gerencia alta acerca de la evolución de la organización

Gestión de Procesos: promover la definición e implementación de los procesos de la organización a partir de las necesidades expresadas por el plan estratégico

Coordinar y colaborar en la mejora de los procesos definidos

Gestión de Proyectos: Asegurar el desarrollo de los proyectos de manera alineada a los objetivos de la organización expresados en su plan estratégico

Gestión de Recursos: Administrar los recursos de la organización proveyendo a los proyectos

Promover y facilitar la administración del capital de conocimiento de la organización

Las actividades de este proceso son soportadas por tres subprocesos: ○

Recursos Humanos y ambiente de trabajo

Bienes,

Conocimiento de la organización

categoría oPeracIón (oPe) Comprende las prácticas de gestión y técnicas de los proyectos de desarrollo

Guillermo Pantaleo

Alfaomega

CAPÍTULO 1

CALIDAD EN EL SOFTWARE

Administración de proyectos específicos: estimar,

planificar y monitorear el desarrollo de los proyectos de desarrollo y la generación de los productos esperados

Desarrollo y mantenimiento de software: desarrollo de las actividades del ciclo de vida de productos nuevos o modificados (análisis,

integración y pruebas) alineadas con los requerimientos del proyecto

También surgieron organizaciones que orientaron sus actividades en torno a los modelos de calidad mencionados,

como es el caso de European Software Institute (ESI-Tecnalia)

Este es un centro tecnológico privado creado en 1993 por la Comisión Europea con el apoyo del gobierno Vasco y de empresas

Calidad II

THE THREE LINES OF DEFENSE IN EFFECTIVE RISK MANAGEMENT AND

aiu edu cursos Fundamentos de Calidad pdf Unidad II La Administración de la Calidad 2 1 Conceptos La administración de la calidad es la función organizacional cuyo objetivo es la prevención de defectos La responsabilidad de la administración de la calidad según Fergenbraurn (1983) son

Calidad ISO TS 16949

UNE-ISO/TS 16949 norma española - UPCommons

¿Qué es la Gestión de la Calidad Automotriz? ISO TS 16949 es el estándar de gestión de calidad para la industria automotriz reconocido mundialmente Reúne   ¿Qué es ISO TS 16949? ISO TS 16949 es la norma reconocida internacionalmente de sistemas de gestión de la calidad (SGC) específico para

Calidad Total 02

Administración de la calidad total

PDF Efectos de la Gestión de Calidad Total en la transformación Core core ac uk download pdf 82123313 pdf PDF Herramientas de la Calidad Total senati virtualvirtual senati edu pe pub cursos ict2 manual u02 ict2

Calidad Total_ Los 14 Puntos de Deming Explicados

CAPÍTULO 1-CALIDAD Y PRODUCTIVIDAD Sería muy difícil para

cursos campusvirtualsp pluginfile php 2332 de mostrar cuáles son las similitudes y las diferencias entre cada uno de los Modelos con el objeto de poder mediante la comparativa, identificar aquellos elementos que contribuyen de forma definitiva a la implantación de un sistema de calidad total 2

Calidad Total y Productividad 3ed - Humberto Gutierrez Pulido

facultad de ingeniería - Core

PDF Calidad Total Y Productividad Humberto Guti Rrez Book Libraryw ww sproutworld calidad total y productividad humberto guti rrez pulido pdf PDF Calidad Total Y Productividad Spanish Edition PDF Online PDF mimeeda breakinankles co uk

Calidad Total y Productividad.pdf

RedalycCalidad, Productividad y Costos: Análisis de Relaciones

PDF CAPÍTULO 1 CALIDAD Y PRODUCTIVIDAD Sería muy difícil para ingenieria unam mx ~dcayeros ac capitulo1 pdf PDF 04212c View Calidad Total Y Productividad (Spanish Edition) By 500mexicocity pdf Calidad 20Total 20y 20Productividad 20(Spanish 20Edition)

Calidad Ttal 2

Administración de la calidad total

2 Garantizar el nivel de calidad y eficiencia en las prestaciones 3 mejora de la Gestión de la Calidad Total en los centros del Insalud El Premio a la  Calidad Total ESTRUCTURA DEL MÓDULO Conceptos de Calidad y el

Calidad y Mejora Continua

proceso de mejora de la calidad - ULPGC

PDF Sistemas de Calidad y Mejora Continua ics aragon cursos gestion de calidad curso pdf PDF Gestión de Calidad y mejora continua en la Congreso 2 congreso gob pe 11 24 SEHUUHANIOFCFJXIULZDFPGJGJIXMCQFHXZBFAPNPUQUE PDF Mejora continua y calidad total

Calidad

La calidad social, un reto para la Unión Europea - Ministerio de

PDF CALIDAD apmarin download 691 cal1 pdf PDF ¿Qué es la calidad? facmed unam mx emc computo infomedic calidad pdf PDF Política de Calidad Egara Optiminnegaraoptiminn politica de calidad EgaraOptiminn pdf PDF Parámetros de

Home back Next
<