1
Aplicacin de buenas prcticas
en un proyecto retomado
Autor: Juan Pablo Sadoly
Abstract -- Cuando un proyecto concluye antes de llegar a
su fin, alguien con mejores intenciones debe retomarlo. Sin
embargo, debe ser necesario actuar en base a las lecciones
aprendidas de los fracasos anteriores, vislumbrando
buenos resultados acompaados de buenas prcticas de
Ingeniera de Software. Este documento brinda un
conjunto de estrategias solucin a problemas comunes que
se presentan en esta situacin.
Palabras ClavesIngeniera en Requerimientos Calidad
Coaching Conocimiento Elicitacin
I. INTRODUCCIN
L A empresa automotriz fue fundada en el ao 1898 en
Francia y se dedica a la fabricacin y venta de vehculos.
sta cuenta con ms de 3000 empleados en Argentina, 2000 en
Crdoba y el resto en la cede de Capital Federal. El rea de
sistemas posee mas de 60 empleados, los cuales el 50% son
tercerizados.
II. CASO DE ESTUDIO
Este trabajo se bas en la evaluacin de la situacin actual de
un proyecto de sistemas que abarca parte del rea comercial, y
que viene desarrollndose desde el ao 2007 donde el
proyecto fue tomado por una consultora B sin poder
concluirlo, y que ahora pas a manos de empleados de la
compaa. En el transcurso pasaron muchos consultores, y
varias empresas consultoras, y an se encuentra en desarrollo.
Se realiz un conjunto de entrevistas (Anexo I) y como
consecuencia se detectaron los siguientes problemas:
A. Comunicacin
La comunicacin entre el analista y el usuario, no es la
adecuada, ya que no presenta buena predisposicin para las
entrevistas, pues se encuentra cansado de "repetir" lo mismo a
los distintos consultores que fueron pasando de anteriores
proyectos, sin llegar a ver un horizonte claro.
B. Elicitacin pobre
La definicin tcnica se desarroll en base a una
definicin funcional que no es la apropiada.
C. Reingeniera
La definicin funcional final, result ser un reflejo del
funcionamiento del sistema actual, sin dejar lugar a una
mejora de los procesos propuestos por el nuevo sistema ERP,
ya que existe una resistencia muy fuerte al cambio.
D. Conocimiento
Al tener definiciones pobres, los analistas consultan
recurrentemente al Sper Analista que posee ms
conocimiento tcnico y del negocio, que ellos. Esto genera una
gran dependencia a esa persona, con los problemas que eso
acarrea.
E. Riesgos
En el staff de consultores, hay analistas que son
funcionales puros y no poseen experiencia en escribir
requerimientos tcnicos ni de analizar tcnicamente los
programas existentes.
F. Testing
Los casos de prueba fueron confeccionados por una
empresa tercerizada experta en Testing en varias tecnologas,
sin embargo, no en el entorno requerido para este proyecto, lo
que implic la prdida de valioso tiempo en explicaciones por
parte de los analistas, que no fue contemplado como una
actividad dentro del proyecto. Esto acarre como consecuencia
que el analista funcional realice la tarea de revisar y corregir
los CP en algunos pocos minutos echando una revisin rpida.
Esto le quita calidad a los casos de prueba.
G. Factory
En la etapa de desarrollo y programacin, se encontraron
numerosas idas y vueltas con los programas que fueron el
resultado de los requerimientos pobres enumerados
anteriormente.
III. MARCO TERICO
A. Coaching: El coaching es una disciplina para el
aprendizaje y el desarrollo, un proceso que ayuda a las
personas a avanzar hacia sus metas, un intercambio
de opiniones y observaciones para generar resultados
previamente acordados, un proceso de inspiracin y
servicio a otros, que les ayuda a encontrar el mejor
camino hacia su propio desarrollo. [1]
B. Elicitacin: Es el proceso de adquirir (eliciting)
[sonsacar] todo el conocimiento relevante necesario para
producir un modelo de los requerimientos de un dominio
de problema, cuyo objetivo consiste en entender el
dominio del problema en particular. [2]
C. Reingeniera: es la revisin fundamental y el
rediseo radical de procesos para alcanzar mejoras
espectaculares en medidas crticas y contemporneas de
rendimiento, tales como costos, calidad, servicio y
rapidez. [3]
D. Gestin del conocimiento: sta ha surgido como una
disciplina cuyo objetivo se centra en generar, compartir y
utilizar conocimiento existente en un espacio u
organizacin determinada para contribuir a dar solucin a
las necesidades de los individuos y el desarrollo de las
comunidades. [4]
1

