Calidad en el proceso de desarrollo de software

Por otro lado se menciona Scalone, que. Figura 1 Estructura de la calidad de software. Fuente: Los autores. Cobit 4. ISO, Modelos a nivel de producto. Figura 3 Modelos de calidad a nivel de producto Fuente: Los autores. Los once criterios base, son: Exactitud, confiabilidad, eficiencia, integridad, usabilidad, mantenibili-dad, testeabilidad, flexibilidad, portabilidad, reusabilidad e interoperabilidad Khosravi, L, son empresas que implementaron el modelo Bootstrap.

En la Tabla 3 se presenta un listado de algunas de las empresas que han implementado el modelo Asencio, , Bustos, , Webb, L, Quental Technologies S. L y Tahbit Software S.

Intracom S. La Tabla 10 , revela algunas empresas que implementaron el modelo Solemon, , Strub, , Boehm, , Mcmurtrey, , Moniruzzaman, , Matkovic, , Weckman, Colvin, Gaskins, Mackulak Estas propiedades principalmente son: de exactitud, internas y descriptivas Adve, Memory models: a case for rethinking parallel languages and hardware.

In: Communications of the ACM. Quality models in software engineering literature: an analytical and comparative study. In: Journal of American Science.

Leydi, et al,. Uso del TSP Team software process en el desarrollo de software. Quito, Tesis Doctoral. Universidad Nacional de La Plata. Cornering the chimera. Jan, Application and Evaluation of the Personal Software Process. In: Kybele Consulting S. L, Managing the software process. ISBN Introduction to the personal software process.

A quality model for design patterns. In German Industry Standard, ISSN: Tratar de implementar alguna mejora simple y mostrar sus resultados. No se debe encarar la mejora ignorando los objetivos de la empresa, que hacen a su cultura, la cual es maximizar las ganancias a partir de un menor gasto en recursos humanos. En la cultura de estas empresas las mejoras se piensan como grandes desembolsos y grandes cambios. La estrategia es mostrarles a los responsables que existen ganas y voluntad de mejora.

La desventaja es que al ser grande los responsables a veces no asumen la autoridad que su rol les otorga, ingrediente esencial a la hora de implementar un proceso de mejoras. Solo atinaban a analizar history bords en targetas con escenarios no siempre entendidos y casi nunca sistematizados. El trabajo con requerimientos necesita de un rol especializado que lo conduzca y ese es el analista.

Interfaz de Desarrollo: para implementar esta interfaz el analista debe estar capacitado para trasladar el producto de su trabajo con los usuarios y clientes al seno del grupo de desarrollo.

Los resultados del primero se mostraron en la tabla 2. Terry, Steven J. Requirements Development. Verification, and Validation Exhibited in Famous Failures. Systems Engineering archive. Wiley Periodicals. Los sistemas de la tabla 4. Tabla 4. En la figura 4. A2 B2 C2 Requerimientos incorrectos, incompletos o inconsistentes. A3 B3 C3 Sin requerimientos.

C4 Requerimientos no factibles. Los requerimientos, como tantas veces se expresa, deben describir el sistema que los clientes y usuarios necesitan, por eso hay que validarlos. El trabajo con los requerimientos no se agota en el relevamiento y el listado resultante, los sistemas necesitan validar reglas que el negocio impone y que deben ser analizadas por los involucrados, comprendidas y asignadas a las entidades indicadas de un modelo que represente el comportamiento del negocio.

Los requerimientos deben expresar las condiciones de funcionamiento del sistema en desarrollo y ser verificados, para comprobar que cubren todos los requerimientos y que el sistema que los implementa posee el comportamiento esperado en el ambiente operacional definido. Estos distintos aspectos del modelo de requerimientos son muy bien presentados en Requirements by Collaboration: Workshops for Defining Needs Requirements by Collaboration: Workshops for Defining Needs. Addison Wesley Professional.

En la tabla 4. Esta es muy similar a la que existe con los niveles. Sin embargo, conservaremos algunas cuestiones esenciales que a nuestro entender deben ser tenidas en cuenta siempre y que hemos visto ausentes en muchos proyectos.

Este modelo propone planificar, ejecutar, revisar y corregir. Esto impide a los usuarios preparar y ordenar sus conocimientos del negocio y a los analistas definir una estrategia de avanzar sobre los diferentes aspectos del problema a investigar.

Este modelo lo explicaremos enumerando algunos beneficios y ejemplificando cada una de sus partes con los escenarios que comunmente se observan en los proyectos. Ejecutar evita: no contar con una sala para el desarrollo, demoras hasta que se nos asigna una, esperas a asistentes que acuden a horarios diferentes, tratar temas dispersos con escaso valor agregado. Evaluar permite: ordenar los resultados de las reuniones y publicarlas a todos los involucrados, dar consistencia a los productos generados, analizar y organizar el trabajo, contar con modelos relacionados traceables , contar con modelos sobre los cuales basar los acuerdos.

Dejamos que dicho documento lo elabore a medida de sus necesidades. Por otra parte las condiciones de funcionamiento en el ambiente operacional son expresadas por los requerimientos no funcionales. Por eso es necesario comunicarse y acordar con ellos a partir de un listado bien construido de requerimientos.

