• Save
Modelos De Calidad para proyectos de Software Y Software Libre
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Modelos De Calidad para proyectos de Software Y Software Libre

  • 5,389 views
Uploaded on

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......

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.

More in: Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • que bien,, buena informacion,,
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
5,389
On Slideshare
4,673
From Embeds
716
Number of Embeds
6

Actions

Shares
Downloads
0
Comments
1
Likes
7

Embeds 716

http://www.eqsoft.net 678
http://www.slideshare.net 32
http://www.linkedin.com 3
http://webcache.googleusercontent.com 1
http://www.google.com.pe 1
https://www.linkedin.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 6. CMMI
  • 7. Moprosoft
  • 8. ISO 15504
  • 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.
  • 12. ¿Y el software libre?
  • 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