Está en la página 1de 207

rad2py: Plataforma de Trabajo para RAD bajo PSP

Facultad de Informática, Ciencias de la Comunicación y Técnicas


Especiales

Trabajo de Diploma
Licenciatura en Sistemas

rad2py: Plataforma de Trabajo


para el Desarrollo Rápido de Aplicaciones
bajo un Proceso de Software Personal

Autor:
Reingart Mariano Alejandro

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 1 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 2 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Facultad de Informática, Ciencias de la Comunicación y Técnicas Especiales

ACTA DEL TRIBUNAL


DE EXAMEN CORRESPONDIENTE AL TRABAJO DE DIPLOMA EN LA CARRERA DE

Licenciatura en Sistemas

rad2py: Plataforma de Trabajo para el Desarrollo Rápido de Aplicaciones bajo un Proceso de Software
Personal

PRESENTADO POR

Mariano Alejandro Reingart (3201-1534)

REALIZADO BAJO LA ​<TUTORÍA/DIRECCIÓN>​ DEL PROFESOR

Lic. Oscar Bravo

INTEGRANTES DEL TRIBUNAL

_________________________ _________________________ _________________________


Integrante Nro. 1 Integrante Nro. 2 Integrante Nro. 3

En el día de hoy, ___ de _______________ del año 20__ , en el aula ______ de la Universidad de Morón se
reúne el tribunal que ha de juzgar el Trabajo de Diploma, constituido por los señores que arriba se citan. Se
procedió a escuchar la exposición con la que el/los alumno/s defendiera/n su Trabajo de Diploma y
posteriormente en turno abierto por el Presidente del Tribunal, se escucharon las contestaciones a las
aclaraciones solicitadas por los miembros del Tribunal sobre el mismo. Realizada la deliberación sobre las
circunstancias antes referidas, el Tribunal decidió conceder a la Tesis presentada la calificación de
“____________________” (Libro _____ , Folio _____ , Año 20__ , Acta Nro. ____ , Fecha ___ / ___ / 20__ )
Y para que así conste, se extiende la presente en F.I.C.C.T.E. de la Universidad de Morón, en la fecha
anteriormente mencionada y que firman los Miembros del Tribunal.

_________________________ _________________________ _________________________


Integrante Nro. 1 Integrante Nro. 2 Integrante

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 3 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 4 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Resumen

En el campo del Desarrollo Rápido de Aplicaciones (método RAD) comúnmente existen


diferentes aproximaciones metodológicas, teorías, estándares y buenas prácticas para llevar
a cabo el Desarrollo de Software; generalmente sin una sólida fundamentación científica o
sin basarse en datos empíricos completos e imparciales, agravándose sobre todo en la
búsqueda de soluciones a las falencias o riesgos que presenta los enfoques ágiles.

A su vez, por estas dispersión conceptual, es difícil encontrar una herramienta (IDE) que de
soporte integral al proceso, cuestión fundamental para la efectividad del método, que no
puede ser salvada efectiva y eficazmente por los utilitarios independientes actualmente en
existencia (editores, depuradores, gestores de proyectos, etc.), más allá de la calidad y
capacidad de cada uno, dado que en este caso se confirmaría el axioma “el todo es más que
la suma de sus partes”, debido a las propiedades emergentes de dichos sistemas complejos.

Por lo tanto, esta investigación busca definir una base teórica y práctica para aumentar la
productividad, resolviendo los problemas asociados al método RAD (aseguramiento de
calidad, mejora continua); proveyendo una nueva generación de herramientas integradas
guiada por el Proceso de Software Personal (PSP), para encauzar la metodología,
solucionando sus falencias pero sin perder sus beneficios.

Palabras Clave:

Mejora del Proceso de Software, Desarrollo Rápido de Aplicaciones, Proceso Personal del
Software, Lenguaje de Programación Python, Herramienta CASE Integrada, Soporte
Automatizado de Proceso, Recolección de Métricas y Aseguramiento de Calidad

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 5 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 6 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

En un estudio de 17 años involucrando más de 100 experimentos con proyectos reales


y 50 tecnologías, el Laboratorio de Ingeniería de Software de la NASA concluyó que
las mejoras se caracterizan por el cambio continuo, sostenido y metódico. No
debemos esperar o depender de los grandes adelantos tecnológicos (Glass 1993).

Las herramientas de productividad de vanguardia pueden jugar un papel importante


en la reducción de los tiempos de desarrollo, pero es bueno para mantener su papel
en perspectiva. Por sí mismas, no son ni necesarias ni suficientes para el logro de un
desarrollo rápido.

Las ventajas estratégicas a largo plazo provienen de mejoras en las personas, el


proceso y el producto. Estar al día en herramientas de productividad forma parte de
la apuesta por permanecer en el juego, pero no le dará una mano ganadora.

Si se implementan nuevas herramientas de una manera casual, el beneficio que se


recibe de ellas sufrirá mejorías y recaídas.

​ apid Development: Taming Wild Software


Traducido de Steve McConnell. 1996. R
Schedules.
Microsoft Press, Redmond, WA, USA.

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 7 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 8 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Agradecimientos

Agradezco profundamente a toda la gente que me rodeó durante estos años de estudio:
docentes, amigos y compañeros con los que recorrí el largo y gratificante camino de
estudiante universitario.

Agradezco especialmente a las comunidades de software libre, especialmente a los


desarrolladores y usuarios de Python, web2py, wxPython, PostgreSQL, GNU/Linux y
Ubuntu, ya que sin el código fuente, documentación y demás contribuciones, este trabajo no
hubiera sido posible.

Por último, expreso mi reconocimiento personal al Profesor Massimo di Pierro, que


gracias a conocerlo me posibilitó comprender mejor su trabajo en perspectiva, y sobre todo,
por reforzar mi creencia de perseguir nuestros ideales respetuosa y científicamente,
entendiendo como buscar alternativas diferentes, útiles para esta investigación.

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 9 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 10 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Dedicatorias

a mi esposa Romina, por estar a mi lado con eterna paciencia

a mis hijos Ivan y Kiara, por ser un desafió siempre gratificante

a mis padres, por su impulso y apoyo continuo

a mis hermanas, por traer diversidad a mi existencia

a la familia de mi esposa, por ayudarme siempre que han podido

a mis abuelas, por haberme enseñado las cosas importantes en el camino de la vida

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 11 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 12 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Indice

Resumen
Agradecimientos
Dedicatorias
Indice
Capítulo 1: Introducción
1.1. Justificación General
1.2. Estructura de la tesis
1.3. Propósito de la Investigación
1.4. Metodología de Investigación
1.4.1. Etapa 1: Desarrollo del Modelo
1.4.2. Etapa 2: Desarrollo del Prototipo
1.4.3. Etapa 3: Análisis y Evaluación del Prototipo
1.4.4. Etapa 4: Conclusiones Finales
1.5. Fundamentos
1.6. El Desarrollo Rápido de Aplicaciones
1.7. El Proceso de Software Personal
Capítulo 2: Estado del Arte
2.1. Relevamiento bibliográfico
2.2. Curso PSP para Ingenieros
2.3. Herramientas RAD
2.4. Herramientas PSP
Capitulo 3: Presentación del problema
3.1. Desarrollo Responsable y Sustentable: buscando Agilidad y
Predictibilidad
3.2. Riesgos y falencias del RAD
3.3. El problema de adopción de PSP
Capítulo 4: Propuesta de solución
4.1. Elección del Modelo
4.2. PSP como proceso rector de la metodología RAD
4.3. Bases de Datos: Modelo Relacional: PostgreSQL
4.4. Integración de Herramientas CASE
4.5. Lenguaje de Programación: Python
4.6. El framework web2py
4.7. Repositorio: Mercurial
4.8. Editor, depurador y consola: ide2py
Capitulo 5: Implantación de la Solución (rad2py)
5.1. Definiciones sobre el proceso y la metodología
5.2. Arquitectura de RAD2PY
5.3. Estado actual del Proyecto RAD2PY
5.4. Implementación de RAD2PY
5.5. Aplicación web de soporte PSP2PY:
Capitulo 6: Prueba de la solución
6.1. Desarrollo de Experimentos:

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 13 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

6.2. Objetivo General


6.3. Objetivos Específicos
6.4. Resultados Esperados
6.5. Datos Obtenidos
6.6. Análisis de los datos obtenidos y pruebas realizadas
6.6.1. Test de correlación y significancia:
6.6.2. Análisis de la distribución de tamaños:
6.7. Análisis de la solución planteadas
6.7.1. Solución a las falencias de las herramientas RAD
6.7.2. Solución al problema de calidad de datos del PSP
6.7.3. Solución al problema de adopción del PSP:
6.8. Evaluación con los lineamientos del SEI
6.9. Resumen de los resultados obtenidos
Capítulo 7: Conclusiones
7.1. Conclusión:
7.2. Futuras líneas de Investigación
7.2.1. Línea de investigación Profesional
7.2.2. Línea de investigación para equipos (TSP)
7.2.3. Línea de investigación educativa
Capitulo 8: Bibliografía
8.1. Referencias:
Capitulo 9: Síglas y Abreviaturas
Capitulo 10: Anexos
Anexo A: Estandard de Codificación PSP
Introduction
General Guidelines
Program Headers
Listing Contents
Documentation Tests
Identifiers
Comments
Major Sections
Blank Spaces
Indenting
Capitalization
Assertions
PEP8 Guidelines
Indentation
Never mix tabs or spaces for Indentation
Tabs are obsolete for Indentation, use spaces
Trailing whitespace is superfluous
Trailing blank lines are superfluous
The last line should have a newline
Limit all lines to a maximum of 79 characters
Imports on separate lines
Compound Statements
Blank Lines
Avoid extraneous whitespace

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 14 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Missing whitespace
(Extra) Whitespace before parameters
(Extra) Whitespace around operator
Missing whitespace around operator
(Extra) Whitespace around comma
(Extra) Whitespace around named parameter equals
Python 3000 has_key deprecated
Python 3000 raise comma deprecated
Anexo B: Estándard de tipos de Defectos
Anexo C: Estandard de Conteo PSP
Introduction
Clarifications
Counting Anomalies
Example
Physical Source Code
Logical Source Code
Results
Anexo D: Lista de comprobación PSP
Purpose
General
Complete
Imports
Initialization
Calls
Names
String
Output Format
(), {}, Pairs
Logic Operators
Line-by-line check
Standards
File Open and Close
Anexo E: Ejercicios del PSP
Programa 1A
Programa 2A
Programa 3A
Programa 4A:
Programa 4A
Programa 5A
Programa 6A
Anexo F: Especificación de Requisitos IEEE830
I. Introducción
II. Identificación de usuarios participantes
III. Catálogo de Requisitos del Sistema
III.1. Objetivos y Alcance del Sistema
III.2. Definiciones, Acrónimos y Abreviaturas
III.3. Descripción General
III.4. Requisitos funcionales:

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 15 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

III.5. Suposiciones y Dependencias


III.6. Requisitos de Usuario y Tecnológicos
III.7. Requisitos de Interfaces Externas
III.8. Requisitos de Rendimiento
III.9. Requisitos de Desarrollo
III.10. Restricciones de Diseño
Anexo G: Diagrama Entidad Relación (PSP2PY)
Anexo H: Diagramas UML
Casos de Uso
Diagramas de Clases (IDE2PY)
Editor:
Soporte PSP:
Repositorio (Mercurial):
Depurador:
Anexo I: Métodos de Prueba
Pruebas de caja Negra
Objetivos
Alcance
Descripción
Casos de Prueba
Resultados:
Pruebas de caja blanca
Objetivo
Alcance
Descripción
Casos de Prueba
Ejemplo:
Resultados
Anexo J: Publicaciones y Presentaciones:

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 16 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Capítulo 1: Introducción

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 17 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 18 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

1.1. Justificación General

En la Ingeniería tradicional, hay un claro consenso de cómo las cosas deben ser
construidas, que estándares deben ser seguidos, y que riesgos deben ser tenidos en
cuenta; si un ingeniero no sigue estas practicas y algo falla, él es demandado. No hay
dicho consenso en la ingeniería de sistemas: Cada uno promueve sus propios
métodos, reclamando altos beneficios en productividad, usualmente no respaldado
por ninguna evidencia científica imparcial.

Traducido del ​Personal Software Process Body of Knowledge​ [PSPBOK05],


citando las críticas frecuentes a la profesión aparecidas en Internet

En la actualidad existen diversas teorías, paradigmas y metodologías abarcando las distintas


áreas de las ingeniería de sistemas informáticos. En general, en cada área de conocimiento de
la profesión y más específicamente las que cubren el desarrollo de sistemas de información,
las metodologías difieren entre si, pudiendo citar:
● Metodologías Ágiles (RAD,XP,Scrum) vs. Robustas o planificadas (Cascada, RUP)
● Procesos de Madurez del Software (PSP,CMM), Normas de Calidad (ISO)
● Modelo Relacional vs. Persistencia de Objetos
● Programación Estructurada; Funcional; Orientada a Objetos, Aspectos, Contextos
● Lenguajes de dinámicos (scripting) vs. Estáticos (system programming);
● Control de Calidad (Testeo) y Aseguramiento de Calidad (Métricas)

A su vez, los beneficios de una determinada metodología sobre otra, generalmente están
influenciados por las comunidades que la utilizan (ya sean usuarios, académicos, o las
empresas que desarrollan y distribuyen las herramientas), y comúnmente no se encuentran
estudios empíricos imparciales o justificación teórica adecuada que sustente la elección
correcta de una metodología sobre otra. Esto puede producir riesgos innecesarios e
imprevistos en el desarrollo de software y problemas de calidad en sus resultados.

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 19 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Si bien la profesión requiere un alto grado de actualización continua, resulta imperioso buscar
una sólida base conceptual que integre las distintas áreas descriptas anteriormente, eligiendo
científicamente el marco teórico que sustente la especialización del futuro profesional luego
de finalizar la carrera de grado, posibilitando un desarrollo laboral con resultados de alta
calidad con una buena relación costo beneficio.

Esta base conceptual es difícil de generalizar merced a los diversos campos de aplicación de
las ciencias informáticas, por lo que se enfocará en el desarrollo de aplicaciones de carácter
general, por parte de un desarrollador independiente.

Para ello, se piensa que el método de Desarrollo Rápido de Aplicaciones (RAD), resuelve
problemas esenciales de la construcción del software, relacionados con el diseño conceptual,
reconocidos como más duros y difíciles, mediante el uso de prototipado, desarrollo
incremental y reuso. Si bien el método ha probado ser efectivo, su eficacia es motivo de
constante debate, comúnmente objetando la calidad de sus resultados, generalmente por la
falta o desapego del seguimiento de un proceso formal de desarrollo y un cambio de enfoque
con respecto a la calidad, priorizando entregas en corto plazo sobre los demás aspectos.

Tomando en cuenta los inconvenientes encontrados, se plantea utilizar junto al método un


proceso disciplinado de desarrollo de software, que lo encause y haga factible su medición
para asegurar su calidad y poder realizar una mejora continua. Se cree que para esto es posible
utilizar el Proceso de Software Personal (PSP) que ha probado cuantificar y mejorar la calidad
sensiblemente.

A su vez, tanto el método RAD y el proceso PSP plantean desafíos para su correcta
implementación, además de la necesidad de completar dicha base conceptual de una manera
sólida con un lenguaje de programación, modelo de datos y teorías que los sustenten y que se
les adecuen; y resulta imprescindible construir una Herramienta de Diseño Asistido por
Computadora Integrada (I-CASE) necesaria, no solo para aplicar correctamente los conceptos
desarrollados por el método (del cual es una parte esencial para lograr disminuir los tiempos

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 20 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

de desarrollo), sino también porque se cree que es fundamental para la recolección y análisis
de métricas de calidad en tiempo real y en línea, solucionando simultáneamente de esta
manera también los inconvenientes del proceso, comúnmente reconocidos como el “problema
de adopción” del PSP (debido al esfuerzo y perseverancia necesarios para aplicarlo).

La suma de una base conceptual sólida y la herramienta tecnológica integrada para utilizarlas
conformará la Plataforma de Trabajo a investigar.

1.2. Estructura de la tesis

En el Capítulo 1 se realiza una introducción general, presentando los conceptos básicos,


metodología y objetivos de la presente investigación y fundamentación general, incluyendo
una breve introducción a los temas relacionados (Desarrollo Rápido de Aplicaciones. Breve y
Proceso de Software Personal).

En el Capítulo 2 se analiza el Estado del Arte mediante un relevamiento bibliográfico,


descripción y enumeración de los cursos de capacitación y las herramientas actuales tanto
para Desarrollo Rápido de Aplicaciones en Python como las de soporte del Proceso de
Software Personal.

En el Capítulo 3 se presenta el problema con una reseña introductoria, los riesgos y falencias
del método de Desarrollo Rápido de Aplicaciones y el problema de adopción del Proceso de
Software Personal (citando estudios sobre factores críticos de éxito, viabilidad, experiencias
de uso, preocupaciones clave y condicionamientos fundamentales de las herramientas
actuales), finalizando con un breve recorrido de los proyectos similares y sus diferencias con
la presente investigación que justifican este trabajo.

En el Capítulo 4 se propone la solución, con su correspondiente elección del modelo a


desarrollar, las herramientas a integrar, el proceso de software y metodología a utilizar, con su
adecuado sustento teórico y tecnológico (modelo relacional para bases de datos PostgreSQL,

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 21 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

lenguaje de programación dinámico Python, marco de trabajo web2py, repositorio de código


fuente Mercurial), cerrando con el enfoque para adaptar las aplicaciones existentes.

En el Capítulo 5 corresponde a la implantación de la solución, con la definición del proceso y


metodología contemplada, arquitectura del prototipo, estado actual del proyecto, su diseño
interno, los módulos construidos para el entorno integrado de desarrollo según RAD (editor,
depurador, interprete, repositorio, servidor web, navegador, etc.), herramienta y aplicación de
soporte al PSP.

En el Capítulo 6 se describe el desarrollo de experimentos para probar el prototipo piloto, con


los objetivos generales y específicos, resultados esperados y obtenidos luego de las pruebas de
la herramienta de desarrollo RAD y aplicación de soporte del PSP (mediante la realización de
ejercicios de programación sugeridos por la bibliografía) y consideraciones estadísticas sobre
los datos recolectados.

En el Capítulo 7 se presenta la conclusión y futuras líneas de investigación, teniendo en


cuenta los supuestos planteados, resultados obtenidos, observaciones realizadas y futuros
cursos de acción que posibilita el presente trabajo, tanto en los ámbitos profesionales,
educativos y académicos.

El Capítulo 8 contiene las referencias bibliográficas a libros y sitios de internet consultados


y/o citados en la presente investigación, y el Capítulo 9 contiene las siglas y abreviaturas
usadas comúmente en este documento.

Forman parte de esta obra los documentos desarrollados para llevar a cabo la este trabajo,
incluyendo estandares de codificación y conteo según el PSP basados en guias del lenguaje
Python, lista de comprobación, ejercicios, código fuente, especificación de requerimientos,
metodología de pruebas y recopilación de publicaciones referidas a esta obra en sitios de
internet y conferencias.

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 22 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

1.3. Propósito de la Investigación

El Beneficio de la Investigación es Proveer de un Marco de Trabajo que sirva como guía a los
profesionales de sistemas que busquen un Desarrollo Rápido de Aplicaciones dando un
enfoque del Proceso de Software de tipo Personal;

Con lo que se beneficia a desarrolladores de sistemas proveyéndoles una base conceptual


sólida y una herramienta que dé soporte a las necesidades del proceso mejorando su
performance y calidad;

Con lo cual se busca:

● Disminución de tiempos y costos en el desarrollo del software, al proveer una


herramienta integrada que cubra todos los aspectos del desarrollo, y simultáneamente
obteniendo automáticamente las métricas de calidad necesarias para ser aplicadas a los
procesos de mejora continua, logrando una mejora en la calidad de los sistemas
producidos por los desarrolladores independientes,
● Minimización de riesgos, tanto para los desarrolladores como para los usuarios finales,
al utilizar una sólida base conceptual, avalada por teorías y datos empíricos
sustentables en el tiempo,
● Fomentando un espíritu crítico, intentando disminuir la tendencia influenciada por
publicidades sin un claro fundamento científico e imparcial.

1.4. Metodología de Investigación

A continuación se detallan las etapas planificadas y llevadas a cabo para realizar este trabajo:

1.4.1. Etapa 1: Desarrollo del Modelo

1. Relevamiento Bibliográfico: se realizó una búsqueda documental en libros de texto,


revistas especializadas. Se analizó en el estado actual de las metodologías de

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 23 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

desarrollo y procesos de mejora de calidad. Se buscaron estudios previos que


demuestren no sólo sus beneficios sino también los inconvenientes planteados, y
futuras líneas de investigación.
2. Realización del Curso “PSP para Ingenieros” del SEI/CMU: con base en [PSP1] se
llevó a cabo el estudio del curso oficial para utilizar el PSP de manera autodidacta con
los archivos descargados de la Universidad de Carnegie Mellon.
3. Estado del Arte: se efectuó el análisis del material recogido que condujo a la
confección del estado del arte.
4. Elección del Modelo: se procedió a determinar cuales podrían ser las herramientas, los
métodos y las técnicas más adecuados de introducir desde el punto de vista del
desarrollo rápido para obtener una mejor calidad.
5. Desarrollo de Experimentos para validar elección teórica: se llevó a cabo el diseño de
la investigación experimental, selección de muestra; recolección y procesamiento de
datos experimentales, para la validación de las teorías, técnicas y herramientas
individuales que sustenten el Modelo.
6. Conclusión Preeliminar sobre el marco conceptual: se confeccionó el informe
preeliminar con el modelo trabajado para el desarrollo del prototipo.

1.4.2. Etapa 2: Desarrollo del Prototipo

Dependiendo del Modelo desarrollado, se utilizó metodologías de análisis y diseño Orientadas


a Objetos, de manera iterativa e incremental (RAD). Para ello se seguieron los siguientes
pasos:
1. Relevamiento de los Requerimientos planteados por el Modelo Desarrollado
2. Planeamiento arquitectónico de las Herramientas a Desarrollar
3. Diseño, Codificación y Testeo iterativo del las funcionalidades
4. Integración final de la herramienta

1.4.3. Etapa 3: Análisis y Evaluación del Prototipo

1. Desarrollo de Aplicaciones de Prueba: se procedió a seleccionar aplicaciones


candidatas, realizar su diseño, codificación y prueba utilizando la herramienta
prototipo desarrollada para validar los supuestos de la presente investigación.

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 24 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

2. Prueba y Validación final del Prototipo: se evaluaron los resultados obtenidos,


métricas recolectadas y consideraciones generales; comparándolos con la bibliografía
y evaluando la viabilidad de prototipo.

1.4.4. Etapa 4: Conclusiones Finales

1. Confección del Informe final y sus Conclusiones: se llevó a cabo un análisis de los
resultados, evaluando la viabilidad del modelo y prototipo y sus futuras líneas de
investigación.

1.5. Fundamentos

Creo que la parte dificultosa de construir software es la especificación, diseño y


testeo de la construcción conceptual, no la tarea de representarlo y testear la
fidelidad de la representación. Por cierto, aún cometemos errores de sintaxis, pero es
irrelevante comparado a los errores conceptuales en la mayoría de los sistemas.

Frederick Brooks (1995) T​he Mythical Man-Month, Essays on Software Engineering,​


[MMM95]

Según Brooks [MMM95], aplicando el pensamiento de Aristóteles en el campo de la


informática, la construcción de software involucra tareas esenciales (dificultades inherentes:
el modelado de estructuras conceptuales complejas que componen la entidad de software
abstracta) y tareas accidentales (dificultades relacionadas a su producción pero no inherentes:
la representación de estas entidades abstractas utilizando lenguajes de programación y el
mapeo de estas en lenguajes de máquina dentro de las restricciones de espacio y velocidad).

A su vez, considera las propiedades inherentes esenciales e irreducibles de los sistemas


de software modernos:
● Complejidad: no existen elementos repetitivos como en la industria automotriz, no
pueden construirse modelos simplificados como en matemáticas,

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 25 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

● Conformidad: no pueden encontrarse principios unificadores como en la física, el


software debe ajustarse a complejidades arbitrarias inherentemente humanas,
● Cambiabilidad: el software esta constantemente sujeto a presiones de cambio, en
mayor medida que en otras disciplinas debido a su naturaleza maleable y funcional,
● Invisibilidad: el software es invisible e invisualizable, su naturaleza no esta influida
por el espacio, por lo que no es posible realizar abstracciones geométricas como en el
caso de la arquitectura, dificultando su representación.

Estas propiedades crean dificultades de diseño, comunicación, aprendizaje y


entendimiento, en una matriz cultural en constante cambio aparejando problemas en la
productividad y calidad de los resultados.

La mayoría de las ganancias en productividad han surgido de remover las barreras


artificiales que habían hecho de las tareas accidentales algo extraordinariamente difícil, como
ser restricciones severas de hardware, lenguajes de programación incómodos, etc. En la
actualidad, como las actividades accidentales no son el grueso del esfuerzo, seguir
disminuyéndolas no dará una mejora sustancial (de un orden de magnitud).

Por lo tanto, sugiere dirigirse a las partes esenciales de las tareas del software, aquellas
concernientes con el modelado abstracto de estructuras conceptuales de gran complejidad:

1. Explotar el mercado masivo para evitar construir lo que puede ser adquirido,
utilizando tecnología existente como base para nuevos desarrollos,
2. Usar el prototipado rápido como una parte de la interacción planeada para establecer
los requerimientos del software,
3. Hacer crecer al software orgánicamente, agregando más y más funciones a los
sistemas mientras son utilizados y testeados, (desarrollo incremental)
4. Identificar y desarrollar a los grandes diseñadores conceptuales de las generaciones
nacientes.

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 26 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

1.6. El Desarrollo Rápido de Aplicaciones

Ya en 1991, James Martin [RAD91] argumentó que los desarrolladores pueden archivar
grandes reducciones en tiempo y costo, entregando sistemas de información de gran calidad al
usar métodos modernos que combinan el involucramiento extensivo del usuario final con
metodologías modernas de desarrollo soportadas por herramientas de diseño asistido por
computadora (CASE) bien integradas (a lo que denomina I-CASE).

En relación a los riesgos y viabilidad del método, en un estudio de campo publicado por la
ACM [RADRSK00], se destaca que si bien existe evidencia creciente que apoya a RAD como
una mejora del “orden de magnitud” en la velocidad de construcción de software, emergen
implicaciones serias. En primer lugar, es importante reconocer que RAD representa un
cambio radical, por lo que se debiera realizar entrenamiento, no solo de conocimientos
técnicos, sino también sobre las mejoras radicales que involucra. Mas importante aún, se
deben evitar las capacidades RAD que deterioran las buenas prácticas en el desarrollo de
sistemas, ya que solo se puede lograr alta calidad, bajo costo y desarrollo rápido si se utiliza
una metodología de desarrollo (proceso de software disciplinado [RADSTN98]).

Es por ello que con esta investigación se busca definir una base conceptual sólida, que
permita desarrollar el método RAD de manera profesional, encuadrado con el Proceso de
Software Personal (PSP) como lineamiento para definir y encauzar la metodología de
desarrollo, para luego desarrollar una herramienta integrada (I-CASE) que le de soporte.

Si bien existen otros acercamientos al tema para solucionar los problemas de calidad
(conocidos como “Metodologías Ágiles”), como ser el Método Dinámico de Desarrollo de
Sistemas (DSDM) desarrollado a partir del RAD [SWQ01], que también se basa en enfocarse
no solo en la velocidad sino también en la calidad. Sin embargo, a diferencia del proceso PSP
más tradicional y robusto [MUKESH08], no existe evidencia empírica públicamente
disponible y consensuada sobre la efectividad del DSDM [AGILDIR03].

1.7. El Proceso de Software Personal

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 27 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

El PSP fue desarrollado en 1993 por Humphrey [PSP00] y es un marco personal y


disciplinado de trabajo para llevar a cabo las tareas de software, que consiste en una serie de
métodos, formularios y guiones que muestran a los ingenieros de software como planear,
medir y administrar su trabajo. La meta del proceso es producir productos con cero defectos,
respetando el calendario y con los costos planeados.

La efectividad de la metodología PSP fue documentada tanto en entornos académicos e


industriales, ya sea en reportes y artículos técnicos. El resultado de estos estudios encontró
que el PSP mejoró el rendimiento (estimación del tamaño y esfuerzo, calidad de producto y
proceso) mientras que no tuvo desventajas en cuanto a la productividad [PSPEMP97].

Si bien estos estudios publicados demuestran las ventajas del PSP, diversos trabajos también
señalan ciertos inconvenientes en la recolección manual de los datos y posterior análisis por
parte de los desarrolladores, cuestionando su exactitud, recomendando que el uso de
herramientas integradas debe ser necesario para un análisis de alta calidad de los datos del
PSP [PSPDAT98].

También se sugiere que si bien los estudiantes aprenden el PSP y logran mejorar sus procesos,
lo abandonan cuando ya no se les requiere utilizarlo. Este “problema de adopción” puede ser
producido por dos causas: sobrecarga de trabajo por la recolección y análisis métricas y el
cambio de contexto (entre la herramienta de desarrollo y la recolección de métricas).
[PSPBEY03].

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 28 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Capítulo 2: Estado del Arte

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 29 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

2.1. Relevamiento bibliográfico

El principal objetivo del PSP es permitir a los ingenieros de software gestionar su


trabajo de manera efectiva y eficiente para desarrollar un código de alta calidad a
tiempo. Los principios PSP son un conjunto de poderosas herramientas que, si se
siguen de la manera correcta, pueden ayudar a hacer el trabajo mejor, más barato y
más rápido.
PSP no es una bala de plata, no va a resolver todos los desafíos de ingeniería de
software. No dice cómo escribir software, pero sugiere dónde y cómo se puede
mejorar el software basado en los datos medidos y proporcionados al PSP.
El método de PSP será muy eficaz si se introduce gradualmente, un paso a la vez, y
con una estrategia de implementación muy bien planificada. Las necesidades del
proyecto deben ser seleccionadas con antelación para aplicar PSP, no debe ser una
idea de último momento.

​ elivering successful projects with TSP and Six Sigma​.


Jain Mukesh, Microsoft Corp. D
[MUKESH08]

Para el presente trabajo se ha realizado una búsqueda documental en libros de texto, revistas
especializadas y sitios de internet para enfocarse en el estado actual de las metodologías de
desarrollo y procesos de mejora de calidad.

Respecto al estado actual, un artículo en memoria de Watts Humphrey [BLOG@CACM10]


resume la importante relevancia de estos temas, aduciendo que el trabajo de dicho autor será
recordado por su búsqueda de que personas, equipos, proyectos, empresas y la industria del
software en su conjunto apliquen los principios sólidos de ingeniería:
● Llevar registro de todo lo realizado
● Aprender y aplicar técnicas cuantitativas y estadísticas de aseguramiento de calidad
● Medir continuamente el esfuerzo, costo y atributos del producto y proyecto,
● Utilizar medidas indirectas para obtener el avance estimado

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 30 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

● Evaluar continuamente el estado de desarrollos, aprendiendo de estos para mejorar el


rendimiento individual, del equipo, proyecto y empresa,
● Utilizar los datos recolectados para desafiar y mejorar las prácticas de software y
procesos.

A su vez, se afirma que no hay contradicción entre la práctica de metodologías ágiles y el


