Guiadesupervivencia desarrollodesoftware

GUIA DE SUPERVIVENCIA PARA EL
DESARROLLO DE SOFTWARE
Cinco pasos para ir del Caos al Control

Por Paul Conte
Picante Software

Traducido por

Eduardo Pulido Rodríguez
con aprobación de SOFTLANDING SYSTEMS

DESARROLLO DE SOFTWARE GUÍA DE SUPERVIVENCIA

Cinco Pasos para ir del Caos al Control
Por Paul Conte
Picante Software
Traducido por Eduardo Pulido

Contenido

INTRODUCCIÓN................................................................................................................................................................. 3

¿QUE TAN BIEN VAN LAS COSAS PARA UD? ............................................................................................................ 3

METAS DE LA ADMINISTRACIÓN DE SOFTWARE ................................................................................................. 5

REDUCCIÓN DE RIESGOS ............................................................................................................................................... 6

PROCESO DE MEJORA CONTINUA.............................................................................................................................. 6

LISTA DE VERIFICACIÒN DE LA ADMINISTRACIÒN DE SOFTWARE ............................................................. 7

CINCO PASOS DEL CAOS AL CONTROL .................................................................................................................... 8
PASO 1: JUSTIFICAR ACCIONES A LA GERENCIA Y EQUIPO............................................................................... 8
PASO 2: ADOPTAR UN PROCESO DE ADMINISTRACIÒN DE CAMBIOS Y HERRAMIENTAS........................ 9
PASO 3: ADOPTAR UN PROCESO DE CONTROL DE CALIDAD Y HERRAMIENTAS ..................................... 10
PASO 4: ADOPTE UN PROCESO PROGRESIVO E ITERATIVO DE DESARROLLO ........................................... 10
PASO 5: EVALUACIONES CONTINUAS Y REFINAMIENTO DE PROCESOS ..................................................... 11
SUMARIO ............................................................................................................................................................................ 12

DONDE APRENDER MÀS................................................................................................................................................ 13

Page 2 of 14


Por Paul Conte
Picante Software

INTRODUCCIÓN

A pesar de los avances alcanzados en la tecnología informática – o quizás debido a ello- el desarrollo de
software continùa siendo un gran desafío, así como tambièn un proceso frecuentemente impredecible. Aùn
los equipos de ingenieros màs talentosos, frecuentemente se embarcan en el mantenimientos o en la
creaciòn de nuevos proyectos de desarrollo, al parecer “ùnicos en su gènero”, con resultados que son
difíciles de predecir.

Como resultado de esto, los proyectos – de mantenimiento o desarrollo de software – usualmente toman más
tiempo, cuestan mucho más, o no proveen lo que el usuario desea o necesita. Teniendo como resultado
final, sistemas que son costosos de sustentar y mantener. Por supuesto, diferentes grupos visualizan el
desarrollo de software de diferentes formas, y el resultado de sus proyectos varía de acuerdo a ello. Para
algunos grupos de desarrolladores, el caos caracteriza la mayoría de sus proyectos, mientras que otros
mantienen un control efectivo durante todo el proceso de desarrollo. Este documento provee una guía
concisa para evaluar como lo está hacienda Ud. Y ademàs expone cinco pasos básicos para alcanzar un
mejor control sobre sus proyectos de desarrollo de software.

¿QUÈ TAN BIEN VAN LAS COSAS PARA UD?

El proceso de desarrollo de software ha sido estudiado extensamente por dècadas. Esta investigación ha
producido un modelo ampliamente aceptado que usted puede utilizar para evaluar còmo su propia
organización lo está haciendo.

La figura No. 1 sumariza el “Modelo de Capacidad de Madurez” (CMM por sus siglas en inglés “Capability
Maturity Model”) desarrollado por el Software Engineering Institue (www.sei.cmu.edu), una organización
financiada por el gobierno de Los Estados Unidos. Las organizaciones operando al Nivel 1 de este modelo,
enfrentan muchos de los problemas causados por un proceso pobre en su definición. En este nivel, la vida
es caótica para los desarrolladores, los gerentes de Tecnología Informatica (TI), y el resto de la organización
que depende del área de TI.

Conforme una organización mejora su proceso de desarrollo y se mueve hacia un nivel más alto de madurez,
los proyectos se tornan más predecibles y exitosos. Como regla general, los pasos para alcanzar el Nivel 3
(Definido), son significativamente más fáciles de implementar que aquellos requeridos para alcanzar el Nivel