Advanced Use Case Modeling. Use Case Modeling. La figura 4. Prototipo de Interfaces Fig. Es frecuente encontrar casos de uso nombrados como Administrar XXX. Administrar puede significar diferentes cosas para las distintas personas de un grupo de desarrollo. Es muy importante darle claridad y consistencia a los diagramas de este tipo definiendo, al nivel del grupo, el significado de las palabras claves.

Suena contradictorio pero no lo es. Los desarrolladores resuelven las cuestiones vinculadas a la infraestructura y dan poca importancia al negocio. Este es el resultado de resolver aspectos tan diferentes como el negocio y la infraestructura en la misma actividad durante el desarrollo. Domain Driven Design. En este punto nuestros conceptos no tienen alcance preciso expresado en sus atributos.

Object - Oriented Analysis and Design with Applications. Streamlined Object Modeling - Patterns, rules and implementations. Analysis Patterns: Reusable Object Models. Addison-Wesley Object Technology Series.

Prentice Hall. Addison-Wesley Professional Computing Series. Patterns of Enterprise Application Architecture. Addison-Wesley Signature Series. Este rasgo distintivo del trabajo con requerimientos por parte de los analistas lo hemos observado en muchos proyectos.

Ambos son igualmente importantes y a ambos se le debe asignar el esfuerzo necesario. La respuesta es simple e importante. La idea es centrar los paquetes en estas entidades y refinar el conjunto resultante. Un posible inconveniente con esta alternativa es que a veces resultan paquetes muy grandes que deben a su vez ser particionados. El resultado exitoso de estas validaciones nos da la certeza de que construiremos el sistema correcto.

Generating Test Cases from Use Case. Rational Software. Director of Technology Solutions. The A Consulting Team, Inc. Los proyectos comenzaban y terminaban casi con los mismos requerimientos. Cada cambio propuesto o pedido en el proyecto pasa por diferentes estados de acuerdo a su ciclo de vida. Se muestran los diferentes estados por los que pasa una solicitud de cambio, las transiciones posibles y los involucrados en el proceso. La idea es agruparlos para su tratamiento.

Es de primera importancia planificar el trabajo con los requerimientos. En todos los casos, administrar los cambios surgidos durante el proceso de desarrollo. Un producto que no es provisto a tiempo, utencillos faltantes, arribo de nuevos asistentes no tenidos en cuenta en nuestras listas, no asistencia de invitados, lluvia y otros pueden compararse en el escenario correspondiente a infraestructura no entregada a tiempo, cambios en el alcance, compromisos no cumplidos por las diferentes partes, etc.

Supongamos que nos dedicamos al negocio de turismo y organizamos excursiones por nuestra ciudad para los visitantes. Cada viaje es organizado de acuerdo a la solicitud de los viajeros. Es otro tipo de proyectos. Unified Software Development Process. Compraremos las entradas y consumiciones en cada lugar al momento de necesitarlas y nos trasladaremos de un lugar a otro cuando los viajeros lo soliciten.

Estas situaciones se presentan todo el tiempo en los proyectos de desarrollo de software. En la figura 5. Agile Software Development. Extreme Programming Explained. Evaluar: para reforzar los aciertos, corregir los errores y replanificar. Trabaja en todo momento administrando los riesgos, conducido por la estrategia fijada para el proyecto.

Ian Spence. Managing Iterative Software Development Projects. Se trata de generar un ambiente en el que todos los roles se apropien del proyecto y trabajen colaborando con el resto de los involucrados para lograr los objetivos planteados. De lo expuesto se deriva que es muy importante la actitud y aptitud de los miembros de las organizaciones.

Por el momento nos basta con el listado de casos de uso a construir con sus respectivas prioridades. Supongamos que los hemos clasificado en: 1. Esenciales: son aquellos sin cuya funcionalidad no puede llevarse ade- lante el negocio. Menos importantes: son aquellos que decoran la funcionalidad esen- cial pero que sin embargo el negocio puede llevarse adelante sin ellos.

No aportan gran valor agregado. Errores detectados en Oct. En la figuras 5. En general la gente asocia los momentos de los proyectos con las actividades que en ellas se llevan adelante. Se ha producido un desfasaje entre los planes y la realidad del proyecto. En la tabla 5. Pueden verse los riesgos que conducen las actividades para el logro de los objetivos y los hitos de cada una de las fases.

Poner el foco en generar resultados sin temor a fallar. Siempre abierto y honesto visibilidad. Basarse en evaluaciones obtenidas a partir de mediciones objetivas y no subjetivas. Richard Turner. Tom Poppendieck. Addison-Wesley Professional. En las secciones que siguen nos ocuparemos de elaborar una respuesta a esta pregunta. Los competidores deben recorrer el itinerario que comienza en la imagen inferior del centro y continua con la imagen de arriba. No es lo mismo desarrollar el mejor producto que salir con el producto lo antes posible al mercado.