enfoque disciplinado propuesto por el PSP (al menos en las no extravagantes, como el
desarrollo iterativo), pero, sin embargo, también se comenta que la aplicación de dicho
enfoque ha sido muy específica debido a que la mayoría de los documentos de CMMI han
sido escritos de forma demasiado burocrática, alejándolos de muchos programadores y
gerentes que no pueden beneficiarse de dichos conceptos, pero que el PSP y otros principios
seminales serán enseñados y practicados incrementalmente como parte de la inevitable
profesionalización de la ingeniería en software.

Para respaldar dichas afirmaciones, podemos citar a los Simposios sobre TSP (realizados
anualmente desde 2006) que en sus anales [PROCEEDINGSTSP10] dan cuenta del uso de
estos procesos en importantes empresas del sector (Microsoft [MUKESH06], Adobe
[ADOBE09]), su compatibilidad con metodologías ágiles [TSPAGILE09], e iniciativas
académicas y gubernamentales para su enseñanza y aplicación en México [PROSOFT08], por
mencionar algunos casos.

Adicionalmente se realizó el correspondiente análisis bibliográfico sobre las herramientas


actualizadas, que se detalla en la sección Estado del Arte a continuación.

2.2. Curso PSP para Ingenieros

Como parte de la publicación del nuevo libro de PSP, el SEI acordó poner a disposición del
público los materiales sobre PSP a dos grupos de personas: estudiantes e instructores
académicos.

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 31 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

La descarga relacionada al material para alumnos [STUDENTPSP11] proporciona acceso a:


● libro de tareas
● guiones, formularios, instrucciones y normas del PSP
● libros de asignación (ocho programas y cinco informes)

La descarga relacionada al material para docentes [INSTRUCTORPSP11] adicionalmente


proporciona acceso a:
● presentaciones
● guía del instructor
● hojas de cálculo del instructor

Si bien el plan de tesis contemplaba la realización de dicho curso, analizándolo en detalle


resulto no ser relevante para el presente proyecto, ya que no aporta elementos adicionales al
libro original [HUMPHREY95] ni a las sucesivas publicaciones actualizadas y revisadas del
Cuerpo de Conocimiento del Proceso de Software Personal [PSPBOK09]

Para el presente trabajo solo se tomarán los materiales útiles (guiones, formularios,
instrucciones y normas del PSP) para mantener coherencia (compatibilidad) y poder dar
soporte a los cursos impartidos de manera oficial por el Instituto de Ingeniería de Software de
la Universidad de Carnegie Mellon, a saber:

● Guiones: proceso, planeamiento, desarrollo, revisión de diseño, revisión de código,


postmortem, estimación PROBE
● Resumen del Plan de Proyecto e instrucciones
● Bitácoras de registro de tiempos, defectos
● Estándar de Codificación
● Plantillas de reportes de prueba, estimación de tamaño, planeamiento de tareas,
especificación de casos de usos, especificaciones funcionales, de estado o lógicas
● Listados de comprobación de diseño y codificación

Si bien el PSP incluye temas avanzados y complementarios como la guía para Propuesta de

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 32 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

mejora del Proceso (PIP), Proceso de Desarrollo del Proceso (PDP), Desarrollo PSP3.0,
Proceso Experimental Prototipo (PEP), Proceso de Mantenimiento del Producto (PMP),
dichos temas están explícitamente fuera del alcance de este trabajo ya que no están
relacionados primariamente con la recolección automática de métricas en el desarrollo rápido
de aplicaciones.

Lo mismo aplica para Proceso de Software en Equipo (TSP - Team Software Process) y
CMM/CMMI, cuya integración ya esta contemplada en otras herramientas y cursos,
excediendo el marco personal aqui planteado.

2.3. Herramientas RAD

Para crear aplicaciones rapidamente, son necesarias herramientas como generadores


de código, herramientas CASE y prototipado y lenguajes de cuarta generación. Las
herramientas son solo parte de la historia. Es necesario concebir metodologías para
usar las herramientas tan efectivamente como sea posible.

No sería podible construir las ciudades actuales o microchps o aviones sin


herramientas poderosas. Nuestra civilización depende de herramientas, aún así, la
aplicación de poder computacional a sistemas corporativos con frecuencia es
realizada manualmente. El diseño de aplicaciones acopladas de una empresa
moderna no es menos complejo que el diseño de un microchip o de un avión. Intentar
este diseño manualmente hoy en día es ridículo.
El uso de herramientas poderosas cambia los métodos de construcción. Ahora que
dichas herramientas existen, es deseable que el proceso de desarrollo de aplicaciones
sea completamente re-examinado y mejorado. Las herramientas avanzadas crean la
necesidad de una disciplina ingenieríl.

La integración precisa de herramientas de análisis y diseño con generadores de


código brinda mucha más productividad que el uso de herramientas que no estén
acopladas

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 33 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

[RAD91] James Martin, (1991) ​Rapid Application Development​; Macmillan


Publishing Co., Inc. pp.10, 35, 37

Este proyecto fue motivado por la falta de una herramienta sencilla para Python estilo Visual
Basic (conociendo sus inconvenientes y las lecciones aprendidas después de usarlo), pero
sobre todo por algunas dificultades con la "IDE" de Python por defecto (especialmente por
inconvenientes en el aula al tratar de enseñar a Python, y también por la pérdida de
productividad de las herramientas de este tipo observado en el trabajo profesional para
empresas de TI).

Si bien hay otros IDE para python [INFOWORLD1], en general presentan inconvenientes
insalvables para realizar esta investigación, como ser:

● no tener un editor de pantallas integrado (SPE, PyScripter, Eric)


● no tener un depurador integrado (SPE)
● no son multiplataforma (PyScripter)
● no son software libre de código abierto (KOMODO, WingIDE)
● no están hechos en python (PyDev para Eclipse, NetBeans)

El único software que podría ser viable para esta investigación sería BOA, pero luego de un
breve analisis interno se lo encontró demasiado complejo y “anticuado”, lo que impediría
llevar a cabo este trabajo.

A modo comparativo, se presentan capturas de pantallas de IDLE y Visual Basic. IDLE, más
allá de no soportar diseño de pantallas, tener una interfaz muy limitada y depurador
demasiado básico, no esta totalmente integrado y presenta algunos problemas de usabilidad y
complejidad interna lo que lo torna inviable para esta investigación.

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 34 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 2.3.1.: IDLE Editor

Figura 2.3.2.: IDLE: Interprete interactivo:

Figura 2.3.3: IDLE: Depurador

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 35 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 2.3.4: Visual Basic Clásico (para comparación)

Por otra parte, la herramienta más similar a Visual Basic encontrada sería PythonCard (que
incluye un diseñador de pantallas y editor código, junto con una biblioteca para desarrollo
rápido de aplicaciones), lamentablemente su enfoque es muy simple y precario, como puede
observarse a continuación, y su desarrollo a sido discontinuado.

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 36 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 2.3.5: PythonCard Code Editor (diseñador de código)

Figura 2.3.6: PythonCard Resource Editor (diseñador de pantallas)

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 37 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

2.4. Herramientas PSP

Las herramientas pueden ser enormemente provechozas, pero por si mismas no


resolverán los problemas de la ingeniería de software. Tampoco lo hará solamente el
proceso. De hecho, herramientas mejoradas son necesarias en la mayoría de los
aspectos del proceso de software. Pueden mejorar la productividad, reducir los
errores, simplificar las tareas rutinarias y liberar a los ingenieros para el trabajo más
creativo.

Las herramientas de soporte pueden facilitar y hacer más eficientes los métodos
descriptos. Dicha ayuda estándard como procesadores de texto, planillas de cálculo y
paquetes estadísticos proveen inicialmente una base adecuada, pero últimamente se
necesitan entornos CASE para contener los métodos PSP en las estaciones de trabajo,
en adición a todas las otras herramientas generalmente disponibles. Las faclidades
CASE que automáticamente registren el tiempo, sigan los defectos, mantengan los
datos y hagan calculos estadísticos, harán que los métodos PSP sean más fácilies de
introducir y usar.

[HUMPHREY95] Humphrey, Watts S. ​A Discipline for Software Engineering​.


Reading, MA: Addison-Wesley, 1995. p.26

Actualmente existen tres generaciones de herramientas que den soporte al Proceso de


Software Personal (PSP):

● Primera generación: el procedimiento original con guias y plantillas manuales con


soporte de planillas de cálculo o bases de datos simples. Su principal inconveniente es
la sobrecarga de trabajo y poca confiabilidad de los datos recolectados, barrera para la
adopción del PSP.
● Segunda generación: herramientas independientes para recolección de métricas y
cálculo de estadísticas, citando como iniciativa destacada al Process Dashboard

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 38 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

[DASHBOARD11]. Si bien solucionan parcialmente el problema de la sobrecarga de


trabajo, introducen nuevos inconvenientes por el cambio de contexto (pérdida de
concentración al alternar entre la herramienta de desarrollo y la herramienta de
medición) y sigue dejando a criterio del programador el señalamiento de las fases (por
ej. inicio y fin de codificación) y detección de incidentes (por ej. errores introducidos,
errores solucionados), pudiendo compromenter la veracidad de los datos recolectados
(ya sea por error u omisión).
● Tercera generación: corresponden a marcos de trabajo para la medición y análisis
dentro de procesos de ingeniería de software (​in-process software engineering
measurement and analysis - ​ISEMA), cuya implementación de referencia más
destacada es Hackystat [HACKYSTAT11] y consiste en aplicar discretamente
telemetría (recolección automática de datos), que en teoría solucionaría la sobrecarga
de trabajo, eliminando las distracciones por cambio de contexto y aumentando la
confiabilidad de datos. Si bien hay casos que demuestran la factibilidad de usar las
herramientas automatizadas [AISEMA09], su uso no se a extendido debido a que
introduce nuevos interrogantes relacionados a la privacidad de los desarrolladores y a
la efectividad de los datos recolectados por ser en ocasiones demasiado voluminosos y
de muy bajo nivel (genéricos), dificultando su interpretación en tiempo y forma
[ISEMA07].

Figura 2.4.1: Ejemplo del Process Dashboard para la medición de tiempos y defectos

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 39 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 2.4.2: Arquitectura de Hackystat

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 40 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Capitulo 3: Presentación del problema

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 41 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

3.1. Desarrollo Responsable y Sustentable: buscando Agilidad y Predictibilidad

“... Los desarrolladores de software están viviendo en un período de gracia respecto a


la responsabilidad: Los tribunales no han exigido que los profesionales de software
cumplan con los estándares absolutos de profesionalidad requerida en otras
disciplinas de ingeniería.”

Jeffrey Voas, et al. 1997. ​A 'Crystal Ball' for Software Liability​. Computer 30, 6, pp. 29-36.
IEEE

En [UNSOLVABLE97] se afirma que los cronogramas de desarrollo de software, la


productividad y la fiabilidad no puede ser estimado de manera objetiva y viable y por lo tanto
seguirá siendo una cuestión de intuición, argumentando los siguientes puntos:

1. El tamaño y complejidad de un programa no puede ser viablemente estimado a priori.,


por lo que el tiempo de desarrollo no puede ser predecido objetivamente.
2. La productividad absoluta no puede ser objetivamente determinada.
3. La corrección de un programa no puede ser objetivamente determinada.

Por lo tanto, dicho autor concluye que magnitudes fundamentales, como la confiabilidad,
quedan fuera del alcance de la Ingeniería de Software por lo que las cuestiones relacionadas al
desarrollo de sistemas se asemejan más a las incumbencias de las Ciencias Sociales.

Si bien no se han encontrado publicaciones acreditadas que validen o rechacen dichas


aseveraciones, es útil tomarlas como punto de partida para introducir la problemática de la
presente investigación.

A su vez, dichas afirmaciones podrían extrapolarse (como demoras en la entrega, incrementos


de costos o errores catastróficos) en mayor o menor medida sobre otras áreas de la ingeniería
ligadas al diseño e innovación propensas al error humano (por ejemplo, en la ingeniería civil,

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 42 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

química, electrónica, aeronáutica, nuclear, entre otras), pudiendo citar distintas teorías de
accidentes inherentes a sistemas complejos [​REVACC01​].

Lo cierto es que es mucho más frecuente escuchar la frase “se cayó el sistema” a ver un
derrumbe de un edificio, la falla de un circuito electrónico o un accidente aéreo.

La presente investigación comparte que los errores de software en general no son aislados ni
circunstanciales provocados por la necesaria improvisación del proceso creativo, sino que
dichos problemas provienen de causas más mundanas como ser que “técnicas probadas y
rutinas en otras disciplinas de la ingeniería son consideradas inovaciones radicales en en la
ingeniería de software” [MMM75] p14, o más específicamente, porque “la brecha entre las
mejores prácticas de ingeniería de software y la práctica promedio es muy ancha - quizás más
amplia que en cualquier disciplina de ingeniería. Una herramienta que difunda buenas
prácticas, sería importante.” [MMM75] p193.

Volviendo al articulo original y entendiendo que es un tema debatible ya que se basa en la


complejidad algorítmica​, y por definición un algoritmo es un ​“​Conjunto ordenado y finito
de operaciones que permite hallar la solución de un problema” por lo que la solución a una
misma tarea puede tener una gran dispersión respecto al tamaño del programa diseñado
dependiendo de infinidad de factores, para esta investigación se entiende que las causas de tal
variabilidad pueden deberse a falencias comunes como no utilizar las herramientas adecuadas,
no seguir un proceso de software repetible o no tener una metodología bien definida, por lo
que pretende encontrar un conjunto de prácticas que minimicen dicha dispersión y permitan
desarrollar software de manera más predecible.

Por otro lado, en [SWQ01] los impulsores de las metodologías ágiles justamente atribuyen los
problemas a los procesos predictivos, atribuyendole una carga demasiado burocrática que sólo
empeora el problema, argumentando que la necesidad de entregar soluciones rápidas y el
advenimiento de tecnología moderna ha obligado un movimiento de salida del proceso de
calidad controlada (serie de etapas secuenciales en cascada) hacia un enfoque de Desarrollo
Rápido de Aplicaciones (RAD).

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 43 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

La disponibilidad de conjuntos de herramientas para prototipado junto con la facilidad de uso


y libertad que otorga una PC, significa que los desarrolladores pueden producir soluciones
muy rápidamente y pasar por alto los controles tradicionales.

En el corto plazo, esto aparentó ser una efectiva solución a un problema inmediato: un sistema
funcionando entregado rápidamente y conducido por las necesidades del negocio, pero para
organizaciones donde la calidad es importante, el foco del RAD en “codificar y entregar”
introdujo mayores riesgos.

3.2. Riesgos y falencias del RAD

La guerra es el conflicto entre el núcleo duro de la gente que aboga por la


recolección de datos y documentación, y la gente de procesos ágiles. Recuerda el
autor que oyó por primera vez la frase "la guerra" en el discurso de apertura de una
conferencia dada por Ken Schwaber, una persona clave detrás del desarrollo del
proceso ágil Scrum. Schwaber describe un panel de discusión en otra conferencia en
la que había dos mesas dispuestas en el escenario, que se habían creado para reflejar
los dos lados en la llamada "guerra". En una mesa había personas que estaban
apoyando a CMM (ahora se llama CMMI), incluyendo a Mark Paulk. En el otro lado
había gente que estaba apoyando los procesos ágiles, entre ellos Ken Schwaber...

Traducido de Epstein, R. G. ―​Getting Students to Think about How Agile Processes Can
Be Made More Secure.​ [AGILESECURE08]

James Martin en [RAD91] argumenta que los desarrolladores pueden archivar ​tremendas
reducciones en tiempo y costo, entregando sistemas de información de gran calidad al usar
métodos modernos que combinan el involucramiento extensivo del usuario final con
metodologías modernas de desarrollo soportadas por herramientas de diseño asistido por

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 44 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

computadora (CASE) bien integradas (a lo que denomina I-CASE).

Plantea entre sus principales ideas:


● Que las Métricas son un ingrediente esencial para mejorar la productividad,
● Que solo las Herramientas realmente integradas hacen posible el RAD,
● Enfatizando en que las Metodologías necesitan evolucionar a través de su uso y tener
un debido soporte por las herramientas integradas y automatizadas

Con respecto a la implementación del método, aboga por el ​prototipado rápido (​ver secciones
anteriores​), describiéndolo como un mejoramiento iterativo continuo de un subconjunto
inicial del sistema, evolucionando al software hacia un sistema completo. También apunta a
las fallas del prototipado a evitar. Se incluye el concepto de ​caja de tiempo (timebox) donde
se aplican un nivel apropiado de funcionalidad a cada fechas de entrega (​ver secciones
anteriores​).

También afirma que los sistemas desarrollados con la metodología RAD son más fáciles de
mantener, principalmente porque las representaciones de alto nivel de las herramientas
I-CASE son más pequeñas y fáciles de entender que una masa de código de bajo nivel.

Técnicamente discute el modelado de la información y la deseabilidad de que los datos estén


en una forma normal (la teoría relacional se ampliara en la sección de Bases de Datos); el
modelado de los procesos, diagramas y los chequeos que las herramientas I-CASE deben
hacer para validar el modelo; y por último, la reusabilidad durante el análisis (​aplicando el
punto 1 de la sección anterior​).

En 1995, un consorcio inglés identifico las características especiales de los proyectos RAD y
publicaron una primera versión de un estándar de desarrollo (DSDM); en el se identifican tres
factores críticos [RADSTD95]:
● La comunidad de usuarios finales debe tener un ​staff senior comprometido que
permita a los desarrolladores el fácil acceso a los usuarios finales,
● El equipo de desarrollo debe ser estable y tener habilidades bien establecidas,

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 45 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

● El área de la aplicación debe ser comercial, con requerimientos iniciales flexibles y un


grupo de usuario claramente definido.

Adicionalmente a estos factores críticos de éxito, el estándar propuesto recomienda que los
proyectos RAD:

● hagan de los requerimientos del negocio una prioridad, de manera opuesta a priorizar
la calidad de las características operacionales del sistema
● tengan una vista basada en el producto, enfatizando que es lo que el trabajo produce en
vez de una visión centrada en como el trabajo es realizado,
● usen procedimientos de control de configuración de primer nivel, porque cada cambio
puede ser revertido,
● a motivar a los equipos para lograr los objetivos del negocio, en vez de simplemente
completar las tareas asignadas,
● integrar el testeo a través del ciclo de vida,
● realizar estimaciones de tiempo y costo sobre la funcionalidad del producto final, en
vez de hacerlo contra las actividades esperadas de desarrollo,
● enfocar el aseguramiento de los riesgos en la funcionalidad del sistema en vez de la
construcción, y
● realizar lineamientos base de alto nivel sobre los requerimientos, para que sean lo
suficientemente flexibles para ser descompuestos durante el desarrollo.

El estándar se enfoca en el producto en vez de las actividades que lo producen. Por ello,
especifica los productos que deben ser obtenidos y deja libertad sobre las técnicas a ser
utilizadas y su notación abierta y flexible.

En relación a los riesgos y viabilidad del método, temas vitales para este trabajo, en un
estudio de campo publicado por la ACM [RADRSK00] se destacan las siguientes
preocupaciones claves:

● Las características de las herramientas relacionadas al desarrollo son extensamente

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 46 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

más usadas que las de modelado,


● Decae el énfasis en el planeamiento y modelado de requerimientos;
● Subversión potencial de la metodología de desarrollo, por un mayor énfasis en la
construcción del sistema y poco en el análisis del dominio
● Tendencia del desarrollador a no buscar errores y malas especificaciones
tempranamente en el ciclo de desarrollo
● Los beneficios de reusabilidad no pueden ser obtenidos con una fase de análisis por
reducción
● Expectaciones gerenciales irreales sobre cuan rápido un sistema puede ser construido
utilizando este método,
● Desarrolladores con experiencia linear en C con dificultades para realizar la transición
a las herramientas basadas en objetos

Como recomendaciones e implicancias, se destaca que si bien existe evidencia creciente que
apoya a RAD como una mejora del “orden de magnitud” en la velocidad de construcción de
software, emergen implicaciones serias. En primer lugar, es importante reconocer que RAD
representa un cambio radical, por lo que se debiera realizar entrenamiento, no solo de
conocimientos técnicos, sino también sobre las mejoras radicales que involucra. Más
importante aún, se deben evitar las capacidades RAD que deterioran las buenas prácticas en el
desarrollo de sistemas, ya que solo se puede lograr alta calidad, bajo costo y desarrollo rápido
si se utiliza una metodología de desarrollo (proceso de software).

Existen acercamientos específicos para solucionar los problemas de calidad, como ser el
Método Dinámico de Desarrollo de Sistemas, DSDM [SWQ01], pero a diferencia del proceso
PSP más tradicional y robusto, no existe evidencia empírica públicamente disponible y
consensuada sobre la efectividad del DSDM respecto a la calidad de entornos RAD
[AGILDIR03].

3.3. El problema de adopción de PSP

… A la gente del CMM no le gustaba el enfoque ágil para el desarrollo de software y

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 47 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

a la gente del proceso ágil no le gustaba el enfoque CMM. Esa es la guerra. A este
autor le gustaría decir que la gente del CMM acusaba a la gente ágil de producir
WMDs (Web-apps of Mass Disruption, aplicaciones web de destrucción masiva)
mientras que la gente ágil acusaba a la gente CMM de producir WMDs (Whorthless
Massive Documents, documentos masivos sin valor). De hecho, parte de esta guerra
es la percepción en el lado de CMM del argumento de que la gente de proceso ágil no
hacen el suficiente diseño por adelantado, lo que conlleva graves implicaciones de
seguridad. La gente de proceso ágil, en cambio, hacen hincapié en el desarrollo
iterativo, afirmando que el CMM sólo resulta en documentos masivos que nadie lee.

Traducido de Epstein, R. G. ―​Getting Students to Think about How Agile Processes Can
Be Made More Secure.​ [AGILESECURE08]

La efectividad del PSP fue documentada tanto en entornos académicos e industriales, ya sea
en reportes y artículos técnicos. El resultado de estos estudios encontró que el PSP mejoro la
performance (estimación del tamaño y esfuerzo, calidad de producto y proceso) mientras que
no tuvo desventajas en cuanto a la productividad [PSPEMP97]:

● La estimación del esfuerzo mejoró en un factor de 1.75 (promedio)


● La estimación del tamaño mejoró en un factor de 2.5 (promedio)
● La tendencia a subestimar el tamaño y esfuerzo fue reducida. El numero de
sobreestimaciones y subestimaciones fue más balanceado.
● La calidad del producto, como defectos encontrados en las pruebas de unidades,
mejoro 2.5 veces (promedio)
● La calidad del proceso, como porcentaje de defectos encontrados antes de la
compilación, mejoró un 50% (promedio)
● La productividad personal, como líneas de código producidas por hora, no cambio
significativamente. Aún así, se espera que la mejora en la cualidad del producto
resultante debido al PSP mejore la productividad y el tiempo del ciclo medido a nivel
de proyecto.

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 48 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Si bien estos estudios publicados demuestran las ventajas del PSP, diversos trabajos también
señalan ciertos inconvenientes en la recolección manual de los datos y posterior análisis por
parte de los desarrolladores, cuestionando su exactitud, recomendando el uso de herramientas
integradas ​(​herramienta de segunda generación​) ​debe ser necesario para un análisis de alta
calidad de los datos del PSP [PSPDAT98].

También se sugiere que si bien los estudiantes aprenden el PSP y logran mejorar sus procesos,
lo abandonan cuando ya no se les requiere utilizarlo. Este “problema de adopción” puede ser
producido por dos causas: sobrecarga de trabajo por la recolección y análisis métricas y el
cambio de contexto (entre la herramienta de desarrollo y la recolección de métricas). Se
presentó un enfoque automatizado ​(h​ erramienta de tercera generación) que elimina la
sobrecarga de trabajo y el cambio de contexto, también cambia el tipo de métricas
recolectadas (al utilizar sensores remotos y no estar directamente diseñada para el PSP),
produciendo preocupación sobre la privacidad de la información personal recolectada del
desarrollador puesta a disposición públicamente a los administradores del proyecto
[PSPBEY03].

Si bien hay casos que demuestran la factibilidad de usar las herramientas automatizadas
[AISEMA09], queda claro de los mismos que su enfoque no es del todo compatible al
Proceso de Software Personal por no ajustarse a los tiempos, procedimientos y datos
necesarios del mismo (sobre todo en el caso de un desarrollador particular que atañe a esta
investigación):

● Fase inicial larga hasta que el sistema comienza a devolver valor a la compañía
(pensado para proyectos de gran escala)
● Se agrega complejidad para mantener la privacidad, monitoreo y auto-reparación del
sistema distribuido de sensores
● Quedan pendiente temas respecto a la presentación, integración y agregación de datos
externos, sumando la necesidad de ajustes para que la información resulte realmente
útil.

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 49 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Adicionalmente, las experiencias actuales con más de 6 herramientas desarrolladas


(Hackystat, EPM, 6th Sense Analytics, PROM, ECG, SUMS) [ISEMA07] implican
condicionamientos fundamentales sobre usabilidad, generalidad, sencillez, adopción y
rendimiento, enfocadas a ambientes y procesos particulares (ninguno de los cuales se ajusta
100% al PSP). Lo mismo ocurre con la telemetría (mediante sensores, extracción de reportes
o monitoreo de archivos) que no aporta directamente al Proceso de Software Personal, sino
que siguen las técnicas convencionales.

3.4. Proyectos Similares

Los sistemas automatizados de medición y análisis no son adoptados a gran escala en


las empresas, a pesar de las oportunidades que ofrecen. El temor al "Gran Hermano"
y la falta de informes que den ideas sobre el proceso de adopción real y sus usos
concretos en la industria son las barreras para su adopción.

[AISEMA09] Irina Diana Coman, Alberto Sillitti, Giancarlo Succi. Free University of
​ case-study on using an Automated In-process Software
Bozen-Bolzano, Italy. A
Engineering Measurement and Analysis system in an industrial environment.

Actualmente existen diversos proyectos similares a la presente investigación, pero con


distinto enfoques y metas:

● PSP Assistant [PSPA05], que si bien esta enfocada a PSP y posee recolección de
métricas automática (tiempos, defectos, LOC), lo cubre solo parcialmente -por ej., no
soporta todas sus fases, solo codificación/compilación y tests solo de unidades.
● Jasmine: A PSP Supporting Tool [JASMINE07]: posee recolección automática de
ciertas métricas y una guía electrónica de proceso ​(EPG), que permite una fácil
navegación por los elementos del PSP, y un repositorio de experiencias (ER), que
permite almacenar y compartir información relativa al proyecto. Como desventaja se

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 50 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

aclara que no puede detectar tiempo fuera de Eclipse (modificación otros documentos,
revisión de código o testeo) y no puede rastrear errores post-publicación.
● PSP EVA [AGENTS09]: aparentemente superadora respecto a las anteriores con una
propuesta de “agentes” (ver figura 3.4.2), presentaría una mejor visualización del
progreso, con una interfaz proactiva para que la interacción no se vuelva una
sobrecarga y provee flexibilidad en el flujo de fases (para evitar la secuencialidad
planificación, diseño, codificación, compilación, pruebas y post-mortem)

Figura 3.4.1: Eclipse IDE Workspace con ventanas del PSP Assistant [PSPA05]

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 51 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 3.4.2: Ejemplo de salida con rendimiento del proyecto [AGENTS09]

Si bien estos proyectos buscan integrar y ayudar a los ingenieros a entender y usar el PSP de
manera efectiva, surgen las siguientes implicaciones:

● no son herramientas de desarrollo en si, sino que utilizan sensores agregados, por lo
que pueden tener complicaciones para implementar funcionalidades no contempladas
y recolectar correctamente las métricas de forma automatizada (por ej, por no poder
medir tiempos de planeamiento, diseño o revisión, por estar dichas características
fuera de las IDE tradicionales, o no poder contemplar todos los casos para detección
de defectos)
● no son enfoques personales sino que están diseñados para grandes organizaciones y
equipos, lo que puede dificultar su instalación y mantenimiento,
● no contemplan las metodologías de desarrollo rápido de aplicaciones per se, y no están
orientadas hacia un framework particular (por ej python+web2py), lo que se entiende
necesario para esta investigación ya que la adopción PSP es una parte de la
problematica junto con RAD (la dispersión conceptual puede afectar la uniformidad de
las métricas)

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 52 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

● son herramientas propietarias (no están disponibles públicamente y su código es


cerrado), dada la escasa información publicada que se pudo recolectar, lo que dificulta
su análisis y mejora, presentando cuestiones legales incompatibles con el software
libre.
● estan realizadas en PHP, .NET o JAVA, lo que dificulta su modificación y/o
integración con sistemas desarrollados en Python, y en ciertos casos, su operación
multiplataforma es inviable o dependen de paquetes complejos como Eclipse.

Por lo tanto, se entiende que es necesario solucionar la problemática actual quedando en


evidencia la necesidad de una herramienta de “cuarta generación” para Python, realizada en
software libre de código abierto, que integre completamente el proceso de desarrollo de
software para simplificar y sustentar una efectiva disciplina personal, totalmente
automatizada, sin necesidad de programas o tareas adicionales.

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 53 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 54 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

Capítulo 4: Propuesta de solución

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 55 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

4.1. Elección del Modelo

Sentimos que PSP y TSP son tecnologías notables que pueden cambiar la cara de la
industria del software, y compartimos el interés del SEI en promover su uso
generalizado. Creemos que una herramienta de soporte poderosa de libre
disponibilidad podría ayudar a eliminar una de las barreras más significativas para
la adopción del PSP / TSP. Por lo tanto, tratamos de crear una herramienta de clase
mundial bajo el modelo de código abierto, y distribuirla libremente a las personas que
utilicen PSP y/o TSP. Creemos que esto es lo menos que podemos hacer para
agradecer a la SEI para el desarrollo y la difusión de estos procesos notables.

Traducido del Página del Proyecto “​ Software Process Dashboard Initiative”


[DASHBOARD11]

Si bien esta investigación comparte la necesidad de una herramienta de soporte para el PSP,
por lo expuesto esto no sería suficiente para eliminar la barrera de adopción y por ello se
plantea la necesidad de proporcionar un entorno integrado de desarrollo (IDE) totalmente
unificado para encauzar el desarrollo rápido de aplicaciones bajo el proceso de software
personal, mejorar la calidad, predictibilidad y eficiencia, evitando el doble trabajo, la
dispersión, cambio de contexto, encauzando la actividad mediante buenas prácticas y
estándares reconocidos en la ingeniería de software.

Como solución, para el presente trabajo, vistos los problemas descriptos en la introducción y
antecedentes, y luego de efectuar una investigación sobre el tema, se plantea:

1. Integrar la cadena de herramientas de desarrollo para lograr una herramienta I-CASE


que dé soporte completo al RAD, estructurándolas sobre el Proceso de Software
Personal, buscando con esto solucionar las deficiencias comúnmente asociadas al

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 56 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

método de desarrollo (poco uso de herramientas de modelado, subversión potencial de


la metodología de desarrollo, falta de planeamiento y control, etc.).
2. Integrar directamente la recolección y análisis de métricas dentro de las herramientas
de desarrollo I-CASE, orientado a eliminar los problemas de datos observados al PSP
(cambio de contexto, sobrecarga de trabajo, privacidad, etc.), obteniendo estadísticas
confiables para la evaluación de la calidad y el proceso de mejora continua.

Al integrar la cadena de herramientas de desarrollo RAD, enfocado sobre el proceso PSP, se


piensa obtener los siguientes beneficios:

● Desarrollar e Integrar las diferentes herramientas de cada etapa del ciclo de vida
(análisis, diseño, codificación, implementación), poniendo énfasis no solo en la
construcción sino también en el análisis del dominio;
● A través de las herramientas, hacer cumplir un proceso bien definido (PSP), para
evitar que se desvirtúe o directamente se abandone la estructura de los proyectos,
mejorando la capacidad de ser controlados y por ende la calidad final de sus
productos;