Page 3 of 14


Por Paul Conte
Picante Software

4 y 5. El Nivel 3, es un objetivo apropiado para la mayoría de los grupos de desarrolladores internos y es a
quienes se dirige este documento. La Figura 1 lista algunas de las prácticas claves para los niveles 2 y 3. Si
su proceso de desarrollo no incorpora la mayoría de los puntos indicados, usted probablemente tiene una
gran oportunidad de mejorar el proceso y ganar más control sobre sus proyectos.

Los niveles 4 y 5 pueden ser llamados los niveles “Empìricos” y “de Perfeccionamiento” porque estos
incluyen resultados de cuantificaciòn e incorporan cambios progresivos en el proceso general para reducir la
variabilidad y mejorar el rendimiento organizacional en forma continua. Estos niveles requieren disciplina
efectiva, automatizaciòn de procesos, y recursos. No se abrume pensando que usted tiene que alcanzar
cualquiera de estos niveles para obtener un beneficio substancial. (Por otro lado, con el paso del tiempo
quizàs usted decida incorporar algunas de las pràcticas de los Niveles 4 y 5 dentro de su propio proceso de
desarrollo). La pàgina web del SEI explica el “Modelo de Capacidad de Madurez” (CMM) en màs detalle y es
un buen lugar para continuar su travesìa hacia un mejor control de desarrollo.

Figura 1
NIVELES DE MADUREZ EN EL PROCESO DE DESARROLLO DE SOFTWARE
Del Instituto de Ingenierìa de Software “Modelo de Capacidad de Madurez” (CMM).

1. Inicial. El proceso de software se caracteriza como ad-hoc (como salga), y ocasionalmente caòtico.
Pocos procesos son definidos, y el èxito depende de esfuerzos individuales y heroicos.

2. Repetitivos. Establecimiento de procesos administrativos bàsicos para el seguimiento de costos,
planes de trabajo y funcionalidad. La disciplina necesaria para los procesos se encuentra implementada
y permite repetir èxitos anteriores en proyectos con aplicaciones similares.

Algunos de los procesos claves son:
• Administración de requerimientos
• Planeamiento y seguimiento de proyectos
• Uso de Software de Administración de Cambios (SCM)
• Implementación de Software de Control de Calidad (SQA)

Page 4 of 14


Por Paul Conte
Picante Software

3. Definido . El proceso de software, tanto para la administración como para la ingeniería son actividades
documentadas, estandarizadas, e integradas dentro de un proceso estandar de software para la
organización. Todos los proyectos cuentan con una versiòn aprobada y hecha a la medida de los
estandares del proceso de software de la organización, los cuales regulan el desarrollo y mantenimiento
de software en general. Algunos de estos procesos claves son:

• Definir y seguir un proceso de desarrollo
• Conducir capacitaciones regulares
• Implementar software de administración integral
• Revisiòn del trabajo desarrollado por colegas – no para criticar sino mejorar

4. Administrado. Medidas, en detalle, del proceso de desarrollo y la calidad del producto elaborado son
recolectadas. Ambos, el proceso de desarrollo y el producto son cuantitativamente entendidos y
controlados.

5. Optimo. Mejoramiento contìnuo del proceso es facilitado por la retro-alimentación cuantitativa obtenida
del proceso mismo, y por la implementaciòn de ideas innovadoras y las nuevas tecnologías disponibles.

METAS DE LA ADMINISTRACIÓN DE SOFTWARE

Antes de tratar los pasos que puede dar para alcanzar mayor control sobre los proyectos de desarrollo,
veamos las metas de la administración de software:
• Entregar productos con la funcionalidad y calidad preveida
• Entrega en los plazos acordados
• Entrega a los costos preveidos
• Alcanzar niveles de servicio preveidos, durante el uso del software

Note como enfatizo estas metas en tèrminos de una característica “preveida” en lugar de utilizar “el mejor
producto”, “el menor tiempo” o “el menor costo”. La administración efectiva del software es el acto de
establecer y obtener expectativas claramente definidas, lo cual require de un proceso de desarrollo de
software que es predecible y que obtiene resultados consistentes.

