Etapas de desarrollo de software

Cmo se mide la calidad en el software?

Este artculo viene como referido al artculo de Rodrigo Corral, "En el software, la calidad, no es opcional". Qu es la calidad en el software?Se puede medir?Cmo? Cuando decimos que para nosotros la calidad es muy importante, a que nos referimos? En primer lugar quiero puntualizar las siguientes afirmaciones de dicho artculo:

Directivos y personal de Mrketin dan ms importancia al nmero de caractersticas que tiene un software que a la calidad, porque la calidad no se puede poner en un anuncio o en una oferta. Algunos directivos al mando de empresas que construyen software caen en el error de pensar en la produccin de software desde los parmetros habituales en otras industrias. La produccin de software es muy diferente, es un proceso creativo no un proceso manufacturero. (Lase ejemplo de bolgrafos en dicho artculo) La principal diferencia cuando 'fabricamos' software es que la calidad no es opcional, no puedes elegir fabricar software de baja calidad y rebajar el precio. Puedes restarle funcionalidad, pero no calidad. Nadie recuerda a quien hizo un buen software (de calidad), pero nadie olvida el que fallaba constantemente (os acordis de los pantallazos azules del w95?) Paradjicamente, y esto es un hecho, es que aadir calidad a nuestro software, al contrario de lo que puede parecer a primera vista, reduce los costes de desarrollo y acorta los plazos.

Y por ltimo quiero citar un prrafo textualmente: "He visitado empresas, con grandes carteles en recepcin del estilo "La calidad es nuestra esencia" o "La calidad al servicio del cliente" y con todas las certificaciones habidas y por haber de 'calidad' que no tienen ni un solo especialista en calidad del software, ni un solo especialista en probar aplicaciones. Y no, los desarrolladores, no son expertos en calidad y pruebas." Bien, dicho esto, y reflexionado sobre ello, podemos afirmar que en otros entornos percibimos la calidad perfectamente, cuando probamos un coche de gama alta, percibimos la calidad, y no tenemos conocimiento del proceso de produccin!, pero si palpamos la calidad, por ejemplo (y siguiendo con el ejemplo del coche), cuando aceleras sientes rendimiento, cuando tomas una curva y percibes estabilidad, cuando frenas, notas seguridad... realmente son indicadores ("mtricas"), que se podran medir y poner una puntuacin de calidad a cada vehculo. Vamos a intentar medir la calidad del software!! Primero vamos a intentar identificar los factores que desde un punto de vista externo definen la calidad del software, no me refiero a los procesos internos de desarrollo, como pruebas unitarias, gestin de cambios, calidad del cdigo... no!! me refiero a lo que se percibe, una vez el software est terminado, implantado y en produccin, lo que nota un usuario. Intentemos pensar (como ejemplo para evaluar la calidad) en un producto software..., uno de los primeros que desarrollamos o probamos, as veremos mejor su evolucin y evaluaremos la calidad teniendo en cuenta factores temporales.

Satisfaccin del cliente (se suelen hacer encuestas para obtener este dato)

Interfaz de usuario (usabilidad, accesibilidad, facilidad de manejo, curva de aprendizaje, diseo...) o Rendimiento de la aplicacin, Seguridad, Despliegue, Actualizaciones, Integracin con sistemas... o ... Nmero de bugs en produccin (bugs encontrados y la importancia de los mismos, se podra incluir en satisfaccin del cliente) Rentabilidad econmica (%, precio de venta - coste de desarrollo) o Este factor no es relevante para el usuario, pero tiene mucha informacin subliminal y por eso lo quiero incluir. Para m est muy ligada la rentabilidad a la calidad, por muchas cosas como la (la buena estimacin, buena planificacin, gestin, previsin, pruebas, buena arquitectura, buen cdigo, pocos bugs, aplicacin modular y bien preparada para el cambio...) por ello lo quiero incluir como factor a tener en cuenta, aunque no le afecte al cliente dirctamente, si indirectamente, ya que si el software es rentable, el cliente obtendr un mejor servicio, soporte, mantenimiento... en definitiva un buen producto...(bueno este es otro tema) Tiempo de vida por cliente (aos que el software est funcionando) o El usuario quiere algo que le satisfaga y si (por ejemplo) en el banco de Cuenca tienen una aplicacin Cobol, desarrollada hace 15 aos, que les satisface las necesidades actuales, desde luego que es un aplicativo con calidad. Al igual que un coche, de hecho es muy tpico ver mercedes de hace 20 aos rodando a diario por las carreteras. Nmero de clientes (clientes que tiene el software implantado y en produccin) o Otro factor importante es el nmero de clientes que tiene un software, (no voy a poner ms ejemplos de coches), por ejemplo existen productos software que estn muy estandarizados (SAP, Subversion, PhotoShop, Office...) es software muy popular, muy testeado, en diferentes entornos y condiciones, y yo creo que eso es un sntoma de calidad.