E. Ingeniera de Requerimientos: comprende todas las
tareas relacionadas con la determinacin de las
necesidades o de las condiciones a satisfacer para un
software nuevo o modificado, tomando en cuenta los
diversos requisitos de los inversores, que pueden entrar
en conflicto entre ellos. [5]
F. ERP: Los sistemas de planificacin de recursos de la
empresa (Enterprise Resource Planning) son sistemas de
gestin de informacin que integran y automatizan
muchas de las prcticas de negocio asociadas con los
aspectos operativos o productivos de una empresa. Los
objetivos principales de los sistemas ERP son:
optimizacin de los procesos empresariales; acceso a
informacin confiable, precisa y oportuna; compartir
informacin entre todos los componentes de la
organizacin; eliminacin de datos y operaciones
innecesarias y reduccin de tiempos y de los costes de los
procesos; entre otras. [6]
G. Prototipos: El prototipado de requerimientos es la
creacin de una implementacin parcial de un sistema,
para el propsito explcito de aprender sobre los
requerimientos del sistema. [7]
H. Testing: es el proceso de ejecutar un programa con la
intencin de encontrar defectos. Es un proceso
destructivo que determina el diseo de los casos de
prueba y la asignacin de responsabilidades, para tratar
de encontrar defectos en un programa. [8]
I. Gestin de Requisitos: es el conjunto de actividades
que ayudan al equipo de trabajo a identificar, controlar y
seguir los requisitos y sus cambios en cualquier
momento. O sea, bsicamente, consiste en gestionar los
cambios a los requisitos acordados, las relaciones entre
ellos, las dependencias entre la Especificacin de
Requisitos del Software (ERS) y otros documentos
producidos por el proceso de desarrollo de software. Esta
actividad asegura la consistencia entre los requisitos y el
sistema construido (o en construccin). Consume grandes
cantidades de tiempo y esfuerzo. Abarca todo el ciclo de
vida del producto. [9]
IV. DESARROLLO
El desarrollo de este documento se bas en encontrar 9
problemas del caso de estudio para luego referenciar una
solucin tcnica basada en conceptos tericos, una solucin
tcnica y otra intuitiva que dio origen a la bsqueda. Por
cuestiones de extensin y agrupamiento, la lista se resumi a
tan slo 5 problemas:
A. Inteligencia Emocional
i. Problemtica
a. Los analistas funcionales rotan constantemente, esto
no permite tener una continuidad de las entrevistas
con el usuario, y por lo tanto lo desmotiva y siente
que pierde el tiempo con cada uno.
b. Al hablar de cierto tema que el usuario ya ha
explicado numerosas veces, el funcional debe tener
2
2
en cuenta que quizs la explicacin que obtenga no
sea del todo completa, ya que pueden omitirse
definiciones importantes por parte del usuario, dado
que como ya lo ha explicado anteriormente y no
debera volver a explicarlo.
c. El analista detecta que hay riesgos en los
requerimientos ya que en ocasiones, no son
explorados en profundidad, o el usuario no provee la
informacin necesaria, llevando a un requerimiento
inconcluso que puede derivar en un gran iceberg. En
requerimientos funcionales, se pueden cometer slo
tres tipos de errores bsicos:
Olvidar un caso de uso.
Definir inadecuadamente lo que debe hacer el
sistema durante un caso.
Implementar mal un caso de uso.
Los siguientes atributos son fuentes potenciales de
riesgos en requerimientos:
Complejidad.
Dificultad.
Factibilidad.
Novedad.
Posibilidad de verificacin.
Volatilidad.
ii. Soluciones
El manejo interpersonal puede ser tratado a travs del
Coaching, considerado hoy en da sumamente importante
para cualquier organizacin, ya que:
Facilita que las personas se adapten a los cambios de
manera eficiente y eficaz.
Moviliza los valores centrales y los compromisos del
ser humano.
Estimula a las personas hacia la produccin de
resultados sin precedentes.
Renueva las relaciones y hace eficaz la comunicacin en
los sistemas humanos.
Predispone a las personas para la colaboracin, el
trabajo en equipo y la creacin de consenso.
Destapa la potencialidad de las personas,
permitindoles alcanzar objetivos que de otra manera son
considerados inalcanzables.
Por lo expuesto se propone:
a. Generar un programa para el desarrollo de la
Inteligencia Emocional, en consonancia con la cultura
deseada, lo que permitir un cambio en los niveles
ms profundos de esta provocando transformaciones
paradigmticas a nivel personal y organizacional, y
permitiendo una modificacin ms real y duradera en
los comportamientos.
b. La gestin del conocimiento, que se desarrollar en el
punto [C], brindar un gran aporte al seguimiento de
los temas definidos por el usuario y le proveer
conocimiento a los analistas funcionales, evitando as
que el usuario deba repetir sus requisitos.
c. Hay varias tcnicas para encontrar errores en
requerimientos. Las principales son:

Definir los casos de testing del sistema a partir
de los requerimientos. Ver tema Testing.
Revisar las especificaciones.
Hacer prototipos. Ver Tcnicas de Elicitacin
Validacin: La validacin de requerimientos
demuestra que el requerimiento est correctamente
definido.
Verificacin: La verificacin demuestra que el
requerimiento est implementado correctamente.
Ambas tienen que ser consideradas en la ingeniera de
requerimientos.
d. Volatilidad del Requerimiento: Categorizar y
traquear el requerimiento (mutante no mutante).
B. Tcnicas de Elicitacin
i. Problemtica
a. La captura de requisitos es uno de los pasos ms
importantes en un proyecto de ingeniera de software.
La experiencia ha demostrado que los requerimientos
incorrectos, incompletos o mal entendido son las
causas ms comunes de mala calidad, los
sobrecostos, y la entrega tarda de los sistemas de
software. La capacidad de emplear un proceso
sistemtico para la obtencin de requerimientos es
por lo tanto, una de las habilidades fundamentales de
un ingeniero de software de calidad.
b. Para que la definicin funcional sea aprobada por el
usuario, sta debe estar escrita de manera que ste
sienta que sus necesidades se vean reflejadas en el
documento, y que el analista tcnico sea capaz de
interpretarlo para realizar su especificacin de bajo
nivel.
ii. Soluciones
a. Se propone Modelar utilizando Prototipos. Como
resultado de utilizar esta tcnica obtendremos una
funcionalidad requerida realista (posible) y til,
teniendo una interfaz exactamente igual o similar a la
del prototipo satisfaciendo los objetivos del sistema.
Este prototipo, ser una versin simplificada de la
interfaz de usuario. El sistema no necesita ninguna o
muy poca funcionalidad. El facilitador simula el resto
durante los experimentos. Si el prototipo fue probado
con las tareas reales, puede convertirse en
requerimientos de estilo de diseo. Si no, es slo un
ejemplo de lo que la interfaz puede parecer. El
requisito tiene que ser al menos orientada al diseo.
(Por ejemplo, funciones o descripcin de tareas).
b. Entrenar al usuario como leer la documentacin
tcnica. Buscar un documento de "dibujo" que pueda
usar como herramienta de comunicacin: Talleres de
Diseo, aqu los usuarios y desarrolladores cooperan
para disear algo, usualmente la interfaz de usuario.
El trmino Diseo cooperativo. si todas las tareas y
objetivos del negocio estn cubiertas, y si los dems
usuarios de la organizacin comprenden la solucin.
En este tipo de taller, es fundamental que el equipo
controle la interfaz de usuario con las descripciones
3
3
de las tareas y los objetivos del negocio. El equipo
tambin debe realizar pruebas de uso con usuarios
que no hayan participado en el proceso de diseo. El
producto real final tendr la esencia de la interfaz
diseada por el equipo, y como resultado se
demostrar que satisface los objetivos del sistema y
que la funcionalidad requerida satisface las
expectativas.
c. Ingeniera de Requerimientos propone hacer realizar
iteraciones hasta que el software cumpla con los
requisitos y expectativas de los usuarios.
C. Gestin del conocimiento
i. Problemtica
a. Un punto interesante cuando hablamos de gestin del
conocimiento es el nfasis que se pone a la
valorizacin de los activos intangibles de una
organizacin, los cuales vienen a complementar de
manera importante el valor econmico de sta, por lo
que un nuevo componente de alto valor econmico
dentro de una organizacin lo representa su capital
intelectual. Con la alta rotacin de personal, y la
envergadura del proyecto, es necesaria reunir toda la
informacin, integrarla, compartirla, exponerla y
realimentarla concentrndola en un solo eje.
d. Se describe a la gestin del conocimiento como un
catalizador en los procesos de innovacin, misma
que, a su vez, resulta necesaria para la creacin de
innovaciones continuas que brinden a la organizacin
ventajas competitivas, puesto que una administracin
eficaz del conocimiento tendr mejores opciones
dentro de los procesos de negocios, pero siempre en
funcin de la intensidad del conocimiento y
complejidad del proceso.
ii. Solucin
Implementar una taxonoma de Modelos de red de
gestin del conocimiento en la organizacin: Tales
modelos surgen de forma conjunta con las teoras de
organizacin de red y se centran en la adquisicin,
intercambio y transferencia del conocimiento como
aspectos fundamentales para el aprendizaje
organizacional, lo que permite la interaccin entre los
interlocutores que intervienen en el proyecto. En este
grupo de modelos se expresa la concepcin del
conocimiento a partir de las redes de actores que
participan en su socializacin y que influye en las
acciones que estos llevan a cabo. Los actores deben
de ser capaces de aprovechar las redes externas de
conocimiento y la adquisicin de nuevas ideas en
beneficio del proyecto y principalmente de la
organizacin. Estos modelos se centran en aspectos
como la vinculacin entre individuos y grupos de
inters para facilitar el intercambio de conocimiento,
motivando as la colaboracin y comunicacin.
D. Reingeniera
i. Problemtica