A su vez, al integrar las métricas PSP a la herramienta de desarrollo, se piensa que mejorará el
proceso ya que:

● No hay cambio de contexto ni sobrecarga de trabajo ya que la recolección de datos


para las métricas será automática en la misma herramienta I-CASE,
● Por lo tanto no se utilizan sensores que pueden ser accedidos remotamente, obteniendo
el análisis directamente de la misma herramienta, dándole al desarrollador total control
de la información personal recolectada.
● Mayor retroalimentación con respecto al análisis de las métricas, ya que se puede
realizar un seguimiento prácticamente instantáneo mejorando de esta forma el proceso
de mejora continua.

Para lograr desarrollar esta herramienta de ingeniería de software integrada (I-CASE) se

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 57 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

propone utilizar el entorno de programación Python [PYWEB], ya que se cree que se ajusta al
método RAD al cumplir los siguientes puntos [PYNEST05, PYPROG05]:

● Prototipado Rápido: al ser un lenguaje dinámico, con tipos de datos nativos de alto
nivel, de sintaxis clara y fácil lectura acelera la productividad, sin comprometer la
mantenibilidad;
● Reuso: provee modularidad completa, jerarquía de paquetes, librería estándar
extensiva, facilidad de extensión vía C, C++, Java, .NET;

A su vez, dos características claves son que permite empotrar el lenguaje dentro de las
aplicaciones (​Scripting, Macros)​ y es altamente flexible por lo que puede ser usado para
intermediar distintas interfaces (​Glue Languaje)​ , lo cual facilitará el desarrollo e integración
de las herramientas de desarrollo.
También se destaca la gran cantidad de herramientas e interfaces de programación (GUI,
bases de datos, HTTP/HTML/XML, etc.) disponibles, en su mayoría de código abierto, lo que
posibilitará desarrollar el presente trabajo utilizando, extendiendo y/o integrando las
herramientas ya desarrolladas.

Adicionalmente, para el presente trabajo, web2py es la herramientas más adecuada de


introducir para obtener una mejor calidad desde el marco conceptual planteado, debido a que
cumple todas las características de desarrollo rápido de aplicaciones (prototipado, iterativo,
incremental, priorizando la funcionalidad y posee testeo integrado), es centrado en bases de
datos relacionales y posee herramientas CASE totalmente integradas (IDE de desarrollo,
pruebas, despliegue).

A su vez, la elección del lenguaje de programación, herramientas y bibiliotecas permiten


definir de manera precisa la metodología de desarrollo de manera integrada, tema central para
esta investigación.

En resumen, como solución se busca desarrollar un proyecto denominado RAD2PY, donde se


plantea integrar directamente la recolección de métricas dentro de las herramientas de

Mariano Reingart - 3201-1543 - ​mreingart@unimoron.edu.ar Página 58 de 207


rad2py: Plataforma de Trabajo para RAD bajo PSP

desarrollo I-CASE del modelo RAD, solucionando de este modo los problemas antes
planteados, generando una herramienta PSP de Cuarta Generación ​que integre completamente
el proceso de desarrollo de software para simplificar y sustentar una efectiva disciplina
personal, totalmente automatizada, sin necesidad de programas o tareas adicionales.

4.2. PSP como proceso rector de la metodología RAD

Como guía para el modelo RAD, (​por los motivos que se detallan en las secciones
anteriores​), se utilizará el Proceso de Software Personal (PSP) desarrollado en 1993 por
Humphrey [PSP00], un marco personal y disciplinado de trabajo para llevar a cabo las tareas
de software, que consiste en una serie de métodos, formularios y guiones que muestran a los
ingenieros de software como planear, medir y administrar su trabajo. El PSP fue diseñado
para su uso con cualquier lenguaje de programación o metodología de diseño, y puede ser
usado en la mayoría de los aspectos del trabajo de software, incluyendo: escribir
requerimientos, correr pruebas, definir procesos y reparar defectos. Cuando los ingenieros
usan el PSP, la meta del proceso recomendado es producir productos con cero defectos,
respetando el calendario y con los costos planeados.

A su vez, se utilizaran el “cuerpos de conocimiento” del PSP descriptos en [PSPBOK05],


donde se detallan los conceptos, hechos y habilidades necesarios para utilizar y mejorar el
proceso personal del desarrollo del software. Este se basa y complementa al “cuerpo de
conocimiento” de la Ingeniería de Software [SWEBOK04], que se utilizará para delinear las
áreas claves generales del desarrollo del software.

El PSP esta dividido en siete versiones para facilitar su uso, ya que no todos los métodos son
generalmente usados por los ingenieros; y expone a estos a 12 de las Áreas Clave de Proceso
del Modelo de Madurez de Capacidad (CMM), y esta también relacionado con el Proceso de
Software de Equipos (TSP).

En el PSP, los ingenieros utilizan datos para monitorear y mejorar su trabajo. Para ello se
reúnen datos sobre los tiempos utilizados en cada fase, el tamaño de los productos (líneas de

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 59 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

código) y calidad (densidad de defectos, tasa de revisión, etc.).

4.3. Bases de Datos: Modelo Relacional: PostgreSQL

La Programación Orientada a Objetos esta entregando importantes beneficios en el


ámbito de la reutilización, pero los beneficios prometidos en las áreas de la
naturalidad y facilidad de uso han sido refutadas (Scholtz, et al. 1994). La
programación orientada a objetos integra muchas de las mejores ideas de los últimos
35 años de desarrollo de software, pero aprender a usarla bien es difícil. Imponen un
carga más para el desarrollador y no una menos, y debe ser vista como tecnología de
expertos. Cuando se ve de esa manera, es una valiosa adición a la caja de
herramientas del desarrollador.

​ apid Development: Taming Wild Software


T​raducido de Steve McConnell. 1996. R
Schedules​ Microsoft Press, Redmond, WA, USA​.

James Martin [RAD91] establece que para los proyectos RAD debe utilizarse el modelo
relacional con los datos normalizados. Este es introducido formalmente por Codd [CODD70],
como un modelo de relaciones n-arias (una forma normalizada para las relaciones de una base
de datos). Este modelo probaría ser superior en varios aspectos a los modelos gráficos y de
red. Además provee las bases para un lenguaje de datos de alto nivel que logrará una máxima
independencia entre los programas por un lado y la organización de los datos por el otro.

A su ves, extendió su trabajo sobre el modelo relacional [CODD79] para incluir más
semántica (semánticas “atómicas” y “moleculares”) y que el sistema de base de datos se
comporte de manera más inteligente.

Este último trabajo sirvió como base a los sistemas de base de datos objeto-relacional,
culminando con “El Tercer Manifiesto” de Darwen y Date [TTM95] donde se analiza el
futuro de las bases de datos, incluyendo ciertas características que han sido muy discutidas

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 60 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

recientemente, incluyen la Orientación a Objetos (OO). Para ello, según los autores, el modelo
relacional no necesita extensión o corrección alguna argumentando que el modelo OO es
ortogonal al Relacional.

De la extensa bibliografía en la materia, se destaca el trabajo de Date [DBD05], al proveer


fundamentos actualizados del modelo Relacional, sin influencias de ningún vendedor o
producto, explicando el motivo de que el modelo sigua siendo directamente relevante a la
tecnología moderna de la base de datos y por que permanecerá así en el futuro próximo, las
causas de las deficiencias del estándar SQL, para utilizar el mejor conocimiento teórico actual
en el diseño de bases de datos y aplicaciones.

Por último, Date [BRA00], plantea la utilización de reglas declarativas (​Bussiness Rules​)
como una solución a los problemas procedurales encontrados al utilizar bases de datos.

Para cumplir las características del presente trabajo, se utilizara [POSTGRES]​, desarrollada
originalmente en el Departamento de Ciencias de la Computación de la Universidad de
California en Berkeley, fue pionera en muchos de los conceptos de bases de datos relacionales
orientadas a objetos que ahora empiezan a estar disponibles en algunas bases de datos
comerciales. Ofrece suporte al lenguaje SQL:2003, integridad de transacciones, y
extensibilidad de tipos de datos. PostgreSQL es un descendiente de dominio público y código
abierto. El proyecto Postgres original, liderado por el Porfesor Michael Stonebraker, fue
esponsorizado por diversos organismos oficiales u oficiosos de los EEUU: la Agencia de
Proyectos de Investigación Avanzada de la Defensa de los EEUU (DARPA), la Oficina de
Investigación de la Armada (ARO), la Fundación Nacional para la Ciencia (NSF), y ESL, Inc.

PostgreSQL es altamente programable (lenguaje procedural Pl/Python), soporta


procedimientos almacenados y tiene características de POO, lo que posibilitan utilizarlo para
propósitos avanzados, incluyendo las reglas declarativas (bussiness rules) y orientación a
objetos, descriptas anteriormente.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 61 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

4.4. Integración de Herramientas CASE

Las Herramientas CASE individuales soportan típicamente un pequeño conjunto de tareas


dentro del proceso de desarrollo de software. Ellas no proveen un soporte coordinado a lo
largo del rango completo de tareas del ciclo de vida. Por ello se utilizaran el conjunto de
conceptos, modelos y líneas guía para la integración de herramientas CASE, planteado por
Brown [CASE01].

El autor presenta un modelo que separa tres aspectos distintos de integración para que sean
examinados por separados y sus relaciones analizadas en conjunto:

● Servicios al usuario final: consideraciones conceptuales


● Mecanismos: consideraciones de implementación
● Proceso: contexto de diseño

A su vez, presenta cuatro clases de integración y sus propiedades importantes:

● Integración de Datos
○ Interoperabilidad: cantidad de trabajo necesario de una herramienta para
manipular datos producida por otra;
○ No Redundancia: cantidad de datos administrados por una herramienta son
duplicados o pueden ser derivados de otra;
○ Consistencia: en que medida dos herramientas cooperan para mantener las
restricciones semánticas de los datos que manipulan;
○ Intercambio: cantidad de trabajo necesario para usar datos no persistentes entre
dos herramientas;
○ Sincronización: en que medida las distintas herramientas comunican los
cambios realizados entre si.
● Integración de Control
○ Provisión: en que medida los servicios de una herramienta son usados por otra

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 62 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

en el entorno,
○ Uso: en que medida una herramienta usa servicios de otra.
● Integración de Presentación
○ Apariencia y Comportamiento: en que medida dos herramientas usan
apariencias de pantalla y comportamientos interactivos similares,
○ Paradigma de Interacción: ídem para las metáforas y modelos mentales,
● Integración de Proceso
○ Pasos del Proceso: en que media dos herramientas combinan para soportar la
realización de un paso del proceso
○ Evento: en que medida dos herramientas convienen en los eventos requeridos
para soportar un proceso
○ Restricciones: en que medida dos herramientas cooperan para reforzar una
restricción.

4.5. Lenguaje de Programación: Python

Python es un lenguaje de programación interpretado dinámico y orientado a objetos, creado


por Guido van Rossum en el año 1990, que puede ser usado para desarrollar aplicaciones de
múltiples tipos (multiparadigma).

Permite integrar fácilmente otros lenguajes y herramientas, incluye una amplia biblioteca de
funciones y es sencillo de aprender. Muchos programadores Python reconocen un sustancial
aumento en su productividad y sienten que el lenguaje mismo los incentiva al desarrollo de
código de mayor calidad y más fácil de mantener. Está disponible en múltiples plataformas,
desde una PC hasta teléfonos celulares, y muchos sitios de Internet utilizan Python como
soporte de sus servicios.

Reconocido en el ambiente del Software Libre, visto como una creciente alternativa a Java y
.NET, es usado actualmente por miles de empresas, incluyendo a Google, Industrial Light &
Magic, iRobot, NASA, y YouTube.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 63 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

En la actualidad Python se desarrolla como un proyecto de código abierto, administrado por la


Python Software Foundation. La última versión estable del lenguaje es la 2.7.2 y 3.2.2.

Se propone utilizar el lenguaje de programación Python [PYWEB], ya que cuenta con las
siguientes características:

● Lenguaje de sintaxis clara y fácil lectura


● Fuertes capacidades de introspección (meta-clases, tipeo dinámico, decoradores)
● Orientación a Objetos Intuitiva
● Expresión natural de código procedural
● Modularidad completa, soportando jerarquías de paquetes
● Manejador de error basado en excepciones
● Librerías estándar extensiva, y módulos de terceras partes para virtualmente
● Facilidad de extensión vía C, C++, Java, .NET
● Empotrable dentro de aplicaciones como un lenguaje de scripting

A su vez, es compatible con otras tecnologías, por lo que permite reutilizar componentes
previamente desarrollados:

● Puede interactuar con objetos COM, .NET y CORBA; JAVA (​Jython es una
implementación de Python para la Maquina Virtual de Java); .NET ( ​IronPython,​ es
una implementación de Microsoft del lenguaje para .NET).
● Puede correr sobre plataformas: Windows (nativo, .NET y Java), Linux/Unix (nativo y
Java), OS/2, Apple Mac, Amiga, Telefonos Celulares, Etc.
● Puede utilizar una Interfaz Gráfica: ​wxWindows:​ Linux/Windows/Mac, ​PyQt​, Etc.

Estas características [PYNEST05, PYPROG05], se resumen en dos puntos de vital


importancia para el Desarrollo Rápido de Aplicaciones:

● Prototipado Rápido: al ser un lenguaje dinámico, con tipos de datos nativos de alto
nivel, de sintaxis clara y fácil lectura acelera la productividad, sin comprometer la

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 64 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

mantenibilidad;
● Reuso: provee modularidad completa, jerarquía de paquetes, librería estándar
extensiva, facilidad de extensión vía C, C++, Java, .NET;

A su vez, al ser de código abierto y poseer gran cantidad de herramientas libres (como ser
PythonWin​: entorno integrado de edición y depuración, ​PyCrust​: facilidades de edición de
texto, ​PythonCard​: construcción y modelado de GUI (utilizando wxPython), ​SPE​:
visualizador de objetos y clases UML, ​PyChecker:​ herramienta para detectar errores – similar
al chequeo realizado por la compilación de los lenguajes estáticos–, ​Py2Exe / Freeze​:
herramienta de despliegue, etc.) facilitará el desarrollo de una herramienta I-CASE integrada.

4.6. El framework web2py

Las necesidades de los científicos para comunicarse de manera efectiva, colaborar a


través de Internet, y organizar y presentar datos de forma estructurada y accesible se
han convertido en algo muy importante. El marco de trabajo web2py ofrece
desarrollo y prototipado rápido de aplicaciones Web seguras con bases de datos y fue
creado específicamente con las comunidades científica y académica en mente.

Massimo Di Pierro, CTI DePaul University. Revista​ C


​ omputing in Science & Engineering
[WEB2PY11]

Del propio libro oficial [WEB2PY10] se extraen las siguientes características:


● web2py es una plataforma web libre de código abierto para el desarrollo ágil de
aplicaciones web seguras, sustentadas en base de datos.
● web2py es una plataforma completa, lo que significa que contiene todos los
componentes necesarios para construir aplicaciones web completamente funcionales;
● web2py está diseñado de manera que guía al desarrollador web a aplicar buenas
prácticas de ingeniería de software, tales como el uso del patrón Model View
Controler (MVC);

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 65 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

● web2py separa la representación de datos (el modelo) de la presentación de datos (la


vista) y también de la lógica de la aplicación y flujo de trabajo (el controlador);
● web2py proporciona un sistema de tickets. Si ocurre un error, los tickets se expiden
para el usuario, y el error se registra para el administrador.

Si bien web2py es una herramienta simple e integrada que permite centrarse en la


funcionalidad a desarrollar [PET10], dada la experiencia con la misma (y con el lenguaje
Python en general), se considera necesario agregar varias funcionalidades para completar el
presente trabajo (según las fases del PSP):

Planeamiento:
● soporte para registro de actividades/tareas, tiempos estimados y acumulados
● medición de tiempos automática (incluyendo interrupciones y detección de cada fase)
● mejoras en el seguimiento a los tickets de defectos (introducidos y removidos en cada
fase)
● soporte para listas de comprobación (checklists) y guiones (scripts)
● estimación según datos estadísticos

Diseño:
● mejorar el soporte para documentación el proyecto (archivo de texto - formato wiki)

Codificación:
● facilitar las técnicas de revisión y detección temprana de defectos (“chequeo estático”)
● medición automática de LOC (líneas código) eliminadas, modificadas, agregadas o
reusadas

Compilación:
● chequeo de sintaxis al editar los archivos
● chequeo estático de nombres de variables y funciones definidas
● chequeo del estándar de codificación (convención de nombres, sangría, etc.)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 66 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Pruebas:
● depurador integrado
● generación de tickets en pruebas automatizadas
● mejora en tickets de error

Si bien el framework es cuestionado en ciertos circulos (sobre todo de herramientas


competidoras), en general dichas afirmaciones no son sólidas o fundamentadas y se basan en
las desiciones clave de su diseño que lo diferencian del resto de las herramientas disponibles:

1. Biblioteca de Abstracción de bases de datos (DAL) en vez de Mapeador


Objeto-Relacional (ORM) más tradicional.
2. Utilizar ​exec​ (ejecución) en vez de ​import​ (importación de modulos tradicional)

Respecto al primer punto, si bien el framework no obliga a utilizar objetos ya que se utiliza un
modelo relacional (y no es una limitación, ver secciones anteriores), estos podrían utilizarse,
con las salvedades que involucra. A su vez, Python es un lenguaje multiparadigma, pudiendo
ser utilizado tanto POO, programación funcional o programación estructurada.

Respecto al segundo punto, se entiende que la “ejecusión dinámica” en vez de la “inclusión


estática” no es un problema sino una ventaja (mas allá de los temas puntuales de
rendimiento), liberando al desarrollo de cierta rigidez del lenguaje y posibilitando alternativas
interesantes, ya que permite código mucho más dinámico y en cierta medida auto-adaptable al
contexto/sesión, pudiendo citar un estudio sobre reuso de software [REUSE05] que comparte
las necesidad de investigar sobre estas consideraciones:

En la actualidad, la mayoría de la investigación se centra en la reutilización y la


creación de la integración de componentes adaptables en desarrollo o en tiempo de
compilación. Sin embargo, con la aparición de la computación ubicua, son requeridas
tecnologias de reutilización que puedan apoyar la adaptación y la reconfiguración de
las arquitecturas y componentes en tiempo de ejecución. Una de las consecuencias de

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 67 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

este desarrollo es que de alguna manera necesitamos integrar el know-how de a


ingeniería en el código para que pueda aplicarse mientras la aplicación esta
corriendo. Se necesita más investigación sobre software auto-adaptativo, software
sensible al contexto, software reconfigurable, y auto-sanación de sistemas.

​ oftware Reuse Research: Status and Future​ [REUSE05]


William B. Frakes and Kyo Kang. S

Por ultimo, un artículo publicado recientemente [INFOWORLD2], compara varios


frameworks web para python, ubicando a web2py con el mejor puntaje gracias a su facilidad
de uso, capacidades, e instalación, reconociéndolo como el mejor software open source del
año para el lenguaje python y herramientas web.

4.7. Repositorio: Mercurial

Mantener el conocimiento en texto sin formato: El texto plano, no quedará obsoleto.


Ayuda a aprovechar su trabajo y simplifica la depuración y pruebas.

​ he Pragmatic Programmer.
Extraido de Andrew Hunt and David Thomas. 2000. T
[PRAGMATIC00]

Si bien el concepto RAD de repositorio es mas complejo e inteligente, se entiende que para
este trabajo es suficiente con un repositorio de las distintas versiones del código fuente, ya
que todos los archivos se manejaran con formato de texto plano.

Para ello se utiliza [MERCURIAL] una herramienta de control distribuido de código fuente.
Justamente su característica distribuida permite crear repositorios locales, útiles para el
análisis de líneas de código agregadas, eliminadas y modificadas, disponible aún para
pequeños proyectos que no dispongan de un servidor centralizado.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 68 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Al estar construido y utilizar el lenguaje Python, su integración con el resto de las


herramientas es relativamente simple.

4.8. Editor, depurador y consola: ide2py

“Usa un Solo Editor Bien: El editor debe ser una extensión de tu mano; asegurate que
sea configurable, extensible y programable

​ he Pragmatic Programmer.
Extraido de Andrew Hunt and David Thomas. 2000. T
[PRAGMATIC00]

Al ser de código abierto y estar programado en Python hay gran cantidad de herrmientas
libres de código abierto que pueden ser útiles para el presente, y si bien se relevaron y
analizaron muchas de ellas (ActiveGrid/PyIDE, wxPyDev, Pyragua, Picalo, SPE, Ninja-IDE,
PythonWin, drPython, PythonCard, IDLE), ninguna era realmente integrada y simple, y
finalmente se optó por un enfoque nuevo y minimalista para poder desarrollar los objetivos de
este trabajo en tiempo y forma.

Un punto importante fue definir el tipo de entorno (aplicación web o aplicación “visual”
GUI). Inicialmente web2py es una aplicación web totalmente administrable por internet (por
ej. con editor de código por el navegador). Esto es muy útil para ambientes distribuidos, pero
es limitado para desarrollar un prototipo simple en tiempo y forma, por lo que se evalúa la
posibilidad de desarrollar un prototipo “visual” con interfaz gráfica de escritorio (ide2py y
gui2py inspirados en facilidades existentes, como el editor predeterminado “de facto” ​IDLE
de Python, y herramientas de de desarrollo rápido “visuales” como ​PythonCard y su juego de
herramientas gráficas ​wxPython)​ .

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 69 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Por esto último, no solo se contribuirá a la comunidad Python con un entorno de desarrollo
totalmente integrado y simple guiado por sólidas prácticas de la ingeniería de software, sino
que también posibilitará el desarrollo rápido de cualquier tipo de aplicación (ya sea de interfaz
gráfica, web o de consola) de manera unificada.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 70 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Capitulo 5: Implantación de la Solución (rad2py)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 71 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

5.1. Definiciones sobre el proceso y la metodología

Postulado de complejidad: El potencial de accidentes aumenta en sistemas complejos,


formados por muchos componentes y diversos modos de fallas posibles.
Postulado de acoplamiento: El potencial de accidentes aumenta en sistemas
acoplados.
Postulado de inevitabilidad: Los sistemas de alto riesgo tienen características
especiales que hacen que los accidentes se produzcan inevitablemente.

Postulado de recurrencia: Las causas de fallas se deben a errores de diseño según


patrones que se dan en la historia de la ingeniería de manera recurrente.

Postulado de ejemplos paradigmáticos: Los patrones de errores se pueden extraer de


estudios de casos, mediante la identificación de ejemplos paradigmáticos o
paradigmas

Postulado de inteligencia operativa. Las causas de los accidentes radican en el


proceso racional de la toma de decisiones por parte de los agentes que controlan el
funcionamiento del sistema. Es decir, en la “inteligencia operativa” que controla el
proceso de toma de decisiones.

Teorías de Accidentes de Perrow, Petroski, Dörner, citados en [​REVACC01]​

Para lograr disciplina y predictibilidad, reduciendo la tasa de defectos tendiendo a 0, el PSP


define las directrices generales (generalmente usadas en otras áreas de la ingeniería), que
deben ser adaptadas a cada desarrollador en particular, para los cuales se entiende que es
necesario aplicar los conceptos de la Metodología de Desarrollo Rápido de Aplicaciones,
lenguaje de programación, herramientas y bibliotecas expuestas en la fundamentación de la
solución propuesta.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 72 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Se entiende para este trabajo que un Proyecto de PSP equivale a una iteracción de RAD. Para
la presente investigación se definieron las siguientes Fases de Proyecto:

● Planeamiento: definición de arquitectura general y estimación de tiempos


● Diseño: conceptual (pseudocodigo), prototipado y documentación
● Codificación: refinación del diseño en lenguaje Python
● Compilación: sintáxis, análisis estático y estandard de codificación
● Revisión: lista de chequeos manuales
● Pruebas (testing): depuración y pruebas de documentación
● Post-mortem: cierre

Documentos:

● Toma de requerimientos: formato wiki markmin


● Diseño: pseudocódigo en Python, modelo relacional y patron
Modelo-Vista-Controlador
● Estandard de Codificación Python (PEP8)
● Estandard de Conteo (líneas de código)
● Lista de Revision

En la sección de anexos se adjuntan cada documento relacionado.

5.2. Arquitectura de RAD2PY

Cuando vemos a una nueva herramienta de software, nos resulta fascinante, no


podemos evitarlo. ¡A quién le importa si es práctica! ¡Tiene barras de desplazamiento
3D! ¡Y los menús personalizables! ¡Mira! Incluso emula Brief, VI y EMACS! Las
nuevas herramientas son seductoras para los desarrolladores de software, y creo que
el síndrome de bala de plata es un riesgo laboral. No estaríamos en este negocio si no
fuéramos propensos a creer que las herramientas de software pueden solucionar
nuestros problemas.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 73 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

​ apid Development: Taming Wild Software


Traducido de Steve McConnell. 1996. R
Schedules​ Microsoft Press, Redmond, WA, USA​.

Esta investigación se enfoca, en primer lugar, en desarrollar una IDE (entorno de desarrollo
integrado), que de soporte al PSP (tanto a nivel fases como recolección de métricas). Para
ello, se integrará la cadena de herramientas, rescatando los puntos sobresalientes de cada una:

● IDLE / PythonWin​: entorno integrado, características de edición y depuración


integradas.
● PyCrust:​ facilidades de consola interactiva
● PythonCard​: construcción y modelado de GUI (utilizando wxPython)
● SPE​: visualizador de objetos y clases UML
● PyFlakes:​ herramienta para detectar errores (similar a la compilación de los lenguajes
estáticos).
● Py2Exe / Freeze:​ herramienta de despliegue

En segundo lugar, se desarrollará una herramienta de soporte y seguimiento, preferentemente


con interfase web, para la adquisición de requerimientos, seguimiento de errores, generación
de documentación on-line; similar a las herramientas ​Trac,​ ​RoundUp.​ Se tomará como
referencia para la captura y análisis de métricas PSP, el sistema ​Process DashBoard​. La
integración de datos se realizará a través de una base de datos relacional.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 74 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 5.2.1: Esquema general de RAD2PY

5.3. Estado actual del Proyecto RAD2PY

El avance de la presente investigación no ha sido sin sobresaltos, encontrando dificultades en


cada etapa del desarrollo, tanto por problemáticas de las bibliotecas externas (wxPython,
Mercurial, etc.) como también con módulos y bibliotecas estandar de Python (Shell y
Depurador, DiffLib, Help, DocTests, etc.), ya sea por falencias en la documentación,
funcionalidades no disponibles o comportamientos no esperados, entre otros.

Igualmente se ha podido avanzar y el estado prototipo actual del Entorno de Desarrollo


Integrado (IDE2PY) es:

● El editor es funcional, con autocompletado de código y calltips básicos, incluyendo


soporte para globales de web2py
● Consola interactiva, con redirección segura de entrada/salida estándar
● Depurador simple con soporte de interrupciones e inspección rápida
● Soporte para repositorios Mercurial limitado (operaciones locales)
● Comparador visual de diferencias experimental
● Ayuda integrada muy básica
● Recolección automática de defectos (chequeo estático y pruebas documentadas)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 75 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

● Medición automática de tiempos en cada fase de desarrollo, contemplando


interrupciones

La aplicación web de soporte (PSP2PY) posee en funcionamiento el modelo básico para


gestionar proyectos PSP (principalmente el almacenamiento de datos históricos de defectos y
tiempos), y se planea agregar interfaz de usuario simple y funcionalidades de planificación,
estimación y seguimiento.

Para interconectar ambas aplicaciones, se ha desarrollado un cliente simple de comunicación


entre procesos utilizando JSON, aprovechando las características de web2py en este sentido
para exponer servicios web.

Internamente, la aplicación IDE2PY almacena los datos de defectos y tiempos en bases de


datos simples utilizando la persistencia de objetos Python nativa (Shelve y Pickle)
Si bien existe ciertas dificultades que pudieran causar inestabilidad de la herramienta, en
líneas generales no se han encontrado mayores obstáculos que tornen inviable el desarrollo
actual.

La gran combinación de sistemas operativos, versiones de python y biblitotecas relacionadas,


sumado a las dificultades encontradas y falta de recursos, han sido factores para reconsiderar
ciertos aspectos del alcance, tendiendo a simplificar y radicalizar aún más los objetivos y
metas del proyecto.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 76 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 5.3.1: Captura de Pantalla de RAD2PY (depurando app web2py)

5.4. Implementación de RAD2PY

Internamente, el diseño de la IDE2PY es muy simple y modular, con un módulo principal


(main.py), conteniendo la aplicación en sí y la administración de la Interfaz Avanzada de
Usuario (AUI) con la ventana madre, los menues, barra de herramientas y distintos paneles. A
su vez, la aplicación se encarga de la configuración utilizando archivos de texto estandar .INI,
con un archivo predeterminado (ide2py.ini.dist) que contiene la disposición básica de los
paneles, editor y demás. De existir, esta configuración se mezcla con el archivo INI del usario
que contiene la información particular sobre el usuario, parámetros recientes (archvivos
abiertos), etc

La ventana principal (PyAUIFrame) puede ser extendida con mixins (Web2pyMixin,


PSPMixin, RepoMixin) que funcionan a modo de clases complementarias heredándole
comportamientos respecto a manejo de eventos y control de los elementos, pudiendo ser
agregada en un futuro mayor funcionalidad sin modificaciones masivas.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 77 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

El editor es un control basado en Scintilla (editor.py), con resaltado de sintaxis,


autocompletado y calltips, y por cada archivo es creada una ventana separada que es manejada
automáticamente con distintas solapas la Interfaz de Documentos Múltiples (AUI MDI). La
introspección es básica (con un espacio de nombres estático), y se basa en evaluar/importar
los módulos necesarios, por lo que en un futuro se buscarán métodos menos invasivos como
PySmell. Para un correcto soporte de las codificaciones (UTF8, Latin-1, etc.) y formatos de
archivos (BOM, saltos de línea unix, windows y mac) se desarrollaron funciones para manejo
de archivos (fileutil.py)

El navegador (browser.py), implementado para probar los sitios web, es un control que deriva
de webkit (gtk, en linux) o Internet Explorer (windows). Por el momento es bastante básico
pero se planea agregarles botones de navegación y herramientas adicionales.

El interprete interactivo (shell.py) se basa en los controles proporcionados por wxPython, con
adaptaciones para integrarlo con la consola (console.py) y depurador (debugger.py). Este
último esta basado en el propio de Python (bdb, similar a la implementación de IDLE), con
ajustes e integración con el editor. Se decidió tener la consola separada del intérprete tanto por
una cuestión visual como también para no afectar la interactividad del usuario. Si bien la
consola puede redirigir la entrada y salida de procesos externos, por simplicidad en esta etapa
de desarrollo, el depurador y el intérprete trabajan ejecutando los programas dentro del mismo
proceso (similar a la implementación de IDLE y PythonWin). En un futuro se podría agregar
un depurador remoto multihilo, además de otras mejoras visuales como un inspector de
espacios de nombre y una ventana con la pila de llamadas.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 78 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 5.4.1: Interprete interactivo (basado en wxPython)

El manejo de repositorios esta abstraído en dos capas, la primera de alto nivel (repo.py) con
las operaciones básicas comunes a todos los repositorios, y la segunda específica de cada
sistema de versionado (repo_hg.py), en este caso con soporte para Mercurial, pudiendo
agregarse otros sistemas. Existen eventos para la detección automática de cambios, y un árbol
básico de los archivos del proyecto para buscar y operar sobre los mismos (agregar, borrar,
comparar diferencias, comprometer, actualizar, etc.). Para comparar las diferencias se mejoró
wxpydiff.py y se adaptaron los módulos estándar de python con un comparador de secuencias
-FancySequenceMatcher- para detectar correctamente los cambios en el código fuente
(diffutil.py).

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 79 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 5.4.2: Cálculo diferencia: líneas modificadas, eliminadas y agregadas