Estos son los factores que se me han ocurrido, seguro que hay muchos mas (espero vuestros comentarios ;) ). Una vez apuntados los factores vamos a medir la calidad, ... qu?cmo?... si si, vamos a medir la calidad..., de las propiedades del software de calidad, podemos sacar mtricas y de esas mtrica (de una manera muy simple y lgica) vamos a preparar una primera versin de la frmula:

Por si alguin no se ha dado cuenta est frmula me la acabo de sacar "de la manga", pero yo creo que tiene los factores clave para darnos una medida de la calidad que percibe un usuario de software.

Es tan dificil medir la calidad..., no cabe duda de que si disemos con una frmula vlida, nos haramos multimillonarios, pero la calidad no es algo tan trivial, que se pueda medir en una escala de 0 a 10... la calidad tampoco es binario o 0 o 1, o se tiene o no se tiene, es algo mas complejo, la calidad es el da a da, el trabajo meticuloso, de trabajo organizado y estructurado, probado y documentado, orientado a la peticin de cambio del cliente y a la facilidad para llevar a cabo el cambio en el equipo de desarrollo, la calidad no es CMMI o SCRUM, aunque si es cierto que cualquier metodologa actual sienta las bases para desarrollar un producto de calidad. Por todo esto y para terminar, decir que la calidad no se puede medir, pero los factores que afectan a la calidad si se pueden identificar y mejorar... por lo tanto la calidad est en la mejora diaria, en cada uno de los eslabones del desarrollo de software, en la buena gestin, en cada lnea de cdigo, ... todos deben aportar calidad, desde la codificacin (tratando de documentar el cdigo, haciendolo, legible, mantenible...), hasta la implantacin del producto (haciendo un aterrizaje suave sobre un entorno de preproduccin, pasar de nuevo el plan de pruebas), hasta incluso despus de la puesta en produccin aportando al cliente un buen bug-tracker y comunicacin continua... Entonces, que tengo que hacer para aplicar calidad a mis desarrollos? ... mejorar! Mejorar en todos y cada uno de los procesos, hitos y tareas de la produccin de software. (Y para decir esta frase el rollo que he soltado...) PD: Si has tenido la paciencia de leer hasta el final, enhorabuena!! ests relmente interesado en mejorar y ese es el requisito fundamental para aplicar calidad al software

Cmo se mide la calidad?

... O ms bien debera ser ms especfico: cmo se mide la calidad del software? Parece ser que la calidad es el atributo favorito a la hora de ser includo en propuestas y propaganda variada de los productos software, pero nunca nos hemos preguntado qu es la calidad? cunta calidad tiene? Si no puedo medir la calidad de un producto para qu me sirve que lo pongan en un folleto o hablen de l los comerciales? (si hasta los terremotos tienen una medida universal gracias al seor Richter). Hace poco lea un blog y me sorprenda la frase: "no puedes elegir fabricar software de baja calidad y rebajar el precio. Puedes restarle funcionalidad, pero no calidad". Por desgracia para el mundo del desarrollo de software, no es as. Claro que se puede ahorrar calidad. Simplemente,

eliminando

las

actividades

que

le

aportan

aseguran

esa

calidad.

Dnde est la calidad?: En arquitecturas conocidas, probadas y para las que se han obtenido datos de experiencias (buenas prcticas, problemas a evitar, cmo mejorar en el futuro, etc.) Es lo que se conoce como mejora continua. En las metodologas de trabajo conocidas y probadas. Y no slo hablo de desarrollo. Tambin de repositorios de documentos, tener claro quin es el responsable de qu...El tener el control de qu hay, dnde est, cmo acceder a ello, y cmo usarlo. En las pruebas del software antes de la entrega al cliente. En las pruebas del software en la implantacin. En las auditoras de calidad. En las auditoras internas del equipo de desarrollo. En las revisiones entre pares (s, s, las Peer Review famosas).