a. Los procesos de negocio fueron evolucionando a
favor de la contemplacin y de las excepciones y no
en post de la calidad y eficiencia. Este negocio es un
gran administrador de excepciones (Key User dixit).
El viejo sistema fue creado a medida, contemplando
adaptndose a las viejas y enroscadas reglas, mientras
que el nuevo sistema, es un GAP dentro de un gran
ERP que abarca toda la organizacin.
ii. Solucin
a. Adaptacin (Tailoring) La adaptacin de un proceso
hace, modifica o adapta la descripcin de proceso
para un fin particular. Por ejemplo, un proyecto
establece su proceso definido adaptndolo a partir del
conjunto de procesos estndar de la organizacin para
cumplir los objetivos, las limitaciones y el entorno
del proyecto. La reingeniera es importante para
analizar los procesos internos basados en el negocio
tomando buenas prcticas de las herramientas que
provee el ERP y adaptndose a ellas. (Se debe tener
en cuenta que para aplicar esta herramienta, la
organizacin requiere un nivel 3 de madurez del
estndar CMMI)
E. Testing
i. Problemtica
a. Un equipo de desarrollo debe evitar tratar de probar
sus propios programas. El razonamiento es que los
integrantes del equipo responsable del desarrollo de
uno o varios programas, tienen la dificultad de
realizar una prueba objetiva de sus propios
programas. La organizacin de la tarea del testing,
debe llevarse a cabo por personas que no pertenezcan
al proyecto. De hecho, es deseable que el equipo de
testing no sea una tarea realizada dentro de la misma
compaa, ya que si lo fuera, seguira siendo
influenciado por las mismas presiones de los altos
mandos del la compaa, que influyen en la
organizacin responsable del equipo de desarrollo.
ii. Solucin
Una forma de evitar este conflicto es contratar a una
empresa independiente especializada en pruebas de
software. Como ventaja obtendremos por lo general,
una mayor motivacin en el proceso de pruebas, una
tarea menos para el equipo de desarrollo, la
eliminacin del proceso de pruebas bajo la misma
gestin que el equipo de desarrollo, y las ventajas de
los conocimientos especializados que la empresa de
pruebas independiente proveer para abordar el
problema. No obstante, existen factores
fundamentales a tener en cuenta al momento de
tercerizar el proceso de Testing:
El testing tiene su ciclo propio, que comienza con
la fase de requerimientos del software y desde all
va en paralelo con el proceso de desarrollo de
4
4
software; para cada fase del proceso de desarrollo
existe una tarea de testing importante.
La mayor parte de los defectos se concentran en
las etapas tempranas del proceso de desarrollo, y
el costo de correccin aumenta a medida que
permanece no detectado.
Prevencin de la migracin de los defectos
utilizando tcnicas de prueba temprana en el ciclo
de vida, ms de la mitad de los defectos se
introducen usualmente en la fase de
requerimientos, y el costo de los defectos se
minimiza si se detectan en la misma fase en que
son introducidos; inspecciones y revisiones
peridicas constituyen una herramienta efectiva y
rentable.
Buenas especificaciones, revisiones e
inspecciones afectan positivamente la calidad de
las pruebas; su mejoramiento no es
conceptualmente difcil, pero requiere esfuerzo y
tiempo, por lo que se requiere una responsabilidad
clara que planifique y gestione el avance.
El Testing es una disciplina profesional que
requiere gente entrenada y competente para tener
xito se requiere de profesionales competentes y
entrenados con el apoyo adecuado de la
administracin superior; no debe ser tratado como
un nivel de entrada o trampoln; debe ser
independiente, imparcial, y organizado para que
cuente con el reconocimiento justo de su
contribucin a la calidad del producto.
Todas las pruebas deben ser trazables a
requerimientos del usuario. Sin especificaciones
de requerimientos adecuadas, este proceso no ver
otra cosa que no sea el fracaso.
V. CONCLUSIN
Teniendo en cuenta toda la informacin obtenida y siguiendo
las buenas prcticas de ingeniera de software, se plante una
estrategia de solucin basada en este conocimiento. Como
resultado vemos importante a este tipo de proyecto usar
Coaching, Ingeniera de Requerimiento, Administracin del
Conocimiento y buenas prcticas para el Testing.
Las metodologas deben ser Flexibles y Adaptables. Si de
antemano se sabe que el camino no es bueno, debe adoptar
una metodologa con ciertas caractersticas que a priori
indiquen el camino correcto, luego comenzar, avanzar, y
evaluar. Si en el camino nos encontramos algn problema,
habr que adaptarse o adoptar un nuevo camino hasta
encontrar el indicado.
VI. LINEA FUTURA DE INVESTIGACION
 5