(basado en wxPyDiff)

Para el chequeo estático se integró PyChequer y PyFlakes (checker.py) que analizan el código
fuente y reportan los defectos encontrados, complementado con pruebas de documentación
(tester.py) que ejecutan las funciones y comparan los resultados esperados según la
documentación de las mismas.

Para el soporte de desarrollo de aplicaciones web se embebió un servidor (web2py.py), que,


gracias al enfoque único del framework (ejecución de los módulos en vez de importarlos
permanentemente) permitio utilizar el depurador simplificado y habilitó la modificación del
código sin necesidad de procesos externos o reinicios, y a la vez, el concreto espacio de
nombres global fue útil también para el editor (calltips y autocomplete). El webserver

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 80 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

incorporado esta basado en la implementación estándar WSGI de Python, y es ejecutado en


los momentos ociosos del loop principal de la aplicación, por lo que se pueden depurar
aplicaciones de desarrollo pero no es recomendable para producción (o utilizarlo para
aplicaciones dentro de la propia herramienta, como PSP2PY), ya que se pueden producir
bloqueos.

Figura 5.4.3: PSP Toolbar (barra de herramientas)

El soporte al Proceso de Software Personal (psp.py) consiste en un listado de defectos (figura


5.4.5) y un grilla de tiempos en cada fase (figura 5.4.4). Ambos son controlados por una barra
de herramientas (figura 5.4.1) que permite iniciar, pausar y detener los cronómetros, elegir el
proyecto y fase e ingresar defectos manualmente. Estos datos son almacenados en archivos
persistentes de python (shelve/pickle) y luego son sincronizados con un webserver
independiente, que contiene la aplicación web de soporte PSP2PY, utilizando procedimientos
remotos con notación javascript (simplejsonrpc.py). De este modo se preserva la privacidad
del desarrollador, eligiendo que datos y en que momento se envían, totalizandolos y pudiendo
corregirlos.

Figura 5.4.4: PSP Plan Summary -Times- (resumen de tiempos)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 81 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 5.4.5: PSP Defect Recording Log (registro de defectos)

Los errores de compilación y errores en tiempo de ejecución son automáticamente


recolectados como defectos siguiendo las directivas del PSP. Estos errores son listados con
un casilla de verificación (figura 5.4.5) y pueden ser editados (click izquierdo) mostrando un
dialogo para tal fin (figura 5.4.6). Al seleccionar un defecto (doble click) este comienza a
acumular el tiempo de corrección (fix time), hasta que el defecto es marcado como corregido
(tildando la casilla correspondiente).

Figura 5.4.6: Dialogo de Edición de Defectos

Para facilitar la detección de la fase de inyección de defectos y mejorar la calidad de las

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 82 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

métricas recolectadas, el módulo PSP incorpora el manejo de metadata (información sobre el


código fuente en sí). Estos datos constan de la última fase donde se introdujo o modificó cada
línea de código, y se actualiza al completar cada fase del PSP. Luego, al detectarse un error, la
herramienta busca en la metadata la linea de código que ha fallado determinando
automáticamente en que fase fue escrita y consignandolo en el campo correspondiente
(“inject_phase” en defectos) para un correcto seguimiento de las métricas del PSP, sin
necesidad de que el usuario necesite recordar en que fase fue introducido el defecto. De ser un
problema complejo originado en otra parte del código fuente, el defecto puede editarse para
reflejar los datos necesarios. En la figura 5.4.6 puede observarse una captura de la metadata
(fase - linea de código):

Figura 5.4.7: Cálculo de metadata (fase de última modificación de la linea)

Respecto a la ayuda en línea, el módulo PSP contempla la visualización de páginas wiki


(formato similar al usado en enciclopedias colaborativas) para facilitar la documentación y
navegación del proceso de software. Contiene la funcionalidad de una Guia Electrónica del
Proceso (Electronic Process Guide o EPG) provistas por proyectos Similares (PSP Dashboard
y/o Jasmine PSP Support Tool ​[JASMINE07]​).

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 83 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 5.5.3: Guía de Proceso en linea (PSP WIKI)

Para los archivos de documentación, se implementó un editor de marcado simple (markmin)


con previsualización (wiki.py).

Para el diseño de interfaces visuales (GUI2PY), se trabajó en un editor HTML que dibuja los
controles utilizando un diseño fluido wxHTML. El funcionamiento general será similar a una
aplicación web pero reemplazando los artefactos HTML por controles nativos wxPython, y
utilizando Python en lugar de Javascript, unificando y simplificando el diseño y disposición
de interfaces y aprovechando las técnicas MVC y ayudantes del framework web.

Para más información sobre el avance, el software del proyecto se publica en [RAD2PY].

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 84 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

5.5. Aplicación web de soporte PSP2PY

La solución planteada cuenta con una aplicación web que permite la gestión básica de los datos
relacionados a proyectos de PSP, permitiendo:

● alta de proyectos
● edición de proyectos
● consulta de proyectos y metricas
● estimación básica
● reportes de productividad, defectos y proyectos
● gráficos de distribución y regresión de tamaños, tiempos y defectos

Los datos de proyectos contemplados son: nombre, descripción, requerimientos, pruebas, usuario,
fecha de inicio y finalización, entre otros, como se muestra en Fugra 5.5.1.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 85 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 5.5.1: Alta de Proyecto PSP

Una vez dado de alta el proyecto, este es visible en la IDE y puede ser seleccionado desde la barra de
herramientas (Figura 5.4.1 y 5.5.2) para enviar o recibir las métricas de desarrollo:

Figura 5.5.2: Selección del Proyecto PSP en la IDE

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 86 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Al enviar las métricas (defectos y tiempos) estas pueden ser visualizadas junto con los datos del
proyecto para análisis y consultas posteriores:

Figura 5.5.2: Vista de un Proyecto PSP con sus métricas

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 87 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

La herramienta contempla la posibilidad de estimar el tamaño del programa utilizando la


técnica PROBE (PROxy Based Estimation, o estimación basada en objetos próximos)
sugerida por la bibliografía del PSP. El procedimiento consiste en identificar objetos similares
a los que va a desarrollar, para los cuales el sistema calcula su cantidad de líneas proyectada
basado en los datos históricos de proyectos previos. Para ello la aplicación contempla la el
almacenamiento y categorización de todos los objetos (funciones) desarrollados con
anterioridad, clasificando su tamaño (muy pequeño, pequeño, medio, grande, muy grande) y
su origen (módulos independientes, modelos, vistas o controladores).

Para la efectividad de la estimación, es necesario realizar un diseño conceptual de alto nivel e


identificar todos los objetos / funciones a desarrollar, como se muestra en la figura 5.5.3.

Figura 5.5.3: Vista de la Estimación Basada en objetos Próximos


(PROBE: PROxy Based Estimation)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 88 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Luego de tener un estimado del tamaño (líneas de código a crear o modificar), la aplicación de
soporte permite estimar los recursos necesarios para el desarrollo (tiempos en este caso). Para
ello es necesario ingresar el tamaño estimado (en líneas de código), seleccionar el intervalo de
predicción (por ej. 70% o 90%) y elegir el proyecto a actualizar, como se muestra en la figura
5.5.4:

Figura 5.5.4: Vista de la Estimación de Recursos


(dado el tamaño en LOC calcular el intervalo de predicción de tiempos)

Para estimar el sistema tomará en cuenta los datos históricos de tamaño y tiempos, realizando
una regresión lineal sobre los mismos y calculando el límite superior e inferior del tiempo
estimado (utilizando la distribución de probabilidad t de student), según se detalla en la
bibliografía.

A su vez, una vez calculado el tiempo estimado, este es distribuido entre las distintas fases
según los datos promediados a la fecha sobre tiempos consumidos en cada fase de desarrollo.

El resultado final son el tamaño y tiempo estimados y distribuidos, como se observa en la


figura 5.5.4:

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 89 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 5.5.4: Vista de un proyecto con recursos estimados:


LOC y tiempo planeado, intervalo de predicción de tiempos -límite inferior y superior-
Tiempo planeado distribuido por cada fase del proyecto

Una vez completado varios proyectos, la herramienta contempla la generación de reportes


necesarios para el correcto seguimiento del proceso de software PSP y su mejora continua,
como se muestra en la figura 5.5.5, conteniendo las secciones de:

● Productividad: indicando las lineas por hora, tiempos totales, y el Índice del Costo
Productividad (CPI), relacinando las planificaciones con los tiempos ejecutados
● Eficiencia en la remoción de defectos: contiene el yield (defectos removidos antes de
compilar), defectos removidos por hora y densidad de defectos, con su cantidad y

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 90 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

tiempo promedio.
● Costo de Calidad: medido como la relación del tiempo de revisión sobre el tiempo de
fallas (compile/test).

Figura 5.5.5: Vista del Reporte General según PSP


(Productividad, Eficiencia de remoción de Defectos, Costo de Calidad, Detalle por Fase)

A su vez, el Reporte General contiene un Reporte por Fase incluyendo los datos acumulados
totales de: tiempo estimado y ejecutado en cada fase, defectos inyectados y removidos, yield,
defectos por hora y DRL (Defect Removal Leverage, relación de defectos por hora contra la
fase de pruebas)

Estos datos son necesarios para mejorar el proceso, principalmente para definir las fases de
revisión de código y diseño (detectando los errores más comunes y como prevenirlos) y

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 91 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

midiendo la efectividad de las estimaciones realizadas.

La herramienta también contempla un reporte de resumen de proyectos como se muestra en la


figura 5.5.6, que contiene todos los proyectos PSP realizados hasta la fecha, con su nombre,
descripción, tiempo planificado, LPI (intervalo inferior de predicción de tiempo), UPI
(intervalo superior de predicción de tiempo), tiempo ejecutado, tiempo en interrupcones, CPI,
Líneas de código planificadas, Líneas de código reales (agregadas o modificadas), cantidad de
defectos y tiempo de corrección.

Figura 5.5.6: Vista del Reporte Resumen de Proyectos PSP

Si bien la estructura de los reportes no es exactamente igual a la planteada por la bibliografía,


estos contienen toda la información necesaria de manera simplificada y resumida, evitando la
necesidad de que el usuario realize cualquier tipo de calculo, que podría ser propenso a error o
omisiones.

En la sección de reportes también está disponible el “Estándar de Tipo de Defectos”, que


contiene la categorización de los errores según su tipo (ver anexo) y la cantidad de
ocurrencias, frecuencia relativa, tiempo total de corrección, porcentaje de tiempo y promedio

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 92 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

por tipo de error, como se observa en la figura 5.5.7:

Figura 5.5.7: Vista del Reporte de Defectos

Por último, para dar soporte completo al método PROBE de estimación, la aplicación
contempla el almacenamiento de datos históricos sobre los objetos (clases y funciones)
desarrolladas, llamado Biblioteca de Reuso. En dicha biblioteca se almacena el proyecto,
nombre de la función y/o clase (métodos), su categoría (módulo, modelo, vista, controlador) y
las lineas de código afectadas. La aplicación contempla un formulario de consulta para buscar
por proyecto, nombre de función o categoría, como se muestra en la figura 5.5.8:

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 93 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 5.5.8: Vista de la Biblioteca de Reuso

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 94 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Capitulo 6: Prueba de la solución

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 95 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

6.1. Desarrollo de Experimentos:

Los desarrolladores de software son bombardeados con afirmaciones extravagantes


sobre productividad: "Reducir el tiempo de desarrollo por un factor de 10!" (o 100! o
1000!)
Capers Jones estima que ha habido afirmaciones falsas de la productividad en un 75
% de los materiales de marketing publicados por proveedores de aplicaciones CASE,
lenguajes de programación, metodologías y herramientas de software en los últimos
años.
Los vendedores de herramientas CASE son los peores, seguidos por los de ingeniería
de la información, RAD 4GL, y los métodos orientados a objetos (Jones, 1994). En
promedio, las herramientas para las cuales se han hecho afirmaciones de “bala de
plata” no producen una mejora visible, o sólo producen una mejora marginal.
Algunas personas han sido realmente engañadas.

​ apid Development: Taming Wild Software


Traducido de Steve McConnell. 1996. R
Schedules ​Microsoft Press, Redmond, WA, USA.

Para la validación de las teorías, técnicas y herramientas individuales que sustenten el modelo
elegido, se tomaron como muestras los datos experimentales recolectados por el prototipo
para su posterior análisis conforme a los métodos estadísticos y matemáticos presentados en el
Proceso de Software Personal [HUMPHER95] para medir el rendimiento y progreso esperado
logrado aplicando el modelo conceptual de la presente investigación.

Inicialmente, la selección de muestras fue relacionada al desarrollo de los programas de


ejemplos en los cursos del PSP que sean aplicables a la presente investigación.

6.2. Objetivo General

El objetivo del trabajo es desarrollar un marco de trabajo teórico-práctico para el Desarrollo


Rápido de Aplicaciones bajo un Proceso de Software Personal.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 96 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Se entiende, para este trabajo, como ​marco de trabajo teórico las distintas metodologías a
utilizar para el desarrollo del software propiamente dicho, debidamente validadas teórica y
empíricamente; y como ​marco de trabajo práctico las herramientas a desarrollar que den
soporte a las metodologías elegidas.

Por Aplicación se entiende, para este trabajo, a Software de Computadora que cumpla con las
siguientes características:

● Plataforma PC
● Sistemas Operativos Principales (Windows, Linux, MacOS)
● Carácter General (comercial o no). Se descartan aplicaciones Soporte de Vida,
Simulación Científica y demás áreas específicas.
● Interfaz Gráfica (GUI) nativa y/o Web.

6.3. Objetivos Específicos

El marco conceptual y la herramienta I-CASE abarcan los siguientes objetivos específicos,


contemplando esta última la automatización de los mismo de acuerdo a los lineamientos que
surgidos de la investigación:

1. Determinar Proceso de Desarrollo de SW


2. Determinar el Modelo de Datos
3. Determinar la Interfase de Usuario
4. Determinar el Paradigma y Lenguaje de Programación
5. Determinar Técnicas de Documentación
6. Determinar Modalidad de Aseguramiento de Calidad
7. Determinar Modelo de Despliegue e Implementación
8. Determinar Técnicas de Seguimiento (​bug-tracking​) y Control de Cambios

6.4. Resultados Esperados

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 97 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Para este trabajo, se buscó validar, cualitativamente, el prototipo que sustenta la solución
propuesta, incluyendo herramienta y métodos planteados.

En principio, se entendió que para que este proyecto sea viable, debería ser posible realizar los
ejercicios del PSP para desarrollar los programas planteados en la bibliografía original
(​[HUMPRHEY95])​, y las metricas obtenidas deberían ser comparables y compatibles a los
datos encontrados en la referencias y herramientas similares.

Luego, al cumplirse la hipótesis de esta investigación, en el futuro sería esperable obtener


resultados ya validados empíricamente por otras investigaciones referidas al RAD y PSP al
utilizarse el marco teorico y práctico planteado:

1. Mejorar la calidad de las aplicaciones desarrolladas con el método RAD, optimizando


el rendimiento y productividad de los desarrolladores. Esto se lograría debido a aplicar
el proceso PSP, que según estudios realizados [PSPEMP97], los desarrolladores
obtienen las siguientes mejoras:
i. La estimación del esfuerzo mejoró en un factor de 1.75 (promedio)
ii. La estimación del tamaño mejoró en un factor de 2.5 (promedio)
iii. La tendencia a subestimar el tamaño y esfuerzo fue reducida. El numero de
sobreestimaciones y subestimaciones fue más balanceado.
iv. La calidad del producto, como defectos encontrados en las pruebas de
unidades, mejoro 2.5 veces (promedio)
v. La calidad del proceso, como porcentaje de defectos encontrados antes de la
compilación, mejoró un 50% (promedio)
vi. La productividad personal, como líneas de código producidas por hora, no
cambio significativamente. Aún así, se espera que la mejora en la cualidad del
producto resultante debido al PSP mejore la productividad y el tiempo del ciclo
medido a nivel de proyecto.
2. Facilitar la adopción del Proceso PSP, al integrar la herramienta I-CASE del método
RAD con la recolección y análisis automático de métricas del PSP. Si bien se estima

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 98 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

que los desarrolladores que utilizan el PSP (entre los otros métodos populares de
mejora del proceso de software), logran una de las productividades más altas y una
disminución de defectos tendiente a cero, lo que se traduce en la tasa mas alta de
retorno de inversión (ROI) con el mejor costo beneficio del estudio [ROISTN02,
ROISPI04], también se observa que estadísticamente solo un 10% de las personas
entrenadas en el PSP lo continúan usando de forma profesional [PSPBEY03, ROIPSP]
debido a los inconvenientes detallados en capitulos anteriores.

Figura 6.4.1: Comparación Costo y Beneficio del PSP vs otros procesos

6.5. Datos Obtenidos

La IDE y herramientas de soporte fueron usadas para desarrollar las tareas de programación
sugeridas por el libro sobre PSP ([HUMPRHEY95], "A discipline for Software Enginering"
pp752-769) para reunir métricas y hacer una validación empírica básica de la hipótesis de esta
investigación (verificando el modelo teórico y prototipo piloto), tomando como muestras los
siguientes programas:

● Program 1A: Desviación Estandard

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 99 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

● Program 2A: Contar Lineas Logicas


● Program 3A: Contar LOC, LOC por objeto y metodos
● Program 4A: Regresión Lineal
● Program 5A: Integración utilizando regla de Simpson, distribución normal
● Program 6A: Estimación de LOC (intervalo de predicción 90/70)
● Program 7A: Correlación y significanza (no obligatorio)
● Program 8A: Ordenar una lista enlazada (no necesario)
● Program 9A: Calcular el grado de una distribución normal (no obligatorio)
● Program 10A: Estimación de la regresión múltiple de tres variables

Se validó la solución propuesta a través de las diferentes pruebas generales y de unidad.


Dentro de estas, se utilizan los métodos de pruebas de caja blanca y pruebas de caja negra,
definiéndose el objetivo de cada una de estas, así como su alcance y detalles de las mismas.
Se adjuntan en el anexo la metodología de pruebas y requisitos contemplados.

Resumen de datos obtenidos (tablas 6.5.1 y 6.5.2):

● Program 1A (desviación estándard) fue practicamente trivial (alrededor de 50 LOC,


reducido a 6 SLOC excluyendo comentarios, documentación y pruebas) pero fueron
encontrados 16 errores (13 automáticos -la mayoría temas menores-, 3 agregados
manualmente, descontando falsos positivos y duplicados) y tomó ~2m para planning,
~20m para design+code, 25m para testing y ~5m para postmortem (53m tiempo total,
mi 60m estimado estuvo correcto, pero el tiempo en cada fase fue incorrectamente
estimado)
● Program 2A (contador de líneas de código) no fue tan trivial (alrededor de 116 LOC,
reducido a 59 SLOC excluyendo comentarios, documentación y pruebas), 31 errores
fueron encontrados, y tomo~5m para planning, ~47m para design, ~60m para code,
3m para "compile", 32m para testing y ~1m para postmortem (148m tiempo total,
excedió el estimado de 96m, mayormente en la fase de codificación)
● Program 3A (contador de líneas de código por objeto) tampoco fue tan trivial

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 100 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

(alrededor de 130 SLOC, redicido a 62 sin las lineas reusadas), 46 errores fueron
encontrados, y tomo ~5m para planning, ~1.45h para design, ~1m para code, 5m para
"compile", 1.32h para testing y ~11m para postmortem (3.14h tiempo total, excedió el
estimado de 1.25h, mayormente en la fase de diseño)
● Program 4A (regresión lineal) fue relativamente pequeño (alrededor de 20 SLOC,
nuevas o modificadas), 29 defectos fueron encontrados, y tomo ~1h para el desarrollo,
similar al tiempo estimado, bajando en gran memdida el tiempo de pruebas.
● Program 5A (integración numérica y cálculo de probabilidades) fué más complejo
(alrededor de 83 SLOC -nuevas o modificadas-, con una estimación por PROBE de
48), 41 defectos fueron encontrados (varios en la fase de postmortem, al probarlo en
otra aplicación, luego de terminar el desarrollo). El tiempo total de 3.27h, excedió el
estimado por PROBE de 2.03h mayormente debido a agregar funcionalidad no
contemplada originalmente (integración de la función de probabilidad acumulada t de
student) y por encontrar defectos luego del desarrollo relacionados a problemas de
división entera y punto flotante.
● Program 6A (intervalo de predicción) fue de tamaño medio (alrededor de 51 SLOC
nuevas o modificadas, superando las 23 estimadas por pruebas y funcionalidades no
contempladas), 30 errores fueron encontrados, y tomo 1.51h de tiempo total, excedió
el estimado de 1.15h estimado por PROBE, mayormente en las fases de codificación y
pruebas por el calculo del valor de la t-student dada una probabilidad (no contemplado
ni documentado en el libro).

Plan Actual Int. Plan. Actual Fix


Project Description CPI Defects
Time Time Time LOC LOC Time

Program Standard 1h 53.65 1h 1.1 21 16 23.15 m


1A Deviation m

Program LOC count 2.50 h 2.47 h 2.50 h 1.0 73 31 21.15 m


2A

Program LOC / object / 1.25 h 3.14 h 1.25 h 0.4 62 46 59.20 m


3A method count

Program Linear 1.02 h 1.05 h 1.02 h 0.9 20 29 5.13 m


4A Regression

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 101 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Parameters

Program Numerical 2.03 h 3.27 h 2.03 h 0.6 48 83 41 59.08 m


5A integration

Program Prediction 1.14 h 1.51 h 1.14 h 0.7 23 51 30 18.72 m


6A Interval

Program Multiple 2.96 h 0s 2.96 h 77 0s


10A Regression
prediction
interval

Tabla 6.5.1: Resumen de métricas por proyecto

Actual
Planned Actual
Planned Time Defects
Time Time Defects Defects
Phase Time To Yield per DRL
To Date To injected removed
To Date Date hour
% Date
%

planning 24.88 m 4.64 % 30.20 4.08 % 0 1 0.94 % 1.99 0.09


m

design 3.12 h 34.86 % 4.18 h 33.87 50 8 7.62 % 1.92 0.09


%

code 1.75 h 19.53 % 2.42 h 19.65 8 2 2.06 % 0.83 0.04


%

compile 22.87 m 4.27 % 26.32 3.56 % 7 17 17.89 % 38.76 1.83


m

test 2.81 h 31.50 % 3.59 h 29.11 41 76 97.44 % 21.17 1.00


%

postmortem 27.87 m 5.20 % 1.20 h 9.73 % 0 2 % 1.67 0.08

Tabla 6.5.1: Resumen de métricas por fase

En el anexo se encuantran disponibles el código fuente de los ejercicios realizados.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 102 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

6.6. Análisis de los datos obtenidos y pruebas realizadas

Recolectamos y analizamos datos para ayudarnos a entender y mejorar nuestros


procesos. Para hacer preguntas inteligentes sobre sus procesos, necesita un modelo
de proceso. Esta es la razón por la cual define un proceso de software antes de
comenzar a reunir datos extensivos.

En tanto comience a usar su proceso personal, probablemente será curioso acerca de


sí su rendimiento esta mejorando. Mientras ésta es una inquietud válida, es
prácticamente imposible responderla sin datos substanciales. Únicamente puede
decirse si se esta mejorando solo examinando estadísticamente un gran volumen de
datos. El problema de juzgar su propia performance tiene dos complicaciones
posteriores: el “bolstering” y la “clutching”. El “bolstering” es cuando
selectivamente recuerda los resultados que refuerzan lo que quiere creer. El
“clutching” es causado por una retroalimentación negativa, esto es, cuando es crítico
que tengamos buenos resultados, frecuentemente no lo hacemos.

Los datos de su rendimiento personal pueden ser desalentadores. Sus resultados


fluctuarán, mientras intente mejorar, pueden no mostrar una mejoría consistente. Aún
cuando sepa que esta intentandolo más intensamente y no funciona, seguramente
seguirá intentando. Para lograr una tendencia de mejora consistente, debe tomar
cambios específicos en su proceso

Con un proceso de línea base, tiene un fundamento para analizar futuros resultados y
determinar cuándo y cómo está haciendo progresos. Hacer esto le ayuda a planificar
su trabajo y justifica sus esfuerzos para mejorar el proceso.

​ Discipline for Software Engineering.​


[HUMPHREY95] Humphrey, Watts S. A
Reading, MA: Addison-Wesley, 1995. pp.228-229

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 103 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Si bien esta investigación no hace juicio de valor sobre la efectividad del PSP o RAD,
cuestión que se entiende demostrada por los antecedentes y referencias, es menester analizar
los datos e impresiones generales obtenidas luego de probar la herramienta experimental
piloto.

Como medidas de productividad, la herramienta de soporte de PSP arrojó los siguientes


resultados:

● LOC per hour:​ 25.14


● Total LOC:​ 310
● Total Time:​ 12.33 hours
● Interruption Time:​ 8.94 hours
● Planned Time:​ 8.94 hours
● CPI​:​ 0.72 (plan/actual time)

Si bien el tamaño y tiempo es subjetivo a cada individuo (dependiendo en gran medida del
lenguaje de programación, en este caso Python) y resultó sensiblemente menor al encontrado
en la bibliografía (por ej. en [HUMPREY95] pp. 70-71 se describe resultados de estudiantes
entre 2 y cuatro horas para producir 100 líneas de código en C++ o Pascal), su relación y
tendencia es compatible (por ej. [HUMPREY95] p.89 cita 15 LOC/hora). Más adelante se
analiza la correlación y significancia de dichos datos.

El valor 0.72 del índice de costo-productividad (CPI) indica un buen grado entre la relación
del tiempo planeado y el tiempo consumido ([HUMPREY95] p.25, ideal acercándose a 1,
demasiado conservador acercándose a 0)

Respecto a la Eficiencia para Remover Defectos, la herramienta calculó las siguientes


mediciones:

● Process Yield:​ 10.38 % (removal before compile)


● Defects per hour:​ 8.60 (injected/removed)
● Test Defects:​ 245.16 removed per KLOC

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 104 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

● Total Defects:​ 341.94 removed per KLOC


● Defect count:​ 106
● Fix Time:​ 2.94 h
● Average Fix Time:​ 1.65 m

El valor del rendimiento del proceso de eliminación de defectos (Yield) indica que se
detectaron y removieron aproximadamente un 10% de los defectos antes de la fase de
compilación. Dado que en esta prueba piloto inicial no se utilizo una fase de revisión formal y
se realizó un chequeo informal antes de cada compilación, el valor obtenido es alto y
comparable a un valor promedio (tomando como ejemplo un estudio de 12 alumnos gráficado
en ​[HUMPREY95] p.253). Se entiende que esto es una ventaja de la integración lograda y por
usar pseudocodigo python, lo que posibilita detectar errores triviales de sintaxis en fases
previas.

Los 8.6 defectos inyectados y eliminados por hora también están dentro de los parámetros
normales (entre 1.31 y 9.43 dependiendo de la fase según una investigación en 36 programas
de Pascal y 25 de C++ tabulada en [HUMPREY95] p.257)

El total de defectos por cada mil líneas de código puede aparentar ser un poco elevado , pero
se encuentra en el orden de magnitud estándar (según se representa en un diagrama de
programas de PSP en [HUMPREY95] p.266). Números similares también pueden observarse
en sistemas automatizados modernos para JAVA (por ej. en PSP Assistant [PSPA05]
diapositiva 40 se detallan 314 defectos para el programa 6). Se entiende que estos números
elevados corresponden a la buena calidad de las métricas ya que se recolectan
automáticamente absolutamente todos los defectos (teniendo en cuenta de no volver a reportar
duplicados) y también al relativo menor tamaño del código por usar el lenguaje python de alto
nivel (lo que inevitablemente subirá la densidad de defectos comparado con lenguajes más
tradicionales).

Cabe aclarar que, salvo indicación contraria, no se toman en cuenta las advertencias de
formato como defectos, por ser violaciones menores al estándar de codificación que no

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 105 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

influyen en la correctitud del código (y tampoco se hace énfasis sobre ellas en la bibliografía).

Respecto al costo de la calidad, al no realizarse en esta prueba piloto una fase de revisión
formal (ya que para la misma se necesita contar con los análisis realizados en la presente
investigación para determinar los defectos más comunes y las técnicas para prevenirlos), la
medición de costo de apreciación (appraisal) arroja 0 por no tener datos de tiempos de
revisión, por lo que solo se consigna el costo de fallas (failure, para fases de compilación y
pruebas), siendo este el costo de calidad (COQ) para estos ejercicios, como se observa en los
datos calculados por la aplicación:

● Appraisal:​ 0.00 % (total review time)


● Failure:​ 32.67 % (total compile + test time)
● COQ​:​ 32.67 % (appraisal + failure)
● COQ A/FR​:​ 0.00 (appraisal / failure)

Igualmente, los valores están dentro de parámetros normales ​(tomando como ejemplo el
estudio de 12 alumnos gráficado en ​[HUMPREY95] p.288)

A continuación se detalla el análisis de las métricas recolectadas según los parámetros de la


bibliografía consultada.

6.6.1. Test de correlación y significancia:

Dado los datos de las métricas recolectadas (Tabla 6.6.1), la herramienta desarrollada calculó
el coeficiente de correlación r2 = 0.828075845371. Según el autor ([HUMPHREY95] p.513
& p.151) dicho índice se considera altamente predictivo dado la escala publicada:

● 0.9 <= r2 : la relación es considerada altamente predictiva


● 0.7 <= r2 < 0.9 : existe una fuerte relación de correlación (caso analizado)
● 0.5 <= r2 < 0.7 : existe una adecuada corelación (use con cuidado)
● r2 < 0.5 : no confiable para propósitos de planificación

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 106 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Para la prueba de significancia, la herramienta calculó los siguientes valores:


● r2 = 0.828075845371 (correlation coefficient)
● t = 4.38931354487 (student-t value)
● p = 0.996453777377 (student-t probability)
● s = ​0.00354622262343 (1-p)

De los mismos se encuentra que la significancia es alta, por lo que es poco probable que la
relación de correlación sea una coincidencia (probabilidad inferior al 0.05 %) por los que los
datos pueden ser considerados buenos dada la escala planteada ( [HUMPHREY95] p.70):

● s < 0.005: muy alta (caso analizado)


● s < 0.01: alta
● s < 0.05: buena
● s < 0.2: adecuada
● s >= 0.2: pobre

La relación de correlación se muestra gráficamente en la figura 6.6.1 donde se determinan los


parámetros de la regresión lineal para mostrar la tendencia esperable.

Size
Time (hours)
(SLOC)
0.89 21
2.47 73
3.14 62
1.05 20
3.27 83
1.51 51
Tabla 6.6.1: Datos de Tiempos y Tamaños para correlación y significancia

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 107 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 6.6.1: Regresión Lineal del tamaño (SLOC) y tiempos (en horas)

6.6.2. Análisis de la distribución de tamaños:

Para la estimación de tamaño se utiliza la técnica de objetos próximos (PROBE) descripta


anteriormente, que consiste en aproximar el esfuerzo de desarrollo basado en la biblioteca de
reuso (desarrollos previos). Si bien para la presente investigación se utilizaron funciones en
vez de objetos, esto esta contemplado en la bibliografía ([HUMPREY95] p. 113), pero en este
caso no es necesario normalizar los objetos por la cantidad de métodos ([HUMPREY95] p.
125).