Cmo medir la calidad? Pues midiendo la calidad de nuestro proceso de desarrollo: Calidad del anlisis: cuntos requisitos se han modificado? cuntos se han aadido? cuntos se han eliminado? Calidad del diseo: cuntos cambios se han producido en el diseo tcnico? Calidad de la arquitectura: cuntos cambios de arquitectura se han producido? Calidad del desarrollo: cuntos defectos se han detectado en pruebas unitarias? Calidad de las pruebas: cuntos defectos ha detectado el cliente en produccin vs defectos encontrados en pruebas en general? cul es el ratio n defectos encontrados vs horas invertidas en pruebas?

Y la calidad del producto? Pues aunque est relacionado, tendramos otros factores: Tiempo que lleva el cliente usando el producto. En mi opinin no es significativo. Por razones varias, el cliente puede verse obligado a usar un psimo software. Realmente el problema est en la competencia y en el precio. Si es suficientemente barato un software alternativo, poco importar la calidad de nuestro software, es probable que el cliente acabe actualizndolo por otro distinto, si los costes encajan. Satisfaccin del cliente. Bueno, volvemos a la cruda realidad. Quin es el cliente? El director general? el que compr el software? El jefe de departamento que lo usa? Los usuarios finales? Al final, la satisfaccin es difcil de medir. Bueno, para eso podis leer mi anterior blog sobre encuestas de satisfaccin. Nmero de fallos en produccin. Realmente no slo es una medida de calidad del software, sino de su proceso de desarrollo. Nmero de clientes. Pues ahora mismo se me ocurren unos cuantos ejemplos de software vendido por millares (por no decir millones), y de calidad psima. Al final, el nmero de clientes lo deciden una serie de factores ajenos a la calidad: precio, esfuerzo comercial, renombre de la marca comercial, etc. Nmero de aos en uso. Uf. Por esa regla de 3, tendramos que el software hecho en cobol en los aos 80 deba de ser de calidad asombrosa, porque se ha usado hasta hace muy poco, o sigue en uso. A la hora de la verdad, este factor no depende de la calidad, sino de la competencia, de la facilidad de actualizar el producto. Si encontramos repuestos de ruedas, las cambiaremos fcilmente. Si no encontramos repuestos, pues...habr que fastidiarse y seguirlos usando (independientemente de su calidad).

Fase de Diseo

Una vez tomada la decisin de acometer el proyecto la primera actividad que debe realizar el director de proyecto es constituir el equipo de proyecto. En el caso de grandes proyectos esta actividad comenzar en la fase de definicin anterior, ya que el trabajo a realizar puede ser considerable debido a la dimensin del proyecto, constituyendo la fase de definicin o viabilidad un proyecto en s misma. La constitucin del equipo siempre llevar asociada en mayor o menor medida la negociacin con los dueos de los recursos normalmente responsables funcionales de la organizacin ejecutante- sobre las personas que trabajarn en el proyecto. La asignacin de personas debe llevarse a cabo de acuerdo a las competencias y experiencia requeridas por el proyecto, por lo que es necesario que el director de proyecto las defina con claridad. Es importante adems que la asignacin se produzca con la mayor prontitud posible ya que las personas de ms vala son siempre las ms demandadas por otros proyectos y actividades, y el xito de nuestro proyecto depender en gran medida de la calidad de los miembros del equipo de proyecto. Si esperamos a que alguien nos asigne recursos sin mas, posiblemente obtengamos los recursos menos tiles de los distintos departamentos de la organizacin. En proyectos con mltiples fases, en los que pueden requerirse diversas competencias a lo largo de las distintas fases, el director de proyecto deber ir modificando el equipo de proyecto al inicio de cada fase. Los objetivos fundamentales de la fase de diseo son los siguientes:
Desarrollo de una solucin o diseo que permita satisfacer los requisitos del cliente (no slo en trminos de calidad, sino tambin en trminos de coste y plazo) de manera que todas y cada una de las caractersticas de diseo sean trazables a los requisitos de cliente y viceversa. En el caso de existir diversas alternativas de diseo, el director de proyecto deber analizar las mismas de acuerdo a los objetivos de proyecto, eligiendo aquella que maximice la probabilidad de xito del proyecto. Si alguna alternativa mereciera consideracin, pero precisara de una modificacin de objetivos, deber consultar al sponsor o patrocinador del proyecto. Elaboracin de una filosofa o estrategia de pruebas que permita detectar en una fase posterior- incumplimientos de los requisitos por parte de la solucin adoptada para as proceder a su correccin. sta consistir bsicamente en determinar entre otros: 1.Como se demostrar cada uno de los requisitos de cliente (ensayo, anlisis, simulacin, etc), 2. Nmero de prototipos, etc. Gestionar la fase de acuerdo al plan de proyecto dentro del coste y plazo asignado.

