Esta presentación es una rápida aproximación a que es un modelo de calidad, cuales modelos existen y como el software libre a evolucionado su modelo de desarrollo y utiliza y facilita herramientas que nos permiten automatizar el proceso de adopción de un modelo de calidad.
Modelos De Calidad para proyectos de Software Y Software Libre
1. Modelos de
Calidad de
Software y
Software Libre
Ernesto Quiñones A.
ernestoq@apesol.org
2. ¿Qué es un modelo de calidad
de software?
Es un conjunto de buenas practicas para el
ciclo de vida del software, enfocado en los
procesos de gestión y desarrollo de
proyectos.
3. Tomar en Cuenta
Los modelos de calidad te dicen QUE hacer.
no COMO hacerlo.
¿Porque?
●Depende las metodologías que uses
●Depende de tus objetivos de negocio
4. Cuantos modelos existen?
●CMMI for Development, v1.2
Carnegie Mellon Software Engineering Institute – SEI.
http://www.sei.cmu.edu/cmmi/
Orientado a mejora de procesos en diferentes niveles de
madurez, mas hacia proyectos específicos.
●Norma ISO/IEC 12207 - 15504
International Organization for Standardization.
http://tinyurl.com/ndppqf
Orientado al proceso del ciclo de vida del software (12207) y a
los procesos de desarrollo (15504).
●Metrica3
Ministerio de Administración Pública de España.
http://www.csi.map.es/csi/metrica3
Modelo e Implementación.
5. Cuantos modelos existen?
Moprosoft
●
Programa Nacional para la Industria de Software administrado
por la Secretaría de Economía de México.
http://www.comunidadmoprosoft.org.mx/
Fundamentado en CMM, ISO 9000 e ISO/IEC TR 15504,
orientado a pequeñas empresas.
ISO 9000-3
●
International Organization for Standardization.
http://tinyurl.com/mofx4u
Guía para la aplicación de ISO 9001 para el desarrollo,
implementación y mantenimiento de software
muchos...muchos mas
9. En general
● Todos los modelos de calidad requieren de mucho
esfuerzo, el compromiso debe ser de toda la
organización.
● Principalmente se busca comenzar a diseñar y/o
documentar procesos, luego desplegarlos y ponerlos
en práctica, con el tiempo y la experiencia la mejora
de los mismos es algo que se da espontáneamente
● Cualquier modelo (mientras no sea personal)
requiere un mínimo de cantidad de personal (no
menos de 4 ó 5 personas por ejemplo para Moprosoft
y más de 10 para CMMI).
● Cualquier proceso de implementación de un modelo
de calidad va a requerir una fuerte inversión
económica.
10. Por donde empezar
● Asegurar el compromiso institucional a más
alto nivel y de toda la organización.
● Automatizar los más posible las actividades
de control y gestión de los procesos de los
proyectos.
● Comenzar a documentar los procesos
implícitos, en la medida de lo posible 0
plantillas en *office, implementación de
sistemas de gestión.
● Existe mucho software libre para apoyarte.
11. ¿Cual modelo debería elegir?
Hay varios factores para elegir un modelo de
●
calidad:
●Objetivos de negocio
●Aceptación en el mercado
●Dimensión de la empresa
●Nivel de inversión que se puede realizar
●Apoyo, consultoría, etc.
13. El software libre a los largo de los años
ha asimilado muchas de las buenas
practicas de la ingeniería de software,
con ello de manera natural ha aplicado
y desarrollado herramientas dentro de
sus propios proyectos que fácilmente
podrían asegurar el cumplimiento
básico de un primer nivel de
certificación de casi cualquier modelo
de calidad.
14. Algo de historia
● Años 60-70
Necesidad no Implementación
Programación
atendida Voluntaria
● Necesidad de los mismos ● 1972 : TCP-IP (protocolo)
“informáticos”. ● 1974 : PDP-11 (Unix de
● Programación en ASM y C Berkley)
● El software se pone tal cual, si da ● 1975 : Emacs (entorno
problemas ellos mismos lo arreglan. completo)
● 1976 : Vi (editor de
texto)
15. Algo de historia
● Años 80 Reporte de Error o código
solucionándolo
Testing
Requerimiento Programación
permanente
Nuevas Ideas
● Requerimientos del movimiento, ● 1981 : BSD 4.1 (OS)
● 1984 : Latex (procesador de
principalmente dev-tools y comm-
apps. textos)
● 1986 : CVS (control de
● Programación en C, C++ y
versiones)
lenguajes de scripting, gestionada ● 1987 : Perl (lenguaje)
en repositorios de código. ● 1987 : GCC (compilador)
● Se establecen convenciones y
estándares para documentación.
16. Algo de historia
● Años 90
Documentación
Reporte de Error o código
solucionándolo
Diseño
Testing
Requerimiento Formal o Programación
permanente
informal
Nuevas Ideas
● Integración de muchos paquetes ● 1993 : Debian y Slackware
independientes y despliege. (distros de Linux)
● 1997 : Doxygen (automatización
● Aplicaciones afinadas y
de documentación a partir del
especializadas para laborar código fuente)
distribuidamente (Internet). ● 1998 : APT (administrador de
● Automatas de pruebas y
paquetes)
documentación
17. Algo de historia
Publicación y
● Actualmente Documentación Testing
Testing permanente
Interno y
Adm. Releases
Gestión de Diseño Programación Gestión de
Proyecto Formal errores y
Reporte de Error o códigorequerimientos
TO-DO solucionándolo
● Software para diseno de software. ● 1998 : Bugzilla (administración de
● Desarrollo basado en MVC. errores y requerimientos)
● 2002 : Umbrello (herramienta case)
● Herramientas de GESTION de
● 2000 : PhpGroupWare (gestión de
trabajo en grupo. proyectos)
● Herramientas de apoyo para
● 2004 : Ruby on Rails (framework de
GESTION de proyectos. desarrollo)
18. Observaciones
● Mucho software libre parte de la “idea” del desarrollador,
no de un requerimiento formal, el usuario no participa
hasta una etapa muy tardía
● Muchos proyectos se enfocan en la funcionalidad sin
importales la usabilidad.
● La frase “el software esta cuando esta” es chocante con
los proyectos convencionales de software, las
estimaciones resultan complicadas cuando la fuerza de
trabajo labora en horas donadas, es difícil plantearse
metas así.
● Mediciones y análisis de los proyectos son complicados,
los indicadores que se pueden obtener son mas de
capacidad técnica.
19. Observaciones
● Pocos proyectos tiene procesos formalizados y
documentados, son pasados de “generación en
generación” verbalmente.
● El paradigma del aseguramiento de la calidad (testing) de
un producto de software libre es radicalmente diferente
al de un proyecto convencional, mas efectivo pero
contradice todo lo estipulado.
● Gran porcentaje de los proyectos de software libre tienen
documentación 0%, tanto a nivel técnico como a nivel
usuario.
20. Pero sin embargo
el Software Libre
nos puede ayudar
en el proceso de adoptar
un modelo de calidad
y mucho
21. Software Libre - Decenas de soluciones
según http://sourceforge.net
●Documentation (1338 proyectos)
●Quality Assurance (1467 proyectos)
●Case Tools (563 proyectos)
●Collaborative Development (141 proyectos)
●Source code analysis (125 proyectos)
●Usability (989 proyectos)
●Debbuger (1272 proyectos)
●Testing (2782 proyectos)
●Version Control (1399 proyectos)
Si solo el 10% de los proyectos esta activo y en
estado de usabilidad entonces tenemos decenas de
opciones libres en las cuales apoyarnos.
22. Algunos ejemplos
Gestión de la configuración:
Conjunto de procesos destinados a asegurar la validez
de todo producto obtenido durante cualquiera de las
etapas del desarrollo de un Sistema de Información
(S.I.), incluye el control de cambios y control de
versiones.
Bazaar + loggerhead , GIT y SVN + Trac
23. Algunos ejemplos
Gestión Integrada de Proyectos:
Conjunto de procesos establecidos para gestionar todos
los aspectos del proyecto y los actores que intervienen
en este.
ProcessMaker Open Source + dotProject (dotProject
además puede unirse a Trac)
24. Algunos ejemplos
Gestión de Requerimientos:
El propósito de la Gestión de Requerimientos (REQM) es
gestionar los requerimientos de los productos del
proyecto y sus componentes e identificar inconsistencias
entre los requerimientos, planes del proyecto y
entregables.
Crow, Sigerar, Open Source Requirements Management
Tool
25. Algunos ejemplos
Gestión de Riesgos:
El objetivo de la gestión de riesgos es aumentar la
probabilidad y el impacto de los eventos positivos,
y disminuir la probabilidad y el impacto de los
eventos adversos para el proyecto.
IT Project Guide- Risk Management
26. En conclusión
Hay muchas herramientas libres que apoyan en
la gestión y automatización de implementar un
área de proceso (de CMMI por ejemplo), algunos
cubren mas de un área de proceso, algunos son
muy especializados en uno solo.
OjO existe una debilidad en herramientas libres
y es en el apoyo en áreas de procesos que
básicamente basan su utilidad en análisis de
métricas.
27. ¡¡¡Gracias!!!
Web Site
http://www.apesol.org
IRC
irc.freenode.net #apesol
Email
info@apesol.org
Listas de Interes
http://listas.apesol.org/mailman/listinfo