Para juzgar los tamaños relativos de los objetos o funciones se usa la desviación estándard.
Dado que los datos de tamaño no se distribuyen de manera normal (principalmente porque no
varía de menos a más infinito, ya que los valores no estan generalmente muy por sobre 0
como las alturas de una población), por lo que para superar dicho inconveniente es posible
usar los logaritmos naturales de los datos, calcular la desviación estándar y media, y luego

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 108 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

convertirlos a líneas de código con antilogaritmos ([HUMPREY95] p. 129).

Object (function) Name Size Range Object LOC Object ln(LOC)

test_prediction_interval very small 3 1.09861228867

logical_to_physical_count very large 41 3.7135720667

compute_integral medium 12 2.48490664979

find_functions_and_classes medium 12 2.48490664979

linear_regression medium 10 2.30258509299

prediction_interval large 15 2.7080502011

count_logical_lines medium 12 2.48490664979

simpson_rule_tests large 24 3.17805383035

simpson_rule_integrate large 27 3.295836866

get_object medium 9 2.19722457734

double_sided_student_t_probability small 6 1.79175946923

count_logical_lines_per_object very large 31 3.43398720449

double_sided_student_t_value medium 12 2.48490664979

stddev small 5 1.60943791243

factorial small 5 1.60943791243

variance small 5 1.60943791243

gamma medium 7 1.94591014906

mean very small 3 1.09861228867

Tabla 6.6.1: Datos de tamaños de objetos (funciones) y su rango de tamaños

Realizando los cálculos necesarios (efectuados automáticamente por la aplicación de soporte


desarrollada) , se obtienen los siguientes parámetros:

● Desviación estándar: 0.747612112404


● Media (promedio): 2.30734135395

Los valores son similares a los presentados en el libro para 12 objetos de Pascal, 0.6346 y
2.802 respectivamente (​[HUMPREY95] p. 129). A su vez, para comprobar que el logarítmo

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 109 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

de los tamaños se distribuyen de manera normal y la categorización de tamaños basada en los


desvios estándar sea útil para la estimación, la frecuencia de los rangos deberían observar la
siguiente escala según la distribución normal ​(​[HUMPREY95] p. 133):

● 6.68 % deberían ser muy pequeños


● 24.17% deberían ser pequeños
● 38.3% deberían ser medianos
● 24.17% deberían ser grandes
● 6.68 % deberían ser muy grandes

Al observar los datos calculados por la herramienta (tabla 6.6.2) se constata que se distribuyen
aproximadamente de forma normal (con un error mínimo debido a la limitada cantidad de
muestras que afecta a los porcentajes), por lo que los datos podrían ser usados para estimación
PROBE (y dicha estimación debería también seguir una distribución similar para ser
balancead).

Quantit
Size Range Range Midpoint LOC Range Midpoint ln(LOC) Percentage
y

very small 2.25267213956 0.812117129138 2 11.11 %

small 4.75753292846 1.55972924154 4 22.22 %

medium 10.0476758992 2.30734135395 7 38.89 %

large 21.2201980507 3.05495346635 3 16.67 %

very large 44.8160161444 3.80256557876 2 11.11 %

Tabla 6.6.2: Datos de distribución de tamaños de objetos (funciones)

En la figura 6.6.2 se grafíca un histograma con la distribución del los tamaños de los objetos
tomados de la biblioteca de reuso (realizado por la herramienta de soporte del PSP),
observando una distribución normal aproximada (línea punteada).

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 110 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Figura 6.6.2: Histograma del tamaño de objetos (escala normal logarítmica)

6.6.3. Análisis de defectos:

Para el análisis de defectos, se comienza con el Reporte de Estandard Tipos de Defectos


(figura 6.6.3) generado automáticamente por la herramienta de soporte en base a las métricas
recolectadas.

Dicho documento se basa en el PSP Defect Type Standard ([HUMPRHEY95], pp48, 260,
262, 661), modelado originalmente sobre el trabajo en IBM Research de R. Chillarege, I.
Bhandari, J. Chaar, M. Halliday, D. Moebus, B. Ray y M. Y. Wong: "Orthogonal Defect
Classification - A Concept of In-Process Measurements" IEEE Transactions on Software
Engineering, vol. 18., no. 11 (November 1992): 943-956.
El estándard ha sido adaptado para seguir las excepciones incorporadas del lenguaje Python,
usando una convención tomada de ​Python Language Reference​, y del chequeador automático,
pep8.py

NOTA: El tipo 30 (Build/Package) se movió dentro del 100 (Environment), para usar el tipo

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 111 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

30 como clasificación automática de los defectos de formatos PEP8 (tipo 22 en el estándar


detallado, [HUMPRHEY95], p.262)

Freq. Fix Time


No Name Description Quantity Avg.
% Time %

10 Documentation Errors in docstrings and 6 3.11 4.78 2.57 % 47 s


comments % m

20 Syntax SyntaxError (spelling, 17 8.81 4.05 2.17 % 14 s


punctuation, format) and % m
IndentationError (block
delimitation)

30 Coding standard PEP8 format warnings and 87 45.08 10.10 5.42 % 6s


errors (long lines, missing % m
spaces, etc.)

40 Assignment NameError (undefined), unused 22 11.40 17.45 9.36 % 47 s


variables, IndexError/KeyError % m
(range/limits LookupError) and
UnboundLocalError (scope)

50 Interface TypeError, AttributeError: 12 6.22 4.22 2.26 % 21 s


wrong parameters and methods % m

60 Checking AssertionError (failed assert) 34 17.62 48.60 26.07 1.42 m


and doctests % m %

70 Data ValueError (wrong data) and 3 1.55 5.65 3.03 % 1.88 m


ArithmeticError (overflow, % m
zero-division, floating-point)

80 Function RuntimeError and logic errors 11 5.70 1.44 46.44 7.87 m


% h %

90 System SystemError and Libraries or 1 0.52 5m 2.68 % 5m


package unexpected errors %

100 Enviroment EnvironmentError: Operating 0 0.00 0s 0.00 %


system and build/third party %
unexpected errors

Tabla 6.6.3: Reporte de Estándard de Tipos de Defectos

Del análisis de los datos de defectos (figura 6.6.3) y experiencia de utilizar la herramienta de

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 112 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

desarrollo se destacan los siguientes puntos :

● Tipo 30 (formato - estándard de codificación): si bien es trivial (causado por falta de


espacios alrededor de separadores, lineas demasiado largas superiores a 80 caracteres,
multiples instrucciones en la misma línea, etc.), es el de mayor ocurrencia y es el más
rápido de corregir (6 s)
● Tipo 60 (chequeos, errores de asersiones): es el segundo en ocurrencia, seguido por el
tipo 40 (asignaciones, nombres y ámbitos), ambos con un tiempo promedio de
correción alrededor de 1 minuto y medio.
● Tipo 20 (errores de sintaxis): sigue en frecuencia de ocurrencia, y si bien son los más
faciles de encontrar (de manera automática), no son tan triviales de corregir (14 s en
promedio) ya que hay ciertas construcciones de python que no solo pueden presentar
problemas de puntuación, sino que también sufren de temas relacionado con la
anidación de delimitadores
● Tipo 50 (interface, parámetros, atributos): también es significativo y relativamente
simple de encontrar de manera automática, con una corrección rápida (21 s en
promedio)
● Tipo 80 (función, lógica, bucles, etc): es el más complejo de resolver (5m en
promedio) y en general su detección es manual
● Tipo 10 (documentación): es poco frecuente y su detección es totalmente manual ya
que se encuentra en errores dentro de los comentarios o docstrings
● Tipo 70 (datos): también es poco frecuente pero su detección en general es automática
(salvo cálculos que no están verificados precondiciones o postcondiciones con asserts,
en ese caso se utiliza el tipo 80)
● Tipo 90 (sistema): solo se encontro 1 error de este tipo (relacionado a un
comportamiento no esperado de la librería utilizada)
● Tipo 100 (ambiente): no se encontró ningún error clasificable en esta categoría.

Analizando la distribución de pareto (figura 6.6.3 mencionada anteriormente), no se


encuentran diferencias significativas con datos presentes en la bibliografía (por ej. respecto a
defectos encontrados en fase de compilación de programas en C++, [HUMPRHEY95],

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 113 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

p.264). Lo mismo se observa de los tiempos promedios de correción (figura 6.6.4), que son
compatibles al datos de programas en Pascal o C++ ([HUMPRHEY95], p.277)

Figura 6.6.3: Distribución de Pareto de los defectos (fase compilación)

Figura 6.6.4: Tiempos promedio de corrección de errores

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 114 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

6.7. Análisis de la solución planteadas

En perspectiva y luego de haber usado otras herramientas disponibles (más básicas, sin
soporte incorporado del PSP o con soporte externo), se entiende de que ha sido un paso
importante para registrar y medir los defectos con el objetivo de su análisis posterior y planteo
de mejoras al proceso.

A su vez, por lo expuesto anteriormente, queda demostrado que es posible implementar un


entorno integrado de desarrollo rápido de aplicaciones (IDE o herramienta I-CASE) que
soporte de manera automatizada un proceso predictivo de desarrollo de software en el
lenguaje de programación python (tomando como base la realización de los ejercicios de del
PSP).

A continuación se describen los puntos destacables recolectados luego de realizar las pruebas
de la herramienta.

6.7.1. Solución a las falencias de las herramientas RAD

Respecto a los inconvenientes que motivaron esta investigación relacionados con


herramientas de desarrollo rápido de aplicaciones para el lenguaje python, se entiende que:

● el presente trabajo indica que es viable realizar una herramienta IDE integrada, simple
y fácil de utilizar, con soporte para clasificación automática de defectos y medición de
tiempos de desarrollo
● la integración completa no solo es útil sino que además facilita el desarrollo, evitando
cambio de contexto y facilitando una curva de aprendizaje más plana y reducida
● la herramienta integrada posibilita realizar tareas automáticamente en cada fase (por
ej. revisar la compilación o ejecutar tests de unidades o documentación), previniendo
omisiones, la alteración o abandono del proceso de desarrollo,
● la integración completa también proporciona una mayor consistencia a las métricas
recolectadas, posibilitando total control para el calculo de las mismas según el análisis

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 115 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

directo del código fuente, sin necesidad de sensores intermedios sobre archivos o
aplicaciones de terceros,
● por último, la integración adicionalmente favorece una mayor uniformidad en la
implementación de aplicaciones, estandarizando el proceso de desarrollo al poder
utilizar más facilmente las características de depuración e interprete interactivo (por ej,
al detenerse automaticamente en aserciones fallidas para inspeccionarlas, posibilitando
el diseño por contrato)

6.7.2. Solución al problema de calidad de datos del PSP

● la mayoría de los defectos son violaciones involuntarias al estandard de codificación


(espacios, saltos de línea, sangrías, etc.), encontrados automáticamente por los
chequeadores estáticos, y tardan muy poco tiempo en resolverse. A medida que uno se
familiariza con la herramienta y el proceso, estos disminuyen.
● el resto de los defectos son errores de sintaxis, excepciones en tiempo de ejecución,
fallas de aserciones y fallas de test de documentación, también detectados
automáticamente al utilizar la IDE en cada fase del proceso
● sólo fue necesario registrar defectos manuales en contadas ocasiones, principalmente
cuando el programa no fallaba lanzando una excepción, pero los datos arrojados eran
incorrectos
● luego de un uso inicial, se encontró que muchos defectos se duplicaban en cada
comprobación, por lo que se ajusto la IDE para no registrar defectos ya agregados con
anterioridad (analizando que el tipo de error y línea de ocurrencia no este previamente
reportada)
● también se encontró una necesidad imperiosa de que el proceso sea lo más
automátizado posible respecto a la detección de fases, porque podía encontrarse un
defecto luego de varias horas de haberlo introducido, lo que dificultaba recordar en
qué fase fue inyectado (por ej, un problema de diseño detectado en la fase de pruebas),
por lo que se adoptó la norma de escribir el pseudocódigo completo en el archivo
fuente para leugo ir refinándolo y así posibilitar que luego el sistema pudiera detectar
en que fase fue introducido según la línea de código

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 116 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

● el usuario es libre de modificar la fase actual, pero esto en general no es necesario ya


que cambia automáticamente al completar cada etapa. A su vez, al encontrar un
defecto, el sistema analiza la linea de código y en que fase fue ingresada, detectando
automáticamente cuando fue inyectado el defecto, y luego al corregirlo, cuando fue
removido. Estos puntos, junto con la medición automática de tiempos, permiten
obtener métricas de calidad fieles a la realidad prácticamente sin intervención del
usuario.

6.7.3. Solución al problema de adopción del PSP:

● la IDE ha sido diseñada específicamente para soportar al PSP, por lo que la sobrecarga
de trabajo es mínima y despreciable. Si bien se podría medir cuantitativamente, no
habría diferencias con otras herramientas ya que la registración de defectos, detección
de fases y medición de tiempos es automática, con una forma de uso igual a otras
herramientas (por ej, misma combinación de teclas y botones respecto a VB)
● no hay cambio de contexto porque el usuario no necesita salir de la herramienta, y
tiene presente en todo momento los tiempos y defectos según el PSP, por lo que la
retroalimentación es instántanea. Ejemplificando, no es necesario salir de la
herramienta para entrar en una aplicación de gestión de proyectos para regristrar un
defecto, esto esta previsto por la IDE. Tampoco es necesario utilizar un cronómetro ni
registros en papel u hojas de cálculo.

6.8. Evaluación con los lineamientos del SEI

Siguiendo la evaluación realizada en [AUTOMATING05], la tabla 6.8.1 muestra el análisis


comparativo de rad2py, la herramienta desarrollada para esta investigación, respecto a las
directrices del SEI.

Directiva Recomendación del SEI Este trabajo

Simplificar la El SEI recomienda que los datos La motiviación de este proyecto fue minimizar
recolección de relativos al PSP sean la sobrecarga al automatizar la recolección y

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 117 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

datos automáticamente copiados entre análisis de datos, almacenandolos en una base de


formularios, eliminando la necesidad datos sin necesidad de intervención del usuario.
de transcribirlos varias veces.

Personalización El SEI recomienda que la herramienta Este proyecto es de código abierto, por lo que el
del Usuario automatizada provea funcionalidades usuario puede crear su propia definición de
de customización. En particular, proceso y las fases pueden ser modificadas,
especifíca que el usuario debería agregadas o eliminadas.
poder renombrar las fases de
programación.

Proceso El SEI recomienda que el usuario Este proyecto hace cumplir y enfatiza
estandar versus obtenga un entendimiento completo explícitamente las fases y elementos del proceso
adaptado del concepto y practicidad del PSP y PSP estándar (modificando la herramienta de
su marco de trabajo antes de hacerle desarrollo) para familiarizar y facilitar los
cambios para soportar una definición conceptos al usuario, a diferencia de otras
de proceso personalizado. herramientas “no intrusivas” por sensores lo
hacen implícitamente.

Flexibilidad El actual marco PSP, se inicio con el Este proyecto provee una caja de selección
para trabajar en ciclo de vida en cascada, en el que se (combo), pudiendo el usuario cambiar la
cualquier fase no permita ir adelante y atrás entre las selección de la fase actual en cualquier momento
fases. Sin embargo, el SEI o seguir un ciclo de vida tradicional al ir
recomienda que al usuario se le de la validando cada etapa. En los defectos también se
capacidad de operar en la fase de su puede cambiar la fase a elección.
elección.

Ayuda en linea El SEI recomienda que la herramienta Este proyecto dispone de ayuda en linea
automatizada tenga disponible ayuda (python) y posee funcionalidad para una Guia
en línea. Electrónica de Proyecto, para documentar el
proceso utilizando tecnología wiki.

Privacidad de El SEI recomienda que es importante Este proyecto almacena las métricas actuales
Datos que las medidas personales sean ende manera local (máquina del desarrollador), y
privadas, con la posibilidad para las envía sólo cuando el usuario lo dispone (al
proveer acceso a los formularios contrario de otros proyectos por sensores que
completados (manteniendo seguro el envían todos los datos en todo momento sin
perfil del usuario) ningún control). A su vez, es posible proteger
los con autenticación y autorización.

Resumen de El SEI recomienda que el PSP Project Este proyecto provee la posibilidad de publicar
Plan de Proyecto Plan Summary pueda estar publicado el resumen de proyectos y demás reportes
Publicado basado en el marco de trabajo actual y especificados en la bibliografía del PSP. Si bien
la estructura de los formularios en sus los datos son similares, la estructura es diferente
diverentes niveles. ya que se utiliza un formato HTML estándar.

Tareas de El SEI establece que el PSP requiere Este proyecto soporta la necesidad de recolectar
Estimación que haya datos históricos disponibles datos históricos, facilitando la funcionalidad
(para predecir productividad, defectos necesaria para realizar estimaciones PROBE de
y tamaño del código), promoviendo el tamaño y la regresión lineal para tamaño y
método PROBE. tiempos (intervalo de predicción)

Tabla 6.8.1: Análisis Comparativo de los Principios Direcrices (SEI Principle


Guidelines)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 118 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

El Software Engineering Institute (SEI), a cargo de la dirección de gestión y fomento de la


Iniciativas de PSP, ha puesto a disposición las directrices principales de una herramienta de
soporte automatizado para PSP (SEI, 1996). Este principio de directrices presenta sugerencias
y suministra los requisitos del sistema de apoyo a marco actual PSP.

De la Tabla 6.8.1, se puede resumir que la herramienta desarrollada cumple con todas las
directrices y requisitos del SEI para herramientas automatizadas de soporte del PSP.

También se destaca que se han seguido y cumplido los lineamientos planteados en el Cuerpo
de Conocimientos del PSP [PSPBOK05] relacionados con las herramientas automatizadas,
específicamente:

● Los datos sobre el software son muy propensos a error. La mejor manera de asegurar
que son de alta calidad es entrenar a los individuos en los métodos propicios para
tomar medidas del proceso y registrar los datos que son colectados. Usar las
herramientas automatizadas, cuando las apropiadas estén disponibles para
recolección de datos,puede ayudar a mejorar la calidad de datos al proveer a los
individuos con medios convenientes para capturar información del proceso
inmediatamente la misma esté disponible.
● Los tiempos son más precisos cuando son recolectados usando herramientas
automatizadas; la herramienta debería poder guardar las fechas de inicio y
finalización, calcular el tiempo transcurrido, substraer el tiempo de interrupciones
para calcular las delta. Cada entrada para el tiempo delta debe también incluir el
nombre de la fase, el producto y elemento en trabajo, el proyecto y persona afectada.
● Los datos sobre el tamaño son más precisos cuando son recolectados usando una
herramienta automatizada que guardará tanto el tamaño planificado como el real
para las partes y componentes del producto. La herramienta debe calcular los totales
de tamaño por categoría o de otro modo, asegurar la consistencia de los datos siendo
recolectados.
● La mejor manera de asegurar colectar datos de alta calidad es requerir a oss
individuos que recolecten su propia información en tiempo real (o tan pronto como
sea posible luego de que son generados). Por el otro lado, los individuos deben estar
seguros de que sus datos de proceso no sean usado para evaluar su desempeño, si la
gente tiene miedo de que los datos serán usados para castigarlos, no recogerán datos
precisos, si es que recogen alguno.

6.9. Resumen de los resultados obtenidos

El objetivo principal de la investigación era encontrar un ​marco de trabajo teórico (distintas

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 119 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

metodologías, debidamente validadas teórica y empíricamente); y un ​marco de trabajo


práctico​ (herramientas a desarrollar que den soporte a las metodologías y procesos elegidos)

Para el marco teórico se entiende que los razonamientos aplicados desde los capítulos
iniciales son consistentes, fundamentados bibliográficamente y validados empíricamente y
estadísticamente según los estudios y documentos a los que se pudo tener acceso.

Para el marco práctico se entiende que la herramienta de desarrollo (IDE) ha permitido


desarrollar, en tiempo y forma, los programas básicos planteados como pruebas iniciales
(sugeridos por la bibliografía y cursos del PSP), con los objetivos puntuales y características
de diseño requeridas por el marco teórico.

Si bien el conjunto de prueba es reducido y, por el momento, las conclusiones del presente no
pueden extrapolarse a sistemas más complejos sin extender la investigación, entendemos que,
dados los recursos disponibles, los conocimientos obtenidos académicamente y los objetivos
planteados por el trabajo de diploma, la investigación ha cumplido su meta, proveyendo de
bases sólidas que permitan futuras líneas de acción.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 120 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Capítulo 7: Conclusiones

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 121 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

7.1. Conclusión:

Pero tenga en cuenta: el objetivo de aplicar los principios de ingeniería para la


producción de software en la década de 1970 fue aumentar la calidad, capacidad de
prueba, la estabilidad y la previsibilidad de los productos de software, no
necesariamente la eficiencia de la producción de software.

La fuerza impulsora de utilizar los principios de Ingeniería de Software en la


producción de software era el temor de los accidentes graves que puedan ser
causados ​por tener artistas incontrolables responsables del desarrollo de sistemas
cada vez más complejos.

Schumacher, E. E, ​Small Is Beautiful: Economics as if People Mattered, Perennial Library


Edition.​ New York: Harper and Row, 1973, p. 244.
citado por F. Brooks (1995) T​he Mythical Man-Month, Essays on Software Engineering​,
[MMM95]

Este trabajo busca resolver los riesgos comúnmente asociados al método RAD, relacionados
con la baja calidad debido a la falta o abandono del seguimiento de un proceso de desarrollo
por parte de los desarrolladores.
Por lo tanto, se plantea utilizar el Proceso Personal de Software, PSP, para controlar el
desarrollo y obtener de esta forma las métricas necesarias para evaluar la calidad y efectuar
mejoras continuas.
Esto a su vez introduce nuevos desafíos, con respecto a la captura y análisis de las métricas y
datos estadísticos, por lo cual se vuelve necesario desarrollar una herramienta que de soporte
tanto al método RAD como al proceso PSP, automatizando los procedimientos manuales,
facilitando e integrando las fases del desarrollo, mejorando de esta forma la calidad de las
mediciones y, por consiguiente de las métricas obtenidas, lo que posibilita aumentar la
productividad y disminuir la tasa de defectos.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 122 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Por ello, dado los beneficios del método RAD y del proceso PSP, se piensa que ambos son
complementarios y solucionan recíprocamente las falencias de cada uno, posibilitando un
desarrollo de software que minimice los tiempos y costos pero logrando alta calidad
mensurable.

Dado el supuesto central de la investigación, y motivo fundamental del proyecto RAD2PY,


que consiste en que es posible el ​“Desarrollo Rápido de Aplicaciones” eficaz y
eficientemente, para un profesional de manera independiente (proceso personal),​ sobre el
marco conceptual y modelo planteado, se extrae del presente y sería posible concluir que, en
principio, según lo investigado y experimentado hasta el momento (observando el avance del
prototipo inicial piloto), las teorías, técnicas y herramientas han demostrado su viabilidad
tanto en el plano teórico como práctico.

7.2. Futuras líneas de Investigación

El “pozo de brea” de la ingeniería del software seguirá siendo pegajoso durante un


largo tiempo. Uno puede esperar que la raza humana siga intentando sistemas dentro
o simplemente fuera de nuestro alcance, y los sistemas de software son quizás las
creaciones más complicadas del hombre. Este arte complejo demandará nuestro
desarrollo continuo de la disciplina, nuestro aprendizaje para componer en grandes
unidades, nuestro mejor uso de nuevas herramientas, nuestra mejor adaptación de los
métodos probados de gestión de ingeniería, la aplicación liberal del sentido común, y
una humildad dada por Dios a reconocer nuestra falibilidad y limitaciones.

Frederick Brooks (1995) T​he Mythical Man-Month, Essays on Software Engineering​,


[MMM95]

7.2.1. Línea de investigación Profesional

Luego de introducir los ajustes necesarios al prototipo inicial piloto sería posible llevar a cabo

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 123 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

los experimentos útiles para recolectar los datos empíricos para confirmar la hipótesis
planteada a mayor escala en una futura investigación, que deberían traducirse en una mejora
tanto en la productividad como en la calidad del trabajo de los desarrolladores de software.

Esta futura investigación no solo probaría la viabilidad de la solución propuesta para el


desarrollo de sistemas más complejos, sino que también proveería de datos estadísticos sobre
PSP relacionados a las diferentes herramientas (python, web2py, etc.), especialmente
métricas y datos cuantitativos para futuros análisis.

La selección de muestras podría ser relacionada al desarrollo de módulos de tres aplicaciones


previas:

● Sistema de Facturación Electrónica, (1KLOC) [FACTURALIBRE]


● Sistema de Gestión de Emergencias, 911 (10KLOC) [AMPATU911]
● Sistema de Gestión Comercial, (750KLOC) [GESTIONLIBRE]

Observaciones ha destacar:

● Ya se ha comenzado con dicho desarrollo en Python (web2py) y no se han encontrado


mayores inconvenientes,
● El desarrollo consiste en la migración de sistemas existentes, por lo que esta
totalmente controlado al no esperar mayores desviaciones en tiempos de análisis y
diseño, ya que se cuenta con el código fuente y documentación técnica para acelerar
dichas etapas.
● La investigación se enfocará sólo en un grupo de módulos de ambos programas
llevado a cabo por desarrolladores individuales, ya que el desarrollo en su totalidad
podría ser inviable dado el alcance, recursos y experiencia recabadas de esta
investigación.

Al ser proyectos de Software libre de Código Abierto, en un futuro es posible extender la

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 124 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

investigación inicial sobre los mismos parámetros, con la colaboración de otros


desarrolladores y entidades, para poder confirmar la hipótesis en una muestra mucho mayor.

7.2.2. Línea de investigación para equipos (TSP)

Para trabajos futuros, estamos actualizando la herramienta automatizada PSP para


apuntar al nivel de desarrollo en equipo.
En este contexto, planeamos desplegar el cuerpo de conocimiento de la gestión de
equipos de software (PMBOK) encima de la disciplina PSP como fue sugerido por
(Nasir and Sahibuddin, 2011a), para así encarar los factores críticos de éxito del
software (Nasir and Sahibuddin, 2011b). Es nuestro deseo que la investigación
propuesta complementará estudios existentes en el área de ingeniería de software,
particularmente en los procesos de software y su mejora​.

Hazrina Hassan, Mohd. Hairul Nizam Md. Nasir, and Shukor Sanim Mohd. Fauzi. 2009.
Incorporating software agents in automated personal software process (PSP) tools​.
[AGENTS09]

El TSP (Team Software Process, o Proceso de Software en Equipo) es la continuación lógica


del PSP, al aplicar los conceptos personales a nivel de grupos de trabajos. Esto luego es
aplicable para lograr acelerar la implementación de CMMI en determinadas empresas,
buscando procesos repetibles y mejora de calidad, políticas que pueden ser obligatorias para
adherirse a régimenes de promoción como la Ley del Software recientemente ampliada.

Si bien en esta investigación se enfocó en el PSP a nivel personal (desarrollador


independiente), sería posible extender las herramientas para soportar el trabajo en equipo,
necesario para empresas y comunidades. Esta tendencia la siguen otros proyectos similares,
aunque hay que destacar que dicha implementación puede ser mucho más compleja que el
presente trabajo y presentar nuevas implicancias y desafíos.

7.2.3. Línea de investigación educativa

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 125 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

El curso comienza con una introducción a los estudiantes a una variedad de procesos
de software, empezando con una introducción de dos semanas para PSP de Watts
Humphrey en el Instituto de Ingeniería del Software. Esto es seguido por una
introducción a los procesos ágiles, con un énfasis en XP y Scrum.

Después de completar nuestro análisis de los procesos de software, pasamos a los


asuntos profesionales de los ingenieros de software. Discutimos conocidos desastres
de software (como el accidentes Therac-25, discutido por Leveson et al.) y por qué el
software falla (utilizando el marco proporcionada por Charette). Naturalmente, esto
lleva a una discusión sobre el Código de Ética de la Ingeniería del Software.
Claramente, una de las obligaciones éticas de un ingeniero de software es hacer un
esfuerzo por ofrecer un software mas seguro (o, tal vez deberíamos decir,
razonablemente seguro).

Traducido de Epstein, R. G. ―​Getting Students to Think about How Agile Processes Can
Be Made More Secure.​ [AGILESECURE08]

Por otra parte, se ha notado que los ejercicios iniciales del PSP incluidos en el curso para
ingenieros están desactualizados y no se ajustan a los lenguajes de programación actuales
(Python en nuestro caso), comparado con los lenguajes tradicionales como ADA, C++ o
Pascal usados en el libro (como quedo demostrado de la realización de los ejercicios en el
presente trabajo), por ejemplo:

● no se necesita diseñar listas enlazadas ya que el lenguaje cuenta con estructuras de alto
nivel, tampoco es necesario diseñar algorítmos de ordenamiento porque ya están
contemplados en la mayoría de los lenguajes de programación modernos
● el diseño de herramientas de conteo y análisis de cambios es trivial porque ya incluyen
módulos para tal fin en la biblioteca estándar, y dichos ejercicios pueden no ser
adecuados para estudiantes de niveles iniciales ya que su lógica no es simple y lineal,

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 126 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

● el lenguaje posee un estándar de calificación y herramientas para su chequeo, por lo


que este punto puede ser simplificado (y el prototipo piloto de esta investigación ya
los incorpora de manera automatizada)
● se dispone de librerías completas para analizar código, inspecciones de funciones y
objetos, funciones matemáticas, etc., por lo que muchos ejercicios son realmente
simples de implementar y no aportan en gran medida al desarrollo del proceso

Por lo tanto, otro curso de acción podría ser proponer un nuevo conjunto de ejercicios,
especialmente diseñados para el aprendizaje de Python y PSP, que, de aplicarse en una
población uniforme y controlada (por ej. estudiantes de un mismo nivel educativo, con
experiencias y plazos de entrega similares).
Esto podría ser útil para la recolección de datos empíricos y facilitar la adopción de sólidos
conceptos de ingeniería (sobre todo entre profesores y alumnos), enseñando con una
herramienta más amigable no solo técnicas de desarrollo, sino también un proceso de mejora
continua a nivel personal.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 127 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Capitulo 8: Bibliografía

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 128 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

8.1. Referencias:

1. [ADOBE09] Noopur Davis, Barbara Spencer. ​Experiences Using the Team


Software Process at Adobe Systems​. Presentations 2009 - Team Software Process
Symposium. September 22nd, 2009
http://www.sei.cmu.edu/tspsymposium/2009/2009/DAY%201%201115%20AM%20D
avis%20Spencer.pdf