Los entregables de la fase de diseo son, adems de la solucin o diseo y la estrategia de pruebas arriba mencionadas, la actualizacin del plan de proyecto a partir de la informacin disponible al acabar la fase. 2.3 Entregables del Proyecto A continuacin se indican y describen cada uno de los artefactos que sern generados y utilizados por el proyecto y que constituyen los entregables. Esta lista constituye la configuracin de RUP desde la perspectiva de artefactos, y que proponemos para este proyecto. Es preciso destacar que de acuerdo a la filosofa de RUP (y de todo proceso

iterativo e incremental), todos los artefactos son objeto de modificaciones a lo largo del proceso de desarrollo, con lo cual, slo al trmino del proceso podramos tener una versin definitiva y completa de cada uno de ellos. Sin embargo, el resultado de cada iteracin y los hitos del proyecto estn enfocados a conseguir un cierto grado de completitud y estabilidad de los artefactos.

Esto ser indicado ms adelante cuando se presenten los objetivos de cada iteracin. 1) Plan de Desarrollo del Software Es el presente documento. 2) Modelo de Casos de Uso del Negocio Es un modelo de las funciones de negocio vistas desde la perspectiva de los actores externos (Agentes de registro, solicitantes finales, otros sistemas etc.). permite situar al sistema en el contexto organizacional haciendo nfasis en los objetivos en este mbito. Este modelo se representa con un Diagrama de Casos de Uso usando estereotipos especficos para este modelo. 3) Modelo de Objetos del Negocio Es un modelo que describe la realizacin de cada caso de uso del negocio, estableciendo los actores internos, la informacin que en trminos generales manipulan y los flujos de trabajo (workflows) asociados al caso de uso del negocio. Para la representacin de este modelo se utilizan Diagramas de Colaboracin (para mostrar actores externos, internos y las entidades (informacin) que manipulan, un Diagrama de Clases para mostrar grficamente las entidades del sistema y sus relaciones, y Diagramas de Actividad para mostrar los flujos de trabajo. 4) Glosario Es un documento que define los principales trminos usados en el proyecto. Permite establecer una terminologa consensuada. 5) Modelo de Casos de Uso El modelo de Casos de Uso presenta las funciones del sistema y los actores que hacen uso de ellas. Se representa mediante Diagramas de Casos de Uso. 6) Visin Este documento define la visin del producto desde la perspectiva del cliente, especificando las necesidades y caractersticas del producto. Constituye una base de acuerdo en cuanto a los requisitos del sistema. 7) Especificaciones de Casos de Uso Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que no baste con una simple descripcin narrativa) se realiza una descripcin detallada utilizando una plantilla de documento, donde se incluyen: precondiciones, post-condiciones, flujo de eventos, requisitos no-funcionales asociados. Tambin, para casos de uso cuyo flujo de eventos sea complejo podr adjuntarse una representacin grfica mediante un Diagrama de