Con un proceso predescible, el staff de TI, sabe razonablemente bien ¿Qué es lo que necesitan hacer y
cuales serán los entregables?, sea que estèn manejando una simple correcciòn de programaciòn, un
conjunto de cambios, o la creacion de una aplicación completamente nueva. Algo que es importante
recalcar, es que los usuarios tambièn ven resultados consistentes por parte de los proyectos de TI cuando
estos se adhieren a estas reglas de juego.

Un proceso predecible de desarrollo de software inevitablemente requiere que tiempo (y dinero) sea
invertido en software para la administración de cambios (CM) y control de calidad (QA), antes de implementar
otras prácticas y herramientas importantes. A pesar de toda la evidencia en contra, algunos desarrolladores
repetidamente aseguran que reduciendo las prácticas de desarrollo de software, ellos pueden entregar una
aplicación más rapidamente y a menor costo. En mi experiencia, tal juego rara vez da resultado, y los
proyectos sin CM y QA casi nunca alcanzan las expectativas de tiempo, dinero o capacidad. En contraste,
las pràcticas sòlidas de administración de software evitan interrupciones en los proyectos que desvían al staff
del trabajo productivo.

Page 5 of 14


Por Paul Conte
Picante Software

REDUCCIÓN DE RIESGOS

Algunas veces los resultados de un proyecto fuera de control pueden ser desastrosos, terminando
por la entrega de un producto inutilizable. Mayormente, una organización de TI que no cuenta con un
adecuado control sobre sus proyectos, siempre se encuentra con retrazos en su plan de trabajo y por encima
del presupuesto asignado, en general, con resultados que son costosos aún cuando no son un completo
desastre.

El incumplimiento en la entrega de nueva funcionalidad o nuevos sistemas de computo en el tiempo
deseado, pueden significar oportunidades de negocio perdidas o reducida competitividad en el mercado. Un
proyecto inconsistente en sus costos o fechas de entrega puede poner en riesgo el negocio completo de una
compañìa y sus planes financieros.

Proyectos que incluyen la entrega de nuevos tipos de funcionalidad, o que utilizan nuevas
tecnologìas, son los que suelen entrar en problemas serios. El mundo de la Tecnologìa Informatica se
encuentra actualmente en un perìodo de cambios ràpidos y constantes. Muchos programas nuevos utilizan
tecnologìas emergentes tales como WebSphere y otros servidores de aplicaciòn Web, Java o lenguajes
como C#, dispositivos inalàmbricos, servicios Web, bases de datos distribuìdas y otros. El predominio de
proyectos que incluyen tecnologia de punta eleva la importancia de reducir los riesgos.

Varias pràcticas especìficas a la administraciòn de software pueden ayudar a reducir los riesgos en
forma significativa, y las voy a tratar en màs detalle en un momento. El punto de ènfasis, aquì, es que una
administraciòn predecible para el desarrollo de software es escencial en la reducciòn de riesgo. Si la manera
en que usted emprende el desarrolo de software no le brinda un control adequado, que le permita fijar y
lograr sus objetivos, luego entonces su organizaciòn corre el riesgo de terminar con proyectos que son
tardios en su cumplimiento, quizà por meses, sobrepasan su presupuesto, y de que estos proyectos se
vengan a bajo antes de su culminaciòn.

PROCESO DE MEJORA CONTINUA

Administrar los riesgos por medio de un proceso de desarrollo de software predecible provee un fundamento
sobre el cual usted podrà desarrollar en forma consistente mejor software, màs ràpidamente y a un menor
costo. Empezando con esta base, usted podrà adoptar tècnicas y herramientas en adiciòn para lograr que
sus desarrolladores sean màs productivos, para elevar la calidad del software, y para automatizar muchos de
los procesos de administraciòn del software, liberando de esta manera màs tiempo para el desarrollo de las
aplicaciones mismas.

Quiero enfatizar la ineficiencia de tratar de hacer un mejor trabajo de desarrollo de software, a largo
plazo, sin contar con un proceso bien definido. Sin tal proceso, las buenas ideas no podràn ser integradas
efectivamente dentro de las pràcticas en ejecuciòn al interior de la organizaciòn de desarrolladores. Es màs,
el tratar de “apagar incendios” (resolver multiples problemas) desperdicia demasiado tiempo y atencion que
deberìan estar enfocados a la mejora en el desarrollo mismo del software.