2. [AGENTS09] Hazrina Hassan, Mohd. Hairul Nizam Md. Nasir, and Shukor Sanim
Mohd. Fauzi. 2009. ​Incorporating software agents in automated personal software
process (PSP) tools​. In Proceedings of the 9th international conference on
Communications and information technologies (ISCIT'09). IEEE Press, Piscataway,
NJ, USA, 976-981.

3. [AUTOMATING05] Mohd Hairul Nizam Md. Nasir and Azwina M. Yusof.


AUTOMATING A MODIFIED PERSONAL SOFTWARE PROCESS​. Malaysian
Journal of Computer Science, Vol. 18 No. 2, December 2005, pp. 11-27
mjcs.fsktm.um.edu.my/downlog.asp?AID=337

4. [AGILBAL03] Barry Boehm, Richard Turner (2003) ​Balancing Agility and


Discipline: A Guide for the Perplexed​; Addison Wesley

5. [AGILDIR03] Abrahamsson, P., Warsta, J., Siponen, M. T., and Ronkainen, J. (2003).
New directions on agile methods: a comparative analysis​. In Proceedings of the
25th international Conference on Software Engineering (Portland, Oregon, May 03 -
10, 2003). International Conference on Software Engineering. IEEE Computer
Society, Washington, DC, 244-254.

6. [AGILESECURE08] Epstein, R. G. ―​Getting Students to Think about How Agile


Processes Can Be Made More Secure​. IEEE 21st Conference on Software

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 129 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Engineering Education and Training (CSEET 2008),Charleston, SC (April 2008).

7. [AISEMA09] Irina Diana Coman, Alberto Sillitti, Giancarlo Succi. Free University of
Bozen-Bolzano, Italy. ​A case-study on using an Automated In-process Software
Engineering Measurement and Analysis system in an industrial environment.
Proceedings of the 31st International Conference on Software Engineering IEEE
Computer Society Washington DC, USA ©2009 ISBN: 978-1-4244-3453-4
http://www.inf.unibz.it/~gsucci/publications/images/ACase-studyonUsinganAutomate
d In-processSoftwareEngineering.pdf

8. [AMPATU911] Reingart Mariano. Bravo Angel, Policia de la Provincia de Buenos


Aires. ​“AMPATU”: Proyecto de Gestión de Eventos de Emergencias 911.​ Alojado
en Google Code. ​http://ampatu.googlecode.com/

9. [BLOG@CACM10] Bertrand Meyer. ​Watts Humphrey: In Honor of a Pioneer.


BLOG @ Communications of the ACM. November 15, 2010
http://cacm.acm.org/blogs/blog-cacm/101708-watts-humphrey-in-honor-of-a-pioneer/f
ulltext

10. [BRA00] Date, C.J. (2000) ​What Not How: Business Rules Approach to
Application Development​; Addison Wesley

11. [CASE01] Brown, Alan W. et al (2001) ​Principles of CASE Tool Integration​;


Oxford University Press, Inc.

12. [CODD70] Codd, E. F. (1970) ​A relational model of data for large shared data
banks.​ Communications of the ACM 13, 6 (Jun. 1970), 377-387.
http://doi.acm.org/10.1145/362384.362685

13. [CODD79] Codd, E. F. (1979). ​Extending the database relational model to capture
more meaning. ​ACM Trans. Database Syst. 4, 4 (Dec. 1979), 397-434.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 130 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

http://doi.acm.org/10.1145/320107.320109

14. [CRYSTAL97] Jeffrey Voas, Gary McGraw, Lora Kassab, and Larry Voas. 1997. ​A
'Crystal Ball' for Software Liability​. IEEE Computer Magazine. Issue 30, 6 (June
1997), 29-36. DOI=10.1109/2.587545 ​http://dx.doi.org/10.1109/2.587545

15. [DASHBOARD11] ​The Software Process Dashboard Initiative


http://www.processdash.com/

16. [DBD05] Date, C.J. (2005) ​Database in Depth: Relational Theory for
Practitioners;​ O’Reilly Media, CA

17. [FACTURALIBRE] Reingart Mariano, Marcelo Alaniz, Alan Etkin, et al. ​Proyecto
“Factura Electrónica Libre”: Interfases, herramientas y aplicativos para
Servicios Web AFIP (Factura Electrónica) en Python.​ Alojado en Google Code.
http://pyafipws.googlcode.com/

18. [GESTIONLIBRE] Reingart Mariano et al. ​Proyecto “Gestion Libre” : Sistema de


Gestión Administrativa y Contable.​ Alojado en Google Code.
http://ampatu.googlecode.com/

19. [HACKYSTAT11] ​Hackystat open source framework project


http://code.google.com/p/hackystat

20. [HSSW06] Baskerville, Richard; et. al. (2006) ​High-Speed Software Development
Practices: What Works, What Doesn’t; ​IT Professional 8, 4 (Jul. 2006), 29-36.
http://doi.ieeecomputersociety.org/10.1109/MITP.2006.86

21. [HUMPHREY95] Humphrey, Watts S. ​A Discipline for Software Engineering​.


Reading, MA: Addison-Wesley, 1995.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 131 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

22. [INFOWORLD1] Rick Grehan. ​InfoWorld review: Nine fine Python development
tools: A wide-ranging flock of Python IDEs offer great options for Windows
scripting, GUI applications, Web frameworks, multilanguage development, and
more. ​ InfoWorld.com SEPTEMBER 08, 2010
http://www.infoworld.com/d/developer-world/infoworld-review-nine-fine-python-develo
p
ment-tools-374

23. [INFOWORLD2] Rick Grehan. ​Pillars of Python: Six Python Web frameworks
compared: CubicWeb, Django, Pyramid, Web.py, Web2py, and Zope 2 give
Python-savvy Web application developers powerful and diverse options.
InfoWorld AUGUST 10, 2011.
http://www.infoworld.com/d/application-development/pillars-python-six-python-web-fra
meworks-compared-169442

24. [INGSW02] Pressman, Roger (2002) ​Ingeniería del Software, Un enfoque práctico;
McGraw-Hill / Interamericana de España S.A.

25. [INSTRUCTORPSP11] ​PSP Academic Material​. Carnegie Mellon University.


Software Engineering Institute. ​http://www.sei.cmu.edu/tsp/tools/academic/

26. [ISEMA07] Philip M. Johnson. ​Requirement and Design Trade-offs in Hackystat:


An in-process software engineering measurement and analysis system.
Proceedings of the 2007 International Symposium on Empirical Software Engineering
and Measurement, Madrid, Spain, September, 2007.
http://csdl.ics.hawaii.edu/techreports/06-06/06-06.pdf

27. [JASMINE07] Shin, Hyunil; Choi, Ho-Jin & Baik, Jongmoon. ―​Jasmine: A PSP
Supporting Tool,​ 73-83. Software Process Dynamics and Agility, International
Conference on Software Process, ICSP 2007, Proceedings (Lecture Notes in Computer
Science Vol.4470), Minneapolis, MN (May 2007).
http://www.springerlink.com/content/1607282107g27767/

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 132 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

28. [JAVA05] Tate, Bruce A. (2005) ​Beyond Java​, O’Reilly

29. [MERCURIAL] ​Mercurial SCM website​. ​http://mercurial.selenic.com/

30. [MMM95] Frederick P. Brooks, Jr. (1995) ​The Mythical Man-Month, Essays on
Software Engineering​, Anniversary Edition; Addison-Wesley

31. [MUKESH06] Mukesh Jain, Microsoft Corporation.​ "Delivering Successful Projects


With Challenges of New Teams"​. Presentations 2006 - Team Software Process
Symposium. Sep 2006; ​http://www.sei.cmu.edu/tspsymposium/2009/2006/deliver.pdf

32. [MUKESH08] Mukesh Jain. ​Delivering Successful Projects with TSP and Six
Sigma: A Practical Guide to Implementing Team Software Process.​ Auerbach
Publications, November 2008. ISBN 978-1420061437

33. [PET10] Mariano Reingart. ​web2py para todos.​ PET: Python Entre Todos. La revista
de la comunidad Python Argentina. San Isidro, Argentina. Agosto 2010. ISSN:
1853-2071 ​http://revista.python.org.ar/1/html/web2py.html

34. [POSTGRES] The PostgreSQL Global Development Group. ​PostgreSQL Website.


http://www.postgresql.org/

35. [PRAG00] Andrew Hunt and David Thomas. 2000. ​The Pragmatic Programmer.
Addison Wesley. ​http://pragprog.com/the-pragmatic-programmer

36. [PROCEEDINGSTSP10] ​2010 TSP Symposium Proceedings Document​. Carnegie


Mellon University. Software Engineering Institute.
http://www.sei.cmu.edu/tspsymposium/past-proceedings/2010/2010_TSP_Proceeding
s.pdf

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 133 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

37. [PROSOFT08] Ivette Garcia - Deputy Director General of Digital Economy at the
Ministry of the Economy, ​Mexico, TSP national initiative​. Presentations 2008 -
Team Software Process Symposium. September 2008
http://www.sei.cmu.edu/tspsymposium/2009/2008/Monday%20830AM.pdf

38. [PSP00] Humphrey, Watts S. (2000) ​The Personal Software Process, Technical
Report; ​Software Engineering Institute, Carnegie Mellon University
http://www.sei.cmu.edu/publications/documents/00.reports/00tr022.html

39. [PSP01] Humphrey, Watts S. (2001)​ Introducción al Proceso de Software Personal;


Pearson Educación, S.A., Madrid, 2001

40. [PSP94] Humphrey, Watts S. (1994) ​A discipline for software engineering​; Boston:
Addison Wesley Professional, 1st edition (December 1994)

41. [PSPA05] Raymund Sison, David Diaz, Eliska Lam, Dennis Navarro, Jessica Navarro.
Personal Software Process (PSP) Assistant.​ In Proceedings of APSEC'2005.
pp.687~696 ​http://www.csie.ntut.edu.tw/labsdtl/95-summer/0823-1.pdf

42. [PSPBEY03] Johnson, P. M., Kou, H., Agustin, J., Chan, C., Moore, C., Miglani, J.,
Zhen, S., and Doane, W. E. (2003) ​Beyond the Personal Software Process: metrics
collection and analysis for the differently disciplined​. In Proceedings of the 25th
international Conference on Software Engineering IEEE Computer Society,
Washington, DC, 641-646.
http://doi.ieeecomputersociety.org/10.1109/ICSE.2003.1201249

43. [PSPBOK05] Marsha Pomeroy-Huff, et. al. (2005) ​The Personal Software Process
Body of Knowledge, Version 1.0, Special Report​; Software Engineering Institute,
Carnegie Mellon University
http://www.sei.cmu.edu/publications/documents/05.reports/05sr003.html

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 134 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

44. [PSPBOK09] PSP BOK Official Release. ​The Personal Software Process (PSP)
Body of Knowledge, Version 2.0. Special Report.​ August 2009 (Revised February
2010). CMU/SEI-2009-SR-018
http://www.sei.cmu.edu/library/abstracts/reports/09sr018.cfm

45. [PSPCAT08] Liu, Chien-Hung; Chen, Shu-Ling; & Huang, Yu-Chun. ―​PSPCAT: A
PSP Data Collection andAnalysis Tool,​ 36-37. The 20th International Conference
Proceedings on Software Engineering & Knowledge Engineering, Redwood City, CA
(July 2008).

46. [PSPDAT98] Disney, A. M. and Johnson, P. M. (1998) ​Investigating data quality


problems in the PSP​. In Proceedings of the 6th ACM SIGSOFT international
Symposium on Foundations of Software Engineering. SIGSOFT '98/FSE-6. ACM
Press, NY, 143-152 ​http://doi.acm.org/10.1145/288195.288292

47. [PSPEMP97] Will Hayes, James W. Over (1997) ​The Personal Software Process:
An Empirical Study of Impact of PSP on Individual Engineers, Technical Report​;
Software Engineering Institute, Carnegie Mellon University;
http://www.sei.cmu.edu/publications/documents/97.reports/97tr001/97tr001abstract.ht
ml

48. [PSPWHY95] Humphrey, W. S. 1995. ​Why should you use a personal software
process?.​ ACM SIGSOFT Softw. Eng. Notes 20, 3 (Jul. 1995), 33-36.
http://doi.acm.org/10.1145/219308.219313

49. [PYDIVE04] Pilgrim, Mark (2004), ​Dive into Python​ ; Apress;


http://diveintopython.org/

50. [PYNEST05] Paul F. Dubois, (2005) ​A Nest of Pythons​; Computing in Science and
Engineering, vol. 07, no. 6, pp. 81-84, Nov/Dec, 2005.
http://doi.ieeecomputersociety.org/10.1109/MCSE.2005.108

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 135 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

51. [PYNSOL05] Michael Tobis, ​PyNSol: Objects as Scaffolding​, Computing in Science


and Engineering, vol. 7, no. 4, pp. 84-91, Jul/Aug, 2005.
http://doi.ieeecomputersociety.org/10.1109/MCSE.2005.78

52. [PYPROG05] Greg Lindstrom (2005) ​Programming with Python​; IT Professional,


vol. 07, no. 5, pp. 10-16, Sept/Oct, 2005.
http://doi.ieeecomputersociety.org/10.1109/MITP.2005.120

53. [PYREF01] Beazley, David (2001) ​Python Essential Reference​, Second Edition,
New Riders Publishing

54. [PYWEB] Python Software Fundation; ​The Python Programming Language,


http://www.python.org/

55. [PYWIN00] Hammond, Mark; Robinson, Andy (2000) ​Python Programming on


Win32​, O’Reilly

56. [PYWX06] Rappin, Noel; Dunn, Robin (2006) ​wxPython in Action​, Manning

57. [RAD2PY] Reingart Mariano.​ Proyecto “RAD2PY” : Rapid Aplication


Development platform for python​. Alojado en Google Code
http://code.google.com/p/rad2py

58. [RAD91] James Martin, (1991) ​Rapid Application Development​; Macmillan


Publishing Co., Inc.

59. [RADRSK00] Agarwal, R., Prasad, J., Tanniru, M., and Lynch, J. (2000). ​Risks of
rapid application development​. Communications of the ACM 43, 11es (Nov. 2000)
http://doi.acm.org/10.1145/352515.352516

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 136 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

60. [RADSTD95] Don Millington, Jennifer Stapleton (1995) ​Developing a RAD


Standard;​ IEEE Software, vol. 12, no. 5, pp. 54-55, (Sept., 1995)
http://doi.ieeecomputersociety.org/10.1109/52.406757

61. [RADSTN98] Stephen E. Cross (1998) ​Toward Disciplined Rapid Application


Development​, Department of Defense Software TechNews; Volume 2 Number 1 -
Rapid Application Development (RAD) issue;
http://www.dacs.dtic.mil/awareness/newsletters/technews2-1/toc.html

62. [RADVFM02] Howard, A. (2002) ​Rapid Application Development: rough and


dirty or value-for-money engineering?​. Communications of the ACM 45, 10 (Oct.
2002), 27-29. ​http://doi.acm.org/10.1145/570907.570925

63. [RAPID96] Steve McConnell. 1996. ​Rapid Development: Taming Wild Software
Schedules​ (1st ed.). Microsoft Press, Redmond, WA, USA.

64. [REUSE05] William B. Frakes and Kyo Kang. ​Software Reuse Research: Status
and Future​. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 31,
NO. 7, JULY 2005

65. [REVACC01] Luis A. Godoy, Claudio Escaudar, Rossana Jaca, Federico Pinto.
Revisión Crítica de algunas teorías de accidentes asociadas a la infraestructura​.
Revista Internacional de Desastres Naturales, Accidentes e Infraestructura Civil, Vol
1, No 2 (2001). ​http://academic.uprm.edu/laccei/index.php/RIDNAIC/article/view/35

66. [REVIEWS09] Kemerer, Chris F. & Paulk, Mark C. ―​The Impact of Design and
Code Reviews on Software Quality: An Empirical Study Based on PSP Data.
IEEE Transactions on Software Engineering,35, 4 (July-August 2009): 534-550.

67. [ROIPSP] Rico, David F., ​What is the Return on Investment (ROI) of PSP​SM
(página web) ​http://davidfrico.com/roi-psppdf.htm

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 137 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

68. [ROISPI04] Rico, David F. (2004) ​ROI of Software Process Improvement: Metrics
for Project Managers and Software Engineers​; J. Ross Publishing
http://davidfrico.com/

69. [ROISTN02] Rico, David F. (2002) ​How to Estimate ROI for Inspections, PSP​sm​,
TSP​sm​, SW-CMM​®​, ISO 9000, and CMMI​sm​, Department of Defense Software
TechNews; Volume 5 Number 4 - Return-On-Investment from Software Process
Improvement issue; ​http://www.dacs.dtic.mil/awareness/newsletters/stn5-4/

70. [STUDENTPSP11] ​Self-Study PSP Material.​ Carnegie Mellon University. Software


Engineering Institute. ​http://www.sei.cmu.edu/tsp/tools/student/

71. [SWEBOK04] IEEE Computer Society (2004) ​Guide to the Software Engineering
Body of Knowledge, 2004 Version​; The Institute of Electrical and Electronics
Engineers ​http://www.swebok.org/

72. [SWQ01] Baltus, B et.al. , ​Software Quality: State of the Art in Management,
Testing, and Tools​; Springer ,2001

73. [TOOL04] Midha, Amit; et. Al. (2004) ​Rapid Integration Tools for Rapid
Application Development: A Case Study on Legacy Integration​; Technical Report;
Software Institute Engineering, Carnegie Mellon University
http://www.sei.cmu.edu/publications/documents/04.reports/04tr023.html

74. [TSPAGILE09] Alan Padula. ​TSP*-Agile Blend: The Gun Smoke Clears.
Presentations 2009 TSP Symposium. September 21-24, 2009
http://www.sei.cmu.edu/tspsymposium/2009/2009/DAY%201%20315%20PM%20Pa
dula.pdf

75. [TSPMEXICO09] Nichols, William R. & Salazar, Rafael. ​Deploying TSP on a

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 138 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

National Scale: An Experience Report from Pilot Projects in Mexico​,


CMU/SEI-2009-TR-011. Carnegie Mellon University, Software Engineering Institute,
2009. ​http://www.sei.cmu.edu/library/abstracts/reports/09tr011.cfm

76. [TTM95] Darwen, H. and Date, C. J. (1995).​ The third manifesto. (foundation for
future database systems);​ ACM SIGMOD Rec. 24, 1 (Mar. 1995), 39-49.
http://www.thethirdmanifesto.com/

77. [UNSOLVABLE97] J.P. Lewis. 1997. ​Formally Unsolvable Problems in Software


Engineering​. ​http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5250

78. [WEB2PY10] Massimo Di Pierro, School of Computing, DePaul University. ​Web2py


Enterprise Web Framework, 3rd Edition​. Lulu.com. October 2010. ISBN
978-0557604142 ​http://www.web2py.com/book

79. [WEB2PY11] Massimo Di Pierro. ​web2py for Scientific Applications​. Computing in


Science and Engineering, vol. 13, no. 2, pp. 64-69, Mar./Apr. 2011,
doi:10.1109/MCSE.2010.97

80. [XP03] Stephens, Matt; Rosenberg, Doug (2003) ​Extreme Programming


Refactored: The Case Against XP​, Apress

Nota:​ las páginas web fueron visitadas en el período de Junio de 2011

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 139 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Capitulo 9: Síglas y Abreviaturas

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 140 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

● 4GL​: 4th Generation Language, lenguaje de cuarta generación


● ACM​: Association for Computing Machinery
● AISEMA​: Automated in-process software engineering measurement and analysis,
análisis y medición automatizada dentro del proceso de ingeniería de software
● ARO​: Army Research Office
● AUI​: Advanced User Interfase, interfaz de usuario avanzada
● BOM​: Byte Order Mark, marca de ordenación de bytes (unicode)
● CASE​: Computer Aided Software Engineering, Ingeniería de Software Asistida por
computadora
● CMM​: Capability Maturity Model, modelo de capacidad y madurez
● CMMI​: Capability Maturity Model Integration
● CMU​: ​Carnegie Mellon University
● DAL​: Database Abstraction Layer, capa de abstracción de bases de datos
● DARPA​: Defense Advanced Research Projects Agency
● DSDM​: Dynamic Systems Development Method, método dinámico de desarrollo de
sistemas
● ECG​: ElectroCodeoGram, electro-codeo-grama (AISEMA)
● EPM​: Empirical Project Monitor, monitor empírico de proyectos (AISEMA)
● GNU​: proyecto de software libre
● GPL​: GNU General Public License, licencia pública general de GNU
● GUI​: Graphics User Interfase, interfaz gráfica del usuario
● HTML​: HyperText Markup Language, lenguaje de marcado de hipertexto
● I-CASE​: Integrated Computer Aided Software Engineering, Ingeniería de Software
Asistida por computadora integrada
● IDLE​: ​IDE basada en Tkinter para Python
● INI​: archivos deconfiguración
● IEEE​: Institute of Electrical and Electronic Engineers
● IDE​: Integrated Development Environment, entorno de desarrollo integrado
● ISEMA​: in-process software engineering measurement and analysis, análisis y
medición dentro del proceso de ingeniería de software
● ISO​: International Organization for Standarization

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 141 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

● JSON​: JavaScript Object Notation, notación de objetos de javascript


● LGPL​: ​ GNU Lesser General Public License, licencia pública general acotada de GNU
● LOC​: Line Of Code, líneas de código
● MDI​: Multiple Document Interfase, interfaz de documentos múltiples
● MVC​: Model-View-Controller, patrón modelo, vista controlador
● NSF​: National Science Fundation
● OOP​: Object-Oriented Programming, programción orientada a objetos
● ORM​: Object-Relational Mapper, mapeador objeto relacional
● PC​: Personal Computer, computadora personal
● PIP​: Process Improvement Plan, plan de mejora de procesos (PSP)
● PEP​: Proceso Experimental Prototipo (PSP)
● PEP​: Python Enhancement Proposal, propuesta de mejora de Python
● Pickle​: Python object serialization, serialización de objetos python
● PROM​: PRO Metrics, métricas profesionales (AISEMA)
● PMP​: Product Maintance Process, proceso de mantenimiento de producto
● PROBE​: PROxy Based Estimation, estimación basada en aproximación (PSP)
● PSP​: Personal Software Process, proceso de software personal
● PSP-BOK​: Personal Software Process Book of Knowledge (libro del conocimiento)
● RAD​: Rapid Application Development, desarrollo rápido de aplicaciones
● ROI​: Return Of Investment, retorno de inversión
● RUP​: Rational Unified Process, proceso unificado de Rational
● SEI​: Software Engineering Instituto, Instituto de Ingeniería de Software (CMU)
● Shelve​: Python object persistence, persistencia de objetos python
● SLOC​: Source Lines Of Code, lineas de código fuente
● SUMS​: Non-intrusive Instrumentation and Statistical Learning (AISEMA)
● TI​: Tecnologias de la información
● TSP​: Team Software Process, proceso en equipos de software
● SW​: software
● UML​: Unified Modeling Language, lenguaje unificado de modelado
● Unicode​: estándar de codificación de caracteres
● UTF8​: Unicode Transformation Format, formato de transformación de unicode

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 142 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

● VB​: Visual Basic (classic)


● XP​: eXtremme Programming, programación extrema

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 143 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Capitulo 10: Anexos

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 144 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Anexo A: Estandard de Codificación PSP

Introduction
While programs must be correct, the source code should be understandable, this requires that it be
well structurd and clearly commented.
This document is based in the PSP coding standard (Humprey, "A discipline for software enginering",
pp670-672), that was largely drawn from a standard developed by Jim Murphy of the University of
Massachusetts.
The standard has been adapted to follow the python programming language syntax and rules, using
conventions from the "PEP 8 -- Style Guide for Python Code", and it automatically checker, pep8.py

General Guidelines

Program Headers
Begin all programs with a descriptive header, including:
● Python interpreter requeriments (​shebang​)
● Character set (utf8 for unicode)
● Module docstring (general description)
● Author, copyright and license
● Version and/or start date (optional, could be provided by the repository)
Example:
#!/usr/bin/env python
# coding:utf-8

"PSP Program 1A - Standard Deviation"

__author__ ​=​ ​"Mariano Reingart (reingart@gmail.com)"


__copyright__ ​=​ ​"Copyright (C) 2011 Mariano Reingart"
__license__ ​=​ ​"GPL 3.0"
__version__ ​=​ ​"

Listing Contents
Provide a summary of the program contents (TOC if necessary). This can be automatically done if
each function or class has their python docstring (documentation string) attached.
Examples:
def​ mean​(​values​):
​"Calculate the average of the numbers given:"

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 145 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

​return​ sum​(​values​)​ ​/​ ​float​(​len​(​values​))

def​ stddev​(​values​):
​"Calculate the standard deviation of a list of number values"
x_avg ​=​ mean​(​values​);​ n ​=​ len​(​values​)
​return​ math​.​sqrt​(​sum​([(​x_i ​-​ x_avg​)**​2​ ​for
x_i ​in​ values​])​ ​/​ ​float​(​n ​-​ ​1​))

Documentation Tests
Include documentation test whenever possible, to show use case and expected results. Example:
def​ mean​(​values​):
​"""Calculate the average of the numbers given:

>>> mean([1, 2, 3])


2.0
>>> mean([1, 2])
1.5
>>> mean([1, 3])
2.0
"""
​return​ sum​(​values​)​ ​/​ ​float​(​len​(​values​))

Identifiers
Use descriptive names for all variables, function names, contastans, and other identifiers. Avoid
abbreviations or single-letter variables.
Example:
number_of_students ​=​ ​0​ ​# This is GOOD
x4 ​=​ j ​=​ ftave ​=​ ​0​ ​# These are BAD

Comments
● Document the code so that the reader can understand its operation
● Comments should explain both the purpose and behavior of the code
● Comment variable definition to indicate their purpose.
Good Comment:
if​ record_count ​>​ limit​:​ ​# have all the records been processed?
Bad Comment:
if​ record_count ​>​ limit​:​ ​# check if record_count greater than limit

Major Sections

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 146 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Precede major program sections by a block comment that describes the processing that is done in the
next section:
# ******************************************************
# this program section will ...
# ******************************************************

Blank Spaces
● Write programs with sufficient spacing so that they do not appear crowded
● Separate every program construct with at least one space

Indenting
Python is sensitive to indentation, so:
● 4 spaces for each indent
● Indent every block (do not use single line multiple statement)

Capitalization
● Capitalize all constants (global variables)
● Use CamelCase​?​ for class names
● Lowercase all other identifiers
Example:
DEFAULT_NUMBER_OF_STUDENTS ​=​ ​14
class_size ​=​ DEFAULT_NUMBER_OF_STUDENTS

Assertions
If possible, include in the main section basic assertions to check sample data and expected results
(basic unit test implementation):
if​ __name__ ​==​ ​"__main__"​:
​# Table D5 "Object LOC" column
sd ​=​ stddev​([​160​,​ ​591​,​ ​114​,​ ​229​,​ ​230​,​ ​270​,​ ​128​,​ ​1657​,​ ​624​,​ ​1503​])
​assert​ round​(​sd​,​ ​2​)​ ​==​ ​572.03
​# Table D5 "New and Changed LOC" column
sd ​=​ stddev​([​186​,​ ​699​,​ ​132​,​ ​272​,​ ​291​,​ ​331​,​ ​199​,​ ​1890​,​ ​788​,​ ​1601​])
​assert​ round​(​sd​,​ ​2​)​ ​==​ ​625.63
​# Table D5 "Development Hours" column
sd ​=​ stddev​([​15.0​,​ ​69.9​,​ ​6.5​,​ ​22.4​,​ ​28.4​,​ ​65.9​,​ ​19.4​,​ ​198.7​,​ ​38.8​,​ ​138.2​])
​assert​ round​(​sd​,​ ​2​)​ ​==​ ​62.26

PEP8 Guidelines
Checking tool provides two kind of messages: E (errors) and W (warnings):

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 147 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

● 100 indentation
● 200 whitespace
● 300 blank lines
● 400 imports
● 500 line length
● 600 deprecation
● 700 statements
Special character conventions:
● \s is used for whitespaces
● \n for new lines
● \t for tabulations
The following section describes automatic checks done by pep8.py
The example format uses "Okay" (when code is correct) or error/warning code followed by colon and
space, the rest of the line is example source code.

Indentation
Use 4 spaces per indentation level.
Okay​:​ a ​=​ ​1
Okay​:​ ​if​ a ​==​ ​0​:\​n a ​=​ ​1
E111​:​ a ​=​ ​1

Okay​:​ ​for​ item ​in​ items​:\​n ​pass


E112​:​ ​for​ item ​in​ items​:\​npass

Okay​:​ a ​=​ ​1​\​nb ​=​ ​2


E113​:​ a ​=​ ​1​\​n b ​=​ ​2

Never mix tabs or spaces for Indentation


Okay​:​ ​if​ a ​==​ ​0​:\​n a ​=​ ​1​\​n b ​=​ ​1
E101​:​ ​if​ a ​==​ ​0​:\​n a ​=​ ​1​\​n​\​tb ​=​ ​1

Tabs are obsolete for Indentation, use spaces


Okay​:​ ​if​ ​True​:\​n ​return
W191​:​ ​if​ ​True​:\​n​\​treturn

Trailing whitespace is superfluous


Okay​:​ spam​(​1​)
W291​:​ spam​(​1​)\​s

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 148 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Trailing blank lines are superfluous


Okay​:​ spam​(​1​)
W391​:​ spam​(​1​)\​n

The last line should have a newline


W292 ​no​ newline at ​end​ of file

Limit all lines to a maximum of 79 characters


E501 line too ​long​ ​(​79​ characters​)

Imports on separate lines


Okay​:​ ​import​ os​\​nimport sys
E401​:​ ​import​ sys​,​ os

Okay​:​ ​from​ subprocess ​import​ ​Popen​,​ PIPE


Okay​:​ ​from​ myclas ​import​ ​MyClass
Okay​:​ ​from​ foo​.​bar​.​yourclass ​import​ ​YourClass
Okay​:​ ​import​ myclass
Okay​:​ ​import​ foo​.​bar​.​yourclass

Compound Statements
Compound statements (multiple statements on the same line) are generally discouraged.
While sometimes it's okay to put an if/for/while with a small body on the same line, never do this for
multi-clause statements. Also avoid folding such long lines!
Okay​:​ ​if​ foo ​==​ ​'blah'​:\​n do_blah_thing​()
Okay​:​ do_one​()
Okay​:​ do_two​()
Okay​:​ do_three​()

E701​:​ ​if​ foo ​==​ ​'blah'​:​ do_blah_thing​()


E701​:​ ​for​ x ​in​ lst​:​ total ​+=​ x
E701​:​ ​while​ t ​<​ ​10​:​ t ​=​ delay​()
E701​:​ ​if​ foo ​==​ ​'blah'​:​ do_blah_thing​()
E701​:​ ​else​:​ do_non_blah_thing​()
E701​:​ ​try​:​ something​()
E701​:​ ​finally​:​ cleanup​()
E701​:​ ​if​ foo ​==​ ​'blah'​:​ one​();​ two​();​ three​()

E702​:​ do_one​();​ do_two​();​ do_three​()

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 149 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Blank Lines
● Separate top-level function and class definitions with two blank lines.
● Method definitions inside a class are separated by a single blank line.
● Extra blank lines may be used (sparingly) to separate groups of related functions. Blank lines
may be omitted between a bunch of related one-liners (e.g. a set of dummy implementations).
● Use blank lines in functions, sparingly, to indicate logical sections.
Okay​:​ ​def​ a​():\​n ​pass​\​n​\​n​\​ndef b​():\​n ​pass
E301​:​ ​class​ ​Foo​:\​n ​def​ bar​():\​n ​pass
E302​:​ ​def​ a​():\​n ​pass​\​n​\​ndef b​(​n​):\​n ​pass
E302​:​ ​def​ a​():\​n ​pass​\​n​\​n​\​n​\​ndef b​(​n​):\​n ​pass
E303​:​ ​def​ a​():\​n​\​n​\​n​\​n ​pass
E304​:​ ​@decorator​\​n​\​ndef a​():\​n ​pass

Avoid extraneous whitespace


● Immediately inside parentheses, brackets or braces.
● Immediately before a comma, semicolon, or colon.
Okay​:​ spam​(​ham​[​1​],​ ​{​eggs​:​ ​2​})
E201​:​ spam​(​ ham​[​1​],​ ​{​eggs​:​ ​2​})
E201​:​ spam​(​ham​[​ ​1​],​ ​{​eggs​:​ ​2​})
E201​:​ spam​(​ham​[​1​],​ ​{​ eggs​:​ ​2​})
E202​:​ spam​(​ham​[​1​],​ ​{​eggs​:​ ​2​}​ ​)
E202​:​ spam​(​ham​[​1​ ​],​ ​{​eggs​:​ ​2​})
E202​:​ spam​(​ham​[​1​],​ ​{​eggs​:​ ​2​ ​})

E203​:​ ​if​ x ​==​ ​4​:​ ​print​ x​,​ y​;​ x​,​ y ​=​ y ​,​ x
E203​:​ ​if​ x ​==​ ​4​:​ ​print​ x​,​ y ​;​ x​,​ y ​=​ y​,​ x
E203​:​ ​if​ x ​==​ ​4​ ​:​ ​print​ x​,​ y​;​ x​,​ y ​=​ y​,​ x

Missing whitespace
Each comma, semicolon or colon should be followed by whitespace:
Okay​:​ ​[​a​,​ b​]
Okay​:​ ​(​3​,)
Okay​:​ a​[​1​:​4​]
Okay​:​ a​[:​4​]
Okay​:​ a​[​1​:]
Okay​:​ a​[​1​:​4​:​2​]
E231​:​ ​[​'a'​,​'b'​]
E231​:​ foo​(​bar​,​baz​)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 150 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

(Extra) Whitespace before parameters


Avoid extraneous whitespace in the following situations:
● Immediately before the open parenthesis that starts the argument list of a function call.
● Immediately before the open parenthesis that starts an indexing or slicing.
Okay​:​ spam​(​1​)
E211​:​ spam ​(​1​)

Okay​:​ dict​[​'key'​]​ ​=​ list​[​index​]


E211​:​ dict ​[​'key'​]​ ​=​ list​[​index​]
E211​:​ dict​[​'key'​]​ ​=​ list ​[​index​]

(Extra) Whitespace around operator


Avoid extraneous whitespace in the following situations:
● More than one space around an assignment (or other) operator to align it with another.
Okay​:​ a ​=​ ​12​ ​+​ ​3
E221​:​ a ​=​ ​4​ ​+​ ​5
E222​:​ a ​=​ ​4​ ​+​ ​5
E223​:​ a ​=​ ​4​\​t​+​ ​5
E224​:​ a ​=​ ​4​ ​+\​t5

Missing whitespace around operator


● Always surround these binary operators with a single space on either side: assignment (=),
augmented assignment (+=, -= etc.), comparisons (==, <, >, !=, <>, <=, >=, in, not in, is, is
not), Booleans (and, or, not).
● Use spaces around arithmetic operators.
Okay​:​ i ​=​ i ​+​ ​1
Okay​:​ submitted ​+=​ ​1
Okay​:​ x ​=​ x ​*​ ​2​ ​-​ ​1
Okay​:​ hypot2 ​=​ x ​*​ x ​+​ y ​*​ y
Okay​:​ c ​=​ ​(​a ​+​ b​)​ ​*​ ​(​a ​-​ b​)
Okay​:​ foo​(​bar​,​ key​=​'word'​,​ ​*​args​,​ ​**​kwargs​)
Okay​:​ baz​(**​kwargs​)
Okay​:​ negative ​=​ ​-​1
Okay​:​ spam​(-​1​)

E225​:​ i​=​i​+​1
E225​:​ submitted ​+=​1
E225​:​ x ​=​ x​*​2​ ​-​ ​1
E225​:​ hypot2 ​=​ x​*​x ​+​ y​*​y

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 151 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

E225​:​ c ​=​ ​(​a​+​b​)​ ​*​ ​(​a​-​b​)

(Extra) Whitespace around comma


Avoid extraneous whitespace in the following situations:
● More than one space around an assignment (or other) operator to align it with another.
E241 multiple spaces after ​'%s'"
E242 tab after '%s'

(Extra) Whitespace around named parameter equals


Don't use spaces around the '=' sign when used to indicate a keyword argument or a default
parameter value.
Okay​:​ ​def​ complex​(​real​,​ imag​=​0.0​):
Okay​:​ ​return​ magic​(​r​=​real​,​ i​=​imag​)
Okay​:​ ​boolean​(​a ​==​ b​)
Okay​:​ ​boolean​(​a ​!=​ b​)
Okay​:​ ​boolean​(​a ​<=​ b​)
Okay​:​ ​boolean​(​a ​>=​ b​)

E251​:​ ​def​ complex​(​real​,​ imag ​=​ ​0.0​):


E251​:​ ​return​ magic​(​r ​=​ real​,​ i ​=​ imag​)

Python 3000 has_key deprecated


Okay​:​ x ​in​ ​{...}
W601​:​ ​{}.​has_key​(​x​)

Python 3000 raise comma deprecated


Okay​:​ aise ​ValueError​(​'message'​)
W602​:​ ​raise​ ​ValueError​,​ ​'message'

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 152 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Anexo B: Estándard de tipos de Defectos

The Defect Type Standard purpose is to facilitate cause analysis and defect prevention.

This document is based in the PSP Defect Type Standard (Humprey 1997, "A discipline for
software enginering", pp38, 260, 262, 661), modeled on the work at IBM Research by types
were taken from R. Chillarege, I. Bhandari, J. Chaar, M. Halliday, D. Moebus, B. Ray and M.
Y. Wong: "Orthogonal Defect Classification - A Concept of In-Process Measurements" ​IEEE
Transactions on Software Engineering​, vol. 18., no. 11 (November 1992): 943-956.
The standard has been adapted to follow the python programming language built-in exception
types, using conventions from the ​Python Language Reference​, and its automatic checker,
pep8.py

NOTE​: Type 30 (Build/Package) was moved inside Type 100 (Environment), so Type 30 is
used to automatically classificate PEP8 format defect (Type 22 in the detailed standard from
the book)

Some python exceptions are not considered errors (StopIteration and GeneratorExit) so they
are not categorized as defects. Other python exceptions were moved to better categories to
maintain consistency with the python exception hierachy (IOError) or for a easier
classification/balance (EOFError, BufferError, ImportError)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 153 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Defect Type Name Description


Type
Number

10 Documentation Errors in docstrings and comments


20 Syntax SyntaxError (spelling, punctuation, format) and
IndentationError (block delimitation)
30 Coding standard PEP8 format warnings and errors (long lines, missing
spaces, etc.)
40 Assignment NameError (undefined), unused variables,
IndexError/KeyError (range/limits LookupError),
UnboundLocalError (scope), ImportError
50 Interface TypeError, AttributeError: wrong parameters and methods
60 Checking AssertionError (failed assert) and failed tests (doctests or
unittest)
70 Data ValueError (wrong data), ArithmeticError (overflow,
zero-division, floating-point), EOFError and BufferError
80 Function RuntimeError and logic errors
90 System SystemError (including MemoryError, ReferenceError) and
Libraries or package unexpected errors
100 Enviroment EnvironmentError: Operating system and build/third party
unexpected errors (including IOError)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 154 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Anexo C: Estandard de Conteo PSP

Introduction
Python has built-in code Tokenizer suitable to parse and count logical lines.
This automated strategy will be adopted to measure software size precisely and repeatable, needed
for performance evaluation (LOC/hour), assessing quality (defect density) and planning (product
estimation).
The following token are used to count Source Lines of Code (SLOC):
● NEWLINE: token indicates the end of a logical line of Python code
● COMMENT: token value used to indicate a comment
Comment to code ratio: ​TBD

Clarifications
The following statement types are counted as logical lines (SLOC):
● executable lines
● docstrings (triple-quote ​"""​ are counted as a single line)
● shebang ​#!/usr/bin/env python​, probably because BOM
Other considerations:
● Comments are counted separately (with no distinction between own lines, with source or
banners)
● Blank lines are not counted at all
● Python languaje doesn't has nonexecutable statements (declarations, compiler directives,
begin/ends blocks)

Counting Anomalies
Although Python Tokenizer can detect more tokens (like COLON ​;​ used as the statement separator)
and could be used to further parse and detect compound statements (multiple assignments, nested
functions call, list comprehension, etc.), initially for simplicity there will be no further code analysis and
that anomalies will be counted as 1 LOC (see bellow).
The following examples will be counted as 1 LOC although it could be decomposed in separate
statements:

x_avg ​=​ mean​(​values​);​ n ​=​ len​(​values​);


return​ math​.​sqrt​(​sum​([(​x_i ​-​ x_avg​)**​2
​for​ x_i ​in​ values​])​ ​/​ ​float​(​n ​-​ ​1​))

Note that using colon to separate statements is a violation to the ​CodingStandard​: ​E701 multiple
statements on one line (colon)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 155 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Example

Physical Source Code


Sample python source code (physical file program1A.py):
#!/usr/bin/env python
# coding:utf-8

"PSP Program 1A - Standard Deviation"

__author__ ​=​ ​"Mariano Reingart (reingart@gmail.com)"


__copyright__ ​=​ ​"Copyright (C) 2011 Mariano Reingart"
__license__ ​=​ ​"GPL 3.0"

import​ math

def​ mean​(​values​):
​"""Calculate the average of the numbers given:

>>> mean([1, 2, 3])


2.0
>>> mean([1, 2])
1.5
>>> mean([1, 3])
2.0
"""
​return​ sum​(​values​)​ ​/​ ​float​(​len​(​values​))

def​ stddev​(​values​):
​"""Calculate the standard deviation of a list of number values:

>>> stddev([160, 591, 114, 229, 230, 270, 128, 1657, 624, 1503])
572.026844746915
>>> stddev([186, 699, 132, 272, 291, 331, 199, 1890, 788, 1601])
625.6339806770231
>>> stddev([15.0, 69.9, 6.5, 22.4, 28.4, 65.9, 19.4, 198.7, 38.8, 138.2])
62.25583060601187
"""
x_avg ​=​ mean​(​values​)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 156 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

n ​=​ len​(​values​)
​return​ math​.​sqrt​(​sum​([(​x_i ​-​ x_avg​)**​2
​for​ x_i ​in​ values​])​ ​/​ ​float​(​n ​-​ ​1​))

if​ __name__ ​==​ ​"__main__"​:


​# Table D5 "Object LOC" column
sd ​=​ stddev​([​160​,​ ​591​,​ ​114​,​ ​229​,​ ​230​,​ ​270​,​ ​128​,​ ​1657​,​ ​624​,​ ​1503​])
​assert​ round​(​sd​,​ ​2​)​ ​==​ ​572.03
​# Table D5 "New and Changed LOC" column
sd ​=​ stddev​([​186​,​ ​699​,​ ​132​,​ ​272​,​ ​291​,​ ​331​,​ ​199​,​ ​1890​,​ ​788​,​ ​1601​])
​assert​ round​(​sd​,​ ​2​)​ ​==​ ​625.63
​# Table D5 "Development Hours" column
sd ​=​ stddev​([​15.0​,​ ​69.9​,​ ​6.5​,​ ​22.4​,​ ​28.4​,​ ​65.9​,​ ​19.4​,​ ​198.7​,​ ​38.8​,​ ​138.2​])
​assert​ round​(​sd​,​ ​2​)​ ​==​ ​62.26

Logical Source Code


For the previous physical source code, the token detects the following logical lines (NEWLINE token)
that get counted:
​ ​(​BOM​)​ ​#!/usr/bin/env python
"PSP Program 1A - Standard Deviation"
__author__ ​=​ ​"Mariano Reingart (reingart@gmail.com)"
__copyright__ ​=​ ​"Copyright (C) 2011 Mariano Reingart"
__license__ ​=​ ​"GPL 3.0"
import​ math
def​ mean​(​values​):
​'docstring - 1 SLOC'
​return​ sum​(​values​)​ ​/​ ​float​(​len​(​values​))
def​ stddev​(​values​):
​'docstring - 1 SLOC'
x_avg ​=​ mean​(​values​)
n ​=​ len​(​values​)
​return​ math​.​sqrt​(​sum​([(​x_i ​-​ x_avg​)**​2for​ x_i ​in​ values​])​ ​/​ ​float​(​n ​-​ ​1​))
if​ __name__ ​==​ ​"__main__"​:
sd ​=​ stddev​([​160​,​ ​591​,​ ​114​,​ ​229​,​ ​230​,​ ​270​,​ ​128​,​ ​1657​,​ ​624​,​ ​1503​])
​assert​ round​(​sd​,​ ​2​)​ ​==​ ​572.03
sd ​=​ stddev​([​186​,​ ​699​,​ ​132​,​ ​272​,​ ​291​,​ ​331​,​ ​199​,​ ​1890​,​ ​788​,​ ​1601​])
​assert​ round​(​sd​,​ ​2​)​ ​==​ ​625.63
sd ​=​ stddev​([​15.0​,​ ​69.9​,​ ​6.5​,​ ​22.4​,​ ​28.4​,​ ​65.9​,​ ​19.4​,​ ​198.7​,​ ​38.8​,​ ​138.2​])
​assert​ round​(​sd​,​ ​2​)​ ​==​ ​62.26

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 157 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Results
● Total LOC count: 21
● Comments couunt: 5

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 158 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Anexo D: Lista de comprobación PSP

Purpose

To guide you in conducting an effective code review.


Based on Table 8.3, "C++ Code Review Guideline and checklist" of the PSP book (Humprey,
"A discipline for software enginering", p242).

General

As you complete each review step, check off that item in the box to the right.
Complete the checklist for one program unit before you start to review the next

Complete

Verify that the code covers all the design and requisites.

Imports

Verify that import statements:


● for included libraries are complete
● there are no unused libraries
● import lines are ordered alphabetically

Initialization

Check variable and parameter initialization:


● at program initiation
● at start of every loop
● at function/procedure entry

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 159 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Calls

Check function call formats:


● parameters
● immutable/mutable types

Names

Check name spelling and use:


● is it consistent?
● is it within the declared scope?

String

Check that all string are:


● opened/closed with’, “, or “””
● correctly encoded/decoded

Output Format

Check the output format:


● line stepping is proper
● spacing is proper

(), {}, Pairs

Ensure the tuple, dict and list delimiters are proper and matched

Logic Operators

Verify the proper use of ==, =, ||, and so on.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 160 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Check every logic function for proper ().

Line-by-line check

Check every line of code for:


● instruction syntax and
● proper punctuation

Standards

Ensure the code conforms to the coding standards.

File Open and Close

Verify that all files are:


● poperly declared (read/write mode, text/binary, etc.)
● opened, and
● closed

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 161 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Anexo E: Ejercicios del PSP

Programa 1A

​#!/usr/bin/env python
# coding:utf-8

"""PSP Program 1A - Standard Deviation


"""

__author__ = "Mariano Reingart (reingart@gmail.com)"


__copyright__ = "Copyright (C) 2011 Mariano Reingart"
__license__ = "GPL 3.0"

import math

def mean(values):
"""Calculate the average of the numbers given:

>>> mean([1, 2, 3])


2.0
>>> mean([1, 2])
1.5
>>> mean([1, 3])
2.0
"""
return sum(values) / float(len(values))

def stddev(values):
"""Calculate the standard deviation of a list of number values:

>>> stddev([160, 591, 114, 229, 230, 270, 128, 1657, 624, 1503])
572.026844746915
>>> stddev([186, 699, 132, 272, 291, 331, 199, 1890, 788, 1601])
625.6339806770231
>>> stddev([15.0, 69.9, 6.5, 22.4, 28.4, 65.9, 19.4, 198.7, 38.8, 138.2])

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 162 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

62.25583060601187
"""
x_avg = mean(values)
n = len(values)
return math.sqrt(sum([(x_i - x_avg)**2
for x_i in values]) / float(n - 1))

if __name__ == "__main__":
# Table D5 "Object LOC" column
sd = stddev([160, 591, 114, 229, 230, 270, 128, 1657, 624, 1503])
assert round(sd, 2) == 572.03
# Table D5 "New and Changed LOC" column
sd = stddev([186, 699, 132, 272, 291, 331, 199, 1890, 788, 1601])
assert round(sd, 2) == 625.63
# Table D5 "Development Hours" column
sd = stddev([15.0, 69.9, 6.5, 22.4, 28.4, 65.9, 19.4, 198.7, 38.8, 138.2])
assert round(sd, 2) == 62.26

Programa 2A

#!/usr/bin/env python
# coding:utf-8

"PSP Program 2A - Count Program LOC"

__author__ = "Mariano Reingart (reingart@gmail.com)"


__copyright__ = "Copyright (C) 2011 Mariano Reingart"
__license__ = "GPL 3.0"

from tokenize import generate_tokens, NEWLINE, COMMENT, NL


import token

# WARNING: it seems that tokenize counts BOM as a logical line!

def count_logical_lines(filename):
"""Count logical python lines and comments using Tokenizer

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 163 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

>>> f = open("test1.py", "w")


>>> f.write('#test\n\"\"\"docstring\n\"\"\"\n(1+\n1)\n\n')
>>> f.close()
>>> count, comments = count_logical_lines("test1.py")
>>> count
2
>>> comments
1
"""
locs = 0
comments = 0
with open(filename) as f:
g = generate_tokens(f.readline) # tokenize
for toknum, tokval, start, end, line in g:
if toknum == NEWLINE: # count logical line:
locs += 1
if toknum == COMMENT:
comments += 1
return locs, comments

def logical_to_physical_count(filename):
"""Place every logical line into a pythical line and count physical lines

>>> f = open("test1.py", "w")


>>> f.write('#test\n\"\"\"docstring\n\"\"\"\n(1+\n1)\n\n')
>>> f.close()
>>> logical_to_physical_count("test1.py")
2
"""

# convert physical to logical lines:


with open(filename) as f:
with open(filename + ".phy", "w") as out:
g = generate_tokens(f.readline) # tokenize
prev_toknum = None
last_col = 0
buf = ""
ident = 0
for toknum, tokval, start, end, line in g:
srow, scol = start

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 164 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

erow, ecol = end


if toknum == token.INDENT: # increment identation
ident += 1
elif toknum == token.DEDENT: # decrement identation
ident -= 1
elif toknum == token.STRING and prev_toknum in (token.INDENT,
token.NEWLINE, NL, None):
# Docstring detected, replace by a single line
buf += "'docstring - 1 SLOC'"
elif toknum == COMMENT:
# comment, do nothing
pass
elif toknum == NEWLINE:
if buf:
out.write("%s%s\n" % (" " * ident, buf))
buf = ""
last_col = 0
elif toknum == NL:
# ignore internal new lines (add space to preserve syntax)
if buf:
buf += " "
elif tokval:
# logical line (docstrig previously printed):
if last_col < scol:
buf += " "
buf += "%s" % tokval
prev_toknum = toknum
last_col = ecol

# count new physical lines from output file:


count = 0
with open(filename + ".phy") as f:
for line in f:
# fail if it is a comment
assert not line.strip().startswith("#")
# fail if it is blank
assert len(line.strip()) > 0
count += 1

return count

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 165 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

if __name__ == "__main__":
# test program1A
loc1, comments1 = count_logical_lines("program1A.py")
phy_loc1 = logical_to_physical_count("program1A.py")
print loc1, phy_loc1, comments1
assert loc1 == 21
assert comments1 == 5
assert phy_loc1 == loc1
# test program2A
loc2, comments2 = count_logical_lines("program2A.py")
phy_loc2 = logical_to_physical_count("program2A.py")
print loc2, phy_loc2, comments2
assert loc2 == 73
assert comments2 == 18
assert phy_loc2 == loc2

Programa 3A

#!/usr/bin/env python
# coding:utf-8

"PSP Program 3A - Count LOC per class/method or function"

__author__ = "Mariano Reingart (reingart@gmail.com)"


__copyright__ = "Copyright (C) 2011 Mariano Reingart"
__license__ = "GPL 3.0"

import os.path
import pyclbr
from tokenize import generate_tokens, NEWLINE, COMMENT, INDENT, DEDENT

# Constants (for results lists)


LINENO = 0
CLASS = 1
FUNCTION = 2
LOC = 3

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 166 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

# WARNING: it seems that tokenize counts BOM as a logical line!

def find_functions_and_classes(modulename, path):


"""Parse the file and return [('lineno', 'class name', 'function')]

>>> with open("test1.py", "w") as f:


... f.write("def hola():\n pass\n#\ndef chau(): pass\n")
... f.write("class Test:\n def __init__():\n\n pass\n")
>>> results = find_functions_and_classes("test1", ".")
>>> results
[[1, None, 'hola', 0], [3, None, 'chau', 0], [5, 'Test', '__init__', 0]]

"""
# Assumptions: there is only one function/class per line (syntax)
# class attributes & decorators are ignored
# imported functions should be ignored
# inheritance clases from other modules is unhandled (super)doctest
for results failed, exception NameError("name 'results' is not defined",)

result = []
module = pyclbr.readmodule_ex(modulename, path=path and [path])
for obj in module.values():
if isinstance(obj, pyclbr.Function) and obj.module == modulename:
# it is a top-level global function (no class)
result.append([obj.lineno, None, obj.name, 0])
elif isinstance(obj, pyclbr.Class) and obj.module == modulename:
# it is a class, look for the methods:
for method, lineno in obj.methods.items():
result.append([lineno, method, obj.name, 0])
# sort using lineno:
result.sort(key=lambda x: x[LINENO])
return result

def get_object(objects, lineno):


"Find the object at the lineno"
obj = None
ret = None
for obj in objects:
if obj[LINENO] > lineno:

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 167 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

break
ret = obj
return ret

def count_logical_lines_per_object(filename):
"""Count logical python lines and comments using Tokenizer, grouping
line count per object (using find_functions_and_classes)

>>> with open("test1.py", "w") as f:


... f.write("def hola():\n pass\n#\ndef chau(): pass\n")
... f.write("class Test:\n def __init__():\n\n pass\n")
>>> results = count_logical_lines_per_object("test1.py")
>>> results
([[1, None, 'hola', 1], [3, None, 'chau', 2], [5, 'Test', '__init__', 2]], 6, 1)
"""
modulename = os.path.splitext(os.path.basename(filename))[0]
path = os.path.dirname(filename)

locs = 0
comments = 0

# get the objects, they must be sorted by lineno


objects = find_functions_and_classes(modulename, path)
obj = None # current object
indent = 0 # indentation
base_indent = None # current function/class indentation (block detection)
with open(filename) as f:
g = generate_tokens(f.readline) # tokenize
for toknum, tokval, start, end, line in g:
srow, scol = start
erow, ecol = end
if toknum == INDENT: # increment identation
indent += 1
elif toknum == DEDENT: # decrement identation
indent -= 1
if base_indent is not None and indent <= base_indent:
base_indent = None
if toknum == NEWLINE: # count logical line:
# get the next object for the current line
obj = get_object(objects, srow)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 168 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

# store the indentation level (to detect when block is left)


if obj and obj[LINENO] == srow:
base_indent = indent
# sum the logical line (only if first line of obj reached)
if obj and base_indent is not None:
obj[LOC] += 1
locs += 1
if toknum == COMMENT:
comments += 1
return objects, locs, comments

if __name__ == "__main__":
# tests:
res = find_functions_and_classes("program1A", ".")
print res
assert res == [[14, None, 'mean', 0], [27, None, 'stddev', 0]]
res = find_functions_and_classes("program2A", ".")
print res
assert res == [[16, None, 'count_logical_lines', 0], \
[40, None, 'logical_to_physical_count', 0]]
res = count_logical_lines_per_object("program1A.py")
print res
assert res == ([[14, None, 'mean', 3], [27, None, 'stddev', 5]], 21, 5)
res = count_logical_lines_per_object("program2A.py")
print res
assert res == ([[16, None, 'count_logical_lines', 12],
[40, None, 'logical_to_physical_count', 41]], 73, 18)

Programa 4A:

​#!/usr/bin/env python
# coding:utf-8

"""PSP Program 1A - Linear Regression Parameter


"""

__author__ = "Mariano Reingart (reingart@gmail.com)"


__copyright__ = "Copyright (C) 2011 Mariano Reingart"

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 169 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

__license__ = "GPL 3.0"

def mean(values):
"""Calculate the average of the numbers given:

>>> mean([1, 2, 3])


2.0
>>> mean([1, 2])
1.5
>>> mean([1, 3])
2.0
"""
return sum(values) / float(len(values))

def linear_regression(x_values, y_values):


"""Calculate the linear regression parameters for a set of n values

>>> x = 10.0, 8.0, 13.0, 9.0, 11.0, 14.0, 6.0, 4.0, 12.0, 7.0, 5.0
>>> y = 8.04, 6.95, 7.58, 8.81, 8.33, 9.96, 7.24, 4.26, 10.84, 4.82, 5.68
>>> b0, b1 = linear_regression(x, y)
>>> round(b0, 3)
3.0
>>> round(b1, 3)
0.5
>>> x = 8.0, 8.0, 8.0, 8.0, 8.0, 8.0, 8.0, 19.0, 8.0, 8.0, 8.0
>>> y = 6.58, 5.76, 7.71, 8.84, 8.47, 7.04, 5.25, 12.50, 5.56, 7.91, 6.89
>>> b0, b1 = linear_regression(x, y)
>>> round(b0, 3)
3.002
>>> round(b1, 3)
0.5

"""

# calculate aux variables


x_avg = mean(x_values)
y_avg = mean(y_values)
n = len(x_values)
sum_xy = sum([(x_values[i] * y_values[i]) for i in range(n)])

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 170 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

sum_x2 = sum([(x_values[i] ** 2) for i in range(n)])

# calculate regression coefficients


b1 = (sum_xy - (n * x_avg * y_avg)) / (sum_x2 - n * (x_avg ** 2))
b0 = y_avg - b1 * x_avg

return (b0, b1)

if __name__ == "__main__":
# Table D8 "Size Estimating regression data"
est_loc = [130, 650, 99, 150, 128, 302, 95, 945, 368, 961]
est_new_chg_loc = [163, 765, 141, 166, 137, 355, 136, 1206, 433, 1130]
act_new_chg_loc = [186, 699, 132, 272, 291, 331, 199, 1890, 788, 1601]
# Estimated Object versus Actual New and changed LOC
b0, b1 = linear_regression(est_loc, act_new_chg_loc)
print b0, b1
assert round(b0, 2) == -22.55
assert round(b1, 4) == 1.7279
# Estimated New and Changed LOC versus Actal and Changed LOC
b0, b1 = linear_regression(est_new_chg_loc, act_new_chg_loc)
assert round(b0, 2) == -23.92
assert round(b1, 4) == 1.4310
print b0, b1

Programa 4A

​#!/usr/bin/env python
# coding:utf-8

"""PSP Program 4A - Linear Regression Parameter


"""

__author__ = "Mariano Reingart (reingart@gmail.com)"


__copyright__ = "Copyright (C) 2011 Mariano Reingart"
__license__ = "GPL 3.0"

def mean(values):
"""Calculate the average of the numbers given:

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 171 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

>>> mean([1, 2, 3])


2.0
>>> mean([1, 2])
1.5
>>> mean([1, 3])
2.0
"""
return sum(values) / float(len(values))

def linear_regression(x_values, y_values):


"""Calculate the linear regression parameters for a set of n values

>>> x = 10.0, 8.0, 13.0, 9.0, 11.0, 14.0, 6.0, 4.0, 12.0, 7.0, 5.0
>>> y = 8.04, 6.95, 7.58, 8.81, 8.33, 9.96, 7.24, 4.26, 10.84, 4.82, 5.68
>>> b0, b1 = linear_regression(x, y)
>>> round(b0, 3)
3.0
>>> round(b1, 3)
0.5
>>> x = 8.0, 8.0, 8.0, 8.0, 8.0, 8.0, 8.0, 19.0, 8.0, 8.0, 8.0
>>> y = 6.58, 5.76, 7.71, 8.84, 8.47, 7.04, 5.25, 12.50, 5.56, 7.91, 6.89
>>> b0, b1 = linear_regression(x, y)
>>> round(b0, 3)
3.002
>>> round(b1, 3)
0.5

"""

# calculate aux variables


x_avg = mean(x_values)
y_avg = mean(y_values)
n = len(x_values)
sum_xy = sum([(x_values[i] * y_values[i]) for i in range(n)])
sum_x2 = sum([(x_values[i] ** 2) for i in range(n)])

# calculate regression coefficients


b1 = (sum_xy - (n * x_avg * y_avg)) / (sum_x2 - n * (x_avg ** 2))
b0 = y_avg - b1 * x_avg

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 172 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

return (b0, b1)

if __name__ == "__main__":
# Table D8 "Size Estimating regression data"
est_loc = [130, 650, 99, 150, 128, 302, 95, 945, 368, 961]
est_new_chg_loc = [163, 765, 141, 166, 137, 355, 136, 1206, 433, 1130]
act_new_chg_loc = [186, 699, 132, 272, 291, 331, 199, 1890, 788, 1601]
# Estimated Object versus Actual New and changed LOC
b0, b1 = linear_regression(est_loc, act_new_chg_loc)
print b0, b1
assert round(b0, 2) == -22.55
assert round(b1, 4) == 1.7279
# Estimated New and Changed LOC versus Actal and Changed LOC
b0, b1 = linear_regression(est_new_chg_loc, act_new_chg_loc)
assert round(b0, 2) == -23.92
assert round(b1, 4) == 1.4310
print b0, b1

Programa 5A

​#!/usr/bin/env python
# coding:utf-8

"PSP Program 5A - Numerical Integration"

__author__ = "Mariano Reingart (reingart@gmail.com)"


__copyright__ = "Copyright (C) 2011 Mariano Reingart"
__license__ = "GPL 3.0"

from math import e, pi, sqrt

def compute_integral(f, x_low, x_high, w, n):


"Compute the numerical approximation of a definite integral"
# composite simpson rule (w and n are the subintervals width and quantity)
term1 = f(x_low)
term2 = 0

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 173 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

for j in xrange(1, n, 2):


term2 += f(x_low + j * w)
term3 = 0
for j in xrange(2, n, 2):
term3 += f(x_low + j * w)
term4 = f(x_high)
y = w / 3.0 * (term1 + 4 * term2 + 2 * term3 + term4)

return y

def simpson_rule_integrate(f, x_low, x_high, error=0.00001):


"Integrate complex funtins within finite limits"
# 1. identify the upper and lower limits of the numerical integration
# correct integration range for symmetrical normalized functions:
if x_high < 0 and x_low == float("-infinity"):
x_high = abs(x_high)
x_low = 0
p = -0.5
elif x_low == float("-infinity"):
x_low = 0
p = 0.5
elif x_low > 0 and x_high == float("infinity"):
x_high = x_low
x_low = 0
p = -0.5
else:
p = 0
# 2. select an initial number N and old result
n = 20
old_y = 0
while True:
# 3. divide the range to get the segment width
w = (x_high - x_low) / n
# 4. compute the numerical integration approximation
y = compute_integral(f, x_low, x_high, w, n)
# 5. compare with the old result if error is permisible
if abs(y - old_y) <= error:
if p >= 0:
return p + y
else:

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 174 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

return - p - y
old_y = y
# 6. double N
n = 2 * n
# 7. repeat ...

def factorial(x, step=1):


"Calculate integer or float factorial (for gamma function, step=2)"
if x > step:
return x * factorial(x - step, step) / step
return x / step

def gamma(n, d=2):


"Calculate gamma function value for a fraction (numerator & denominator)"
# WARNING: only tested for d=2 !
if n % 2 != 0 and d == 2:
return factorial(n - 2, step=2.0) * sqrt(pi)
else:
i = n / d
return factorial(i - 1)

def simpson_rule_tests():
"Calculate the probability values of the normal/t distribution"
inf = float("infinity")

# normal distribution
f_normal_dist = lambda u: (1 / (2 * pi) ** (0.5)) * e ** ((- u ** 2) / 2.0)
p = simpson_rule_integrate(f_normal_dist, - inf, -1.1)
assert round(p, 4) == 0.1357
p = simpson_rule_integrate(f_normal_dist, - inf, 2.5)
assert round(p, 4) == 0.9938
p = simpson_rule_integrate(f_normal_dist, - inf, 0.2)
assert round(p, 4) == 0.5793

# student t distribution
n = 9 # degrees of freedom
assert round(gamma(n, 2), 4) == 11.6317
k = gamma(n + 1, 2) / (sqrt(n*pi) * gamma(n, 2))

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 175 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

f_t_dist = lambda u: k * (1 + (u ** 2) / float(n)) ** (- (n +1) / 2.0)


# WARNING: the Table A17 on [HUMPHREY95] pp.524 seems to be wrong...
assert round(f_t_dist(0), 4) == 0.3880
#assert round(f_t_dist(1), 4) == 0.3874
#assert round(f_t_dist(2), 4) == 0.3854
#assert round(f_t_dist(20), 4) == 0.2065
p = simpson_rule_integrate(f_t_dist, - inf, 1.1)
assert round(p, 4) == 0.8501

n = 4 # degrees of freedom
k = gamma(n + 1, 2) / (sqrt(n*pi) * gamma(n, 2))
f_t_dist = lambda u: k * (1 + (u ** 2) / float(n)) ** (- (n +1) / 2.0)
p = simpson_rule_integrate(f_t_dist, - inf, 3.747)
assert round(p, 4) == 0.99

p = simpson_rule_integrate(f_t_dist, 2.132, inf)


assert round(p, 4) == 0.05

if __name__ == "__main__":
simpson_rule_tests()

Programa 6A

​#!/usr/bin/env python
# coding:utf-8

"PSP Program 6A - Linear Regression Prediction Interval"

__author__ = "Mariano Reingart (reingart@gmail.com)"


__copyright__ = "Copyright (C) 2011 Mariano Reingart"
__license__ = "GPL 3.0"

from math import sqrt, pi

# reuse previous programs


from program1A import mean
from program5A import simpson_rule_integrate, gamma

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 176 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

def double_sided_student_t_probability(t, n):


"Calculate the p-value using a double sided student t distribution"
# create the function for n degrees of freedom:
k = gamma(n + 1, 2) / (sqrt(n * pi) * gamma(n, 2))
f_t_dist = lambda u: k * (1 + (u ** 2) / float(n)) ** (- (n + 1) / 2.0)
# integrate a finite area from the origin to t
p_aux = simpson_rule_integrate(f_t_dist, 0, t)
# return the area of the two tails of the distribution (symmetrical)
return (0.5 - p_aux) * 2

def double_sided_student_t_value(p, n):


"Calculate the t-value using a double sided student t distribution"
# replaces table lookup, thanks to http://statpages.org/pdfs.html
v = dv = 0.5
t = 0
while dv > 0.000001:
t = 1 / v - 1
dv = dv / 2
if double_sided_student_t_probability(t, n) > p:
v = v - dv
else:
v = v + dv
return t

def variance(x_values, y_values, b0, b1):


"Calculate the mean square deviation of the linear regeression line"
# take the variance from the regression line instead of the data average
sum_aux = sum([(y - b0 - b1 * x) ** 2 for x, y in zip(x_values, y_values)])
n = float(len(x_values))
return (1 / (n - 2.0)) * sum_aux

def prediction_interval(x_values, y_values, x_k, alpha):


"""Calculate the linear regression parameters for a set of n values
then calculate the upper and lower prediction interval

"""

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 177 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

# calculate aux variables


x_avg = mean(x_values)
y_avg = mean(y_values)
n = len(x_values)
sum_xy = sum([(x_values[i] * y_values[i]) for i in range(n)])
sum_x2 = sum([(x_values[i] ** 2) for i in range(n)])

# calculate regression coefficients


b1 = (sum_xy - (n * x_avg * y_avg)) / (sum_x2 - n * (x_avg ** 2))
b0 = y_avg - b1 * x_avg

# calculate the t-value for the given alpha p-value


t = double_sided_student_t_value(1 - alpha, n - 2)

# calculate the standard deviation


sigma = sqrt(variance(x_values, y_values, b0, b1))

# calculate the range


sum_xi_xavg = sum([(x - x_avg) ** 2 for x in x_values], 0.0)
aux = 1 + (1 / float(n)) + ((x_k - x_avg) ** 2) / sum_xi_xavg
p_range = t * sigma * sqrt(aux)

# combine the range with the x_k projection:


return b0, b1, p_range, x_k + p_range, x_k - p_range, t

def test_student_t_integration():
# test student t values
assert round(double_sided_student_t_probability(t=1.8595, n=8), 4) == 0.1
assert round(double_sided_student_t_value(p=0.1, n=8), 4) == 1.8595

if __name__ == "__main__":
test_student_t_integration()
# Table D8 "Size Estimating regression data"
est_loc = [130, 650, 99, 150, 128, 302, 95, 945, 368, 961]
act_new_chg_loc = [186, 699, 132, 272, 291, 331, 199, 1890, 788, 1601]
projection = 644.429
# 70 percent
b0, b1, p_range, upi, lpi, t = prediction_interval(

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 178 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

est_loc, act_new_chg_loc, projection, alpha=0.7)


print "70% Prediction interval: ", b0, b1, p_range, upi, lpi, t
assert round(t, 3) == 1.108
assert round(b0, 2) == -22.55
assert round(b1, 4) == 1.7279
assert round(p_range, 3) == 236.563
assert round(upi, 2) == 880.99
assert round(lpi, 2) == 407.87
# 90 percent
b0, b1, p_range, upi, lpi, t = prediction_interval(
est_loc, act_new_chg_loc, projection, alpha=0.9)
print "90% Prediction interval: ", b0, b1, p_range, upi, lpi, t
assert round(t, 2) == 1.86
assert round(p_range, 2) == 396.97
assert round(upi, 2) == 1041.4
assert round(lpi, 2) == 247.46

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 179 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Anexo F: Especificación de Requisitos IEEE830

I. Introducción

Esta especificación tiene como objetivo analizar y documentar las necesidades funcionales
que deberán ser soportadas por el sistema a desarrollar. Para ello, se identificarán los
requisitos que ha de satisfacer el nuevo sistema según la bibliografía, el estudio de los
problemas de las unidades afectadas y sus necesidades actuales. Además de identificar los
requisitos se deberán establecer prioridades, lo cual proporciona un punto de referencia para
validar el sistema final que compruebe que se ajusta a las necesidades del usuario.

II. Identificación de usuarios participantes

Para el presente trabajo se identificó a los siguientes usuario:

● Desarrollador (actor principal)


● Usuario final (actor secundario)

III. Catálogo de Requisitos del Sistema

El objetivo de la especificación es definir en forma clara, precisa, completa y verificable todas


las funcionalidades y restricciones del sistema que se desea construir. Esta especificación se
ha realizado de acuerdo al estándar “IEEE Recomended Practice for Software Requirements
Specifications (IEEE/ANSI 830-1993)”, y se basa en la bibliografía consultada y el estudio de
la documentación existente.

III.1. Objetivos y Alcance del Sistema

Los principales objetivos del sistema a desarrollar son la edición de código fuente; su
compilación, ejecución y depuración (IDE); gestión de proyecto (tiempos, defectos, LOC y
fases) del proceso según la metodología RAD y proceso PSP.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 180 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

El sistema lleva el nombre de RAD2PY, la herramienta de desarrollo IDE2PY y la aplicación


de soporte PSP2PY.

III.2. Definiciones, Acrónimos y Abreviaturas

Definiciones:

● Edición de código fuente​: procedimiento por el cual se crea, modifica y almacena las
instrucciones y documentación relativa a un programa de computadora.
● Compilación​: procedimiento por el cual genera el código objeto (a partir del código
fuente) necesario para que el programa sea ejecutado
● Ejecución​: procedimiento por el cual se interpreta el código objeto, procesando las
entradas y produciendo la salida del programa
● Depuración​: procedimiento por el cual se interpreta el código objeto de manera
controlada, pudiendo inspeccionar, pausar, avanzar, detener el estado de ejecución
para analizar el funcionamiento o encontrar defectos del programa.
● Defecto (PSP)​: toda falla, error u omisión que cause que el programa no se comporte
para lo cual fue concebido.
● Fases (PSP)​: etapas necesarias para implementar un sistema y llevar la adecuada
contabilidad de métricas necesaria para el proceso: Planificación, Diseño,
Codificación, Compilación, Pruebas y Post-Mortem

Acrónimos/Abreviaturas:

● IDE: Integrated Developmen Environment, entorno de desarrollo integrado


● PSP: Personal Software Process, proceso de software personal
● RAD: Rapid Aplication Development, desarrollo rápido de aplicaciones

III.3. Descripción General

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 181 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Esta sección nos presenta una descripción general del sistema con el fin de conocer las
funciones que debe soportar, los datos asociados, las restricciones impuestas y cualquier otro
factor que pueda influir en la construcción del mismo.

Las funciones que debe realizar el sistema se pueden agrupar de la siguiente manera:

● IDE: debe permitir crear, editar, almacenar achivos de código fuente python; ejecución
(solicitando entradas e informando salida del programa); depuración con inspección de
variables, puntos de detención -breakpoints-, y funciones de pausa/ejecución paso a
paso o cancelación del programa; soportar un repositorio para versionado de archivos
(permitiendo agregar, borrar, actualizar y confirmar los archivos y cambios a los
mismos)
● Gestión de Proyecto: debe permitir detectar, mostrar, editar, almacenar y borrar
defectos según el PSP (incluyendo su fase de inyección y eliminación, tiempo de
corrección, etc.); debe permitir ingresar tiempos estimados, cronometrar tiempos en
cada fase y almacenar ambos datos, incluyendo interrupciones y sus motivos; debe
permitir contar las lineas de código agregadas, modificadas o eliminadas; debe
contemplar el cálculo de estimaciones PROBE; debe generar reportes y gráficos de
rendimiento, distribución y regresión de tiempos, tamaños y defectos.

III.4. Requisitos funcionales:

A continuación se enumeran las funciones del sistema. Dado que estan basadas en el IDE de
facto de Python (IDLE), fueron inspiradas de programas existentes como “Visual Basic” o el
“Process Dashboard” o documentadas en la Tesis o el libro de PSP, solo se las menciona
brevemente:

Funcionalidades de Archivos:
● New: crear nuevo archivo (abriendo una ventana de edición)
● Open: abrir y leer el contenido de un archivo (abriendo una ventana de edición con el

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 182 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

contenido)
● Save: guardar el contenido en el archivo correspondiente
● Save As: similar a guardar, pero pudiendo especificar otro nombre de archivo
● Close: cerrar la ventana de edición (guardando el archivo de corresponder)
● Recent Files: Archivos recientes (sesion)

Funcionalidades de Edición:
● Undo: deshacer último cambio
● Redo: rehacer último cambio
● Cut: cortar texto seleccionado
● Copy: copiar texto seleccionado (al clipboard)
● Paste: pegar texto (desde clipboard)
● Find: buscar un texto
● Replace: reemplazar un texto por otro
● Comment: comentar o descomentar un bloque de código (anteponiendo #)
● Goto Line: posicionar el cursor en la línea especificada

Funcionalidades de Ejecución:
● Run in the interpreter: ejecutar en el interprete interactivo
● Run in the debugger: ejecutar en el depurador
● Run as external process: ejecutar como proceso externo
● Kill external process: terminar proceso externo
● Set arguments: establecer argumentos (sys.argv)

Funcionalidades de Depuración:
● Step In: paso a paso entrando a función
● Step Next: paso a paso sin entrar a función
● Step Return: Paso a paso hasta salir de la función
● Continue up to the cursor: Continuar hasta el cursor
● Continue: Continuar
● Jump to instruction: Saltar a la instrucción

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 183 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

● Stop: detener el depurador, terminando el programa


● Quick Inspection: inspeccionar una variable (texto selecionado)
● Toggle Breakpoint: establecer Punto de Interrupción
● Clear All Breakpoint: limpiar todos los puntos de interrupción

Funcionalidades del PSP:

● Change PSP Phase: cambiar de fase PSP


● Change Project: cambiar de proyecto
● Upload metrics: subir metricas
● Download metrics: descargar métricas
● Start stopwatch: iniciar el cronómetro
● Pause stopwatch: detener el cronómetro (interrupción)
● Stop stopwatch: detener cronometro definitivamente
● Add Defect: agregar defecto
● Check Completion: verificar complitud
● Show Metadata: mostrar meta datos

Funcionalidades de varias:
● Quick Help: mostrar información de ayuda
● About: mostrar informacion acerca de la herramienta (versión, autor, etc)
● Exit: salir y cerrar la herramienta

Funcionalidades de la herramienta de soporte del PSP:


● Proyectos:
○ Creación
○ Consulta
○ Edición
● Estimación según PROBE (tamaños en linea de código)
○ Categorización de artefactos (objetos y funciones)
○ Consulta de biblioteca de reuso

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 184 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

○ Histograma de frecuencias de tamaño


● Estimación (de tiempos según tamaño)
○ Test de correlación lineal de los datos históricos
○ Test de Significancia de los datos históricos
○ Resumen de tiempos en cada fase
○ Gráfico de regresión lineal
● Reportes:
○ Reporte general (rendimiento, efectividad en la remoción de defectos y costo
de calidad)
○ Resumen por proyecto (tiempos, defectos)
○ Defectos:
■ Distribución de Pareto (frecuencia por tipo de defecto encontrado)
■ Diagrama de tiempos de corrección promedio (por fase y tipo)

Modelo de Datos:

PSP_PHASES = ["planning", "design", "code", "compile", "test", "postmortem"]


PSP_TIMES = ["plan", "actual", "interruption"]
PSP_DEFECT_TYPES = {10: 'Documentation', 20: 'Synax', 30: 'Build',
40: 'Assignment', 50: 'Interface', 60: 'Checking', 70: 'Data',
80: 'Function', 90: 'System', 100: 'Enviroment'}
PSP_CATEGORIES = ["module", "model", "controller", "view"]
PSP_SIZES = ["very small", "small", "medium", "large", "very large"]

psp_project = project_id, name, description, requeriments, testing, user_id, started, completed,


planned_loc, actual_loc, planned_time, time_lpi, time_upi

psp_time_summary =id, project_id, phase, plan, actual, interruption


psp_comment = id, project_id, phase, message, delta
psp_defect = id, project_id, number, summary, description, date, type, inject_phase,

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 185 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

remove_phase, fix_time, fix_defect, filename, lineno, offset, uuid

psp_reuse_library = id, project_id, filename, class_name, function_name, category, lineno,


loc

III.5. Suposiciones y Dependencias

El presente sistema da por supuesto la corrección y viabilidad de las formulas, cálculos y


procedimientos descriptos en la bibliografia consultada.

Las dependencias utilizadas son:


● Python y su Biblioteca Estandard
● Paquetes pep8 y pyflaques parachequeo estático
● Biblioteca matplotlib y numpy para graficación
● Programas de ejemplo del libro PSP

III.6. Requisitos de Usuario y Tecnológicos

Requisitos de usuario:

Las interfaces deben ser intuitivas, fáciles de usar y amigables, de manera que con unas
breves instrucciones los desarrolladores sean capaces de usarla.

Requisitos tecnológicos:

En vista de que es necesario instalar las aplicaciones en varias computadoras, se ha optado por
un entorno económico y fácil de instalar. La aplicación se ejecutará sobre un esquema
cliente/servidor, con los procesos e interfaz de usuario ejecutándose en los clientes y éstos
solicitando requerimientos al servidor que cumple su proceso.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 186 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

El sistema operativo de los clientes puede ser Linux, Windows o Mac. Es necesario tener
instalado Python, wxPython, web2py. La base de datos será PostgreSQL

III.7. Requisitos de Interfaces Externas

Interfaces de usuario: La interfaz de usuario debe ser orientada a ventanas tipo Windows.

Interfaces Hardware: Ratón y teclado estándar.

Interfaces software: La interfaz con el de la herramienta de desarrollo con la aplicación de


soporte al PSP será por servicios web utilizando el protocolo JSONRPC.

III.8. Requisitos de Rendimiento


El tiempo de respuesta de la aplicación a cada función solicitada por el usuario debe ser no
detectable por el usuario (menor de 1 segundo), excepto en el análisis estático del código, ya
que los tiempos dependeran de la longitud del archivo a analizar (aprox. 1 segundo cada 10
LOC).

III.9. Requisitos de Desarrollo

El ciclo de vida será el de Prototipado Evolutivo, debiendo orientarse hacia el desarrollo de un


sistema flexible que permita incorporar de manera sencilla cambios y nuevas funcionalidades.

III.10. Restricciones de Diseño

Ajuste a estándares: La gestión de métricas será llevada a cabo de acuerdo al PSP


Seguridad: La seguridad de los datos será establecida por el Sistema Gestor de Base de Datos
Relacional que se emplee.
Política de Respaldo: No se ha definido.
Base de Datos: El Sistema Gestor de Base de Datos debe ser relacional.
Política de Borrado: No se ha definido.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 187 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 188 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Anexo G: Diagrama Entidad Relación (PSP2PY)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 189 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Anexo H: Diagramas UML

Casos de Uso

Nota​: por cuestiones de espacio solo se enuncian los casos de uso principales. Para mas
información ver especificación de requerimientos.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 190 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Diagramas de Clases (IDE2PY)

Nota​: por cuestiones de espacio las clases secundarias se detallan en las secciones siguientes.
Aclaración​: los diagramas solo muestran las características más importantes (solo se
muestran las operaciones, los atributos -propiedades- son generalmente privados y no están

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 191 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

incluidos)

Editor:

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 192 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Soporte PSP:

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 193 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Repositorio (Mercurial):

Consola (interprete):

Depurador:

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 194 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 195 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Anexo I: Métodos de Prueba

Pruebas de caja Negra

La prueba de caja negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del
software. O sea, los casos de prueba pretenden demostrar que las funciones del software son
operativas, que la entrada se acepta de forma adecuada y que se produce un resultado
correcto, así como que la integridad de la información externa se mantiene.

Objetivos

El objetivo de realizar este tipo de prueba al sistema es para revelar el incorrecto o incompleto
funcionamiento de este, así como los errores de interfaz, rendimiento y errores de
inicialización y terminación.

Alcance

El proceso de pruebas de caja negra se va a centrar principalmente en los requisitos


funcionales del software para verificar el comportamiento de la unidad observable
externamente y la calidad funcional.

Descripción

Se llevan a cabo sobre la interfaz del software, y es completamente indiferente el


comportamiento interno y la estructura del programa. Los casos de prueba de la caja negra
pretenden demostrar que:

● Las funciones del software son operativas.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 196 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

● La entrada se acepta de forma adecuada.


● Se produce una salida correcta.
● La integridad de la información externa se mantiene.

La prueba de la caja negra intenta encontrar errores de las siguientes categorías:

● Funciones incorrectas o ausentes.


● Errores de interfaz.
● Errores en estructuras de datos o en accesos a bases de datos externas.
● Errores de rendimiento.
● Errores de inicialización y de terminación.

Estas pruebas permiten obtener un conjunto de condiciones de entrada que ejerciten


completamente todos los requisitos funcionales del programa. En ellas se ignora la estructura
de control, concentrándose en los requisitos funcionales del sistema y ejercitándolos.

Casos de Prueba

Para los casos de prueba se usaron los casos de usos detallados en la especificación de
requerimientos.

Básicamente la prueba consistió en utilizar el prototipo para desarrollar los programas


sugeridos por la bibliografía, siguiendo las fases del PSP:

● Planificar los tiempos


● Crear un archivo
● Realizar el diseño
● Realizar la codificación (comprobando errores de sintaxis)
● Realizar la compilación (comprobando standard de codificacion, variables no
declaradas, etc)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 197 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

● Realizar la prueba (ejecutar el programa, ejecutar las pruebas documentadas)


● Revisar defectos
● Post-mortem

Resultados:

A continuación se muestra una lista de los problemas encontrados, cuales fueron corregidos y
cuales dejados para futuras líneas de investigación:

PSP phases:
● automatic change to next phase when done (tick button)
● load/save metric is not intuitive (stop in pm should save it)
● do not allow close pm phase with open defects !

PSP defects:
● bind DEL key to delete action
● fix DBNotFoundError issues (deleting selected defect?)
● refresh selected item on deletions
● detect inject phase from metadata
● fix error when defect has no program file
● fix defects number sequence
● add summary (ex description)
● sort defects by number (when loading)
● fix TypeError​?​ when creating a defect and then double clicking it

PSP checks:
● syntax errors do not show correctly summary
● add exception text as description (only useful for syntax errors)
● add traceback field? (tested, but not useful)
● do not report IDE exceptions as defects (direct or indirect)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 198 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

● better categorization of python exceptions (defect types)


● avoid pep8 false-positives (fails in shebang and doctests, is it broken?)
● avoid duplicates and allow wontfix status
● separate doctest from syntax checking (see phase)
● "doctest for mean(3​?​) failed, want 2.0 got 2.0 "
● compile vs check is not clear, review the button at toolbar

Debugger:
● when pressing stop, do not start debugger if already stopped
● fix deadlocks under windows that makes debugger unusable
● fix wx event handler debugging (gui2py recipe)
● find a workaround for wx.App singleton to debug simple wx
● issue 7​: fix incorrect lineno in traceback after exec'ing in main module

Shell:
● fix annoying Copy/Paste issues (not working using the keyboard)
● clean local namespace dictionary before running a script

Editor
● fix wx.STC styling issues when highlight searchs
● enhance find to search selected text
● remove asterisk at notebook title when the file is just opened and not modified
● fix erroneous/bogous repaint on ubuntu
● issue 4 ​: fix undo CTRL+Z
● highligh errors/defect lines
● automatically inspect the text under cursor
● fix IOError when opening a nonexistent file

Repository
● fix folder separator under windows
● show unversioned files by default (new repos)

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 199 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

● append all files when creating a local repo?

Main:
● correctly close files
● test running/debugging multiple files
● issue 5​: wx.SafeYield​?​ blocks the app in rare occasions
● issue 6 ​: misterious exception on AUIFrame (filehistory, and other attribs)
● preserve session (open files)
● fix not closing issue after using debugger (horphan thread?)
● fix help system (enhance html pydoc)
● internationalization T()

Pruebas de caja blanca

Objetivo

El objetivo de realizar este tipo de prueba al sistema es garantizar que se ejerciten por lo
menos una vez todos los caminos independientes de cada módulo o método, todos los bucles
(ciclos) en sus límites operacionales, así como las estructuras internas de datos para asegurar
su validez.

Alcance

El proceso de pruebas de caja blanca se va a concentrar principalmente en validar que cada


uno de los módulos o segmentos de códigos funcione apropiadamente.

Descripción

Las pruebas de caja blanca permiten examinar la lógica interna del programa sin considerar

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 200 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

los aspectos de rendimiento. Se diseñan casos de prueba para examinar la lógica del
programa. Es un método de diseño de casos de prueba que usa la estructura de control del
diseño procedimental para derivar casos de prueba que garanticen que:

● Se ejerciten todos los caminos independientes de cada módulo.


● Se ejerciten todas las decisiones lógicas.
● Se ejecuten todos los bucles.
● Se ejecuten las estructuras de datos internas.

La prueba de Caja Blanca es considerada como uno de los tipos de pruebas más importantes
que se le aplican a un software, logrando como resultado que disminuya en un gran por ciento
el número de errores existentes en los sistemas y por ende una mayor calidad y confiabilidad.

Casos de Prueba

Se probaron con este método los módulos no interactivos relevantes para la presente
investigación:

● pyflakes: detección estática de varialbes no utilizadas, no definidas, etc.


● pep8: chequequeo estatico del estándard de codificación
● diffutil: utilitario de generación de diferencias (analisis de cambios del codigo fuente)

Cabe aclararar que los dos primeros son modulos externos y el tercero es una extensión a la
librería externa de Python.

De pyflakes y pep8 se utilizaron las pruebas incluidas en los mismos (ver Anexo: Estandard
de Codificación). No obstante, se realizaron pruebas de caja negra, cuyo resultado se
encuentra en la sección precedente.

Ejemplo:

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 201 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

El siguiente es el fragmento de código que documenta la prueba diseñado para diffutil,


modulo que compara el codigo fuente para detectar las lineas agregadas, eliminadas y
modificadas:

#!/usr/bin/env python
# coding:utf-8

"Diff facilities enhancing python stdlib (difflib.SequenceMatcher)"

__author__ = "Mariano Reingart (reingart@gmail.com)"


__copyright__ = "Copyright (C) 2011 Mariano Reingart"
__license__ = "GPL 3.0"

import difflib

class FancySequenceMatcher(difflib.SequenceMatcher):
"""Adapted SM that splits 'replace' block detecting the modified line
(based on difflib.Diffier but returning opcodes instead of text lines)

Example:

>>> s = FancySequenceMatcher(None,
... "private Thread currentThread difflib;b a".split(),
... "alas priVate volatile Thread currentThread difflib;".split())
>>>

>>> for opcode in s.get_opcodes():


... print "%6s a[%d:%d] b[%d:%d]" % opcode
insert a[0:0] b[0:1]
replace a[0:1] b[1:2]
insert a[1:1] b[2:3]
equal a[1:3] b[3:5]
replace a[3:4] b[5:6]
delete a[4:5] b[6:6]

For the sake of comparison, original SequenceMatcher only detect replaces

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 202 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

>>> for opcode in difflib.SequenceMatcher.get_opcodes(s):


... print "%6s a[%d:%d] b[%d:%d]" % opcode
replace a[0:1] b[0:3]
equal a[1:3] b[3:5]
replace a[3:5] b[5:6]

"""

En este código se puede observar que se importa y extiende el modulo difflib de la librería
extandar para agregarle funcionalidad, y se diseñó la prueba tanto de la nueva funcionalidad
(FancySequenceMatcher) como su comparación con la funcionalidad de la clase original
(difflib.SequenceMatcher).

Para correr las pruebase se utilizo doctest, perteneciente a la bibliotéca estándard de Python:

def _test():

import doctest, diffutil


return doctest.testmod(diffutil)

if __name__ == "__main__":
_test()

Resultados

Ejemplo de la salida de correr los tests para diffutil:

reingart@desktop:~/tesis/rad2py/ide2py$ python diffutil.py -v


Trying:
s = FancySequenceMatcher(None,
"private Thread currentThread difflib;b a".split(),
"alas priVate volatile Thread currentThread difflib;".split())
Expecting nothing
ok
Trying:
for opcode in s.get_opcodes():
print "%6s a[%d:%d] b[%d:%d]" % opcode

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 203 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Expecting:
insert a[0:0] b[0:1]
replace a[0:1] b[1:2]
insert a[1:1] b[2:3]
equal a[1:3] b[3:5]
replace a[3:4] b[5:6]
delete a[4:5] b[6:6]
ok
Trying:
for opcode in difflib.SequenceMatcher.get_opcodes(s):
print "%6s a[%d:%d] b[%d:%d]" % opcode
Expecting:
replace a[0:1] b[0:3]
equal a[1:3] b[3:5]
replace a[3:5] b[5:6]
ok
Trying:
print track_lines_changes("a b c d".split(), "a 1 b 2 d e".split())
Expecting:
[(0, 0), (None, 1), (1, 2), (None, 3), (3, 4), (None, 5)]
ok
6 items had no tests:
diffutil
diffutil.FancySequenceMatcher._fancy_helper
diffutil.FancySequenceMatcher._fancy_replace
diffutil.FancySequenceMatcher._intraline_diffs
diffutil.FancySequenceMatcher.get_opcodes
diffutil._test
2 items passed all tests:
3 tests in diffutil.FancySequenceMatcher
1 tests in diffutil.track_lines_changes
4 tests in 8 items.
4 passed and 0 failed.
Test passed.

Se puede observar que los test han sido satisfactorios, incluyendo los del modulo original
importado.

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 204 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Anexo J: Publicaciones y Presentaciones:

El proyecto relativo a este trabajo de investigación es software libre de código abierto y ha


sido publicado en Google Code desde el 23 de junio de 2011:

● Codigo Fuente: ​http://code.google.com/p/rad2py/source/checkout


● Documentación Técnica: ​http://code.google.com/p/rad2py/w/list
● Incidencias: ​http://code.google.com/p/rad2py/issues/list
● Descargas: ​http://code.google.com/p/rad2py/downloads/list
● Actualizaciones: ​http://code.google.com/p/rad2py/updates/list?num=50&start=100

Si bien todavia no se ha difundido ampliamente por ser un prototipo experimental, los


paquetes han sido descargados aproximadamente 300 veces y se han reportado 9 incidencias
relacionadas en general con problemas de instalación y dependencias ajenas al proyecto.

El prototipo de la presente obra ha sido introducida y comentada en distintas listas de correos


y sitios de discusión, principalmente:

● Lista de Correo del Grupo de Usuarios de Python de Argentina, enviado el 24 de Junio


de 2011 por el autor: [Enlace 1]
● Lista de Correo del Grupo de Usuarios de wxPython, enviado el 24 de Junio de 2011
por el autor: [Enlace 2]
● Lista de Correo del Grupo de Usuarios de Web2py, enviado el 11 de Agosto de 2011
por el autor: [Enlace 3]
● Lista de Correo del Grupo de Usuarios de Web2py en Español, enviado el 11 de
Agosto de 2011 por el autor: [Enlace 4]
● Reddit (sitio de discusiones técnicas), enviado inicialmente el 12 de Agosto de 2011
por el usuario mdipierro: [Enlace 5]

A su vez, el proyecto ha sido presentado en las siguientes conferencias de software libre:


● Conferencia Python Argentina 2011, Universidead Nacional del Noroeste de la

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 205 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

Provincia de Buenos Aires, 24 de Junio de 2011: [Enlace 6]


● 11vas Jornadas Regionales de Software Libre, Universidad Nacional de Salta, 29 de
Octubre de 2011 [Enlace 7]
● Ciclo de Charlas de Software Libre, Universidad Nacional de Lujan, 19 de Noviembre
de 2011 [Enlace 8]

Se ha publicado un artículo sobre el proyecto en la 4ta Edición de la Revista “Python Entre


Todos” de la Comunidad Python en Argentina [Enlace 9] (Editores: Juan Bautista Cabral y
Tomas Zulberti. Editor responsable: Roberto Alsina, Don Bosco 146 Dto 2, San Isidro,
Argentina. ISSN: 1853-2071), impresa y distribuida en la Conferencia Python Argentina
2011.
Dicho artículo también ha sido publicado a través de Consejo Profesional de Ciencias
Informáticas de la Provincia de Buenos Aires (newsletter y sitio web) [Enlace 10].

Figura J.1: Notan en la Revista Python Entre Todos - ISSN 1853-2071, 4ed. Sept 2011

Enlaces:

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 206 de 207
rad2py: Plataforma de Trabajo para RAD bajo PSP

1. http://permalink.gmane.org/gmane.org.user-groups.python.argentina/48339
2. http://wxpython-users.1045709.n5.nabble.com/ANN-ide2py-an-integrated-editor-shell-
debugger-hg-repo-and-diff-tools-for-wxPython-td4680969.html
3. http://groups.google.com/group/web2py/browse_thread/thread/8dbbaa9884990246/87
2a89ecc8476332
4. http://groups.google.com/group/web2py-usuarios/browse_thread/thread/abf2018d2cc0
0aa6/9c14a481fc78595c
5. http://www.reddit.com/r/Python/comments/jgoaz/rad2py_rapid_application_developm
ent_platform_for/
6. http://ar.pycon.org/2011/activity/accepted#1
7. http://www.jornadasregionales.org/jrsl2011/schedule/index
8. http://cdcsol.unlux.com.ar/cdcsol2011/activity/accepted#10
9. http://revista.python.org.ar/4/es/html/rad2py.html
10. http://www.cpciba.org.ar/modulos/articulos/popup_articulos.php?articulo_id=1183&b
d=cpciba&dominio_site=http://www.cpciba.org.ar&ruta_modulos=..

​ reingart@unimoron.edu.ar
Mariano Reingart - 3201-1543 - m Página 207 de 207