Actividad. 8) Especificaciones Adicionales Este documento capturar todos los requisitos que no han sido incluidos como parte de los casos de uso y se refieren requisitos no-funcionales globales. Dichos requisitos incluyen: requisitos legales o normas, aplicacin de estndares, requisitos de calidad del producto, tales como: confiabilidad, desempeo, etc., u otros requisitos de ambiente, tales como: sistema operativo, requisitos de compatibilidad, etc. 9) Prototipos de Interfaces de Usuario Se trata de prototipos que permiten al usuario hacerse una idea ms o menos precisa de las interfaces que proveer el sistema y as, conseguir retroalimentacin de su parte respecto a los requisitos del sistema. Estos prototipos se realizarn como: dibujos a mano en papel, dibujos con alguna herramienta grfica o prototipos ejecutables interactivos, siguiendo ese orden de acuerdo al avance del proyecto. Slo los de este ltimo tipo sern entregados al final de la fase de Elaboracin, los otros sern desechados. Asimismo, este artefacto, ser desechado en la fase de Construccin en la medida que el resultado de las iteraciones vayan desarrollando el producto final. 10) Modelo de Anlisis y Diseo Este modelo establece la realizacin de los casos de uso en clases y pasando desde una representacin en trminos de anlisis (sin incluir aspectos de implementacin) hacia una de diseo (incluyendo una orientacin hacia el entorno de implementacin), de acuerdo al avance del proyecto. 11) Modelo de Datos Previendo que la persistencia de la informacin del sistema ser soportada por una base de datos relacional, este modelo describe la representacin lgica de los datos persistentes, de acuerdo con el enfoque para modelado relacional de datos. Para expresar este modelo se utiliza un Diagrama de Clases (donde se utiliza un profile UML para Modelado de Datos, para conseguir la representacin de tablas, claves, etc.) . 12) Modelo de Implementacin Este modelo es una coleccin de componentes y los subsistemas que los contienen. Estos componentes incluyen: ficheros ejecutables, ficheros de cdigo fuente, y todo otro tipo de ficheros necesarios para la implantacin y despliegue del sistema. (Este modelo es slo una versin preliminar al final de la fase de Elaboracin, posteriormente tiene bastante refinamiento). 13) Modelo de Despliegue Este modelo muestra el despliegue la configuracin de tipos de nodos del sistema, en los cuales se har el despliegue de los componentes. 14) Casos de Prueba Cada prueba es especificada mediante un documento que establece las condiciones de ejecucin, las entradas de la prueba, y los resultados esperados. Estos casos de prueba son aplicados como pruebas de regresin en cada iteracin. Cada caso de prueba llevar

asociado un procedimiento de prueba con las instrucciones para realizar la prueba, y dependiendo del tipo de prueba dicho procedimiento podr ser automatizable mediante un script de prueba. 15) Solicitud de Cambio Los cambios propuestos para los artefactos se formalizan mediante este documento. Mediante este documento se hace un seguimiento de los defectos detectados, solicitud de mejoras o cambios en los requisitos del producto. As se provee un registro de decisiones de cambios, de su evaluacin e impacto, y se asegura que stos sean conocidos por el equipo de desarrollo. Los cambios se establecen respecto de la ltima baseline (el estado del conjunto de los artefactos en un momento determinado del proyecto) establecida. En nuestro caso al final de cada iteracin se establecer una baseline. 16) Plan de Iteracin Es un conjunto de actividades y tareas ordenadas temporalmente, con recursos asignados, dependencias entre ellas. Se realiza para cada iteracin, y para todas las fases. 17) Evaluacin de Iteracin Este documento incluye le evaluacin de los resultados de cada iteracin, el grado en el cual se han conseguido los objetivos de la iteracin, las lecciones aprendidas y los cambios a ser realizados. 18) Lista de Riesgos Este documento incluye una lista de los riesgos conocidos y vigentes en el proyecto, ordenados en orden decreciente de importancia y con acciones especficas de contingencia o para su mitigacin. 19) Manual de Instalacin Este documento incluye las instrucciones para realizar la instalacin del producto. 20) Material de Apoyo al Usuario Final Corresponde a un conjunto de documentos y facilidades de uso del sistema, incluyendo: Guas del Usuario, Guas de Operacin, Guas de Mantenimiento y Sistema de Ayuda en Lnea 21) Producto Los ficheros del producto empaquetados y almacenadas en un CD con los mecanismos apropiados para facilitar su instalacin. El producto, a partir de la primera iteracin de la fase de Construccin es desarrollado incremental e iterativamente, obtenindose una nueva release al final de cada iteracin. Los artefactos 19, 20 y 21 se generarn a partir de la fase de Construccin, con lo cual se han incluido aqu slo para dar una visin global de todos los artefactos que se generarn en el proceso de desarrollo.