Pero obviamente, establecer un proceso predecible de desarrollo, no es el objetivo final. Conforme
gane experiencia y se familiarice con tecnologìas cambiantes, usted deberà adaptar su proceso de desarrollo
para alcanzar metas màs elevadas, no sòlamente de forma predecible y la disminuciòn del riesgo, sino
tambièn: mejorar el software producido, mejorar el soporte otorgado, y reducir los costos de operaciòn y
mantenimiento. La mejora continua del proceso de desarrollo le permiten a usted, afrontar nuevos desafìos,
establecer – y lograr – expectativas màs altas de capacidad, calidad, cronogramas, y costos.

Page 6 of 14


Por Paul Conte
Picante Software

LISTA DE VERIFICACIÒN DE LA ADMINISTRACIÒN DE SOFTWARE

Si usted desea mejorar los resultados de sus proyectos de software, usted tiene que mejorar el proceso. No
hay “balas de plata” o una soluciòn inmediata al problema.
La administraciòn de software involucra una variedad de tareas que cubren el ciclo de vida completo
del desarrollo. La Figura 2 lista ocho de las àreas principales que requieren pràcticas bien definidas. A
manera de auto-evaluaciòn, un gerente de IT puede hacerse las siguientes preguntas para cada uno de estos
puntos:
Si asigno a un desarrollador para trabajar en una tarea en esta àrea, ¿ tiene nuestra organizaciòn
claramente definida una descripciòn de lo que èl o ella deberà hacer?. Directivas verbales dadas
informalmente pueden funcionar en forma adecuada para tareas pequeñas que pueden ser completadas por
una sola persona en algunos dìas. Cualquier otra tarea màs significativa o necesarias por màs de una vez
necesita una mejor definiciòn.

Este consejo no significa que todas las organizaciònes necesitan volùmenes tras volùmenes de
descripciones de procesos personalizados. Muchas organizaciones exitosas tienen documentos breves que
definen pasos claves en cada àrea y hacen referencia a libros o manuales de productos que proveen màs
detalles.
Si usted aùn no cuenta con nada definido para las ocho àreas claves en la Figura 2, aquì tiene una
manera sencilla de empezar:
• Cree un documento (ej. En Word) con una secciòn para cada uno de los ocho items indicados
• Inicie cada secciòn escribiendo un pàrrafo titulado: “Lo que hacemos hoy en dia”
• Añada otro pàrrafo titulado: “Lo que necesitamos hacer”
• Inicie una lista titulada “Recursos” y adicione los nombres de libros, productos, Webs y URLs, y
otros recursos de competencia.
• Inicie una serie de listas de verificaciòn sencilla de las cosas que un desarrollador deberìa hacer
cuando se le asigne una tarea en particular.

Su primera experiencia en este punto no tiene que ser comprensiva. Pero tome su tiempo de manera que
usted y su equipo puedan captar las pràcticas màs importantes a seguir durante un proyecto de desarrollo de
software.

El dar este paso no quiere decir que su organizaciòn serà elevada al nivel 3 en la escala de madurez del
proceso. Pero usted contarà con una guìa inicial para lideres de proyectos y su equipo de trabajo, y obtendrà
un lugar tangible para expandir y mejorar la descripciòn de sus procesos. Su lista de pràcticas de desarrollo
tambièn proveerà la base para decidir que tareas podrìan verse beneficiadas por la automatizaciòn.

Debido a que los principios bàsicos de administraciòn de software se extienden a industrias diversas, o tipos
de aplicaciòn y/o ambientes computacionales, usted puede apoyarse en la experiencia de expertos y colegas
foraneos a su propia organizaciòn para iniciar el proceso. Conforme vaya creando su lista de verificaciòn,
usted podrà determinar si està creando una guìa ùtil para el desarrollador, siempre y cuando pueda contestar
estas cuatro preguntas:
• ¿Què hago en esta tarea? (Esto establece el propòsito y actividades de la tarea)
• ¿Cuando estarè listo para ir a la siguiente tarea? (Esto puede indicar los entregables que se
produzcan)
• ¿Cuàl es la siguiente tarea? (Esto describe el orden de las tareas dentro de cada fase del
proyecto)
• ¿Còmo avanzo de la tarea actual a la siguiente tarea? (Esto cubre còmo los resultados de
una tarea seràn utilizados en las actividades de la tarea siguiente)

Page 7 of 14


Por Paul Conte
Picante Software

Figura 2
AREAS CENTRALES DE ADMINISTRACIÒN DE SOFTWARE

CINCO PASOS DEL CAOS AL CONTROL