Mejorar la etapa de diseo y desarrollo basndose en las
buenas prcticas expuestas.

5
 6
VII. ANEXO I I. REFERENCIAS

Cuestionario de Entrevista [1] Curso de Coaching y liderazgo. PROGRAMA DE DESARROLLO DE

HABILIDADES PARA EL LIDER-COACH. FLORENCIA
ANNACONDIA, NORA PATLIS, NICOLS RODRGUEZ ALVAREZ -
1. Cul es el problema a resolver? UTN - Extensin Universitaria 2007

[2] Loucopoulos, P., Karakostas, V.,System Requirements Engineering,

McGraw-Hill, 1995, London.Nuseibeh; B., Easterbrook, S.,
Requirements Engineering: A Roadmap, ICSE2000, Limerick

[3] Material de clase materia Sistemas de Informacin Avanzada

UP Universidad de Palermo Martn Piattini Velthuis 2006-2012
2. Cules son las caractersticas del sistema que se [4] Aproximacin a una taxonoma de modelos de gestin del conocimiento -
utiliza para resolver el problema? Alejandro Barragn Ocaa
Universidad Nacional Autnoma de Mxico UNAM (Mxico)

[5] http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos

[6] http://es.wikipedia.org/wiki/Planificaci
%C3%B3n_de_recursos_empresariales

[7] Introduccin a los Sistemas de Informacin - Material de estudio Mdulo

3. Cules son las entradas? 1 -Instituto Superior de Formacin Tcnica N 38 - Tecnicatura Superior
en Anlisis de Sistemas.
www.cgoni.com.ar/webinst/isi/modulo1.doc

[8] Material de clase - Ingeniera de Software Avanzada - Universidad

Tcnica Federico Santa Mara Chile.
http://www.inf.utfsm.cl/~visconti/inf323/Documentos/CursoTestingEcono
.pdf
4. Cules son las salidas?
[9] http://www.monografias.com/trabajos41/requisitos-software/requisitos-
software2.shtml

II. CV

Juan Pablo Sadoly (Capital Federal,

5. Cules son las restricciones?
Argentina, 3 de Febrero de 1984) Analista
de Sistemas de Informacin recibido en el
Instituto Bernardo Houssay en Diciembre
2004. Actividad Laboral: Consultor
Analista SAP en Atos S.A. He ingresado en
la empresa en el ao 2010 y he pasado por
las tareas de Programacin, Anlisis
Funcional, Anlisis Tcnico y Testing.
6. Quines utilizarn el sistema? Mencione las reas
intervinientes en este proceso.