A cada requerimiento le asignaremos una de estas de acuerdo a los objetivos del proyecto. Si los objetivos fueron acordados estaremos en mejores condiciones de asignar prioridades. Prentice hall. Software Project Survival Guide. De todas estas recomendaciones nos extenderemos en un par de ellas. Contra esta podremos trabajar para minimizar su efecto. Contra la de otros, no. Sin embargo es importante que su impacto no crezca. Este hecho se muestra en la figura 5. Perspectiva financiera b.

Perspectiva del cliente y los usuarios c. Valores a sumar al negocio 2. Conocer los riesgos a. Detectarlos b. Relevar requerimientos b. Listar casos de uso c. Priorizar casos de uso 4. Estimar el esfuerzo ajustado al proyecto a. Casos de uso b. Interfaces con sistemas externos c. Reportes 5. Definir los procesos a seguir a. Asignar roles a los involucrados 6. Hitos d. Generar en tiempo y forma los eventos planificados 2. Facilitar los acuerdos necesarios 3.

Tomar decisiones 5. Se requiere una gran madurez para tomar estas decisiones, tanto de parte de quien las toma como de las organizaciones involucradas en el proyecto.

Mary y Tom Poppendieck op. Analizar los riesgos y problemas, y acordar acciones orientadas a solucionarlos con todos los involucrados.

Estas reuniones duraban tres o cuatro horas y en ellas se trataban una decena de temas. La mayor cantidad de conflictos y desacuerdos que he presenciado se debieron a acciones no entendidas por algunos de los involucrados.

Gianluigi Caldiera. Dieter Rombach. The Goal Question Metric Approach. Son momentos de intensa actividad en el seno del proyecto. Estas son especulaciones, necesitamos una respuesta. Yo he participado de estas sesiones y a decir verdad en muchas de ellas el producto a revisar era tan importante como muchos otros que no se revisaron.

The Art of Software Testing. En el esquema de la figura 6. Estas actividades se muestran sin color cuando son llevadas adelante en la forma tradicional. Esta forma de trabajo determina que las pruebas muchas veces no se repitan por el esfuerzo que ello implica. Software Verification and Validation for Practitioners and Managers. Second Edition, Artech House.

Code Complete. Redmond, Wa. En la figura 6. Nota del autor. Practical Integration Software Patterns Series. Esto es importante por los reiterados cambios a que es sometido el software mientras se desarrolla. Para un sistema desarrollado en Java, por ejemplo, se muestran en la tabla 6.

Ward Cunningham. Prentice Hall PTR. El administrador de IC informa por mail a los miembros del grupo de desarrollo de los resultados del build. Duvall with Andrew Glover and Steve Matyas La arquitectura del ambiente mostrado en el esquema se presenta en las dos figuras.

Genera datos acerca del producto y del proceso de desarrollo 2. Genera datos acerca del producto y del proceso de desarrollo 3. Genera conocimiento entre miembros del grupo de desarrollo 4. En la siguiente tabla se muestran las diferencias entre ambas. Formales: Con roles y responsabilidades, y un procedimiento definido.

Informales: Con roles desdibujados y sin procedimiento. En las figuras 6. Ambas fueron obtenidas con el framework inCode para el mismo sistema. Paulk, B. Curtis, et al. Capability Maturity Model for Software.

Una estructurada en cinco niveles de madurez y otra en seis de capacidad. En la figura 7. El nivel de madurez uno ML 1 indica que los procesos no se realizan, lo que significa que los proyectos se desarrollan de manera impredecible y descontrolada. Estas son dejadas para mejorar en niveles superiores 3. En la tabla 7. Los resultados no fueron tan frustrantes ni tuvieron un impacto tan importante para aquellas organizaciones que eligieron ISO en lugar de CMMi.

Sin embargo debemos hacer notar que la norma y el modelo resultan incomparables, ya que fueron pensados para objetivos diferentes. En definitiva, CMMi es un modelo bien pensado por gente que conoce acerca del desarrollo de software, pero muy mal utilizado por una gran cantidad de personas que desconocen acerca de este tema. Toda su experiencia en el desarrollo de software se reduzca al modelo porque el trabajo con este tipo de mentores genera resultados insuficientes.

Enarbolen antecedentes de procesos realistas, algunos exitosos, otros con problemas, porque evidencia que ha habido un proceso de aprendizaje de los errores cometidos. No es un proyecto impuesto por sus dirigentes, sino que es un proyecto al cual se invita a participar a todos.

Los procedimientos son adaptados, cuando sea necesario, basados en los resultados de la prueba piloto. El resultado de este relevamiento se compara con los definidos por el modelo CMMi para los objetivos fijados por la empresa. En base a la diferencia resultante se determina el alcance del proyecto. En los PAs se asignan objetivos, cronogramas, personas y actividades a desarrollar. Se construye un repositorio donde se instalan todos los productos generados en el proyecto. Se comunican los resultados a todos los miembros.

Mayoritariamente los recursos a invertir corresponden a honorarios profesionales de miembros propios y externos. Eso, como propondremos, si las herramientas a utilizar son open source y free, las cuales hay de excelente calidad. La idea es que participen los mejores recursos de cada especialidad. Este es otro recurso a tener en cuenta a la hora de elaborar el presupuesto. Auerbach Publications. En las figuras 7.