Una vez que tenga claro donde se encuentra y donde quiere estar, los siguientes cinco pasos le
permitiràn avanzar en forma significativa en direcciòn al Nivel 3 de madurez y a un mejor control de
sus proyectos.

PASO 1: JUSTIFICAR ACCIONES A LA GERENCIA Y EQUIPO

Por varias razones, la buena administraciòn de software no parece ser una pràctica intuitiva para
nadie, incluyendo desarrolladores y gerentes poco tècnicos. Los desarrolladores se caracterizan por
ser muy optimistas respecto de los resultados de los proyectos y poco entusiastas sobre actividades
que no sean las de diseño y la codificaciòn inmediata.

A los gerentes poco tècnicos tìpicamente no les gusta escuchar sobre estimaciones realistas,
especialmente aquellas como “Nosotros no hemos hecho este tipo de proyecto anteriormente, de
modo que necesitaremos invertir tiempo y dinero para evaluar lo que tomarà llevarlo a cabo.” En la
mayorìa de organizaciones, tendrà que justificar la adopciòn de metodologìas sòlidas para el
desarrollo de software.
Para los desarrolladores, he encontrado que el argumento fundamental es que la buena
administraciòn del software reduce dramàticamente el esfuerzo. Aquì estàn algunos de los
beneficios directos para los desarrolladores:
• Gran satisfacciòn y estima de los usuarios finales
• Menos aburrimiento y frustraciòn en la recodificaciòn para arreglar defectos y deficiencias

Page 8 of 14


Por Paul Conte
Picante Software

• Menor nivel de interrupciones en el trabajo (o en el tiempo personal) para solucionar
fallas crìticas en el software.

Los desarrolladores que trabajan en organizaciones con una efectiva administraciòn del
desarrollo de software son los mejores “evangelizadores” porque ellos pueden dar cuenta a sus
compañeros que la vida es mucho mejor bajo control que en caos. Como un beneficio adicional, un
buen proceso de desarrollo de software provee màs tiempo para las partes verdaderamente creativas
del desarrollo de software.
Para la gerencia, hay un argumento altamento exitoso que puede usar: La buena
administracion del desarrollo de software reduce substancialmente los riesgos. Una de las cosas que
los gerentes universalmente temen es un proyecto de envergadura que se viene abajo ante sus
propios ojos. Me he dado cuenta de que en general, los gerentes que no pertenecen al campo de
Tecnologìa Informàtica son usualmente los màs inclinados a dar respaldo a los requerimientos para
lograr un mejor control de los proyectos de software, aùn cuando esto requiera inversiones de
antemano para capacitaciòn y herramientas, y aùn cuando el proceso rebaje las expectativas (poco
realistas, por lo general). Asì como sucede con los desarrolladores, la mejor referencia entre gerentes
son sus colegas – especialmente gerentes que han visto a una organizaciòn de Tecnologìa
Informàtica mejorar sus practicas y productividad gracias a una buena administraciòn del desarrollo
de software.

PASO 2: ADOPTAR UN PROCESO DE ADMINISTRACIÒN DE CAMBIOS Y HERRAMIENTAS

La administraciòn de cambios (algunas veces llamado gerencia de configuraciòn de software, SCM
por sus siglas en inglès), es absolutamente escencial para un proceso efectivo de desarrollo de
software. Algunas pràcticas bàsicas del control de cambios incluyen:
• Herramientas para el seguimientos de cambios de una aplicaciòn, tales como el fuente y sus
archivos ejecutables
• Identificar versiones internas/comunes y de prueba/producciòn de todos los componentes
• Control de acceso a componentes (fuentes, reserva para cambios y liberaciòn)
• Control del movimiento de versiones (ej. Promociòn de pruebas a producciòn)
• Identificaciòn y creaciòn de versiones (relaciòn de versiones)
• Registro historico de cambios (ej. Correcciòn de defectos, adiciòn de funcionalidades, etc.)
• Proveer comparaciònes “relativas” de diferentes versiones de un componente.

Grupos pequeños de desarrolladores(ej. Uno o dos personas), con aplicaciones simples para
desarrollar pueden usar documentaciòn y procesos manuales, sin automatizacion. Sin embargo,
la mayorìa de organizaciones tendràn mejores resultados con sistemas de Administraciòn de
Cambios (CM por sus siglas en inglès) que proveen herramientas automàticas para promociòn,
archivamiento, administraciòn de versiones, comparaciones, distribuciòn de aplicaciones, entre
otras funciones.

La automatizaciòn reduce substancialmente el tiempo requerido para realizar tareas de CM tales
como check-in/check-out (estos tèrminos denotan exclusividad para la modificaciòn o creaciòn de
còdigo fuente asì como la liberaciòn del mismo respectivamente), ubicar objetos relacionados
para archivarlos cuando una nueva versiòn es creada, mover todos los objetos relacionados con
la aplicaciòn cuando la aplicaciòn es promovida, etc.

El primer beneficio tangible de un sistema de automatizaciòn CM, se puede ver en la reducciòn
de errores y la perdida de tiempo originada por equivocación humana en la construcciòn de la versiòn
de producciòn. CM tambièn evita que multiples desarrolladores trabajen sobre el mismo componente
y sobreescriban cambios originando resultados conflictivos en el accionar de los mòdulos. Pero el
mayor beneficio del CM es que provee la infraestructura de trabajo para planear y realizar
seguimientos tangibles de los componentes durante todo el proceso de desarrollo de la aplicaciòn.

Page 9 of 14


Por Paul Conte
Picante Software

Algunos sistemas automatizados de CM tambièn facilitan la recolecciòn de mediciones de
productividad y calidad que usted puede utilizar para evaluar y administrar el proceso de desarrollo.

Idealmente, una sola herramienta automatizada de CM deberìa englobar todos los tipos de
mòdulos relacionados al proyecto de TI, incluyendo fuentes y objetos de varios lenguajes (ej. ILE
RPG, Java, CL); tablas para bases de datos, vistas, e indices; elementos de pàginas Web (ej. HTML,
scripts, y archivos de imàgenes); documentaciòn; archivos de configuraciòn XML; propietarios de
archivos, etc. El utilizar multiples sistemas de CM para diferentes tipos de componentes es
inconveniente y no permite la incorporacion de modulos interrelacionados con dependencias mutuas
y estrechas.
Un buen sistema de CM tambièn se debe integrar con otras herramientas de desarrollo y
administraciòn tales como Ambientes Integrados de Desarrollo (IDEs por sus siglas en inglès),
herramientas de pruebas, y utilitarios para el seguimientos de problemas. El valor de un sistema de
CM va màs allà de simplemente “check-in/check-out” del còdigo fuente, sino tambien provee la base
para el desarrollo de aplicaciones completas de TI, la puesta en producciòn y el soporte para el flujo
de trabajo. Estandarizaciòn y automatizaciòn de estos flujos de procesos puede reducir el tiempo
que toma realizar una correcciòn o desarrollar un proyecto nuevo, tambièn puede reducir
significativamente problemas de puesta en producciòn.

PASO 3: ADOPTAR UN PROCESO DE CONTROL DE CALIDAD Y HERRAMIENTAS

Control de Calidad es un conjunto de pràcticas que permiten medir y mejorar la calidad de un
producto. Esto incluye la reducciòn de defectos y la entrega de software que alcanza los niveles
especificados de funcionalidad y rendimiento. La pràctica mas importante de QA que puede seguir
es registrar todos los defectos y otros tipos de problemas. Usted no puede reducir problemas sin
hacerles seguimiento.
CM y QA dependen el uno del otro. Un efectivo sistema de QA requiere CM para asociar los
defectos y sus correcciones con versiones y componentes especìficos (Esto puede ser manejado
eficientemente con sistemas automatizados de QA y CM que estàn bien integrados).
De manera inversa, incorporando QA para reducir defectos y el doble trabajo que estos causan es
esencial para que un sistema de CM no sea usado tan frecuentemente en forma innecesaria, en cilos
de che-out/recodificaciòn/check-in/pruebas/promociòn.
QA tambièn incluye pruebas de unidad, integraciòn, y componentes a nivel de sistemas,
incluyendo pruebas de regresiòn para estar seguro que la nueva versiòn no fallarà con el còdigo
actualmente en funcionamiento que pueda o no haber sido modificado.
Asì como CM, productos disponibles de software de QA son usualmente recomendados para
cualquier proyecto de gran embergadura que sobrepasen la capacidad de grupos pequeños de
desarrolladores y proyectos sencillos.
Dependiendo de los equipos de desarrolladores en el proyecto y el tipo de proyecto a
emprenderse, sus pràcticas de QA pueden beneficiarse al hacer uso del diseño inicial, la revisiòn de
còdigo, “programaciòn en pares”, y otras tècnicas especìficas. La clave principal de QA es identificar
las medidas de calidad (por ejemplo, nùmero de defectos) para luego validar el progreso y ver cuales
pràcticas proveen beneficios reales.

PASO 4: ADOPTE UN PROCESO PROGRESIVO E ITERATIVO DE DESARROLLO

En teorìa, usted puede aplicar la practica del “Big Bang” para emprender proyectos: haga el anàlisis,
el diseño, la implementaciòn y las pruebas, finalmente, entregue el software a producciòn. En la vida
real, esta teorìa funciona solamente con proyectos simples. Un proceso progresivo y e iterativo
resulta en menos riesgo y mejores resultados para la mayorìa de proyectos.
Una estrategia progresiva identifica entregables concretos que son màs pequeños que el
producto completo de cualquier fase en desarrollo. Por ejemplo, usted puede identificar una serie de
versiones de una aplicaciòn con funciones adicionales agregadas a cada versiòn en forma

Page 10 of 14


Por Paul Conte
Picante Software

progresiva. Sin embargo, los incrementos pueden ser màs pequeños que una versiòn final y pueden
estar asociados con objetivos tales como criterios de performance, facilidad de uso, etc.,

Con una estrategia iterativa, usted planea repetir y re-tocar una o màs fases del desarrollo
(ej. anàlisis, diseño, implementaciòn, etc.) varias veces. El desarrollo incremental e iterativo, van de
la mano; sin embargo, describen difererentes aspectos del flujo en un proyecto. Producir “piezas”
claramente identificada (ej. especificaciones o còdigo) da al proyecto una estructura de progreso
incremental. Ciclos de trabajo que son repetitivos en diferentes fases del proyecto es lo que hace a
un proceso iterativo. Una iteraciòn puede producir un nuevo incremento (resultado) o puede darse
simplemente para modificar un logro producido.

El desarrollo incremental e iterativo provee, en forma temprana y continua, la necesaria retro-
alimentaciòn de información que permite aprender lo que la aplicaciòn realmente requiere y lo que
tomarà finalizarla para su entrega. Juntas, estas pràcticas lo protejeràn contra el riesgo màs grande
en cualquier proyecto: “Lo que no se sabe, no importa”. Con el desarrollo incremental e iterativo,
usted podrà ajustar los entregables planeados y sus agendas (y otros aspectos de su plan de
proyecto tambièn) conforme aprenda de su experiencia.

Al entregar partes de la aplicaciòn a tiempo y regularmente, el equipo de desarrollo tambièn
gana y establece credibilidad en su entorno, y crea auto-estima. A la vez, una estrategia incremental
se enfoca màs en las necesidades de los usuarios, instándolos a identificar sus prioridades en cada
etapa del proyecto.

PASO 5: EVALUACIONES CONTINUAS Y REFINAMIENTO DE PROCESOS

Teniendo un sistema de CM y QA establecidos, y siguiendo un curso incremental e iterativo de
desarrollo, su organizaciòn de desarrolladores tiene la base necesaria para evaluar que tan buenos
procesos especìficos del proyecto estàn trabajando o no, y si se necesita revisar otros a medida que
avanza el proyecto.

Los procesos iterativos proveen una manera natural de llevar a cabo correcciones simples a lo largo
de todo el proyecto. Pero lo màs importante de esta metodologìa, es que usted puede incorporar
puntos de control explìcitos al final de cada ciclo de iteración. Si existen problemas, usted puede
revisar y corregir partes del proceso para la siguiente iteraciòn. Otro beneficio de la evaluaciòn del
proceso en forma continua es que usted puede descontinuar pràcticas no efectivas al final de
cualquier iteraciòn.
Con el tiempo, el proceso continuo de mejoras es la transiciòn mas fàcil y efectiva para salir
del caos y establecer un verdadero control de desarrollo. En lugar de realizar cambios radicales en
la manera como desarrolla e implementa software, usted puede adaptarse gradualmente a las
necesidades de su organizaciòn, al estilo de su equipo de trabajo, y a cambios en la tecnologìa.
Usted tambièn puede controlar el ritmo en que incorpora desarrollos adicionales y herramientas de
administraciòn. Si su organizaciòn se compromete al continuo mejoramiento de procesos de
desarrollo, usted prodrìa finalmente alcanzar los Niveles de Madurez 4 y 5.

Page 11 of 14


Por Paul Conte
Picante Software

SUMARIO
El desarrollo de software nunca serà un proceso mecànico en su totalidad. Sin
embargo, hoy en dìa estamos màs allà de la era cuando el proceso de desarrollo era
considerado como “magia negra”. Muchas organizaciones exitosas, hoy en día,
utilizan una combinación de metodologías formales e informales de desarrollo, y una
mezcla de herramientas compradas y/o desarrolladas en casa, para conducir
proyectos de manera predecible, que aceleren el desarrollo y reduzcan el riesgo
innatos en estos.
La adopciòn de sistemas de CM y QA son la base integral para la administraciòn del
desarrollo de software. El desarrollo incremental, iterativo, y la evaluaciòn/mejora
continua del proceso son piezas claves para lograr el control completo de un
proyecto.

Paul Conte es presidente de Picante Software, una firma consultora en Eugene,
Oregon, y es editor senior para e-Pro Magazine e iSeries NEWS Paul ha publicado
numerosos artìculos sobre pràcticas de desarrollo de software y es una autoridad
ampliamente reconocida en tecnologìa de base de datos. El es autor o co-autor de
cinco libros, incluyendo SQL/400 Guìa del Desarrollador y SQL Server 2000 Guìa del
desarrollador. Paul tiene un Bachillerato en Sicologìa de la Universidad del Estado de
Georgia y una maestrìa en Ingeniería de Sistemas de la Universidad de Oregon.

Page 12 of 14


Por Paul Conte
Picante Software

DONDE APRENDER MÀS
• “14 Ways to Succeed at Project Management”
Paul Conte IT Financial Management
http://www.businesstechnology.com/BT/Content/Index.cfm/fuseaction/viewArti
cle/ContentID/9

En este artìculo, elabore una variedad de pràcticas especìficas que lo ayudaràn a
ser exitoso con proyectos de desarrollo de software

• Cockburn, Alistair Surviving Object-Oriented Projects
Reading, MA: Addison-Wesley Publishing Company, 1997

Este libro es bastante corto pero provee una excelente explicaciòn de los riesgos
administrativos y las tècnicas incrementales e iterativas del desarrollo

• McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft
Press, 1997

Una buena introducciòn a muchos principios del desarrollo de software. Por
ejemplo McConnell nos ilustra con el siguiente pensamiento: “Proyectos
efectivos, controlan los cambios; mientras que proyectos inefectivos se dejan
controlar por ellos”

• Software Engineering Institue Web site: http://www.sei.cmu.edu

Aquì usted podrà aprender màs sobre el Modelo de Capacidad de Madurez
referenciado en la Figura 1. Para una descripciòn detallada de los niveles de
capacidad vea el capìtulo 4 en el “Capability Maturity Model Integration,
Version 1.1” documento en PDF disponible en:
http://www.sei.cmu.edu/cmmi/products/v1.1se-sw-cont.pdf

El site SEI tiene una variedad amplia de documentos en lìnea, sin embargo; los
documentos tienden a estar escritos en un estìlo acadèmico.

• NASA Software Engineering Laboratory Web site:
http://sel.gsfc.nasa.gov

Otra fuente de investigaciòn documentada y guìa sobre la administraciòn de
software

• Softlanding System Web Site:
http://www.softlanding.com/swmanagement/index.htm

Una fuente especìfica sobre informaciòn de administraciòn de software en una
plataforma iSeries y links a otros articulos y Web sites de mucha utilidad.

Page 13 of 14


Por Paul Conte
Picante Software

SoftLanding Systems, Inc. 84 Elm Street, Peterborough, SISRED S.A.C. , Canaval y Moreyra 350 Of. “F”
NH 03458. 800-545-9485, 603-924-8818. Email: Webmaster San Isidro – Lima – Perú Tel. 511-421-0925
Copyright 2003, SoftLanding Systems, Inc. Email: webmaster@sisred.com

Page 14 of 14

Guiadesupervivencia desarrollodesoftware

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Guiadesupervivencia desarrollodesoftware

Ähnlich wie Guiadesupervivencia desarrollodesoftware (20)

Mehr von CARLOS VILLARROEL PALOMINO

Mehr von CARLOS VILLARROEL PALOMINO (8)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Guiadesupervivencia desarrollodesoftware