Método Básico de Desarrollo de Software

TECNOLÓGICO NACIONAL DE MÉXICO
Instituto Tecnológico de La Paz
“2015, Año del Generalísimo José María Morelos y Pavón”
INSTITUTO TECNOLÓGICO DE LA PAZ

DIVISIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN
MAESTRÍA EN SISTEMAS COMPUTACIONALES
TESIS
Método Básico de Desarrollo de Software (BADESO) aplicando

el modelo KUALI-BEH.
QUE PARA OBTENER EL GRADO DE

MAESTRA EN SISTEMAS COMPUTACIONALES
PRESENTA
Ana Luz Rodríguez Sarabia
DIRECTOR DE TESIS:
M.C. María Guadalupe Elena Ibargüengoitia González
M.A.T.I. Luis Armando Cárdenas Florido
La Paz, Baja California Sur, junio del 2015

Dedicatoria
A Dios, por todo lo que me ha dado.
A mi amada madre, mejor…imposible;
A mis adorados hijos, el motor de mi vida;
A mí querido hermano Carlos, no tengo palabras para describir todo lo bueno
que significa para mí.

Agradecimientos
A mi querida directora Lupita Ibargüengoitia, por su infinita paciencia, apoyo,

conocimientos y comprensión esta meta no sería posible. Gracias por tan grande
honor.
A mi querido amigo Mario Ayala, por su amistad y sus sabias palabras. Gracias
Mario.
A mi estimada Iliana Castro siempre dispuesta a mostrarme el camino donde sea

que este. Gracias Ili.
A Armando Cárdenas por ser mi director de tesis y por las oportunidades de

crecimiento, aprendizaje y experiencia que me ha brindado, por creer en mí.
Gracias mi estimado Armando.
A todas las personas que me permitieron el honor de ser su profesora y asesora

de residencias profesionales en su momento, porque esta tesis es la suma de
dichas experiencias. Gracias queridos muchachos.
A todas las personas que en el largo transitar del camino a la meta me brindaron
su apoyo, paciencia y consejo, infinitas GRACIAS.
Resumen
Los sistemas de información automatizados forman parte de las actividades

diarias de las personas; están por todos lados: supermercado, banco, trabajo,
médico, gasolineras, etc. Manejan nuestro dinero, salud, decisiones; en
resumen: nuestra vida. Su importancia radica precisamente en la información
que manejan y que los errores que ésta tenga pudieran resultar en pérdidas
monetarias conocidas y tiempos sobrepasados, lo cual es lamentable cuando
ocurre. Sin embargo, es incalculable el valor de perder imagen por parte de una
compañía; pérdidas materiales y económicas intangibles, pero sobretodo, perder
la vida de personas a causa de errores de la información que arrojan los
sistemas.
Por eso es importante que los sistemas de información “no se equivoquen”, que
estén bien construidos, que sean robustos, confiables, íntegros, seguros,
mantenibles; que sean de calidad. Para desarrollar su cumplir con estos criterios
es necesario aplicar métodos y prácticas que nos guíen durante su construcción.
El objetivo de la presente tesis es proporcionar un método de desarrollo de

software formado por un conjunto de prácticas que sirvan de guía justamente
para ello. La forma de definirlas es a través de KUALI-BEH, que es un estándar
que forma parte de ESSENCE y que es el adecuado para este fin, ya que brinda
las plantillas necesarias para la definición de métodos y prácticas de desarrollo
de software que son eficientes y eficaces para una organización.
Para plantear el método objeto de esta tesis, en el capítulo uno se describe el

contexto de la organización. Esto con la intención de situar al lector en una
misma perspectiva: si se tiene un método de desarrollo de proyectos de software,
entonces los alumnos tendrán una guía para su residencia profesional junto con
su asesor interno para lograr un producto homogéneo y estandarizado.
En el segundo capítulo se habla de los fundamentos que sustentan esta tesis:

Ingeniería de Software y KUALI-BEH. Los conceptos que se manejan en
Ingeniería de software y en el modelo KUALI-BEH al ser identificados y definidos,
son los que nos permiten plantear el método y sus prácticas.
En el capítulo 3 el objetivo es mostrar precisamente cómo el método Básico de

Desarrollo de Software (BADESO) planteado y sus prácticas cumplen con el
modelo KUALI-BEH.
Una vez que BADESO está definido, en el cuarto capítulo se hace la

presentación de las prácticas que conforman el método.
En el capítulo cinco se mostró la aplicación del método en una residencia y sus

resultados.
El capítulo seis contiene la conclusión del trabajo y también gracias a la

aplicación del método, las fortalezas y debilidades del mismo. Ya para terminar,
en el capítulo hago una pequeña propuesta de lo que podría ser la siguiente
versión de BADESO.
Abstract
Automated information systems are part of the daily activities of people; they are
everywhere: supermarkets, banks, office, doctor’s office, gas stations, etc. These
systems control our money, health, decisions, in short: our life. Their importance
resides precisely in that the important information they use and the errors
contained in such information may result in enormous money losses and time
wasted, which when it occurs is regrettable. However, it is invaluable to get a bad
reputation as a company, to have material and economical losses, but above all,
to lose lives due to mistakes on the information provided by these information
systems.
That is why it is important that information systems do “not make mistakes”, that
they are properly developed, be robust, reliable, integral, safe, sustainable, in
other words: with Quality. In order to achieve that the information systems have
these levels of quality, it is necessary to apply methodologies and practices that
guide their development.
The objective of this thesis is to provide a software development methodology

made up by a set of practices that serve as a guide for the development of the
software. They are defined through KUALI-BEH, which is a standard part of the
ESSENCE and it is the appropriate method for this purpose, since it provides the
necessary templates for the definition of methods and practices for the
development of software that are efficient and effective for an organization.
In order to propose the methodology object of this thesis, the first chapter
describes the context of the organization. The intent is to position the reader on
the same perspective, if a software development methodology is used, the
students will have a guide for their professional residency together with their
thesis counselor in order to produce a homogeneous and standardized product.
The second chapter describes the foundation over which this thesis is built:
Software Engineering and KUALI-BEH. The basic concepts of software
engineering project management. It summarizes what KUALI-BEH is and what it
consists of. This chapter is the fundamental part of this thesis, and because of
that, it is important that the reader understands how the same concepts used in
software engineering are the fundament for the KUALI-BEH model; and these
concepts, once identified and defined, allow us to use the methodology and its
practices.
The objective of the third chapter is to show precisely how the methodology Basic
Software Development (BADESO) proposed and its practices comply with the
model KUALI-BEH, through which the practices and methods for software
development can be defined.
Once BADESO is defined, in the fourth chapter the practices that make up the
methodology are introduced, showing the contribution and importance of each of
these practices for the method and their interrelationship.
In the fifth chapter the application of the method on a residency project and the
results were shown
The sixth chapter contains the conclusion of the work performed and also, thanks
to the aplication of the method, the strengths and weaknesses of the method
identified. To conclude the chapter, a proposal is made of what the next version
of BADESO could be.
CONTENIDO
CONTENIDO .................................................................................................... 7
TABLA DE ILUSTRACIONES ......................................................................... 10
CAPÍTULO 1 PLANTEAMIENTO DEL PROBLEMA ......................................... 12
INTRODUCCIÓN .................................................................................................. 12
ANTECEDENTES ................................................................................................ 12
DESCRIPCIÓN DEL PROBLEMA ............................................................................. 13
OBJETIVO GENERAL .......................................................................................... 19
OBJETIVOS ESPECÍFICOS.................................................................................... 19
HIPÓTESIS ........................................................................................................ 19
BENEFICIOS Y ALCANCES ................................................................................... 19
CAPÍTULO 2 INGENIERÍA DE SOFTWARE Y KUALI-BEH ............................. 21
INTRODUCCIÓN .................................................................................................. 21
INGENIERÍA DE SOFTWARE ................................................................................. 22
Conceptos principales de la Ingeniería de Software ................................... 24
Conceptos principales de la Administración del desarrollo de software ...... 26
Actividades de desarrollo de Ingeniería de Software .................................. 27
Modelo de desarrollo ................................................................................... 29
KUALI-BEH ..................................................................................................... 29
Conceptos comunes en proyectos de software ........................................... 31
Infraestructura de métodos y prácticas (MPI) .............................................. 33
Plantillas de KUALI-BEH ............................................................................. 33
CAPÍTULO 3 MÉTODO BÁSICO DE DESARROLLO DE SOFTWARE

(BADESO). ......................................................................................................... 38
INTRODUCCIÓN .................................................................................................. 38
CARACTERÍSTICAS DEL MÉTODO BADESO.......................................................... 39
pág. 7
KUALI-BEH CONCEPTOS COMUNES EN LOS PROYECTOS DE SOFTWARE Y BADESO
........................................................................................................................ 39
MÉTODO BADESO DEFINIDO EN LA PLANTILLA DE KUALI-BEH ............................ 42
BADESO COHERENTE, CONSISTENTE Y COMPLETO. ............................................ 43
Coherencia .................................................................................................. 45
Consistencia ................................................................................................ 62
Completo ..................................................................................................... 72
CAPÍTULO 4 PRÁCTICAS DEL MÉTODO BÁSICO DE DESARROLLO DE

SOFTWARE (BADESO). ................................................................................... 76
INTRODUCCIÓN .................................................................................................. 76
PRÁCTICAS DE BADESO ................................................................................... 76
PRÁCTICAS ADMINISTRATIVAS DE BADESO ........................................................ 77
Determinar el alcance del sistema (PA1). ................................................... 77
Definir el plan del proyecto (PA2). ............................................................... 81
Obtener aprobación de avance por el cliente (PA5). ................................... 85
Dar a conocer el manejo de estándares para el proyecto (PA6). ................ 88
PRÁCTICAS DE EQUIPO DE BADESO .................................................................. 93
Definir mecanismos de comunicación del equipo (PE4).............................. 96
Manejar cambios en el proyecto (PA7). .................................................... 100
PRÁCTICAS DE DESARROLLO DE BADESO ........................................................ 102
Modelar el negocio (PD8). ......................................................................... 103
Obtener requisitos del sistema (PD9). ....................................................... 105
Realizar el análisis del sistema (PD10). .................................................... 108
Diseñar el sistema (PD11)......................................................................... 110
Construir el sistema (PD12). ..................................................................... 114
Probar el Sistema (PD13).......................................................................... 117
Implantar el sistema (PD14). ..................................................................... 121
CAPÍTULO 5 APLICACIÓN DEL MÉTODO BADESO. ................................... 125
pág. 8
INTRODUCCIÓN ................................................................................................ 125
DATOS DE LA EMPRESA .................................................................................... 125
ACTIVIDADES Y EXPERIENCIAS DURANTE LA RESIDENCIA PROFESIONAL APLICANDO
BADESO ....................................................................................................... 127
Determinar el alcance del sistema (PA1). ................................................. 127
Dar a conocer el manejo de estándares para el proyecto (PA6). .............. 129
Obtener aprobación del cliente (PA5). ...................................................... 131
Organizar el equipo (PE3). ........................................................................ 132
Definir mecanismos de comunicación del equipo (PE4)............................ 133
Manejar cambios en el proyecto (PA7). .................................................... 134
Plan del proyecto (PA2)............................................................................. 135
Modelar el negocio (PD8). ......................................................................... 136
Obtener requisitos del sistema (PD9) ........................................................ 137
Realizar el análisis del sistema (PD10). .................................................... 138
Diseñar el sistema (PD11)......................................................................... 139
Construir el sistema (PD12). ..................................................................... 141
Probar el sistema (PD13). ......................................................................... 142
Implantar el sistema (PD14). ..................................................................... 144
Conclusión de la aplicación de BADESO .................................................. 145
CAPÍTULO 6 CONCLUSIONES ...................................................................... 151
Trabajos futuros ........................................................................................ 153

BIBLIOGRAFÍA .................................................................................................. 155
pág. 9
TABLA DE ILUSTRACIONES
Ilustración 1 Estructura global del modelo KUALI-BEH ...................................... 30
Ilustración 2 Plantilla de proyecto de software. .................................................. 34
Ilustración 3 Plantilla para método...................................................................... 35
Ilustración 4 Plantilla para práctica. .................................................................... 36
Ilustración 5 Conceptos comunes de KUALI-BEH .............................................. 40
Ilustración 6 Método BADESO definido en KUALI-BEH ..................................... 43
Ilustración 7 Método Básico de Desarrollo de Software (BADESO). ................. 44
Ilustración 8 Conjunto coherente de prácticas en KUALI-BEH. .......................... 45
Ilustración 9 Modelar el negocio (PD8) ............................................................... 48
Ilustración 10 Obtener requisitos del sistema (PD9) y Realizar el análisis del

sistema (PD10). .................................................................................................. 49
Ilustración 11 Diseñar el sistema (PD11). .......................................................... 51
Ilustración 12 Construir el sistema (PD12). ........................................................ 52
Ilustración 13 Probar el sistema (PD13). ............................................................ 53
Ilustración 14 Implantar el sistema (PD14). ........................................................ 54
Ilustración 15 Práctica Obtener aprobación de avance por el cliente (PA5) y su

aplicación en las diferentes prácticas a través del método ................................. 56
Ilustración 16 Práctica Dar a conocer el manejo de estándares para el proyecto

(PA6) y su efecto en el resto de las prácticas. ................................................... 57
Ilustración 17 Aplicación de Manejar cambios en el proyecto (PA7). ................. 58
Ilustración 18 Práctica Definir los mecanismos de comunicación del equipo (PE4)

como parte de los procesos de apoyo. ............................................................... 60
pág. 10
Ilustración 19 Prácticas Determinar el alcance del sistema (PA1), Definir el plan
del proyecto (PA2) y Organizar el equipo (PE3) de los procesos organizativos.
........................................................................................................................... 61
Ilustración 20 Conjunto consistente de las prácticas de un método. .................. 62
Ilustración 21 Entradas y Salidas del método BADESO. .................................... 64
Ilustración 22 Entradas a la primera práctica del método. .................................. 65
Ilustración 23 Resultados de la última práctica del método, Implantar el sistema

(PD14). ............................................................................................................... 66
Ilustración 24 De Determinar el alcance del sistema (PA1) Definir el alcance de

sistema a Definir el plan del proyecto (PA2) Definir el plan de proyecto. ........... 69
Ilustración 25 De Dar a conocer el manejo de estándares para el proyecto (PA6)

a Definir el plan de proyecto (PA2). .................................................................... 70
Ilustración 26 De Definir el plan del proyecto (PA2) hasta Obtener requisitos del
sistema (PD9) y Realizar el análisis del sistema (PD10). ................................... 71
Ilustración 27 De Obtener requisitos del sistema (PD9) y Realizar el análisis del

sistema (PD10) hasta Construir el sistema (PD12). ......................................... 73
Ilustración 28 De Construir el sistema (PD12) hasta obtener los resultados del

método. .............................................................................................................. 74
Ilustración 29 Conjunto completo de prácticas. .................................................. 75
pág. 11
Capítulo 1 Planteamiento del
problema
“Los problemas... son diferentes para cada uno, y cada uno

tiene necesidad de un medio diferente para resolver sus
problemas. Por consiguiente tenemos que crear nuestro propio
método. Si se imita, se cae en el error. Hay que crear por sí
mismo.” Taisen Deshimaru
Introducción
La producción de software se ha incrementado notablemente en los últimos
tiempos y de forma directamente proporcional, su complejidad y diversidad de
aplicaciones. Construir software con calidad es de vital importancia; más que por
el retraso en la entrega o la elevación de costos planeados, porque puede influir
en decisiones de vida o muerte. Por lo cual, para lograr un software con calidad
en tiempo y dentro del presupuesto, es necesario un enfoque organizado.
Antecedentes
Cuando se habla de desarrollo de proyectos de software es imposible no citar la
crisis del software con el bajo número de proyectos exitosos, presupuestos
sobrepasados, requerimientos ignorados y demanda creciente de software, que
más que una crisis dio origen a una aflicción.
pág. 12
Capítulo 1 Planteamiento del problema
“Utilizar mejores prácticas en los procesos de una organización, es un elemento

fundamental para mejorar la calidad y productividad de sus productos y servicios”
(iCenter, 2004) (Beynon, 2007). Identificar las mejores prácticas de desarrollo de
proyectos de software dentro de una organización es un factor decisivo para
eliminar los problemas de la crisis del software, a su vez que permiten aumentar
la satisfacción del cliente, del desarrollador y eliminar los proyectos fallidos.
Descripción del problema

Los proyectos de desarrollo de software como parte de las Residencias
Profesionales también exigen una administración como cualquier proyecto, así
como todos los elementos involucrados en ella. El punto es que ningún proyecto
de software es perfecto ni genérico, y es que entre otras causas, son
abstracciones idealizadas que cuentan con puntos de vista diferentes. Cada
empresa u organización que desarrolla software va acumulando con el tiempo y
la experiencia una serie de prácticas organizadas en métodos que les resultan
efectivos. Pero si son informales y no están documentados la definición de
prácticas y métodos, difícilmente se obtienen como resultados productos
homogéneos, y esto da lugar a problemas como los que describo a continuación,
particularmente en los proyectos de Residencias Profesionales del Instituto
Tecnológico de La Paz.
Los Proyectos de Residencias Profesionales involucran a los residentes, a los

profesores del Departamento de Sistemas y Computación en su papel de
asesores internos, y a los clientes en su papel de cliente y de asesor externo. En
el desarrollo de un proyecto de software se pueden presentar problemas
diferentes como un software incompleto y desfasado de tiempo, por lo tanto, sin
la calidad propuesta.
pág. 13
Los Proyectos de Residencias Profesionales se realizan en un tiempo mínimo de

16 semanas y un tiempo máximo de 25 semanas. Pueden realizarse de forma
individual o en equipo.
Cuando el alumno requiere realizar la Residencia Profesional, debe solicitarla a

través de la Coordinación de la Carrera de Ingeniería en Sistemas
Computacionales.
Una vez que el alumno tiene su Anteproyecto de Residencias Profesionales, la

coordinación lo envía al Departamento de Sistemas y Computación para que se
asigne un revisor del Anteproyecto de Residencias Profesionales. El revisor debe
determinar si el proyecto es factible como Proyecto de Residencia Profesional.
Una vez que se acredita el Anteproyecto de Residencias Profesionales, el

Departamento de Sistemas y Computación asigna un asesor interno (del propio
departamento o de la División de Estudios de Posgrado e Investigación). Por su
parte, la empresa nombra un asesor externo.
Entre los problemas a los que se enfrenta un residente en la Residencia

Profesional con las metodologías de desarrollo actuales, se encuentran los
siguientes:
 Anteproyecto de Residencias Profesionales mal definido. Si en el
Anteproyecto de Residencias Profesionales los requisitos específicos

están pobremente definidos y no enfocados en la funcionalidad, se
considera que el objetivo general del sistema es ambiguo y confuso.
Cuando se enfrentan a la residencia con un sistema más grande o más
complejo de lo que esperaban, o por el contrario, con un sistema tan
sencillo que no se justifica como Proyecto de Residencia Profesional,
ambos casos suponen un problema.
 El producto no se alcanza a terminar en el tiempo planeado. El proyecto
debe terminar en el número de semanas especificado (16 a 25 semanas),
pág. 14
ya que de no ser así, el residente tiene que pedir prórroga si especificó

menos de 25 semanas; teniendo como límite el máximo de semanas
permitidas (25). En otro caso, el residente puede reprobar la Residencia si
no acaba el proyecto en ese máximo de semanas permitidas o si no se
cumplen los objetivos planteados. En estos casos a veces se llega a un
acuerdo de palabra con el cliente de que el residente seguirá a cargo del
proyecto hasta que se termine, aunque ya haya acabado el periodo de
Residencias Profesionales.
 Alcance mal definido y evolutivo. Lo que dificulta determinar la
complejidad del producto a desarrollar y puede generar requisitos confusos
e incompletos.
 Clientes con expectativas crecientes. Esto afecta el tiempo disponible
para el proyecto.
 Disponibilidad de recursos para implantar el sistema. Si no se tienen
los requerimientos de implantación del sistema a tiempo, puede retrasar la
implantación del sistema y, a su vez, la finalización de la Residencia. En
ocasiones, el cliente no realiza la compra y no es posible hacer la
implantación del sistema por lo que este sencillamente nunca se usa.
 Mala administración del proyecto. La mala gestión del tiempo y de
actividades en el proyecto genera retrasos.
 Falta de disponibilidad de los involucrados en el proyecto. Si los
involucrados son personas muy ocupadas, lo cual ocurre a menudo, y no
se tiene un plan de revisiones y reuniones, se genera una mala
comunicación que lleva a riesgos de retrasos y requerimientos mal
definidos.
 Reporte de Residencias Profesionales pobremente documentados. La
memoria de Residencias Profesionales es una opción para que los
egresados de licenciatura puedan obtener su título (ITLP I. T., 2014).
Cuando los residentes egresan, tienen como opción de titulación el reporte
pág. 15
de su Residencia Profesional. Como parte de este proceso de titulación, se

asignan dos revisores del Reporte de Residencias Profesionales, además
del asesor interno; en total, tres revisores. Sin un marco común de
desarrollo es muy difícil homogenizar criterios para dicha evaluación.
Además, es posible encontrar que para unos trabajos de Residencias
Profesionales se les exige más puntos a cubrir que para otros.
La obligación de cumplir con otros puntos retrasa el tiempo de entrega del

Reporte de Residencias Profesionales y por lo tanto la liberación de las
Residencias Profesionales. Esto puede tener una de las siguientes
consecuencias: impedir al egresado salir titulado para la ceremonia de
graduación, retrasar su titulación y en el peor de los casos que el egresado
se vea forzado a optar por otra forma de titulación.
Para los revisores, en algunos casos se pueden generar reportes más completos
que otros, lo que implica una inversión adicional de tiempo y esfuerzo en aquellos
proyectos que carecen de la documentación apropiada.
 Productos con características de calidad distintas. Los distintos

asesores internos trabajan en diferentes especialidades de sistemas
computacionales. Por lo tanto, los métodos y prácticas aplicadas en los
procesos de desarrollo suelen variar, lo que genera productos no
homogéneos.
 Poco soporte para la administración de proyectos. Los asesores
internos suelen encontrarse con los siguientes problemas al administrar un
proyecto de software: mala comunicación con el cliente, criterios de éxito
inapropiados, ausencia de métricas, uso de estándares casi nulo, falta de
capacitación adecuada para el manejo de proyectos de software y dificultad
para medir el avance real del proyecto y de los estudiantes. Lo anterior da
como resultado que los productos que se obtienen dependan del gusto del
asesor y de la capacidad de los residentes.
pág. 16
 Retraso en el reporte de actividades por parte del asesor interno. Por

otro lado, el asesor interno debe entregar un reporte y asignar las
calificaciones de los residentes al finalizar una Residencia. Para esto, él
también cuenta con fechas definidas. Del buen cumplimiento de las
actividades de Residencias Profesionales por parte del asesor interno,
depende tanto la entrega de su liberación de actividades de Residencia
Profesional, como la evaluación en la misma.
El cliente es el principal afectado cuando no se tiene un método de desarrollo bien

definido, ya que se tiene el riesgo de un proyecto que no se ajuste al tiempo, que
se obtenga un producto sin terminar, sin probar, sin implantar o que no sea lo que
él requirió.
Al cliente se le pueden presentar cualquiera de las siguientes situaciones al

término de las Residencias Profesionales: proyectos con calidad cuestionable;
insatisfacción con el producto porque no satisface sus necesidades; software sin
implantar por falta de gestión de requerimientos de hardware y software; usuarios
sin capacitación porque se acabó el periodo de Residencias Profesionales; falta
de manuales del sistema porque no se especificaron como parte de la entrega. Lo
anterior trae como consecuencia que en ocasiones el software ni siquiera se
utilice.
Para nuestra institución las Residencias Profesionales son una carta de

presentación de nuestros residentes próximos a egresar. Si los proyectos no se
terminan satisfactoriamente, la imagen de nuestros egresados, de nuestra carrera
y de la propia institución se ve afectada.
La problemática anteriormente descrita es una constante en el desarrollo de

proyectos de software. Las propias características del software, su complejidad,
su invisibilidad, la maleabilidad y el manejo de la conformidad lo hacen caótico; lo
pág. 17
que contribuye a que su construcción sea diferente al desarrollo de productos en

cualquier otra ingeniería.
En el artículo “No Silver Bullet” (Brooks F. , 2014), se hace una importante

referencia sobre la naturaleza del software y plantea los grandes problemas que
presentaba el desarrollo de software en 1987. Los problemas a los que hace
referencia Brooks hace más de 20 años y los que se mencionan en este
documento son iguales, y se originan en gran parte por las propias características
del software.
Aunque se han desarrollado diversos enfoques para construir software, sigue

siendo desafiante fabricarlo, y aún se mantiene lo que comentó en su artículo 1 “No
0F
existe ningún desarrollo, ya sea en tecnología como en administración, que por sí

solo prometa siquiera una mejora de un orden de magnitud en la próxima década
en lo referido a productividad, confiabilidad, simplicidad” (Brooks F. , 2014).
Se ha avanzado mucho en la Ingeniería de Software, pero es una disciplina en

donde el proceso de maduración se ha tardado un poco más que en otras
especialidades. Por eso es necesario tener un proceso disciplinado, definido y
predecible que funja de guía en las actividades de desarrollo.
Los asesores y los residentes, como cualquier empresa que desarrolla software,
con el tiempo han aplicado distintos enfoques de desarrollo y se han adquirido
experiencia en prácticas que históricamente han alcanzado mejores resultados;
mismas que por lo mismo se han adoptado como parte de los métodos de trabajo.
Sin embargo, no están documentadas. Para documentar dicho proceso se
propone usar el modelo KUALI-BEH. De esta forma se tendría una guía
documentada para todos los residentes.
1 No silver bullet
pág. 18
Objetivo General
Definir un método y sus prácticas para las Residencias Profesionales permitirá la
realización de proyectos homogéneos sin importar quién sea el asesor.
Objetivos específicos
 Identificar y definir las prácticas aplicadas para el desarrollo de proyectos
de software en Residencias Profesionales; es decir, un proceso definido y
predecible que provea una adecuada visibilidad a los residentes.
 Definir el método conformado con el conjunto de prácticas.
 Especificar el método y sus respectivas prácticas a través del modelo
KUALI-BEH.
 Tener un marco común para proyectos de desarrollo de software.
Hipótesis
Es posible especificar un método y sus prácticas para el desarrollo de proyectos
de software de las Residencias Profesionales con KUALI-BEH; que pueda
aplicarse a cualquier proyecto de software, sin importar su tamaño, su
complejidad, el número de integrantes en el equipo de trabajo y el ciclo de vida.
La aplicación del método definido a través de KUALI-BEH permitirá a los alumnos

tener una guía para realizar productos de software en las Residencias
Profesionales con la calidad deseada y en el tiempo previsto.
Beneficios y alcances
 Para los asesores internos que tienen especialidades diferentes a desarrollo
de proyectos de software será más fácil administrar proyectos de Residencias
Profesionales de Software, porque se tendría una guía de la cual partir.
 Al asesor interno se le facilitará la entrega de reportes de avance de
Residencias Profesionales del asesor interno.
pág. 19
 Para el asesor interno será más fácil la evaluación de la Residencia

Profesional.
 El cliente es el principal beneficiado con un método bien definido, ya que se
obtendría un proyecto ajustado a las circunstancias de tiempo y ejecución de
las Residencias Profesionales. Obtendría un producto terminado, probado,
puesto en marcha y que satisfaga los requisitos que él definió.
 El residente próximo a egresar acabaría en tiempo y forma sus Residencias
Profesionales sin necesidad de prórrogas ni la reprobación de las mismas.
 Tener el método documentado para desarrollar proyectos de software le
servirá de guía al residente para el desarrollo de la Residencia Profesional,
optimizando los recursos y tiempo invertido para ello.
 El egresado que opte por obtener su título a través del trabajo de Residencias
Profesionales se enfrentaría a un proceso de revisión con un mínimo de
observaciones y en un corto periodo de tiempo.
 Los trabajos de Residencias Profesionales para titulación cumplirían con
procesos de desarrollo y los productos obtenidos tendrían características
similares.
 El realizar proyectos de calidad de software redunda en beneficios para
nuestra escuela, para seguir manteniendo nuestra imagen de institución de
calidad; y para el área de Sistemas y Computación. Ya que los productos de
los proyectos de software son una carta de presentación y de recomendación.
pág. 20
Capítulo 2 Ingeniería de Software y
KUALI-BEH
“Los que se enamoran de la práctica sin la teoría son como los
pilotos sin timón ni brújula, que nunca podrán saber a dónde
van.” Leonardo Da Vinci.
Introducción
Un proyecto es un esfuerzo que se lleva a cabo para crear un producto, servicio
o resultado único, tiene la característica de ser naturalmente temporal, es decir,
que tiene un inicio y un final establecidos, y que al final se alcanza cuando se
logran los objetivos del proyecto o cuando se termina el proyecto porque los
objetivos no se cumplieron o no pueden ser cumplidos o cuando ya no existe la
necesidad que dio origen al proyecto (PMBOK, 2015). Sin embargo, al ejecutarlo
es posible aplicar técnicas y métodos comunes.
Cuando se habla de proyectos informáticos ocurre lo mismo. A pesar de la

naturaleza del software, de los riesgos de obsolescencia de la tecnología y de la
fuerte participación del recurso humano, es posible definir prácticas comunes para
su desarrollo. Las actividades del ciclo de vida de un proyecto informático lo
conforman dos actividades:
 Gestión; relacionadas con la administración de las organizaciones,

personas, sistemas y procedimientos;
 Desarrollo; que son actividades del propio desarrollo, desde el análisis del
negocio hasta el mantenimiento del sistema.
pág. 21
Capítulo 2 Ingeniería de Software y KUALI-BEH
Con el objetivo de ser más competitivas, las organizaciones de software buscan

implantar la construcción disciplinada de los proyectos. Sin embargo, una de las
dificultades que enfrentan es la gran cantidad de conceptos que se manejan en la
elaboración de un proyecto de software, y además que hay un gran número de
buenas propuestas que desafortunadamente no garantizan su funcionamiento
para las necesidades particulares de su organización.
Aprender sobre la Ingeniería de Software y los principales elementos de desarrollo

de proyectos de software permite descubrir las mejores prácticas para construir
software como parte de los proyectos de Residencias Profesionales, además de
conocer la forma de documentarlos de tal manera que sirvan de guía a los
residentes. Sin embargo, identificar las mejores prácticas es insuficiente, lo
realmente importante es que, una vez que se establecen, se disponga de un
repositorio estandarizado mediante el cual se definan las prácticas y su
interrelación, para poder conformar un método, que es el aquel que funciona en
la organización; esto es lo que KUALI-BEH proporciona, un modelo para definir
prácticas y métodos de desarrollo de proyectos de software.
Para esta tesis documentaremos las prácticas y el método para las Residencias
Profesionales a través de KUALI-BEH.
Ingeniería de Software
La Ingeniería de Software es una disciplina que tiene como meta el desarrollo de
sistemas de software con calidad, a tiempo y costeable. Desde 1968 se ha
procurado el desarrollo de software dentro del marco de esta disciplina. A
continuación cito una definición de Ingeniería de Software “La Ingeniería de
Software es una disciplina de la ingeniería que comprende todos los aspectos de
la producción de software desde las etapas iniciales de la especificación del
sistema hasta el mantenimiento de éste después de que se utiliza” (Sommerville,
2005).
pág. 22
El autor destaca dos aspectos claves dentro de la definición. El primero, que los
ingenieros hacen que las cosas funcionen aunque no existan teorías y métodos
explícitos para resolver los problemas que se les presenten. El segundo aspecto
que enfatiza dentro de la definición es el hecho de que construir software abarca
más que el proceso técnico; implica administración del proceso de desarrollo,
gestión de proyectos y otras actividades de apoyo para la producción del software.
El autor concluye la definición de la siguiente manera: “…los ingenieros de

software adoptan un enfoque sistemático y organizado en su trabajo, ya que es la
forma más efectiva de producir software de alta calidad. Sin embargo, aunque la
ingeniería consiste en seleccionar el método más apropiado para un conjunto de
circunstancias, un enfoque más informal y creativo de desarrollo podría ser
efectivo en algunas circunstancias” (Sommerville, 2005). Cada desarrollador,
grupo de desarrolladores o empresa, sin importar su tamaño, tiene su propio
“estilo”. El estilo lo definen las elecciones que se toman para lograr un efecto
deseado. Dentro del desarrollo de sistemas, el “estilo” lo forman el conjunto de
prácticas que dan como resultado un método que a una organización le “funciona”
para producir software. El “estilo” que es efectivo en sus propias “circunstancias”.
Hablar de Ingeniería de Software cobra sentido cuando se habla de desarrollar

proyectos de software. “Un proyecto es un conjunto organizado de actividades
compuestas por tareas que usan recursos ya sea participantes, equipo o tiempo,
y que tiene como objetivo la creación de un producto de trabajo que puede ser un
sistema, documento o un modelo” (Bruegge & Dutoit, 2002). El “estilo” es el
conjunto estructurado de actividades, tareas, recursos, notaciones y participantes
en el que se basa el desarrollo de los proyectos.
Realizar un proyecto de software incluye aplicar conceptos de Ingeniería de

Software, actividades de desarrollo de Ingeniería de Software y administración del
desarrollo de software (Bruegge & Dutoit, 2002).
pág. 23
Conceptos principales de la Ingeniería de Software
Los conceptos principales de la Ingeniería de Software según (Bruegge & Dutoit,

2002) son:
Participantes y papeles
“…personas con diferentes formaciones o intereses” (Bruegge & Dutoit, 2002).

Son todos los involucrados en el proyecto; personas que bien se benefician o en
todo caso salen perjudicados con el desarrollo del producto y que tienen definida
una función específica en dicho proceso.
Sistemas y modelos
“Usamos el término sistema para referirnos a la realidad subyacente, y el término

modelo para referirnos a cualquier abstracción de la realidad” (Bruegge & Dutoit,
2002). La instalación eléctrica de una casa es un sistema. El plano que sirve de
guía para realizar la instalación eléctrica es un modelo. Los modelos sirven como
borrador guía de lo que se va a construir.
Productos de trabajo
“Es un artefacto que se produce durante el desarrollo, como un documento o un

fragmento de software para los demás desarrolladores o para el cliente” (Bruegge
& Dutoit, 2002). Los artefactos resultantes de una etapa del desarrollo pueden
requerirse en otra etapa o pueden ser realizados para entregarse al cliente
durante el proceso o al final del mismo; depende como se hayan calendarizado al
iniciar el proyecto.
Actividad
“Conjunto de tareas que se realiza con un propósito específico…a las actividades

a veces también se les llama fases” (Bruegge & Dutoit, 2002). Por ejemplo, el
definir requisitos es una actividad que se realiza para establecer las funciones que
pág. 24
debe tener el sistema. Una actividad usa productos de trabajo de actividades

anteriores y genera otros productos de trabajo que pueden o no ser usados por
actividades o fases posteriores.
Tarea
“Representa una unidad atómica de trabajo que puede ser administrada” (Bruegge
& Dutoit, 2002). Construir un componente del software es una tarea que realiza un
desarrollador y que es asignada por el desarrollador líder. Las tareas usan
recursos para procesar las entradas (que pueden ser artefactos resultantes de
otras actividades o fases) y producir artefactos.
Recursos
“Bienes que se usan para realizar el trabajo” (Bruegge & Dutoit, 2002). Los
recursos pueden ser materiales, humanos e incluso de software. Sin los recursos
no pueden llevarse a cabo las tareas y por lo tanto tampoco pueden producirse
artefactos.
Objetivo
“Es un principio de alto nivel que se usa para guiar el proyecto” (Bruegge
& Dutoit, 2002).
Requerimientos
“Son características que debe tener el sistema. Un requerimiento funcional es un

área funcional que debe soportar el sistema y, en cambio, un requerimiento no
funcional es una restricción sobre la operación del sistema” (Bruegge & Dutoit,
2002).
Notación
pág. 25
“Es un conjunto de reglas gráficas o textuales para representar un modelo”

(Bruegge & Dutoit, 2002). Es la nomenclatura formada por reglas, puntos y
símbolos particulares que se va a utilizar a lo largo del desarrollo del proyecto para
crear los modelos necesarios. En este trabajo se usa UML (lenguaje unificado de
modelado) y notación orientada a objetos (Booch, Rumbaugh, & Ivar, 1999).
Método
“Es una técnica repetible para la resolución de un problema específico” (Bruegge

& Dutoit, 2002). Por ejemplo, Definir la arquitectura del software es una técnica
efectiva en el Diseño del software.
Una metodología
“Es una colección de métodos para la resolución de una clase de problemas”

(Bruegge & Dutoit, 2002).
Conceptos principales de la Administración del desarrollo de software
La administración del desarrollo de software (Bruegge & Dutoit, 2002) incluye las
actividades que ayudan y sirven de apoyo para realizar el proyecto. El autor
menciona las siguientes:
Comunicación
“…actividad más crítica y la que consume más tiempo en la Ingeniería de

Software” (Bruegge & Dutoit, 2002). La comunicación entre los participantes
implica relaciones y actividades; relaciones interpersonales que no son lógicas ni
ilógicas, lo cual las hace complejas y con un alto grado de incertidumbre, que a su
vez las puede volver tóxicas hasta el punto de hacer fracasar el proyecto. Son
actividades que están relacionadas de forma lógica pero que al fin y al cabo
dependen de los participantes y de su “buena comunicación”.
pág. 26
Administración de la fundamentación
“… es la justificación de las decisiones” (Bruegge & Dutoit, 2002). Cuando se

necesita tomar una decisión deben conocerse las razones que respaldan la acción
a seguir.
Pruebas
“…durante las pruebas, los desarrolladores encuentran diferencias entre el

sistema y sus modelos ejecutando el sistema (o partes de él) con conjuntos de
datos de prueba” (Bruegge & Dutoit, 2002). El autor incluye las pruebas como una
actividad administrativa porque ayudan a determinar la calidad del sistema. En el
presente trabajo las pruebas se manejan como una actividad del desarrollo de la
Ingeniería de Software.
Administración de la configuración del software
“…es el proceso que supervisa y controla los cambios en los productos de trabajo”
(Bruegge & Dutoit, 2002). Esta actividad busca prevenir problemas en el sistema
y en su desarrollo.
Administración del proyecto
“…incluye las actividades de vigilancia que aseguran la entrega de un sistema de

alta calidad a tiempo y dentro del presupuesto” (Bruegge & Dutoit, 2002).
Actividades de desarrollo de Ingeniería de Software
Las actividades de desarrollo de Ingeniería de Software son las actividades

técnicas del desarrollo. De acuerdo a (Bruegge & Dutoit, 2002) son las siguientes:
Obtención de requerimientos
pág. 27
“…el cliente y los desarrolladores definen el propósito del sistema” (Bruegge &
Dutoit, 2002). En esta actividad se describen los requerimientos del sistema y se
modelan.
Análisis
“…los desarrolladores tratan de producir un modelo del sistema que sea correcto,
consistente, claro, realista y verificable” (Bruegge & Dutoit, 2002). El modelo del
análisis dice qué se va a construir.
Diseño del sistema
“Los desarrolladores definen los objetivos del diseño del proyecto y descomponen
el sistema en subsistemas más pequeños que pueden realizar los equipos
individuales” (Bruegge & Dutoit, 2002). El diseño del sistema describe cómo se
construirán los modelos del análisis.
Diseño de objetos1
“Los desarrolladores definen objetos personalizados para cubrir el hueco entre el

modelo de análisis y la plataforma de hardware y software definida durante el
diseño del sistema” (Bruegge & Dutoit, 2002).
Implementación
“… la actividad de implementación cubre el hueco ente el modelo de diseño de

objetos detallado y el conjunto completo de archivos de código fuente que pueden
ser compilados juntos” (Bruegge & Dutoit, 2002). La implementación del software
1 El diseño de objetos es una actividad que maneja el autor (Bruegge & Dutoit, 2002) que no
necesariamente se maneja de la misma forma en el presente trabajo. La mención se realiza porque
forma parte del conjunto de conceptos que él maneja dentro de las actividades de desarrollo de
Ingeniería de Software.
pág. 28
es la construcción del código a partir de los modelos obtenidos en las fases

anteriores.
Modelo de desarrollo
Para desarrollar un buen sistema, el ingeniero o el equipo debe tener una

estrategia de desarrollo de software que le ayude a seguir un camino para su tipo
de sistema en diferentes fases, que le ayudará a obtener resultados parciales
antes de entregar su producto final.
Por lo regular, un modelo de desarrollo o modelo de proceso (llamado así

comúnmente) tiene al menos 4 fases, las cuales son: la especificación, diseño e
implementación, validación y evolución del sistema (Sommerville, 2005).
Los conceptos de Ingeniería de Software, las actividades y la administración del

desarrollo de software que manejan los autores (Bruegge & Dutoit, 2002)
coinciden con los distintos especialistas de la disciplina de Ingeniería de Software
y es lo que se trata de mostrar precisamente al citarlo. Para esto, se decidió
basarse en particularmente un autor Bruegge & Dutoit.
Cada grupo de desarrolladores definen su “estilo” propio para construir software,

tal como se menciona en la cita de (Sommerville, 2005) “…los ingenieros de
software adoptan un enfoque sistemático y organizado en su trabajo, ya que es la
forma más efectiva de producir software de alta calidad”. Es importante
documentar que se tiene sin importar el tamaño de la organización; esto puede
hacerse a través del modelo KUALI-BEH.
KUALI-BEH
KUALI-BEH forma parte de la especificación formal ESSENCE versión 1.0.
[Morales M., O. H. (2012). KUALI-BEH Software Project Common Concepts.
Object Management Group. Retrieved from http://www.kuali-
kaans.mx/proyectos/kuali-beh]
pág. 29
KUALI-BEH es un modelo que permite registrar las prácticas y métodos que se

manejan en una organización para el desarrollo de software y lo hace a través de
los conceptos básicos que son comunes al desarrollar proyectos de software
dentro del marco de la Ingeniería de Software.
KUALI-BEH está compuesto por dos vistas: la estática que proporciona un marco
para la definición de métodos para desarrollar proyectos de software y la vista
operacional en la que se maneja su ejecución.
En la ilustración 1 (kaans, 2014) se muestra la estructura global del modelo

KUALI-BEH.
Ilustración 1 Estructura global del modelo KUALI-BEH
En la vista estática se manejan los conceptos que son comunes en el desarrollo

de proyectos de software. Las palabras destacadas en negritas son justamente
las usadas por KUALI-BEH en su modelo.
pág. 30
“Los proyectos de software son desarrollados por profesionales de la

Ingeniería de Software para construir productos de software que cumplan con
las características y necesidades de los clientes; a través de métodos
coherentes, consistentes y completos; que son aplicados por profesionales que
pueden usar herramientas, recolectar métricas y que requieren de
conocimientos y habilidades para realizar las tareas que conforman las
actividades que sirven de guía en las prácticas que pertenecen al método que
se sigue para transformar las entradas en resultados que cumplan con los
criterios de verificación; los resultados de las prácticas pueden ser a su vez
productos de trabajo que servirán de entrada a otras prácticas o bien el producto
de software que se tiene como objetivo desarrollar en el proyecto de software”2.
Conceptos comunes en proyectos de software
Los conceptos comunes de proyectos de software que maneja KUALI-BEH son:
Proyecto de software
Esfuerzo temporal emprendido por parte de un equipo de trabajo utilizando un

método, con el fin de desarrollar, mantener o integrar un producto de software, en
respuesta a las necesidades de las partes interesadas y en condiciones
particulares.
Los involucrados3, las necesidades de las partes interesadas y las condiciones del
proyecto, definen los objetivos a cumplir en el producto de software que va a ser
construido por el equipo de trabajo, mismo que es conformado por los
profesionales de la Ingeniería de Software.
2 Se destacan en negritas los conceptos comunes que maneja KUALI-BEH.

3 También conocidos como stakeholders.
pág. 31
Definición de método
Articulación de forma coherente, consistente y completa del conjunto de prácticas,

con el propósito específico de cumplir con las necesidades de las partes
interesadas bajo condiciones específicas.
Definición de práctica
Guía de trabajo con un objetivo específico, que aconseja cómo producir un

resultado que es originado a partir de una entrada.
Una práctica es una guía formada de actividades y tareas para procesar entradas
auxiliándose de herramientas, se requiere tener conocimientos y habilidades para
obtener resultados que cumplan con las condiciones acordadas.
Propiedades del método
El método y el conjunto de prácticas que lo conforman deben observar las

propiedades de coherencia, consistencia y completitud.
Entiéndase por coherencia, que el objetivo de cada práctica debe contribuir a

lograr el objetivo del método.
La consistencia implica que debe haber al menos una práctica cuya entrada sea
igual con la entrada del método y al menos una práctica cuyo resultado sea igual
al resultado del método; así como también la salida de una práctica debe ser igual
a la entrada de al menos otra práctica, y la entrada igual a la salida de otra
práctica.
El método se considera completo si se cumple la propiedad de consistencia y de

coherencia.
pág. 32
Infraestructura de métodos y prácticas (MPI)
La infraestructura de métodos y prácticas (MPI) es el conjunto de métodos y

prácticas aprendidas por los miembros de la organización con base en la
experiencia, la abstracción o la detención. Sirve de guía para desarrollar proyectos
de software y también como instrumento de capacitación a los nuevos miembros
de la organización.
Esta base de conocimientos puede ampliarse o modificarse continuamente; y

puede contener métodos, prácticas organizadas como familias, prácticas
individuales o patrones de prácticas.
Plantillas de KUALI-BEH
KUALI-BEH maneja las siguientes tres plantillas: para proyectos de software, para
método y para práctica.
Estructura de la plantilla de proyecto de software
En esta plantilla (Ilustración 2) se almacena la información y los datos del proyecto

de software.
Estructura de plantilla para método
Esta plantilla (Ilustración 3) guarda la información y los datos para el método. Es

necesario asentar el conjunto de buenas prácticas que interrelacionadas sirven de
guía para desarrollar proyectos de software. La información contenida en esta
plantilla recopila la experiencia y conocimiento de los desarrolladores de proyectos
de software.
Estructura de plantilla para práctica
En esta plantilla (Ilustración 4) se asienta la información basada en la experiencia

adquirida en el desarrollo de proyectos, las actividades y las tareas que puedan
pág. 33
servir de guía para nuevos proyectos. El conjunto de estas prácticas conforman

los métodos.
[identificador] Proyecto de Software
[nombre]
Interesado
[lista de interesados]
Fecha de inicio Fecha de fin
[fecha de inicio del proyecto] [fecha de fin del proyecto]
Entradas Resultados
[necesidades de los interesados, condiciones [producto de software, …]

del proyecto, producto de software, …]
Método
[método seleccionado, …]
Equipo de trabajo
[desarrolladorA,
…,
desarrolladorZ, …]
Ilustración 2 Plantilla de proyecto de software.
pág. 34
[identificador] Método
[nombre]
Propósito
[propósito]
Entrada Resultado
[Necesidades de los involucrados, condiciones del [Producto de software ,…]

proyecto,…]
Prácticas
[Requerimientos de las pràcticas,
Resultados de la pràctica, …]
Ilustración 3 Plantilla para método.
pág. 35
Práctica
Nombre
Objetivo
Entrada Resultado
Guía
Actividades
Herramientas (opcional)
Conocimientos y habilidades
Criterios de Verificación
Métricas
Ilustración 4 Plantilla para práctica.
pág. 36
KUALI-BEH, como se menciona anteriormente, consta de dos vistas: estática y

dinámica. A través de las plantillas se tiene sólo la vista estática.
A diferencia de otros modelos, KUALI-BEH proporciona una estructura que

permite registrar los métodos y prácticas que sigue una organización al desarrollar
proyectos de software. Es verdad que hay muchos modelos estandarizados
actualmente, pero no hay otro modelo que cumpla con este objetivo.
Para llevar a cabo esta tesis fue necesario manejar los conceptos inherentes al
desarrollo de proyectos de software; tanto los elementos de Ingeniería de
Software como los conceptos de KUALI-BEH. Esto para definir el método guía que
se propone y se describe a través de las plantillas que proporciona KUALI-BEH
para este fin.
pág. 37
Capítulo 3 Método Básico de
Desarrollo de Software (BADESO).
“No hay un simple desarrollo en tecnología o técnica de gestión,

que por sí solo prometa incluso una mejora en la productividad,
confiabilidad, simplicidad, en un orden de magnitud por [diez]
dentro de una década” Frederick Brooks, 1986 (Brooks F. ,
2014).
Introducción
Se ha descrito en los capítulos anteriores qué es Ingeniería de Software, en qué
consiste KUALI-BEH y cuál es su propósito.
En este capítulo se verá cómo está estructurado el método propuesto en esta

tesis, el Método Básico de Desarrollo de Software (BADESO).
Aunque BADESO está pensado para que sirva de guía a los Proyectos de
desarrollo de Software de Residencias Profesionales del Instituto Tecnológico de
La Paz (ITLP); también puede utilizarse en las materias del área de Ingeniería de
Software, que tienen un proyecto integrador para la construcción de software.
Para realizar la Residencia Profesional se cuenta con un tiempo ajustado (16 a 25

semanas) es por esto que, uno de los objetivos al plantear el método fue
proporcionar plantillas en la práctica denominada Dar a conocer el manejo de
estándares para el proyecto (PA6), que facilitaran las actividades y las hicieran
más naturales y fluidas.
pág. 38
Capítulo 3 Método Básico de Desarrollo de Software (BADESO).
Características del método BADESO

BADESO toma como paradigmas metodologías ya existentes; sin embargo tiene
como objetivos:
 Enfatizar las prácticas que ayudan a reducir el tiempo de desarrollo y a

cumplir con los requisitos del cliente,
 Fortalecer el aprendizaje adquirido durante la carrera en materias de
Ingeniería de Software
 Homogenizar los entregables por medio de estándares.
KUALI-BEH conceptos comunes en los proyectos de software

y BADESO
KUALI – BEH maneja conceptos comunes1 en los proyectos de software los
cuales podemos observar en la ilustración 5.
1Cada uno de estos conceptos han sido previamente definidos en el capítulo 2.
pág. 39
Ilustración 5 Conceptos comunes de KUALI-BEH
pág. 40
BADESO fue concebido para ser aplicado en los Proyectos de Residencias

Profesionales particularmente para proyectos de software.
Producto de Software
Es lo que queremos obtener al llevar a cabo proyectos de software. En nuestro

contexto es el resultado de la Residencia Profesional.
Condiciones del Proyecto
Son las necesidades particulares del proyecto que pueden afectar el éxito del
mismo.
Como ejemplo de estas condiciones están: la complejidad del sistema, el tipo de

aplicación, las habilidades y conocimientos de los desarrolladores, entre otros;
que hacen única a cada Residencia Profesional y a cada proyecto de software de
la misma.
Partes Interesadas2
Las partes interesadas son los clientes o patrocinadores, los que deciden la
aceptación del proyecto y por lo tanto de ellos depende el éxito del proyecto. En
el caso de BADESO las Partes Interesadas son: para efectos de documentación,
el asesor externo; para efectos prácticos, todos aquellos que están interesados
en el sistema que se va a desarrollar y que proporcionan información necesaria
para su desarrollo.
Equipo de trabajo
Es un grupo de personas que trabajan juntas en un ambiente de colaboración para

lograr un objetivo común.
2 También conocidos como stakeholders.
pág. 41
En BADESO se prevé que una Residencia Profesional se puede llevar a cabo de

manera individual o en Equipo. Por eso en la práctica Organizar el equipo (PE3)
se sugiere emular los roles de SCRUM si el equipo es de una o dos personas; o
aplicar TSPi si el equipo es mayor a tres personas.
Desarrolladores
Un Desarrollador es la persona que se dedica a construir el producto de software

basado en los principios y fundamentos de Ingeniería de Software. En BADESO
se identifican como Desarrolladores a el(los) Residente(s) que participan en el
equipo de trabajo.
Método BADESO definido en la plantilla de KUALI-BEH

Además de apoyarse en los conceptos de KUALI-BEH, se hace uso de las
plantillas que el modelo propone para la definición de métodos y prácticas.
BADESO está definido en el marco que proporciona KUALI-BEH (Ilustración 6), y

está compuesto de catorce prácticas. Las cuales se agrupan en tres áreas:
Desarrollo, Administrativas y de Equipo.
BADESO Método
Método Básico de Desarrollo de Software
Propósito
Desarrollar Proyectos de Software para Residencias Profesionales del ITLP

mediante procesos del ciclo de vida del software.
Entrada Resultado
pág. 42
1. Anteproyecto de Residencias 1. Software entregado y liberado.

Profesionales. 2. Documentos de aceptación.
3. Reporte final de la Residencia
Profesional del ITLP versión final.
Profesional del ITLP versión final en
dispositivo de almacenamiento
secundario.
5. Discos del sistema.
Prácticas
A. Prácticas Administrativas (PA)

PA1. Determinar el alcance del sistema.
PA2. Definir el plan del proyecto.
PA5. Obtener aprobación de avance por el cliente.
PA6. Dar a conocer el manejo de estándares para el proyecto.
PA7. Manejar cambios en el proyecto.
B. Prácticas de Desarrollo (PD)
PD8. Modelar el negocio.
PD9. Obtener requisitos del sistema.
PD10. Realizar el análisis del sistema.
PD11. Diseñar el sistema.
PD12. Construir el sistema.
PD13. Probar el sistema.
PD14. Implantar el sistema.
C. Prácticas de Equipo (PE)
PE3. Organizar el equipo.
PE4. Definir mecanismos de comunicación del equipo.
Ilustración 6 Método BADESO definido en KUALI-BEH
BADESO coherente, consistente y completo.

El método y el conjunto de las prácticas del método (ilustración 6) deben
conservar las propiedades de coherencia, consistencia y completitud para
permitir el logro del objetivo del método.
pág. 43
Ilustración 7 Método Básico de Desarrollo de Software (BADESO).
pág. 44
A continuación se procederá a demostrar que BADESO cumple con estas

tres propiedades.
Coherencia
Un conjunto de prácticas del método es coherente si el objetivo de cada

práctica contribuye a lograr el objetivo del método (Oktaba, Morales Trujillo,
& Dávila Muñoz, 2013).
La ilustración 8 ilustra un conjunto coherente de las prácticas. El Símbolo

gráfico M representa un método y P una práctica (Oktaba, Morales Trujillo, &
Dávila Muñoz, 2013):
Ilustración 8 Conjunto coherente de prácticas en KUALI-BEH.
Para demostrar que el método BADESO posee la propiedad de coherencia se

procederá de la siguiente manera:
a) Comprobar que los objetivos de las catorce prácticas del método BADESO
cumplen con los objetivos del método.
b) Si es así, se concluye que el método BADESO cumple con la propiedad de
coherencia.
Si los objetivos de sus prácticas satisfacen el objetivo de BADESO, “Desarrollar

Proyectos de Software para Residencias Profesionales del ITLP mediante
pág. 45
procesos del ciclo de vida del software” entonces se concluye que el método
cumple con la propiedad de coherencia.
La norma ISO/IEC 12207:2006 identifica tres grupos de procesos en un ciclo de

vida de software: Principales, de Apoyo y Organizativos; desarrollando estos
grupos de procesos se alcanza el objetivo propuesto por la norma que es el mismo
objetivo del método propuesto en esta tesis.
Estos procesos tienen tareas y actividades que permiten construir los productos
de software que se entregarán al cliente. Para los procesos principales se
requieren ejecutar las prácticas de desarrollo: Modelar el negocio (PD8), Obtener
requisitos del sistema (PD9), Realizar el análisis del sistema (PD10), Diseñar el
sistema (PD11), Construir el sistema (PD12), Probar el sistema (PD13) e
Implantar el sistema (PD14).
Los procesos de apoyo, ayudan a otros procesos con un propósito bien definido y
contribuyen al éxito y calidad del proyecto de software. Para llevar a cabo los
procesos de apoyo es necesario realizar el conjunto de prácticas propuestas:
Definir mecanismos de comunicación del equipo (PE4), Obtener aprobación de
avance por el cliente (PA5), Dar a conocer el manejo de estándares para el
proyecto (PA6) y Manejar cambios en el proyecto (PA7).
Y finalmente, los procesos organizativos son los que administran y apoyan el

desarrollo del proyecto; para estos procesos se precisa efectuar las prácticas:
Determinar el alcance del sistema (PA1), Definir el plan del proyecto (PA2) Y
Organizar el equipo (PE3).
Procesos principales
Modelar el negocio (PD8).
Para obtener el Documento de modelo del negocio se ejecuta (Ilustración 9) la

práctica Modelar el negocio (PD8), que tiene el objetivo: “Modelar el contexto del
pág. 46
sistema a construir”, para lograr una abstracción del sistema actual, su

funcionamiento y su entorno; y esto permite obtener el resultado de esta práctica
que también es un resultado del método.
Obtener requisitos del sistema (PD9) y Realizar el análisis del sistema (PD10).
Las prácticas Obtener requisitos del sistema (PD9) y Realizar el análisis del
sistema (PD10) se ejecutan de forma paralela (Ilustración 10), y una vez
realizadas son aprobadas a través de aplicar: Obtener aprobación de avance por
el cliente (PA5), para obtener el Documento de modelo de requisitos aprobado y
el Documento de modelo de análisis aprobado. Esto se logra a través de los
objetivos de cada una de estas prácticas:
Obtener requisitos del sistema (PD9) plantea como objetivo: “Definir los requisitos
del sistema a construir a partir de la comprensión del problema y su entorno”.
Si se conocen e identifican los servicios que el cliente requiere, entonces se tiene

la información para construir el Documento de modelo de requisitos.
El objetivo de Realizar el análisis del sistema (PD10) es: “Construir los modelos
del análisis del sistema”. Es necesario hacer un borrador del sistema de los
servicios que el cliente quiere; y eso se plasma en el Documento de modelo de
análisis.
pág. 47
Ilustración 9 Modelar el negocio (PD8)
pág. 48
Ilustración 10 Obtener requisitos del sistema (PD9) y Realizar el análisis del sistema (PD10).
pág. 49
Diseñar el sistema (PD11).
La práctica Diseñar el sistema (PD11) es en la que se elabora el Documento de

modelo de diseño aprobado (Ilustración 11) que al realizar las actividades de la
misma y alcanzar su objetivo, muestra cómo construir el software. Su objetivo es:
“Crear la representación del software que sirva de guía para su construcción”.
Construir el sistema (PD12).
Busca como objetivo: “Escribir el código fuente en concordancia con las

especificaciones del Modelo de diseño, de modo que se facilite la depuración,
pruebas y modificaciones”.
Construir el sistema (PD12) es una práctica que se propone se realice al menos

tres veces (como se muestra en la ilustración 12) porque se plantea una
integración continua e incremental; al final de estos ciclos se obtiene el
Documento de construcción del sistema y los componentes de software probados,
documentados e integrados; estos productos se requieren para integrarlos en la
práctica Probar el sistema (PD13).
Probar el sistema (PD13).
La práctica Probar el sistema (PD13) tiene como objetivos: “Aplicar pruebas del
sistema y de aceptación y, Generar manuales del sistema”. Los resultados de esta
práctica (Ilustración 13) contribuyen con el manual técnico y de usuario; y con el
resultado del método que es el software y además van integrando el Documento
de implementación que forma parte de los resultados de la práctica Implantar el
sistema (PD14).
pág. 50
Ilustración 11 Diseñar el sistema (PD11).
pág. 51
Ilustración 12 Construir el sistema (PD12).
pág. 52
Ilustración 13 Probar el sistema (PD13).
pág. 53
Ilustración 14 Implantar el sistema (PD14).
pág. 54
Los objetivos de la práctica (Ilustración 14) son: “Instalar y liberar el sistema y

finalizar la Residencia Profesional”. La conversión, implantación, pruebas y
capacitación del sistema se realizan en la última práctica Implantar el sistema
(PD14). Es aquí donde se terminan de integrar los resultados del método:
Documento de modelo de implementación, Manual técnico, Software (discos),
Documentos de aceptación, Reporte final de la Residencia Profesional impreso y
en versión electrónica.
Procesos de apoyo
Obtener aprobación de avance por el cliente (PA5).
La práctica Obtener aprobación de avance por el cliente (PA5), como se muestra

en la ilustración 15, contribuye enormemente en el logro de los objetivos del
método validando los requisitos y los productos que se van aprobando, a través
del cumplimiento de su objetivo: “Mantener informado del progreso del proyecto
al cliente, manejar una buena retroalimentación oportuna del avance completado,
y obtener la aprobación del cliente sobre el mismo”.
Dar a conocer el manejo de estándares para el proyecto (PA6).
La práctica tiene como objetivo: “Dar a conocer los estándares que se utilizarán
en el proyecto”. Por lo que establece el manejo de los estándares que se van a
utilizar a lo largo de la ejecución del proyecto, y es importante explicarlos al inicio
del proyecto (como se muestra en la ilustración 16) porque van a ser utilizados en
todas las prácticas del método.
El objetivo de la práctica Manejar cambios en el proyecto (PA7) es: “Establecer el

procedimiento para manejar los cambios en el proyecto, desde su planteamiento,
aprobación y si es el caso, seguimiento”.
pág. 55
Ilustración 15 Práctica Obtener aprobación de avance por el cliente (PA5) y su aplicación en las diferentes prácticas a través del método
pág. 56
Ilustración 16 Práctica Dar a conocer el manejo de estándares para el proyecto (PA6) y su efecto en el resto de las prácticas.
pág. 57
Ilustración 17 Aplicación de Manejar cambios en el proyecto (PA7).
pág. 58
En todos los proyectos pueden presentarse cambios (ilustración17), la manera de

administrarlos, documentarlos y fundamentarlos es importante para el éxito del
logro del proyecto.
Definir mecanismos de comunicación del equipo (PE4).
La actividad de comunicación se fortalece en esta práctica al alcanzar el objetivo

(Ilustración 18): “Establecer los mecanismos necesarios para compartir la
información entre los integrantes del equipo”.
Procesos Organizativos
Determinar el alcance del sistema (PA1).
De acuerdo a los requisitos establecidos se evalúa la viabilidad del alcance dadas

las condiciones de la Residencia Profesional, para que sea posible la finalización
del proyecto. Esto se plasma en el objetivo: “Determinar la dimensión del sistema
a desarrollar con base en las funciones deseadas, necesidades del cliente,
contexto del negocio, restricciones que se tienen, rendimiento y confiabilidad
esperada”.
El objetivo de la práctica es: “Elegir la organización del equipo y asignar roles”. Lo

que permite definir la estructura del equipo; si los integrantes del equipo saben
qué hacer, se logra un uso eficiente del tiempo.
Definir el plan del proyecto (PA2).
Para una buena administración del proyecto se debe establecer la planeación del
desarrollo, este es el objetivo de la práctica: “Elaborar un plan que asegure que el
producto se construya dentro del tiempo, con calidad y de acuerdo a las
necesidades del cliente”.
pág. 59
Ilustración 18 Práctica Definir los mecanismos de comunicación del equipo (PE4) como parte de los procesos de apoyo.
pág. 60
Ilustración 19 Prácticas Determinar el alcance del sistema (PA1), Definir el plan del proyecto (PA2) y Organizar el equipo (PE3) de los procesos
organizativos.
pág. 61
La planeación del proyecto (Ilustración 19) incluye definir actividades, tareas,

tiempos y asignar responsabilidades; las actividades y tareas las proporciona el
mismo método. De una buena planeación depende si concluimos el proyecto, si
se termina a tiempo y si se satisfacen los requisitos.
Con lo expuesto en este apartado se ha demostrado que con las 14 prácticas se

alcanza el objetivo propuesto por los tres tipos de procesos del estándar ISO/IEC
12207:2006.
Por lo tanto se concluye que el método BADESO cumple con la propiedad de

coherencia ya que los objetivos de sus prácticas satisfacen los objetivos de los
procesos del estándar ISO/IEC 12207:2007 y el objetivo de este es el mismo
objetivo de BADESO:
“Desarrollar proyectos de software para Residencias Profesionales del ITLP

mediante procesos del ciclo de vida del software”.
Consistencia
La propiedad de consistencia (Oktaba, Morales Trujillo, & Dávila Muñoz, 2013) se

puede observar en la ilustración 20.
Ilustración 20 Conjunto consistente de las prácticas de un método.
pág. 62
Un conjunto de prácticas de un método es consistente si:
 La entrada de una práctica es igual a la entrada del método y, al menos el

resultado de una práctica es igual al resultado del método.
 Para cada práctica del conjunto se cumple que:
Realmente haya una práctica que tenga como entrada la entrada del
método y la salida de alguna práctica sea la salida del método y, todas las
intermedias usen lo que generó la anterior y su resultado sea la entrada de
la que sigue.
Para demostrar que el método posee la propiedad de consistencia se procederá

de la siguiente manera:
a) Primero mostrar que todas las prácticas están relacionadas al menos con
otra práctica a través de un diagrama donde se muestre dicha relación a
través de sus entradas y resultados.
b) Mostrar paso a paso cómo se van relacionando las prácticas para obtener
los resultados del método.
c) Por lo tanto se concluiría que el método BADESO cumple con la propiedad
de consistencia porque para el conjunto de prácticas al menos una entrada
de una práctica es igual a la entrada del método y el resultado de una
práctica es igual al resultado del método; y para cada práctica del conjunto
se cumple que el resultado es igual a la entrada de otra práctica y su
entrada es igual al resultado de otra práctica.
Un conjunto de prácticas de un método es consistente si:
 La entrada de una práctica es la misma que la entrada del método y, al

menos el resultado de una práctica es igual al resultado del método.
pág. 63
Ilustración 21 Entradas y Salidas del método BADESO.
pág. 64
Ilustración 22 Entradas a la primera práctica del método.
pág. 65
Ilustración 23 Resultados de la última práctica del método, Implantar el sistema (PD14).
pág. 66
En la ilustración 21 se muestran las entradas y salidas del método; En la

ilustración 22 se puede verificar constatar que las entradas a la primera práctica
del método, Determinar el alcance del sistema (PA1) y las entradas al método son
las mismas.
En la ilustración 21 se exponen los resultados del método y en la ilustración 23 se

muestran los resultados de la última práctica, Implantar el sistema (PD14), se
puede verificar que ambos resultados son los mismos.
Como la entrada de la práctica Determinar el alcance del sistema (PA1) es igual

a la entrada de BADESO y el resultado de Implantar el sistema (PD14) es igual al
resultado de BADESO entonces queda demostrado que se cumple la condición
de consistencia.
Para probar la consistencia de BADESO es necesario también mostrar la segunda

condición:
Para cada práctica del conjunto se cumple que:
 El resultado es igual a igual a la entrada de otra práctica y,

 Su entrada es igual al resultado de otra práctica.
Cuando un proyecto inicia hay un documento que es fundamental y que va a

definir todo el proyecto, la organización, desarrollo y producto, es el Documento
de alcance de sistema, este se obtiene en la práctica Determinar el alcance del
sistema (PA1).
La entrada del método (EM) se requiere para ejecutar Determinar el alcance del
sistema (PA1) y Dar a conocer el manejo de estándares para el proyecto (PA6),
pero enfocado en Determinar el alcance del sistema (PA1), de igual forma se
podría haber empezado por Dar a conocer el manejo de estándares para el
proyecto (PA6).
pág. 67
La entrada del método se requiere como entrada en Determinar el alcance del

sistema (PA1), para obtener el Documento de alcance del sistema; este resultado
es la entrada para Obtener aprobación de avance por el cliente (PA5) que es la
práctica donde se valida el alcance del sistema y el cliente lo aprueba, por eso el
documento resultante es Documento de alcance del sistema aprobado; El cual se
requiere como entrada en Definir el plan del proyecto (PA2) como puede verse en
la ilustración 24.
Dar a conocer el manejo de estándares para el proyecto (PA6) también requiere

como entrada además, la entrada del método; Dar a conocer el manejo de
estándares para el proyecto (PA6) es una práctica que se utiliza en el resto de las
practicas (Ilustración 16) ya que marca la ejecución y el uso de los estándares
para el proyecto, por eso en el diagrama se muestra como se aplica al resto de
las prácticas, a partir de que se ejecuta al menos una vez.
El resultado de Dar a conocer el manejo de estándares para el proyecto (PA6)

alimenta las prácticas Organizar el equipo (PE3), Definir mecanismos de
comunicación del equipo (PE4) y Manejar cambios en el proyecto (PA7); los
resultados de estas últimas son la entrada de Definir el plan del proyecto (PA2),
como se muestra en la ilustración 25.
Se ha llegado a Definir el plan del proyecto (PA2) cuyo resultado (una vez
aprobado por el cliente en Obtener aprobación de avance por el cliente (PA5))
marca la organización del proyecto y es la entrada para Modelar el negocio (PD8).
La práctica Modelar el negocio (PD8) tiene como resultado el Documento de

modelo de negocio; el cual es entrada para la práctica Obtener aprobación de
avance por el cliente (PA5), cuyo resultado se requiere como entrada para
ejecutar las prácticas Obtener requisitos del sistema (PD9) y Realizar el análisis
del sistema (PD10).
pág. 68
Ilustración 24 De Determinar el alcance del sistema (PA1) Definir el alcance de sistema a Definir el plan del proyecto (PA2) Definir el plan de proyecto.
pág. 69
Ilustración 25 De Dar a conocer el manejo de estándares para el proyecto (PA6) a Definir el plan de proyecto (PA2).
pág. 70
Ilustración 26 De Definir el plan del proyecto (PA2) hasta Obtener requisitos del sistema (PD9) y Realizar el análisis del sistema (PD10).
pág. 71
Obtener requisitos del sistema (PD9) y Realizar el análisis del sistema (PD10) son
prácticas que se ejecutan de forma simultánea y cuyo resultado una vez aprobado
en Obtener aprobación de avance por el cliente (PA5), es entrada de Diseñar el
sistema (PD11), como se muestra en la ilustración 26.
Diseñar el sistema (PD11) genera el Documento de modelo de diseño para ser

aprobado en Obtener aprobación de avance por el cliente (PA5), y este resultado
alimenta a la fase de construcción que se lleva a cabo ejecutando Construir el
sistema (PD12). Como se puede observar en la ilustración 27.
El resultado aprobado de Construir el sistema (PD12) es la entrada para Probar

el sistema (PD13), práctica que obtiene como resultado el Documento de pruebas
del sistema y los manuales; una vez aprobada esta práctica su resultado es la
entrada de la última práctica del método, Implantar el sistema (PD14).
Como se muestra en la ilustración 28, una vez obtenido el resultado de Implantar

el sistema (PD14), este alimenta a Obtener aprobación de avance por el cliente
(PA5) para obtener la aprobación del cliente y el resultado de ésta es el resultado
del método.
Por lo tanto, se concluye que BADESO cumple con la propiedad de consistencia

porque la entrada de una práctica del conjunto es igual a la entrada del método y
cada uno de los resultados se utiliza como entrada en otra práctica o es el
resultado del método.
Completo
Para que un método sea completo debe cumplir con la tercera propiedad que
KUALI – BEH define de la siguiente manera:
pág. 72
Ilustración 27 De Obtener requisitos del sistema (PD9) y Realizar el análisis del sistema (PD10) hasta Construir el sistema (PD12).
pág. 73
Ilustración 28 De Construir el sistema (PD12) hasta obtener los resultados del método.
pág. 74
El conjunto de prácticas del método es completo (Oktaba, Morales Trujillo, &

Dávila Muñoz, 2013) si el logro de todos los objetivos de las prácticas cumple
totalmente el objetivo del método y cada uno de los resultados se utiliza como
entrada de otra práctica o es el resultado del método, como se muestra en la
Ilustración 29.
Ilustración 29 Conjunto completo de prácticas.
Esto significa que para que un método sea completo debe cumplir con la
propiedad de coherencia y consistencia. BADESO es completo porque como
quedó demostrado anteriormente cumple con ambas propiedades por lo tanto
también cumple con esta propiedad.
pág. 75
Capítulo 4 Prácticas del Método
Básico de Desarrollo de Software
(BADESO).
“Sólo tengo una lámpara que guía mis pisadas, es la lámpara de

la experiencia”, Patrick Henry.
Introducción
Las prácticas que se logran a través de llevar a cabo una y otra vez una serie de
tareas para el logro de objetivos con buenos resultados, se identifican como
buenas prácticas. Cada organización desarrolladora de software tiene e identifica
sus propias buenas prácticas de su organización. El hecho de que sean efectivas
para esa empresa no garantiza que ese mismo conjunto de prácticas sean útiles
para otra organización. Por esta razón es tan importante que cada organización
documente sus prácticas y genere sus propios métodos de desarrollo de software.
En el capítulo 3 se habló del método BADESO y de las prácticas que lo componen,

además, de cómo cumple con las propiedades que KUALI – BEH solicita para un
buen método. En este capítulo se revisa cada una de las prácticas que lo
componen.
Prácticas de BADESO
BADESO está compuesto por tres tipos de prácticas: administrativas, de equipo y
de desarrollo de software. Se analizarán por separado cada uno de estos tipos de
prácticas.
pág. 76
Capítulo 4 Prácticas del Método Básico de Desarrollo de Software (BADESO)
Prácticas administrativas de BADESO

A menudo se piensa que el éxito de un proyecto de software depende de las
actividades de desarrollo, por lo cual se excluyen totalmente las actividades
administrativas. Es un error común. Las actividades administrativas son
igualmente importantes que las de desarrollo para culminar un proyecto sin
retrasos, sin mediocridad, completo y sin costos sobrepasados.
En conclusión, las prácticas administrativas se realizan para asegurar que los

objetivos del proyecto se cumplan.
Las prácticas administrativas son:
Es establecer la función del software de manera clara y precisa para, con base en
esto, delimitar el alcance del proyecto. Se define el alcance en conjunto con los
involucrados en el proyecto.
Determinar el alcance del sistema es fundamental para el proyecto. Si no se

conoce ¿Cómo se pueden calcular recursos necesarios? ¿Cómo hacer un plan
de proyecto? ¿Cómo estimar recursos? Sería como correr un maratón
desconociendo la meta.
El objetivo de la práctica es determinar qué se va a construir, esto significa conocer

qué información se necesita, qué función y rendimiento se espera: las interfaces,
las restricciones y la confiabilidad deseados. Una vez establecido el alcance del
sistema ya se puede empezar a trabajar, porque se tiene un punto de partida y se
sabe adónde se quiere llegar. En ocasiones también es importante el determinar
lo que el alcance NO INCLUYE. Muchas veces se establecen premisas respecto
a lo que se incluye que no son completamente claras, o simplemente para
establecer claramente que algo no está incluido en el alcance.
pág. 77
Hecho esto se puede establecer el plan de proyecto, distribuir recursos,

pronosticar necesidades y planear su administración y desarrollo.
Por eso, para empezar un proyecto de Residencias Profesionales, se necesita

como punto de partida el Anteproyecto de Residencias Profesionales en el que se
autoriza al alumno la realización del mismo. Este documento proporciona la
información general de las funciones generales y específicas del software.
Al finalizar esta práctica se obtiene una idea precisa de qué se construirá y con
base en eso es posible hacer un plan del proyecto más realista que el que
originalmente se había propuesto en el Anteproyecto de Residencias
Profesionales.
PA1 Práctica
Determinar el alcance del sistema.
Objetivo
Determinar la dimensión del sistema a desarrollar con base en las funciones deseadas,
las necesidades del cliente, contexto del negocio, restricciones que se tienen,
rendimiento y confiabilidad esperados.
Entradas Resultados
1. Anteproyecto de Residencias 1. Documento de alcance del

Profesionales del ITLP sistema.
autorizado1. 2. Formato de aprobación de avance
para el Documento de alcance del
sistema.
1 El Anteproyecto de Residencias Profesionales es autorizado a través de la Academia de

Sistemas y Computación.
pág. 78

Profesional del ITLP 1.0.
Guía
Actividades
1) Identificar y definir el alcance del sistema

a) Reunir información de la empresa (documentos informativos de la empresa).
i) Realizar una revisión de registros que permita conocer:
(1) Misión.
(2) Visión.
(3) Organigrama con nombres de los que ocupan los puestos.
(4) Información histórica de la empresa.
(5) El área para quien se desarrollará el sistema y las funciones que
realizan.
b) Investigar sistemas del mismo tipo.
i) Determinar qué tipo de sistema de información es.
ii) Buscar información en libros, páginas de internet, artículos, revistas, etc.
sobre las características y funciones de sistemas de información del
mismo tipo que el sistema a desarrollar.
c) Preparar reunión con los involucrados en el proyecto.
i) Especificar fecha, lugar, hora de inicio y hora de terminación para la junta.
ii) Determinar los recursos necesarios.
iii) Establecer una guía de preguntas (indispensable) que ayuden a definir las
funciones y la dimensión del sistema.
iv) Establecer la agenda de la reunión.
v) Confirmar con los involucrados la reunión y dar a conocer el objetivo de la
misma.
vi) Debe haber al menos dos integrantes del equipo (si son más de uno)
presentes en la junta.
d) Realizar reunión(es) con los involucrados en el proyecto.
i) Pedir permiso para grabar la entrevista.
ii) Tomar notas durante la reunión.
iii) Iniciar la entrevista explicando el porqué de la reunión.
iv) Ceder la palabra al cliente para que exponga sus motivos.
v) Añadir las preguntas que surjan durante la exposición de motivos del
cliente.
vi) Permitir, si es el caso, que otros asistentes tomen la palabra.
vii) Hacer las preguntas que tiene planeadas.
pág. 79
viii) Preguntar y confirmar durante la reunión.

2) Identificar y definir los límites del sistema.
a) Con la información, identificar y contestar los puntos de límites del sistema.
3) Con la información obtenida, establecer el alcance del sistema. El producto
resultante se denomina Documento de alcance del sistema.
4) Procesar la información y llenar los puntos 1.2, 1.3 y 1.6 del Reporte final de la
Residencia Profesional del ITLP que se encuentra en el Documento de
estándares. El documento resultante se denomina Reporte final de la Residencia
 Procesador de texto, software para presentaciones y hoja de cálculo.
 Habilidad para identificar funciones principales.

 Habilidad para comunicarse en forma oral y escrita.
 Habilidad para identificar problemas potenciales.
 Habilidad para discriminar información.
Criterios de verificación
 Alcance del sistema. Debe contener los siguientes puntos:

a. Funciones principales.
b. Entradas principales.
c. Controles.
d. Rendimiento.
e. Resultados esperados.
 Límites del sistema. Debe contener los siguientes puntos:
a. Restricciones de hardware.
b. Restricciones legales externas.
c. Restricciones de software.
d. Restricciones económicas.
 Completitud de la información. Debe contener los siguientes puntos:
a. Puntos del alcance completo.
b. Puntos de límites completos.
pág. 80
c. Información completa para elaborar Anteproyecto de Residencias

Profesionales.
 En la documentación de la práctica es necesario que se tenga lo siguiente:
a. Guía de preguntas para primera reunión con el cliente.
b. Documento informativo sobre la empresa.
c. Documentos informativos sobre el tipo de sistema a desarrollar.
Métricas
1. Tiempo de la reunión.
2. Cantidad de requisitos logrados.
3. Registro de asistencia de los involucrados.
Definir el plan del proyecto (PA2).
El objetivo de la planeación del proyecto es cumplir con las necesidades del

cliente, entregar el trabajo dentro del tiempo de la Residencia Profesional,
proporcionar un producto con calidad y, por lo tanto, reducir los costos de
mantenimiento. No obstante, aun tratándose de una Residencia Profesional
donde los costos tangibles son pocos, se busca evitar y reducir costos tanto
intangibles como medibles.
Para hacer el plan del proyecto es necesario conocer el alcance del sistema, por
eso esta práctica es posterior a la de Determinar el alcance del sistema aprobado
(PA1, PA5). Si se desconoce la dimensión de lo que se va a realizar, ¿cómo se
puede hacer un plan?
Las prácticas Organizar el equipo (PE3) y Definir mecanismos de comunicación del

equipo (PE4) también se pueden y se recomiendan hacer antes que esta práctica,
para optimizar el tiempo. Se pueden realizar antes ya que son prácticas de
organización de equipo y consisten en ponerse de acuerdo en la forma de trabajo
pág. 81
y los mecanismos de comunicación. Una vez hecho esto y Determinar el alcance

del sistema aprobada (PA1, PA5), se puede plantear el plan de desarrollo.
Elaborar el plan del proyecto implica planear el desarrollo y la administración del

mismo, y esto se hace a través de: el conocimiento de los recursos con los que se
cuenta, la asignación de responsabilidades, la definición de los resultados y el
establecimiento de puntos para evaluar la calidad del proyecto y poder
supervisarlo. La planeación permite saber con qué se dispone. Y esto, lejos de ser
negativo, es una ventaja, ya que se planea y se realiza la estrategia con los
recursos económicos, humanos y de equipo y software con los que se cuenta.
Una vez obtenido el plan, el siguiente paso es ejecutarlo.
PA2 Práctica
Definir el plan del proyecto.
Objetivo
Elaborar un plan que asegure que el producto se construya dentro del tiempo, con
calidad y de acuerdo a las necesidades del cliente.
Entrada Salida
1. Documento de alcance del 1. Documento de plan del proyecto.

Sistema aprobado. 2. Reporte final de la Residencia
2. Anteproyecto de Residencias Profesional del ITLP 2.0.
Profesionales del ITLP autorizado. 3. Formato de aprobación de avance
3. Reporte final de la Residencia para el Documento de plan del
Profesional del ITLP 1.0. proyecto.
4. Documento de estándares. 4. Formato de solicitud de cambio3.
5. Documento de formalización de
equipo2.
2 No aplica para residentes individuales.

3 Se obtiene como salida este formato si se necesita realizar cambios al proyecto.
pág. 82
6. Documento de formalización de la
comunicación.
7. Documento Formato de
formalización del cambio con
respuesta.
Guía
Actividades
1. El Documento de Estándares contiene los formatos, plantillas, estándares y el

manejo del proyecto.
2. Establecer fechas para actividades, responsables4 y productos a lograr.
a. Para el programa, con base en el alcance y las restricciones del
proyecto
i. Identificar los productos a lograr.
ii. Relacionar los productos.
iii. Establecer prioridades de los productos y dependencias.
b. Para el personal5 asignar funciones a los integrantes del equipo con el
Documento de formalización de equipo.
c. Para el producto
i. Si necesita comprar software y/o hardware entonces
1. Elaborar estudio de factibilidad tipo A para software.
2. Elaborar estudio de factibilidad de Tipo B si se requiere
de hardware para el producto final.
ii. Revisar los entregables establecidos en la práctica Dar a
conocer el manejo de estándares para el proyecto (PA6) y
ajustar al proyecto actual si se considera necesario.
d. Para el proceso, determinar fechas y tiempos para cada práctica.
3. Modelar el plan del proyecto
a. Con base en el programa, proceso, personal y el producto, elaborar el
calendario detallado del proyecto mediante un diagrama de Gantt,
usando una herramienta CASE.
b. Actualizar el Formato de reporte de avance de proyecto de
Residencias Profesionales que se marca en la práctica Dar a conocer
el manejo de estándares para el proyecto (PA6).
4 En caso de que la Residencia Profesional se realice por más de un estudiante.

5 No aplica para residentes individuales.
pág. 83
c. Revisar el calendario para identificar las tareas que puedan llevarse a

cabo de forma simultánea y las prácticas principales que podrían
retrasar el proyecto.
d. Asignar responsables para cada tarea.
4. Integrar el Documento de plan del proyecto con todos los productos obtenidos
en las actividades anteriores integrando el Documento de formalización de la
comunicación.
5. Construir el punto 1.7 Marco teórico del Reporte final de la Residencia
Profesional.
6. Actualizar el Documento Reporte final de la Residencia Profesional del ITLP
1.0 con la información resultante y denominar Reporte final de la Residencia
7. Llenar Formato de aprobación de avance para el Documento de plan del
proyecto.
8. Si es el caso llenar el Formato de solicitud de cambio y ejecutar Manejar
cambios en el proyecto (PA7).
Herramientas
 Software de administración de proyectos (Microsoft Project, Gantt Project).
 Habilidad para identificar objetivos.

 Habilidad para identificar prioridades.
 Habilidad para desarrollar calendarios reales y sujetarse a ellos.
Criterios de verificación
 Considerar los productos y los entregables en el calendario.

 Cada integrante del equipo debe tener asignadas funciones con base en un rol
(Si el número de residentes es mayor a uno).
 Confirmar viabilidad de las tareas simultáneas.
 Verificar que el tiempo asignado a las prácticas de pruebas no sea mayor que
el tiempo destinado a la construcción del software.
 Verificar que la organización del calendario permita planear de nuevo.
pág. 84
Métricas
1. Existencia de funciones por rol (Si el número de residentes es mayor a uno).

2. Número total de semanas para el proyecto.
3. Número total de semanas por fase.
La práctica 5 hace una diferencia, ya que enfatiza la obtención de la aprobación

del cliente en hitos predefinidos en el plan del proyecto. De hecho, la
recomendación es no continuar hasta que el cliente acepte el avance. El objetivo
es tener un punto de revisión y además, avanzar con la seguridad de que los
objetivos se están cumpliendo, ya que satisfacen los requisitos del cliente, con la
propia revisión por parte de éste. Esto logra una comunicación sólida entre el
cliente y el equipo de desarrollo, generando una buena retroalimentación. Otro
objetivo de la práctica no menos importante es que el cliente conozca el avance
del proyecto.
En la práctica Obtener aprobación de avance por el cliente (PA5) se aplican los

siguientes hitos:
Determinar el alcance del sistema (PA1), Definir el plan del proyecto (PA2),
Modelar el negocio (PD8), Obtener requisitos del sistema (PD9), Realizar el
análisis del sistema (PD10), Diseñar el sistema (PD11), Construir el sistema
(PD12), Probar el sistema (PD13) e Implantar el sistema (PD14).
Por esta razón en las entradas en dicha práctica se señala con un (*) que el
documento será de acuerdo a la práctica sobre la que se esté aplicando la práctica
denominada Obtener aprobación de avance por el cliente (PA5). La misma
indicación (*) aplica para la salida de la práctica.
pág. 85
Cabe mencionar, que lo deseable es que el cliente apruebe el documento. Sin

embargo, puede ser que se presenten cualquiera de los siguientes casos:
 El cliente aprueba el documento y señala algunos detalles a cambiar;

 El cliente no aprueba el documento y señale los cambios que desea. Si el
caso es este último, entonces debe repetirse la práctica Obtener
aprobación de avance por el cliente (PA5), hasta que el cliente dé “luz
verde” aprobando el producto que se está presentando.
Obtener la aprobación del cliente por escrito brinda seguridad de que el proyecto
va por buen camino, y es la misma certeza que el cliente siente hacia su proyecto.
Además que los clientes se sienten parte del proyecto.
PA5 Práctica
Obtener aprobación de avance por el cliente.
Objetivo
 Mantener informado al cliente del progreso del proyecto,

 Obtener retroalimentación oportuna del avance completado,
 Obtener la aprobación del cliente sobre el mismo.
Entrada Resultado
1. Archivo de la presentación oral 1. Formato de aprobación de avance

del avance del proyecto. llenado y firmado.
2. Documento 6* de avance de 2. Formato de solicitud de cambio7.
proyecto.
3. Formato de aprobación de
avance*.
6* Significa que aquí pueden ser los resultados de cualquiera de las siguientes prácticas: PA1,
PA2, PD8, PD9, PD10, PD11, PD12, PD13 y PD14.
7 Se obtiene como salida este formato si se necesita realizar cambios al proyecto.
pág. 86
4. Documento de estándares.
Guía
Actividades

2. Realizar la presentación oral de avance al cliente
a. Debe iniciarse la reunión con una exposición de motivos.
b. El encargado del avance a presentar debe conducir la presentación.
c. Es deseable que el cliente participe cuantas veces lo considere
necesario.
3. Debe cuidarse que la presentación sea sencilla y puntual. Exponiendo
claramente el avance a mostrar.
4. Presentar el Documento de avance de proyecto. El Documento debe mostrar la
información presentada en la presentación oral, pero con detalles más concretos
de la información y debe proporcionarse al inicio de la reunión.
El Documento de avance de proyecto debe contener:
a. Portada,
b. Índice,
c. Desarrollo,
d. Glosario,
e. Debe estar paginado, sin faltas de ortografía y ser un documento formal,
claro y sencillo.
f. Debe cumplir con el Estándar de documentación previamente acordado.
5. Proporcionar el Documento de avance de proyecto. Al inicio de la reunión se le
entrega a los asistentes el Documento de avance de proyecto y se enfatiza la
importancia de la retroalimentación para el proyecto, por lo que se les pide que
registren los comentarios. Al término de la presentación se les solicita que
entreguen el formato lleno y firmado.
6. Llenar Formato de aprobación de avance. Al finalizar la reunión, si el cliente está
de acuerdo con el avance presentado, se le proporciona el Formato de
aprobación de avance y se le pide llenar y firmar.
 Software para presentación.
pág. 87
 Habilidad para trabajar en equipo.

 Capacidad para comunicarse de forma oral y escrita.
 Capacidad de comunicarse con el cliente y entender sus solicitudes.
 Cuidar la agenda a seguir durante la reunión.

 Revisar que el Documento de avance de proyecto lo entreguen debidamente
firmado.
 Revisar que el Formato de aprobación de avance lo entreguen
debidamente firmado.
Métricas
1. Tiempo real de duración de la reunión8.
El objetivo de la práctica Dar a conocer el manejo de estándares para el proyecto

(PA6) es explicar el manejo que se dará al proyecto. Podría pensarse en principio
que en esta actividad se deben definir estándares; sin embargo, la intención es
definir el manejo del proyecto sin importar quiénes participen en el mismo o de
qué proyecto se trate. En sí, se pretende que los estándares se mantengan.
Pueden ajustarse, pero no modificarse. La ventaja que se logra es que los
residentes profesionales y sus respectivos asesores tienen una guía de
estándares a aplicar que mejoran la calidad y además les ahorran tiempo.
8Cabe aclarar que todo este tipo de comunicación no tiene que ser presencial. Es decir, todo el
proceso de revisión y aprobación de documentos puede ser realizado también en forma virtual,
con aprobaciones electrónicas por medio de emails o documentos firmados y escaneados.
pág. 88
La ejecución del proyecto comienza cuando inicia la Residencia Profesional, por

eso la entrada es el Anteproyecto de Residencias Profesionales autorizado: es
una actividad que se realiza de inicio a fin, durante todo el tiempo que dure el
proyecto, desde la primera hasta la última práctica. Es por esto que su salida hace
referencia al Documento de estándares, que es donde se encuentran las plantillas
a utilizar.
PA6 Práctica
Dar a conocer el manejo de estándares para el proyecto.
Objetivo
Dar a conocer los estándares que se utilizarán.
Entrada Resultado
1. Anteproyecto de Residencias 1. Documento de estándares.

Profesionales del ITLP
autorizado9.
Guía
Actividades
1) Dar a conocer el Estándar de documentación

a) El estándar a manejar es el marcado por el Instituto Tecnológico de La Paz
en el documento denominado Instructivo para la elaboración del Reporte
final de la Residencia Profesional (ITLP, 2013).
Salvo en situaciones muy particulares se definirá otro estándar; sin embargo
los factores a considerar son los mismos que se manejan en dicho
documento.
2) Explicar Manejo de la programación
9 El Anteproyecto de Residencias Profesionales es autorizado a través de la Academia de

Sistemas y Computación.
pág. 89
a) En este punto es importante que el administrador del desarrollo en caso de

TSPi y el programador senior en caso de SCRUM, expliquen el estándar que
debe seguirse para la programación. Debe establecerse por escrito y en un
documento disponible para todos los integrantes del equipo en el repositorio
del proyecto10 en el que definan el estilo de programación (Fairley, 1988,
págs. 223,229) y guías de implementación acertada (Braude, 2003, págs.
362-367).
3) Revisión de la programación
a) Los desarrolladores deben generar la lista de comprobación de código de
acuerdo al lenguaje de programación que utilicen. Para ello, se pueden
basar en las listas de comprobación de código propuestas por (Humphrey,
Introducción al proceso software personal, 2001, pág. 185). Sin embargo, sí
entre las listas de comprobación que maneja el autor no se encuentra
disponible la adecuada al lenguaje de programación que se va a utilizar, es
necesario generarla. Para eso se toma como base el formato propuesto por
(Humphrey, Introducción al proceso software personal, 2001, pág. 191).
4) Plantear el Estándar de documentación de código.
a) El Estándar de documentación de código se define tomando como base el
estándar propuesto por (Humphrey, Introducción al proceso software
personal, 2001, págs. 198,199).
b) El manejo de comentarios se realiza considerando las sugerencias de
(Fontela, 2011, pág. 129).
c) El estándar debe ser acorde al lenguaje de programación a utilizar.
d) El equipo tiene la libertad de acordar los puntos a observar en dicho
estándar.
e) El Estándar de documentación de código debe formalizarse por escrito y
ponerse a disposición de todos los integrantes del equipo en el repositorio
del proyecto.
5) Reporte de avance de Residencias Profesionales (ITLP, 2013).
a) Se entregan tres reportes durante el semestre a la Coordinación. Para el
reporte se utiliza el Formato de reporte de avance de proyecto de
Residencias Profesionales que se encuentra en la página del Instituto en la
sección de Residencias Profesionales.
6) Dar a conocer el Estándar para los documentos entregables previamente
acordados
a) Reporte de Residencias Profesionales
10Repositorio del proyecto: sitio donde se guarda físicamente el proyecto y al que todos tienen
acceso.
pág. 90
El Reporte de Residencias Profesionales debe contener los puntos que se

marcan en el documento denominado Instructivo para la elaboración del
Reporte final de la Residencia Profesional (ITLP, 2013).
Particularmente para el punto 1.8 Procedimiento y descripción de las
actividades realizadas. Se debe observar el estándar para evaluar el
apartado de metodología de los proyectos de desarrollo de software
acordado por la Academia de Sistemas y Computación del Instituto
Tecnológico de La Paz; el estándar marca los modelos a obtener como parte
de las Residencias Profesionales para proyectos de desarrollo de software.
b) Manual técnico
Se debe entregar el manual técnico al cliente; en versión electrónica (CD,
por ejemplo). Los productos de las prácticas de desarrollo (8, 9, 10, 11, 12,
13 y 14) forman las secciones de este manual.
7) Dar a conocer los formatos a utilizar en las diferentes prácticas durante el
desarrollo del proyecto:
a) Plantilla de pruebas.
b) Formato de solicitud de cambio.
c) Formato de aprobación de avance.
d) Formato de historias de usuario.
e) Formato de reporte de avance de proyecto de Residencias Profesionales.
f) Formato de evaluación de residentes.
g) Formato del plan de instalación.
h) Formato del plan de conversión.
8) Integrar el Documento de estándares con todos los productos obtenidos en las
actividades anteriores.
 Conexión a internet, navegador de internet, Repositorios de información a

través de Internet, correo electrónico, redes sociales.
 Habilidad para elegir estándares precisos, adecuados y equilibrados al

proyecto.
 Habilidad para establecer estándares para actividades y productos
representativos.
pág. 91
 Habilidad para tener un equilibrio entre los estándares y el proyecto.
 Verificar que todos y cada uno de los documentos de estándares estén

disponibles en el repositorio del proyecto11.
 Verificar que se hayan definido los siguientes estándares y formatos:
a) Estándar de documentación.
b) Estándar de manejo de la programación.
c) Estándar de documentación de código.
d) Formato de Reporte de las reuniones exprés.
e) Estándar de Reporte de Residencias Profesionales.
f) Estándar de manual técnico.
g) Plantilla de pruebas.
h) Formato de solicitud de cambio.
i) Formato de aprobación de avance.
j) Formato de historias de usuario.
k) Formato de reporte de avance de proyecto de Residencias
Profesionales.
m) Formato de evaluación de residentes.
n) Formato del plan de instalación.
o) Formato del plan de conversión.
Métricas
1. Número de estándares definidos.

2. Número de estándares aplicados.
11Repositorio del proyecto: sitio donde se guarda físicamente el proyecto y al que todos tienen
acceso.
pág. 92
Prácticas de equipo de BADESO

Los proyectos se llevan a cabo por personas, y las relaciones interpersonales no
son lógicas; esto dificulta el trabajo en equipo ya que provoca conflictos
personales, ambientes de trabajo tensos, pobre comunicación entre los
integrantes del equipo, entre otras.
Las prácticas de equipo buscan fomentar y ayudar a que los involucrados en el

proyecto se integren adecuadamente para trabajar en un ambiente favorable. Un
proyecto puede fracasar si el equipo no logra trabajar junto. Por eso es importante
que se aprenda a trabajar en equipo, a pesar de nuestras diferencias.
Los fracasos en los proyectos en muchos de los casos poco tienen que ver con
problemas técnicos, son el resultado de un problema de equipo.
El objetivo de las prácticas de equipo son justamente formar un buen equipo de

trabajo, esto se propone lograr por medio de:
1. La práctica Organizar el equipo (PE3) mediante definir las

responsabilidades de cada integrante del equipo, establecer metas entre
todos los integrantes del equipo, definir tareas específicas para cada
miembro del equipo y establecer controles para el avance y desempeño de
cada miembro del equipo.
2. Las prácticas Definir mecanismos de comunicación del equipo (PE4) y
Organizar el equipo (PE3) se proponen para fortalecer las relaciones entre
los integrantes del equipo mediante definir medios de comunicación
efectivos conocidos por todos y establecer reuniones con el equipo de
trabajo, entre otras actividades.
Durante el tiempo de vida de un proyecto, deben realizarse varias actividades que

van desde la planeación, desarrollo, servicios, documentación, control de calidad,
apoyo y hasta el mantenimiento; cuando se trabaja en equipo es necesario
pág. 93
organizarse: para determinar quién realizará cuáles de esas actividades. Lo

deseable es que cada miembro defina y determine las actividades a realizar
porque considera que las desempeña mejor con base en su autoconocimiento; sin
dejar de lado la programación, actividad en la que todos deben participar.
Para establecer las funciones a realizar por cada integrante del equipo se debe
escoger la estructura que éste tendrá. En BADESO, la estructura propuesta se
basa en SCRUM12. La razón es la sencillez que proporciona dicha estructura. Sin
embargo, en las Residencias Profesionales pueden presentarse grupos de 3 o
más integrantes, en estos casos se propone que sea TSPi13, pero queda a juicio
de los asesores.
El objetivo de esta práctica es elegir la estructura organizacional del equipo y

determinar las funciones a realizar por cada integrante del mismo. En caso de que
la residencia se realice de manera individual, esta práctica no es necesaria.
La práctica se realiza una vez que se aprueba el Documento de alcance del

sistema. Al término de la práctica se obtiene documentado el compromiso de las
tareas y roles de cada miembro del equipo en el Documento de formalización de
equipo.
PE3 Práctica
Organizar el equipo.
Objetivo
12SCRUM Metodología ágil de desarrollo. SCRUM es un proceso en el que se aplican de manera

regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el
mejor resultado posible de un proyecto (Agiles.org, 2014).
13TSPi Team Software Process (TSP) proporciona un marco de trabajo de procesos definidos que
está diseñado para ayudarle a equipos de gerentes e ingenieros a organizar y producir proyectos
de software (libre, 2014).
pág. 94
Elegir la organización del equipo y asignar roles.
Entrada Resultado
1. Anteproyecto de Residencias 1. Documento de formalización de

Profesionales del ITLP autorizado. equipo.
Guía
Actividades

2. De acuerdo a los residentes integrados en el Anteproyecto de Residencias
Profesionales, definir la organización del equipo
a. Cada miembro del equipo hace una lista de sus habilidades y
fortalezas.
b. Cada miembro del equipo hace una lista de sus debilidades.
3. Si el número de integrantes es mayor a dos, entonces la estructura del equipo
se basa en los roles que maneja el TSPi.
a. Con base en las listas de habilidades de los integrantes del equipo, se
elige al líder de equipo.
4. Si el número de integrantes del equipo es menor a 5, entonces
a. Fusionar roles de acuerdo al número de integrantes y de las
habilidades identificadas.
5. Si son dos integrantes se manejan los roles propuestos por SCRUM y se elige
el SCRUM master.
6. El reporte de la reunión exprés se basa en el propuesto en la metodología ágil
SCRUM. Es un reporte oral, donde cada miembro del equipo da respuesta a
tres preguntas: ¿qué hice?, ¿qué voy a hacer?, ¿qué obstáculos tengo para
hacerlo?.
7. Si el modelo elegido es TSPi entonces cada miembro del equipo define sus
funciones con base en el rol asignado. Si el modelo a usar es SCRUM todos
los integrantes del equipo juegan el papel de programadores y hay un SCRUM
master.
8. Documentar funciones y responsabilidades de cada miembro del equipo en el
Documento de formalización del equipo.
9. Con las prácticas aplicadas hasta este momento, empezar a construir el punto
1.8 del Reporte de Residencias Profesionales apoyado del Documento de
estándares.
pág. 95
 Habilidad para comunicarse en forma oral y escrita.

 Habilidad para auto describirse.
 Habilidad para identificar habilidades.
 Las funciones deben ser determinadas con base en las habilidades

identificadas por cada miembro del equipo y las propuestas por el modelo
elegido.
Métricas
1. Roles repartidos.
La comunicación entre todos los involucrados en el proyecto es fundamental para

el logro de los objetivos, de ahí la importancia de esta práctica.
Entre los integrantes del equipo es necesario que estén “localizables”, es decir,
no debe darse la oportunidad de que algún miembro del equipo desaparezca por
días. El equipo debe tener la capacidad de trabajar de forma presencial y no
presencial, síncrona o asíncronamente.
La información del proyecto debe estar disponible todo el tiempo para todos los
integrantes, no debe depender de una persona. El objetivo de esta práctica es
pág. 96
justamente ese: “Establecer los mecanismos para compartir la información entre

los integrantes del equipo”. La práctica se inicia una vez que se aprueba el
Documento de alcance del sistema.
Por otro lado, es recomendable también establecer las formas de comunicación

con los asesores de la Residencia Profesional, porque tener una buena y
constante comunicación con ellos favorece el avance y feliz término del proyecto.
Esta práctica aplica a los integrantes del equipo y a todos los involucrados en el
proyecto.
PE4 Práctica
Definir mecanismos de comunicación del equipo.
Objetivo
Establecer los mecanismos necesarios para compartir la información entre los

miembros del equipo.
Entrada Resultado
1. Anteproyecto de Residencias 1. Documento de formalización de la

Profesionales del ITLP comunicación.
autorizado.
Guía
Actividades

2. De acuerdo a los residentes integrados en el proyecto de Residencias
Profesionales, establecer medios de comunicación síncronos
a. Reuniones de proyecto.
pág. 97
i. Establecer agenda de reunión de proyecto especificando los

siguientes puntos: Fecha de la reunión, lugar de la reunión,
acciones a reportar, puntos a tratar, asignación de nuevas
acciones.
ii. Definir tiempos para cada punto de la agenda.
iii. Durante la reunión documentar los acuerdos tomados.
iv. Elaborar el plan de reuniones exprés indicando días (máximo
cada tercer día), duración y lugar.
v. Establecer lugar de reunión, días y duración.
b. Durante la reunión exprés: Dar un reporte breve de lo realizado desde
la última reunión, compartir que hará antes de la próxima reunión y
comentar los obstáculos que considera que podrían presentarse.
c. Reuniones de asesoría y/o resolución de problemas. Cuando se
necesiten.
d. Mensajería móvil. Cada miembro del equipo instalará un software
común de chat en su dispositivo electrónico móvil y se pondrán a
disposición los números de teléfonos.
Profesionales, establecer mecanismos de comunicación asíncronos. Se usará
para cualquiera de los siguientes puntos: revisiones de productos,
aclaraciones, noticias e intercambio de documentos.
a. Correo electrónico.
b. Salas de chat.
c. Foros.
d. Repositorio del código del proyecto.
4. Los datos de los integrantes del proyecto que resulten de los acuerdos de
comunicación deben registrarse y agruparse en una agenda del equipo.
Profesionales, definir el Calendario de comunicación: Definir el calendario de
reuniones de proyecto indicando los siguientes puntos: Tipo de Reunión,
Fecha y producto a presentar.
6. Establecer un repositorio para el código del proyecto. Se usará para cualquiera
de los siguientes puntos: revisiones de productos, compartir y/o actualizar
código.
7. Integrar el Documento de formalización de la comunicación con todos los
productos obtenidos en las actividades anteriores y cumpliendo con el
estándar correspondiente.
pág. 98
 Repositorios de información a través de Internet, correo electrónico, redes

sociales.

 Capacidad para comunicarse de forma oral y escrita.
 Destreza en el manejo de redes sociales.
 Verificar que la agenda cumpla con todos los puntos de la estructura y los
tiempos para cada punto antes de ser enviada a los integrantes del equipo.
 Comprobar con una semana de anticipación que los productos a presentar ya
estén elaborados.
 Asegurar que se cumplan los tiempos asignados.
 Revisar que en cada reunión exprés se lleven a cabo los tres puntos de la
estructura por cada miembro del equipo.
 Examinar tabla de registro de acuerdos tras cada reunión de proyecto.
 Verificar que el calendario de comunicación contenga la información completa.
 Verificar que el de Documento de formalización de la comunicación incluya:
a. Calendario de comunicación.
b. Tabla de registro de acuerdos.
c. Plan de reuniones exprés.
d. Agenda del equipo.
Métricas
1. Tiempo real de las reuniones del proyecto.

2. Tiempo real de la reunión exprés.
pág. 99
Manejar cambios en el proyecto (PA7).
Una de las principales causas de fallas en los proyectos es la mala administración

de cambios. Los cambios pueden ser pequeños ajustes al sistema y no deben ser
requerimientos crecientes o faltantes por una mala definición. Querer incluir
nuevos requerimientos provoca retrasos en los proyectos de Residencias
Profesionales.
El objetivo de esta práctica es documentar los cambios solicitados así como la

gestión de los mismos; es decir, qué ocurre con la solicitud si se aprueba y el
seguimiento del cambio. Sí no se aprueba, por qué no se aceptó, registrando las
razones del rechazo del cambio. La práctica se lleva a cabo únicamente cuando
se solicita un cambio.
Realizar esta práctica permite llevar un registro de las solicitudes del cliente y por
lo tanto, de las responsabilidades que conlleva. También permite tener un control
sobre los cambios.
PA7 Práctica
Manejar cambios en el proyecto.
Objetivo
Establecer el procedimiento para manejar los cambios en el proyecto, desde su

planteamiento, aprobación y si es el caso, seguimiento.
Entrada Resultado
1. Formato de solicitud de 1. Documento Formato de solicitud de

cambio. cambio con respuesta14.
14Como resultado de un cambio aprobado también se actualizan los documentos impactados.
pág. 100
Guía
Actividades
1. El Documento de Estándares contiene los formatos, plantillas, estándares y

el manejo del proyecto.
2. Solicitud de cambio recibida:
a. Llenar el Formato de solicitud de cambio (que se proporciona en la
práctica Dar a conocer el manejo de estándares para el proyecto
(PA6) por parte del solicitante
i. Se proporciona el Formato de solicitud de cambio al cliente y
se le acompaña a llenarlo.
ii. Se busca retroalimentar en una reunión no mayor a 15
minutos el cambio que se desea introducir.
iii. Se acuerda con el cliente una fecha posterior, para dar
respuesta a la solicitud.
b. Evaluación de la solicitud de cambio
i. Revisión de la solicitud de cambio por parte del equipo.
1. Reunirse el equipo ya sea en reunión exprés o en
reunión semanal para revisar la solicitud de cambio.
2. Determinar el tipo de cambio del que se trata.
ii. Establecer impacto del cambio.
1. Determinar a qué elementos afecta el cambio.
2. Evaluar cómo implementar el cambio.
3. Determinar quién implementará el cambio.
4. Determinar el tiempo que llevará realizar el cambio.
iii. Dictaminar la respuesta al cambio solicitado.
1. Llenar el Formato de solicitud de cambio en la parte
de desarrollador.
2. Acordar la respuesta al cambio solicitado.
3. Si el cambio es rechazado, registrar las razones del
porqué del rechazo.
4. Si el cambio es aprobado entonces, de acuerdo al
impacto determinado se hacen los cambios en los
elementos afectados.
c. Informar al cliente de la respuesta del cambio solicitado.
i. Hablar con el cliente e informar la respuesta al cambio
solicitado.
pág. 101
1. Si el cambio es aprobado, supervisar la

implementación del cambio.
2. Si es rechazado, informar al cliente las razones.
 Herramienta de manejo de cambios.
 Habilidad para establecer y administrar calendarios.

 Habilidad para manejar contingencias.
 Habilidad para negociar.
 Verificar la completitud y precisión de los datos de la forma de solicitud de

cambio.
 Verificar que se llevó a cabo una retroalimentación verbal con el cliente
además de la solicitud de cambio.
Métricas
1. Número de cambios solicitados.

2. Número de cambios aprobados.
3. Número de cambios realizados.
4. Número de cambios rechazados
Prácticas de desarrollo de BADESO

Las prácticas de desarrollo incluyen las actividades que se basan en el ciclo de
vida y representan las actividades técnicas del proyecto.
pág. 102
Cuando se construye un sistema debe visualizarse como parte de la organización

a la que pertenece, como parte de un todo. No es un elemento aislado, no es una
isla; es un subsistema de un sistema mayor: la empresa. Por lo tanto, para
entender el funcionamiento del software a construir, es necesario comprender el
funcionamiento de sistema del cual forma parte.
Las entradas a esta práctica son toda la información que permite al residente
convertirse en “experto” en el tipo de aplicación a construir. La salida de esta
práctica es justamente el modelo que representa al sistema y al mundo que lo
rodea.
PD8 Práctica
Modelar el negocio.
Objetivo
Modelar el contexto del sistema a construir.
Entrada Resultado
1. Documento de estándares. 1. Documento de modelo de negocio.

2. Documento de plan del 2. Formato de aprobación de avance
proyecto aprobado. para el Documento de modelo de
3. Documento de formalización de negocio.
equipo. 3. Documento Reporte final de la
4. Documento de formalización de Residencia Profesional 3.0.
la comunicación. 4. Formato de solicitud de cambio15.
5. Documento Formato de
formalización del cambio con
respuesta.
15 Este formato se obtiene como salida si se necesita realizar cambios al proyecto.
pág. 103
6. Documento Reporte final de la

Residencia Profesional 2.0.
Guía
Actividades

2. Realizar investigación preliminar
a. Describir el problema
i. Pedir a todos los involucrados que hagan por escrito una
descripción del sistema actual, donde describan los procesos que
realizan actualmente16.
ii. Si es posible investigar los procesos en documentos fuentes, para
complementar la información proporcionada.
iii. Si es posible utilizar otra técnica de obtención de información como
observación para complementar la información obtenida.
b. Realizar un diagrama de actividades del sistema actual con UML o
modelar con BPMN.
c. Elaborar glosario del sistema.
d. Integrar el Documento de modelo de negocio con los incisos a, b y c.
3. Llenar Formato de aprobación de avance para el Documento de modelo de
negocio.
4. Actualizar el Documento Reporte final de la Residencia Profesional 2.0 con la
información resultante incorporando el Documento de modelo de negocio al punto
1.8; denominar Reporte final de la Residencia Profesional 3.0.
5. Si es el caso llenar el Formato de solicitud de cambio y ejecutar Manejar cambios
en el proyecto (PA7).
16En ocasiones cuando pedimos a los involucrados que ellos hagan esta descripción no funciona,
entonces se recomienda facilitar la sesión en la que se modelen y documenten los procesos
actuales. De esta forma también se garantiza que haya comprensión del modelo y procesos de
negocio y aprobación de la documentación del mismo
pág. 104
 Herramientas de modelado como Herramientas CASE para la elaboración de

diagramas UML.
 Herramientas de edición de texto.
 Habilidad de análisis.
 Habilidad para comunicarse de forma verbal y escrita.
 Verificar entendimiento del negocio plasmado en el modelo.

 Verificar aprobación del modelo del negocio por parte del cliente.
Métricas
1. Formato de aprobación de avance para el Documento de modelo de negocio

firmado por el cliente.
Obtener requisitos del sistema (PD9).
Es el proceso en el que se establecen los servicios que el cliente requiere que el

sistema realice y las restricciones bajo las cuales será desarrollado.
El objetivo de la práctica 9 es realizar una especificación completa de los

requisitos del sistema. Un sistema pobremente especificado decepcionará al
usuario, ya que la definición de los requisitos afecta la calidad, el tiempo de
desarrollo y la completitud del software.
Para dar inicio a esta práctica es necesario haber definido el alcance del sistema
en la práctica Determinar el alcance del sistema (PA1), y ejecutar la práctica
Modelar el negocio (PA8) para realizar un modelo del negocio. En esta práctica
pág. 105
es de suma importancia revisar los requisitos con el cliente y asegurarse que sean
entendidos por todos los involucrados en el proyecto. Una vez logrado esto, firmar
la aprobación de los requisitos del sistema.
PD9 Práctica
Obtener requisitos del sistema.
Objetivo
Definir los requisitos del sistema a construir a partir de la comprensión del problema
y su entorno.
Entrada Resultado
1. Documento de estándares. 1. Formato de aprobación de avance

2. Documento de modelo de para el Documento de modelo de
negocio aprobado. requisitos.
3. Documento de avance de 2. Documento de modelo de
proyecto. requisitos.
4. Documento del alcance. 3. Formato de solicitud de cambio.
Guía
Actividades

2. Identificar requisitos
a. Revisar el objetivo general en el Documento del alcance.
i. Pedir a los involucrados del sistema que hagan un resumen de
necesidades, haciendo hincapié que no es de soluciones.
ii. Validar el objetivo general del Anteproyecto de Residencias
Profesionales del formato del ITLP con la información anterior.
iii. En caso de ser necesario, redefinir el objetivo general en
colaboración con el cliente.
pág. 106
iv. Validar los requisitos identificados en el Anteproyecto de

Residencias Profesionales del formato del ITLP con el resumen
de necesidades. En caso de ser necesario, modificar los que se
requieran en colaboración con los involucrados.
b. Especificar requisitos
i. Identificar los requisitos.
ii. Clasificar los requisitos como funcionales y no funcionales de
acuerdo a su naturaleza.
c. Elaborar modelo de casos de uso.
d. Elaborar modelo de datos del negocio (modelo entidad relación).
e. Conformar el Documento de modelo de requisitos con los productos
obtenidos en el inciso a, b, c, d y e.
requisitos.
 Herramientas CASE para la elaboración de diagramas UML.

 Verificar requisitos claros, completos; no ambiguos.

 Verificar aprobación del modelo de requisitos por parte del cliente.
 Verificar el modelo de datos contra los requisitos.
Métricas
1. Número de requisitos funcionales.
pág. 107
2. Número de requisitos no funcionales.

3. Número de casos de uso.
Realizar el análisis del sistema (PD10).
El objetivo de realizar el análisis del sistema es construir un bosquejo de lo qué se

va a construir. Representar los requisitos en un modelo permite enfocarse en los
datos, definir las funciones y representar el comportamiento; lo que es una guía
para el diseño.
La entrada para esta práctica, entre otras, es el modelo del negocio; ya que la
especificación de requisitos y el análisis del sistema son prácticas que pueden
realizarse de manera simultánea. Esto brinda la oportunidad de aclarar requisitos
al irlos modelando.
La salida de esta práctica es la representación de lo qué se va a construir sin

detalles del cómo construirlo.
PD10 Práctica
Realizar el análisis del sistema.
Objetivo
Construir los modelos del análisis del sistema.
Entrada Resultado
1. Documento de modelo de 1. Documento de modelo de análisis.

negocio aprobado. 2. Formato de aprobación de avance
2. Documento de estándares. para el Documento de modelo de
3. Reporte final de la Residencia análisis.
Profesional del ITLP 3.0
pág. 108

4. Formato de solicitud de cambio.
Guía
Actividades

2. Retomar el modelo de datos del negocio y elaborar el modelo de datos del
análisis normalizado.
3. Elaborar modelo de clases del análisis.
5. Documentación de los casos de uso de acuerdo al formato acordado. (Booch,
Rumbaugh, & Ivar, 1999).
6. Construir la interfaz del sistema, de acuerdo a los cinco principios para el buen
diseño (Shneiderman, 2005).
7. Si es posible, diseñar el modelo de pruebas del sistema con base en el formato
propuesto en la práctica Dar a conocer el manejo de estándares para el
proyecto (PA6).
8. Integrar los productos generados siguiendo el Documento de estándares y
denominar como el Documento de modelo de análisis.
9. Actualizar Reporte final de la Residencia Profesional del ITLP 3.0 con el
Documento de modelo de requisitos y con el Documento de modelo de análisis.
Al documento resultante, denominar Reporte final de la Residencia Profesional
del ITLP 4.0.
análisis.
11. Si es el caso, llenar el Formato de solicitud de cambio y ejecutar Manejar
 Herramientas CASE para la elaboración de diagramas UML.

pág. 109
 Habilidad para diseño de interfaces.
 Verificar aprobación de la interfaz por parte del cliente.

 Revisar requisitos en las interfaces.
Métricas
1. Número de casos de uso documentados.

2. Número de interfaces.
3. Número de casos de prueba.
El objetivo de diseñar el sistema es proporcionar las especificaciones de su

construcción. El diseño debe satisfacer los requisitos del usuario.
Diseñar es un proceso creativo que debe fundamentarse en principios para el

buen diseño y servir de guía para saber cómo se construirá el mismo.
Las entradas para esta práctica son los modelos de negocio, requisitos y análisis
que proporcionan la información necesaria del problema que se quiere solucionar.
La salida de esta práctica es el modelo de diseño que da solución al sistema.
PD11 Práctica
Diseñar el sistema.
pág. 110
Objetivo
Crear la representación del software que sirva de guía para su construcción.
Entrada Resultados
1. Documento de modelo de 1. Documento de modelo de diseño.

requisitos aprobado. 2. Formato de aprobación de avance
2. Documento de modelo de para el Documento de modelo de
análisis aprobado. diseño.
3. Documento de estándares. 3. Reporte final de la Residencia
4. Reporte final de la Residencia Profesional del ITLP 5.0.
Profesional del ITLP 4.0. 4. Formato de solicitud de cambio.
Guía
Actividades

2. Diseñar base de datos
a. Con el modelo de datos del análisis diseñar la base de datos.
b. Implementar el modelo de datos en un lenguaje de programación.
c. Validar el modelo de la base de datos mediante consultas de información
necesarias para los requisitos del sistema.
3. Arquitectura del sistema (Braude, 2003)
a. Seleccionar entre las diferentes arquitecturas estándar la que mejor
satisface los objetivos seleccionando entre los patrones arquitectónicos,
uno que se ajuste a la aplicación. Si no desea seleccionar una
arquitectura estándar o un patrón arquitectónico, ambos pueden servirle
de guía para desarrollar su propia arquitectura.
b. Definir el ambiente de construcción: los frameworks, las bibliotecas,
manejador de base de datos, etc. con sus versiones.
c. Con la información anterior, modelar la arquitectura del sistema en un
diagrama de paquetes (separación lógica); modelando las relaciones y
dependencias entre los subsistemas, frameworks y/o bibliotecas.
pág. 111
d. Con la información obtenida en las actividades anteriores, elaborar el

diagrama de componentes para representar la organización de la
aplicación mediante el modelaje de las relaciones entre los componentes
del software y sus interfaces.
e. Actualizar el modelo de paquetes y de componentes en caso de ser
necesario.
4. Diseñar modelo de clases17
a. A partir del modelo de la base de datos del paso 1: las clases
identificadas y la arquitectura, identificar clases y atributos.
b. Identificar métodos para cada una de las clases.
c. Modelar el comportamiento con diagramas de secuencia e identificar
clases de diseño faltantes y/o refinar el diagrama de clases de diseño.
i. Construir los diagramas de secuencia por cada caso de uso
identificado en los requisitos.
ii. Identificar e introducir casos de uso adicionales. Si se requieren,
con su respectivo diagrama de secuencia. Tomar como base el
modelo de arquitectura y el modelo de clases del diseño.
5. Revisar el modelo de interfaz de usuario
a. Partiendo del Modelo de interfaz que se realizó en el Modelo de análisis,
el diagrama de clases del diseño y los diagramas de secuencia.
Identificar y añadir si es el caso, las interfaces de usuario faltantes.
b. Identificar las interfaces externas partiendo del Modelo de requisitos.
c. Identificar las interfaces internas tomando como base el Modelo de
clases del diseño.
d. Si se considera necesario y el tiempo lo permite, realizar diagrama de
estados de la interfaz de usuario.
e. Actualizar el Modelo de la interfaz de usuario si es necesario.
6. Diseñar el nivel de componentes
a. Para realizar esta actividad se requiere del diagrama de paquetes,
diagrama de componentes, diagramas de secuencia y el modelo de
clases del diseño.
b. Realizar para cada componente
i. Identificar las interfaces apropiadas entre componentes.
ii. Identificar las clases requeridas para administrar cada
componente.
17Es necesario tomar en cuenta que algunas clases se añadieron en la actividad de diseño de la
arquitectura del sistema.
pág. 112
iii. Para las clases o componentes que se considere necesario

modelar el comportamiento, con diagramas de secuencia, de
actividades, de estado o seudocódigo.
7. Integrar los productos generados incluyendo el modelo de la base de datos del
Documento de modelo de análisis siguiendo el Documento de estándares y
denominar como el Documento de modelo de diseño del sistema.
Documento de modelo de diseño; denominar Reporte final de la Residencia
diseño.
 Herramientas CASE para la elaboración de diagramas UML, lenguajes de

programación, Herramientas de bases de datos.
 Conocimientos de modelado con UML y diagramas de flujo.

 Habilidad para la resolución de problemas.
 Conocimientos de bases de datos, diseño de sistemas y programación.
 Verificar el diagrama de paquetes con la arquitectura elegida.

 Verificar el diagrama de componentes con la arquitectura elegida.
 Verificar en el diagrama de componentes las relaciones y dependencias
entre ellos.
 Revisar en el diagrama de componentes el acoplamiento y la cohesión,
buscando maximizar la cohesión y minimizar el acoplamiento.
 Verificar el diagrama de clases del diseño con respecto al modelo de
requisitos (diagrama de casos de uso y lista de requisitos).
pág. 113
 Verificar que en el modelo de clases estén:

o Indicados el tipo de los atributos.
o Indicados los valores que devuelven los métodos.
o Indicados parámetros para los métodos y de qué tipo son.
o Especificados la visibilidad de atributos o métodos.
 Verificar los diagramas de secuencia con respecto a la documentación de
los casos de uso que se obtiene del Documento de modelo de requisitos que
se realizó en la práctica Obtener requisitos del sistema (PD9) y al diagrama
de clases del diseño.
 Verificar que las interfaces de usuario nuevas cumplan con los estándares
de diseño acordados (Shneiderman, 2005).
 Si se realiza el diagrama de estados de la interfaz, verificar congruencia con
la interfaz.
 Verificar que el modelo a nivel de componentes defina para cada
componente su(s) clase(s), interfaz (ces) y componente(s) asociado(s).
 Verificar que se observe en los diagramas la arquitectura elegida.
 Verificar que los diagramas resultantes de esta práctica modelen el diseño.
Métricas
1. Número de objetivos del diseño.

2. Número de diagramas de secuencia.
3. Número de paquetes.
4. Número de diagramas de componentes.
5. Número de clases.
6. Número de pantallas.
7. Número de atributos.
8. Número de métodos.
9. Número de casos de uso.
El objetivo de la construcción del software es traducir el Documento de modelo de

diseño a código fuente. Dicho código y su documentación debe ser claro, sencillo
y elegante, de tal forma que sea verificable, fácil de depurar, fácil de probar y fácil
pág. 114
de mantener. Esto suena sencillo de hacer, ya que si se tiene el diseño, la

programación se da de forma más natural. Sin embargo, la interpretación errónea
del diseño conduce a un código erróneo; la complejidad o restricciones del propio
lenguaje de programación pueden conducir a un código fuente difícil de mantener
y probar.
La entrada principal a esta práctica es el modelo del diseño del sistema y se

espera como salida principal los componentes del software probados,
documentados e integrados. Estos se van probando conforme se van
construyendo, pero una vez terminado este proceso, es necesario integrarlos para
construir el sistema. Cada componente se va integrando incrementalmente
conforme se va desarrollando.
PD12 Práctica
Construir el sistema.
Objetivo
Escribir el código fuente en concordancia con las especificaciones del Documento de

modelo de diseño, de modo que se facilite la depuración, pruebas y modificaciones.
Entrada Resultado
1. Documento de diseño del 1. Documento de construcción de

sistema aprobado. software.
2. Documento de estándares. 2. Componentes de software
3. Reporte final de la Residencia probados, documentados e
Profesional del ITLP 5.0. integrados.
3. Formato de aprobación de avance
para los componentes de software
probados, documentados e
integrados.
pág. 115
Guía
Actividades

2. Establecer la estrategia de implementación de acuerdo a la arquitectura elegida.
3. Con base en dicha estrategia repartir los componentes entre los integrantes del
equipo, si es el caso.
4. Revisar el Documento de estándares
a. Manejo de la programación definido en el Documento de estándares,
punto 2.
b. Estándar de documentación del código definido en el Documento de
estándares, punto 3.
c. Si es necesario hacer adecuaciones a los estándares existentes.
i. Actualizar la documentación.
5. Explicar la técnica de codificación.
6. Para cada componente:
a. El programador requiere
i. Interfaces apropiadas para dicho componente.
ii. Clases requeridas para administrar dicho componente.
iii. Modelo de comportamiento del componente.
b. Hacer
i. Desarrollar el componente.
ii. Depurar el componente.
iii. Aplicar pruebas de desarrollo.
iv. Probar el componente con pruebas de caja blanca.
v. Aplicar la lista de comprobación del código que proporciona el
Documento de estándares,
Hasta lograr el comportamiento y resultado esperado.
7. Integrar en el sistema cada componente terminado.

a. Probar el sistema con el nuevo componente.
8. Elaborar diagrama de despliegue.
9. Integrar los productos generados y denominar como el Documento de
construcción de software.
pág. 116
Documento de construcción de software; denominar Reporte final de la
Residencia Profesional del ITLP 6.0.
11. Llenar Formato de aprobación de avance para los componentes de software
probados, documentados e integrados.
 Lenguajes de programación.
 Herramientas de edición de texto como Word.
 Conocimientos de bases de datos y programación.
 Verificar que el código cumple con las especificaciones del diseño.

 Verificar que el código cumple con los puntos de la lista de comprobación.
 Verificar el apego a estándares de documentación.
 Verificar el apego al manejo de la programación y los estándares de
implementación.
Métricas
1. Número de componentes probados.

2. Número de líneas de código.
Probar el Sistema (PD13).
Las pruebas de software son el proceso de buscar y enmendar errores.

Contrariamente a lo que se piensa, si una prueba no logra detectar errores,
pág. 117
entonces puede considerarse que fracasó, ya que el no encontrar errores no

garantiza que el software se encuentre libre de estos, sino que indica que no se
pudieron detectar. Cuando se desarrolla software, lo deseable es localizar y
corregir los errores antes de entregarlo al cliente.
La fase de pruebas generalmente la vemos como la fase posterior a la

construcción de software, cuando en realidad debe estar asociada a todas las
fases del desarrollo del mismo y debería efectuarse tanto la verificación de
requisitos como la correcta operación del código.
Una prueba perfecta no es posible, porque literalmente no es viable verificar cada

una de las combinaciones posibles de entradas, salidas y estados. Entonces,
¿qué tantas pruebas deben hacerse y dónde deben aplicarse?
Hay distintos tipos de aplicaciones y particularmente hay sistemas críticos: como

sistemas médicos, sistemas de tráfico aéreo, etc… que deben ser probados con
mayor rigor. De tal forma que la respuesta a la pregunta planteada es, que
depende del tipo de aplicación. En la presente tesis se proponen técnicas de
prueba para software convencional no crítico en el que deberán hacerse pruebas
más exhaustivas.
La mayoría de los desarrolladores dedican poco tiempo a las pruebas,

generalmente es una fase que incluyen en la etapa de construcción. Sin embargo,
si las pruebas se inician en las primeras fases del ciclo de vida, puede empezar a
validar los requerimientos. No hacerlo es como dejar crecer una pequeña bola de
nieve colina abajo, ¿qué significa esto? Bueno, si hace falta un requisito, es mejor
darte cuenta en las primeras fases que en las etapas finales, para no arrastrar el
error y segundo, porque es más económico.
Para esta práctica la entrada requerida es el software terminado e integrado. Una

vez ejecutada la práctica se tendrá como resultado el software probado y los
manuales del sistema.
pág. 118
PD13 Práctica
Probar el sistema.
Objetivo
Aplicar pruebas del sistema y de aceptación.
Generar manuales del sistema.
Entrada Resultado
1. Componentes de software 1. Software probado.

probados, documentados e 2. Documento de pruebas del sistema.
integrados aprobados.
3. Formato de aprobación de avance
2. Documento de la construcción para el sistema probado.
del sistema.
4. Manual de técnico.
3. Documento de estándares. 5. Reporte final de la Residencia
4. Reporte final de la Residencia Profesional del ITLP 7.0
Guía
Actividades

2. Elaborar los planes de pruebas del sistema y de aceptación.
a. Establecer lo necesario para cada prueba: quién participará,
infraestructura necesaria, fechas y hora en que se harán las pruebas.
b. Definir los casos de prueba
c. Definir los resultados esperados
3. Para cada una de las pruebas a aplicar al sistema, realizar los siguientes pasos:
a. Ejecutar el plan de pruebas.
b. Corregir el sistema de acuerdo a los resultados que arroje la prueba.
c. Evaluar las pruebas.
4. Integrar los productos generados y denominar como el Documento de pruebas
del sistema.
pág. 119
5. Hacer el Manual técnico integrando los documentos resultantes de la ejecución

de las prácticas.
6. Actualizar el Documento Reporte final de la Residencia Profesional del ITLP 6.0
en el punto 1.8 con la información del proceso de pruebas y actualizar anexos
con las portadas e índices de ambos manuales; denominar el documento
resultante Reporte final de la Residencia Profesional del ITLP 7.0.
7. Llenar Formato de aprobación de avance para el sistema probado.
 Software de apoyo a pruebas.
 Conocimientos de programación.
 Conocimientos de cómo probar software.
 Conocimientos de herramientas de prueba.
 Software funcionando.
 Software aceptado por el usuario.
Métricas
1. Numero de errores en la prueba del sistema.

2. Numero de errores corregidos en la prueba del sistema.
3. Numero de errores en la prueba de aceptación.
4. Numero de errores corregidos en la prueba de aceptación
pág. 120
Es el conjunto de tareas necesarias para instalar el sistema desarrollado en el sitio

del cliente; para hacer la transición a los usuarios de forma efectiva y
eficientemente.
El objetivo de la implantación del sistema es instalar y liberar el sistema en el

ambiente de la organización: lograr que los usuarios de la información y los
operadores del sistema se familiaricen con la operación del sistema y sus
resultados.
Hay muchas razones por las que un proyecto de software puede fracasar, pero no
se puede permitir que la razón del fracaso sea una mala implantación.
La entrada principal a esta práctica es el software y los entregables; sin embargo

es una práctica que se puede empezar a realizar simultáneamente con la Práctica
Probar el sistema (PD13), porque puede ganarse tiempo si se empiezan realizar
las actividades de instalación y pruebas en el lugar del cliente. El proceso a
realizar es la conversión y liberación del sistema. Una vez realizada la práctica se
libera la Residencia Profesional, porque el proceso de implantación ya se ha
finalizado.
PD14 Práctica
Implantar el sistema.
Objetivo
Instalar y liberar el sistema.
Entrada Resultado
pág. 121
1. Documento de estándares. 1. Software entregado y liberado.

2. Componentes de software 2. Documentos de aceptación.
probados, documentados e 3. Reporte final de la Residencia
integrados aprobados. Profesional del ITLP versión final.
3. Documento de construcción 4. Reporte final de la Residencia
de software. Profesional del ITLP versión final en
4. Software probado aprobado. dispositivo de almacenamiento
5. Documento de pruebas del secundario.
sistema. 5. Discos del Sistema.
6. Manual de instalación.
Profesional del ITLP 7.0
Guía
Actividades
1. El Documento de Estándares contiene los formatos, plantillas, estándares y

el manejo del proyecto.
2. Instalar el sistema
a. Elaborar el plan de instalación
i. Preparar la instalación.
ii. Instalar el sistema
iii. Probar el sistema
b. Ejecutar plan de instalación
3. Capacitar al personal
a. Elaborar el plan de capacitación.
i. Identificar al personal a capacitar.
ii. Determinar el método de capacitación.
b. Ejecutar plan de capacitación.
4. Manejar la conversión del sistema
a. Elaborar el plan de conversión
i. Determinar la conversión de equipo
ii. Determinar el enfoque de conversión a aplicar
iii. Manejar la conversión de archivos
iv. Prepararlos procedimientos de arranque
b. Ejecutar el plan de conversión
5. Entregar el sistema
a. Entregar documentación del software.
pág. 122
b. Entregar software y programas complementarios.

c. Realizar presentación del sistema.
6. Revisión post implantación
a. Revisar periódicamente las actividades de la persona encargada de
los datos de entrada
b. Detectar algún problema de programación que requiera solución
inmediata
c. Comprobar si los controles del sistema funcionan correctamente
d. Retirar los procedimientos, programas, formas, etc., anticuados y de
relación que formaron parte del sistema anterior o del periodo de
conversión.
7. Realizar junta de aceptación.
a. Obtener Documento de aceptación.
8. Integrar los productos generados y denominar como el Documento de
modelo de Implantación del sistema.
9. Realizar evaluación del proceso de desarrollo realizado.
a. Plantear las conclusiones de la Residencia Profesional.
b. Plantear las recomendaciones y ajustes necesarios para futuros
residentes profesionales.
c. Evaluar el impacto del producto de la Residencia Profesional del
ITLP.
10. Actualizar el Documento Reporte final de la Residencia Profesional del ITLP
7.0 con la información resultante y denominar Reporte final de la Residencia
Profesional del ITLP versión final.
 Lenguajes de programación.
 Habilidad de planeación, administración, comunicación y soporte.

 Conocimientos de programación y bases de datos.
pág. 123
 Verificar que los requerimientos del sistema se han instalado correcta y

completamente.
 Verificar los resultados de las pruebas.
 Verificar el seguimiento de errores resultantes de las pruebas.
 Verificar la asistencia a la capacitación.
 Verificar la ejecución completa de los temas del plan de capacitación.
 Verificar que los requerimientos de conversión han sido cubiertos.
 Verificar la correcta conversión de archivos.
 Verificar que la conversión del sistema ha sido completada.
 Verificar la entrega completa de productos.
Métricas
1. Número de productos entregados y Número de productos a entregar.

2. Número de archivos de conversión y Número de archivos convertidos.
3. Número de programas complementarios a instalar y Número de programas
complementarios instalados.
4. Número de errores detectados y Número de errores corregidos.
5. Número de temas de capacitación planeados y Número de temas de
capacitación vistos.
6. Tiempo de capacitación planeado y tiempo de capacitación real.
pág. 124
Capítulo 5 Aplicación del método
BADESO.
“Aquella teoría que no encuentre aplicación práctica en la vida,
es una acrobacia del pensamiento”, Swami Vivekananda.
Introducción
A continuación se muestra como las catorce prácticas del método BADESO han
sido aplicadas en un proyecto de Residencias Profesionales. La intención es,
además de poner en práctica lo descrito, encontrar las fortalezas y debilidades del
mismo.
En primer término se detallan los datos de la empresa para el caso de estudio de

la Residencia Profesional que se llevó a cabo en el Laboratorio de Física del
Instituto Tecnológico de La Paz (ITLP). Después se describen las actividades y la
experiencia obtenida por los alumnos durante la realización de cada práctica. A
continuación, las conclusiones de cómo les sirvió el aplicar las prácticas durante
el desarrollo de la residencia. Posteriormente se incluye una retroalimentación
para el método BADESO de acuerdo a la experiencia vivida.
Datos de la empresa
El Instituto Tecnológico de La Paz (ITLP) fue fundado en octubre de 1973, bajo la
misión de ser un instrumento para el desarrollo de la comunidad de Baja California
Sur. Es una Institución pública de educación dependiente de la Secretaría de
pág. 125
Capítulo 5 Aplicación del método BADESO
El Sistema de Control para el Laboratorio de Física (SICOLF) se desarrolló para

el Laboratorio de Física que depende organizacionalmente del Departamento de
Ciencias Básicas del ITLP; se contó con el apoyo de:
 El Jefe del Laboratorio de Física como asesor externo y como otros

involucrados1: prestadores de servicio social, profesores que hacen uso del
laboratorio y alumnos que cursan materias del área de Ciencias Básicas.
 Asesora interna.
El Laboratorio de Física es un espacio en donde se crea una retroalimentación de

las materias de Ciencias Básicas. El aula cuenta con computadoras, las cuales
se utilizan para el manejo de software, el cual es indispensable para
complementar las actividades que ahí se realizan: manejo de prácticas, los
materiales a utilizar y el desarrollo de las prácticas. También se cuenta con un
pequeño almacén, donde se requiere actualizar el inventario cada determinado
tiempo y esto se realiza de manera manual, llevando registros de los adeudos,
para tener control sobre éstos.
El sistema debe alcanzar los siguientes objetivos:
1. Manejar apropiadamente la entrega y recepción de los materiales de

cada práctica.
2. Administrar el inventario y tener información actualizada con respecto a
los materiales, registrando faltantes debido a pérdida, deterioro o mala
ubicación del material, entre otros.
3. Administrar a los profesores que imparten prácticas en el laboratorio,
las prácticas que se están realizando y los alumnos involucrados.
4. Llevar el historial de liquidación y adeudos.
1Partes interesadas.
pág. 126
Actividades y experiencias durante la Residencia Profesional

aplicando BADESO
En esta sección se describen las prácticas realizadas por los alumnos para el
desarrollo del sistema (SICOLF).
Para empezar a desarrollar el software, primero se realizó la práctica Determinar

el alcance del sistema (PA1).
Se inició con la actividad Identificar y definir el alcance del sistema, reuniendo

información de la empresa, para esto se hizo una investigación preliminar sobre
la manera en que se trabaja actualmente en el Laboratorio de Física, mediante
estancias, revisión de registros y observación de los procesos que se llevan a
cabo ahí mismo.
Se hizo un análisis de una aplicación similar y a partir de ahí se generaron una

serie de preguntas para los interesados.
Se llevaron a cabo reuniones con los involucrados en el proyecto, mediante una

serie de entrevistas al Jefe de Laboratorio de Física, auxiliares de laboratorio y
alumnos usuarios del laboratorio. Se obtuvieron los requerimientos, necesidades
y se recabaron los documentos necesarios para establecer el alcance del sistema.
Las historias de usuarios que llenaron alumnos y docentes que hacen uso del
Laboratorio de Física, el laboratorista, ayudante de laboratorio y el administrador,
fueron de gran ayuda para entender la manera en que se trabaja. Con esta
información se integró el Documento de alcance del sistema, el cual cumplió con
el estándar para documentos definido para este fin en la práctica Dar a conocer el
manejo de estándares para el proyecto (PA6).
pág. 127
Como otra actividad de esta práctica se realizó un avance del Reporte final de la
Residencia Profesional del ITLP2 que atendió el estándar marcado en la práctica
Conclusión
El tener información de la empresa de primera mano de los interesados fue de

gran ayuda para lograr los objetivos del proyecto.
Revisar el Anteproyecto de Residencias Profesionales con el cliente y definir el

alcance del sistema, permitió que los residentes aclararan y definieran los límites
del sistema, y sobretodo que quedara documentado para referencias futuras.
Enseguida para acordar el alcance del sistema con el asesor externo se ejecutó
la práctica Obtener aprobación de avance (PA5); con esto el alcance quedó
establecido y formalizado.
Retroalimentación
Una métrica que podría incluirse aquí es el número de entrevistas que se realicen.
Tener claro el alcance del sistema permitió definir un buen plan del proyecto
(práctica Definir el plan del proyecto (PA2)). Esta es una práctica que aunque es
la base del proyecto, en algunos casos no se realiza porque se considera que está
implícita en las actividades del propio desarrollo, sin embargo BADESO, enfatiza
la importancia de realizarla y del impacto en el resto del proceso.
Las métricas planteadas fueron usadas, pero es necesario definir las siguientes:
1. Número de entrevistas.
2. Aplicaciones consultadas.
3. Número de documentos fuentes revisados.
2No se incluye el documento por lo extenso del material.
pág. 128
Esta práctica se aplica simultáneamente con la práctica Determinar el alcance del

sistema (PA1), aunque también se usa en todas las demás prácticas a lo largo
de todo el proyecto.
En esta práctica la intención no es definir estándares, aquí se explicó a los

residentes las plantillas y estándares que se manejarían a lo largo del proyecto:
1. Estándar de documentación, aunque es el que marca el ITLP para el

Documento Reporte final de la Residencia Profesional, en la Residencia
Profesional se propuso para todos los documentos generados.
2. Manejo de la programación, este punto ayudó a hacer fluida y clara la
comunicación en términos de programación.
3. Conocer las listas de comprobación de código con antelación, ayuda a ir
cumpliendo con los puntos y tener menos correcciones que hacer.
4. Estándar de documentación de código, fue importante manejarlo desde el
principio porque de esta forma al llegar a la parte más fuerte de
programación los estándares no fueron, ni deben ser, una carga adicional.
5. Reportes de actividades, permitió saber con antelación como elaborarlos y
esto ayudó a cumplir bien con ellos.
6. Dar a conocer los documentos entregables, aquí se hace la aclaración que
pueden agregarse algún cambio a petición del cliente.
7. Explicar plantillas a usar en diferentes prácticas, que más que estándares
son plantillas que sirvieron de guía para hacer el trabajo.
La intención de esta práctica es que los residentes conocieran los estándares y

plantillas a manejar, entendieran cómo y cuándo tenían que aplicarlos.
pág. 129
Conclusión
El conocer anticipadamente los estándares hizo más fácil el desarrollo, los

residentes sabían cómo se trabajaría y las normas a cumplir. Independientemente
de que tarea le tocó a cada quien.
Retroalimentación
Algunos estándares, durante la ejecución del proyecto, deberían revisarse para

evaluar su importancia. Son los siguientes:
 El reporte individual (Humphrey, Introducción al proceso software

personal, 2001, págs. 20-26), es la suma de los reportes de las reuniones
exprés, pero determinando tiempos y los productos obtenidos. Cada
miembro del equipo debería llenar un reporte individual.
 El reporte de equipo (Humphrey, Introducción al proceso software personal,
2001, págs. 31-40), debe ser llenado por al menos dos integrantes de
equipo, se obtiene a partir de los reportes individuales. Al igual que los
reportes individuales se deben indicar tiempos y productos, entre otras
cosas.
 Reporte de rangos de tamaños de programas.
Se considera que con los productos semanales, los hitos programados, las
reuniones exprés y los Reportes de avance de Residencias Profesionales logran
tener cubierto este punto. Llenar más reportes puede hacer que la actividad se
torne burocrática y se corre el riesgo de que se pierda el objetivo del estándar,
que es ser un medio no un fin. Este es un buen e importante cambio que debería
hacerse en el método BADESO.
pág. 130
Obtener aprobación del cliente (PA5).
Las aprobaciones del cliente se hicieron tal como estaban planeadas excepto que
la presentación oral solo se llevó a cabo dos veces: al principio y al final del
proyecto.
Durante las reuniones de proyecto que se tuvieron con el cliente, se le mostraron

los avances del proyecto y se le explicó en qué consistían. En caso de que se le
mostrara un avance de software, se le explicó detalladamente como es que
funcionaba el módulo presentado. Después el cliente probaba el sistema. Al
momento de que el cliente llenaba el formato y se le hacía hincapié de que anotara
las observaciones o en su defecto los residentes las anotaban y al final se
retroalimentaban para asegurarnos que era lo mismo que él había sugerido.
En su mayoría el cliente estaba satisfecho con los avances que se le entregaron

en cada reunión.
Conclusión
Fue importante realizar esta práctica porque formalizó las decisiones que se
tomaron y validó los avances que se fueron haciendo. Es decir, elevó el nivel de
compromiso y de formalización de cada avance realizado.
En la práctica de la Residencia Profesional se dio una situación muy particular que

fue el cambio del Jefe de Laboratorio de Física ya casi al final de la misma, lo que
al principio causó preocupación, ansiedad y estrés, sobre todo cuando se mostró
el sistema al nuevo Jefe de Laboratorio de Física y éste empezó a sugerir cambios
y nuevos requisitos al sistema.
El haber contado con la documentación de aprobación del cliente a lo largo del

proyecto fue un buen respaldo para amablemente explicarle que no eran posibles
dichos cambios, porque la residencia ya estaba llegando a su fin.
pág. 131
Retroalimentación
Realizar la presentación formal (oral) al inicio y al final del proyecto fue una buena
práctica y se recomienda que se haga así, porque facilita su ejecución y ahorra
tiempo al evitar invertir tiempo para preparar presentaciones formales en todos y
cada uno de los avances.
Aunque se espera que el cliente apruebe el proyecto, durante un proceso de

desarrollo es común que pase mucho tiempo y no se tenga comunicación con el
cliente. Esta práctica busca favorecer la comunicación, validar los requisitos,
fomentar la participación del cliente y caminar con paso firme al obtener la
aprobación de los avances por parte del cliente y/o en su defecto las correcciones
necesarias para el logro de los objetivos.
Es una de las prácticas principales en que BADESO busca aportar mejoras.
Para definir la organización de equipo, se realizó una lista, en la cual cada

integrante del equipo identificó sus habilidades, fortalezas y debilidades; la cual
permitió visualizar el potencial de cada integrante. De esta manera fue más fácil
dividir las tareas a realizar durante la práctica Definir el plan del proyecto (PA2).
Después se decidió que estructura de equipo a utilizar y se optó por SCRUM, por
las siguientes razones: eran dos integrantes, el proyecto era pequeño y con ciclos
cortos.
Se definieron las funciones y responsabilidades de cada miembro del equipo en

el Documento de formalización de equipo.
Conclusión
Identificar estas actividades permitió asignar más acertadamente las tareas a cada
residente al ejecutar la práctica Definir el plan del proyecto (PA2),
pág. 132
Retroalimentación
En esta práctica se propuso inicialmente que se tomara como base dos formas de
organización dependiendo del tamaño del equipo, SCRUM o TSP; sin embargo
se encontró que la metodología SCRUM con su simplicidad y por ser ágil aporta
ventajas como claridad y naturalidad al aplicarse.
Durante el desarrollo del proyecto se realizaron reuniones con los integrantes de

equipo. En las cuales se llegaban a acuerdos sobre lo que se iba a trabajar, la
manera en que se iban a realizar las tareas y las fechas establecidas para la
entrega. Las reuniones se realizaron en la sala de maestros 3 veces a la semana,
lunes y miércoles, de 11: 00 a.m. a 11:20 p.m.; la reunión de los viernes era de
11:00 a 12:00.
En el calendario de comunicación se programaron los días y el punto de encuentro

de la reunión. Durante la reunión se revisaban los avances, las correcciones y
aclaraban dudas.
Se estableció con los residentes por medio de redes sociales constante

comunicación y en todo momento para reuniones de asesoría y/o resolución de
problemas. Se mantuvo la información de todo el proyecto en repositorios
compartidos en internet.
La comunicación entre los interesados se llevaba vía redes sociales y por celular;
La comunicación por mecanismos de comunicación asíncronos se llevó a cabo
por correo electrónico y repositorio del código del proyecto.
La tabla de registros de acuerdos en las que se trabajó durante las reuniones fue
una Pila de Sprint (Navegapolis, 2014) . Donde se establecía lo que se iba a hacer.
Se pidió a los residentes que escribieran las actividades a realizar en notas de
colores para diferenciarlas.
pág. 133
Las reuniones de proyecto con el cliente, fueron de acuerdo a los hitos y se

realizaron en martes en horario de 9:00 a.m. a 11:00 a.m., durante cada reunión
se le mostraban los avances del proyecto al cliente y se llegaba a acuerdos para
la siguiente reunión.
La información resultante se guardó en un documento denominado Documento

de formalización de la comunicación.
Conclusión
La comunicación del proyecto, entre los interesados estaba bien definida y

establecida, lo que ayudó mucho para la realización del proyecto, tanto para
resolver dudas como para trabajar. También se fortaleció mucho la relación con
los residentes y el asesor externo. Ayudó a que los requisitos fueran claros y
entendidos por todos, aclarar dudas y confirmar que se iba por el camino correcto.
Retroalimentación
Las reuniones con el cliente deben ser hitos definidos en la práctica Definir
mecanismos de comunicación del equipo (PE4). Por otro lado debe buscarse en
las reuniones con el cliente que las expectativas no sean crecientes, es decir fuera
del alcance del sistema previamente establecido para que los requisitos
permanezcan estables como ya se han acordado.
Manejar cambios en el proyecto (PA7).
En las reuniones de proyecto con el cliente se hizo una observación porque se

requería realizar un cambio. La observación fue en la interfaz.
Para eso se llenó el Formato de solicitud de cambio, se analizó el cambio entre

los residentes y el asesor interno; una vez analizado y aprobado, se le dió
respuesta al usuario y se realizó el cambio, haciendo los cambios a los
documentos y al código involucrado. El documento que se obtuvo como resultado
de la práctica fue el Formato de solicitud de cambio con respuesta.
pág. 134
Conclusión
El realizar la solicitud de cambios por escrito aseguró una revisión a fondo de los
cambios aunque fueran pequeños y sobretodo en común acuerdo de todos los
involucrados. Se tuvo un buen manejo sobre el control de cambios. En conclusión
se confirma que es una buena práctica.
Retroalimentación
No hay.
Plan del proyecto (PA2).
Para realizar la práctica fue necesario realizar la práctica Organizar el equipo (PE3)
y Definir mecanismos de comunicación del equipo (PE4). Lo primero que se hizo
como parte de la práctica Definir el plan del proyecto (PA2) fue establecer fechas
para las actividades, los responsables de las tareas y los productos a lograr.
Para definir el plan del proyecto, los residentes definieron la lista de actividades
con base en las prácticas a realizar, a las cuales se les establecieron fechas para
su desarrollo y se les asignaron a cada integrante del equipo con base en lo
acordado en la práctica Organizar el equipo (PE3).
También los residentes identificaron los productos que se tenían que obtener al
final de la Residencia Profesional. Como también qué productos no se tenían que
realizar, por ejemplo, para el producto final, no fue necesario realizar un estudio
de factibilidad tipo A y B, ya que no se requirió comprar software ni hardware.
Para modelar el proyecto se modeló un diagrama de Gantt, en el cual proyectaron

el plan de proyecto. La información resultante se guardó en un documento
denominado Documento de plan del proyecto.
Como parte de esta práctica se avanzó en el Documento Reporte final de la

Residencia Profesional en el punto del marco teórico.
pág. 135
El cliente debe aprobar el plan de proyecto, y para eso se debe ejecutar la práctica
Conclusión
Esta práctica sirvió para que a partir del diagrama de Gantt que se planteó en el
Anteproyecto de Residencias Profesionales, se replanteara el plan del proyecto,
ya con una idea más clara de los objetivos y requisitos del sistema, y con esto
programar fechas más realistas, asignación de responsabilidades y actividades
más detalladas. En realidad el diagrama de Gantt planteado fue muy diferente al
que se modelo en el Anteproyecto de Residencias Profesionales porque éste
último modelaba macro procesos.
Definir y establecer por escrito los acuerdos los formaliza. Aunque normalmente
los conoces en un equipo pero a veces incluso no se comentan, son reglas no
escritas y por lo tanto pareciera que no son un compromiso.
Esta práctica ayudó a los residentes y a los asesores a trabajar mejor en equipo
y con mayor comunicación y tener un buen control sobre el proyecto y su
supervisión. Además el realizar la práctica 5, Obtener aprobación de avance por
el cliente (PA5), fue importante para que el asesor externo también supiera las
fechas y los productos que se obtendrían.
Retroalimentación
No hay.
Las historias de usuario que se realizaron en la práctica Determinar el alcance del

sistema (PA1) sirvieron de base para hacer un mejor modelo del negocio, aquí la
idea fue representar el funcionamiento del sistema en su entorno y su
comportamiento actual. Esto se modeló a través de diagramas de actividades.
pág. 136
Se elaboró el glosario del sistema.
En esta práctica además, como parte de los productos desarrollados, se siguió

trabajando en el punto 1.8 del Documento de Reporte final de la Residencia
Profesional. Esta información se archivó en un documento denominado
Documento de modelo de negocio.
Conclusión
Los residentes realizaron el servicio social en el Laboratorio de Física, así que ya

sabían de primera mano el funcionamiento y las actividades que ahí se realizan.
Eran candidatos a no tener que hacer la práctica Modelar el negocio (PD8) para
modelar el negocio. Sin embargo, al hacer el modelo les fue más fácil especificar
los requisitos y ver los distintos escenarios o casos que se presentan a pesar de
que ya los habían vivido, porque no es lo mismo saberlos, que escribirlos o
modelarlos.
Retroalimentación
Esta práctica originalmente se había pensado como opcional sin embargo, se

concluyó que es necesario hacerla, ya que permite conocer mejor el sistema e
identificar los requisitos de manera más clara, acertada y sin confusiones.
Obtener requisitos del sistema (PD9)
Para conseguir la especificación de requisitos se realizaron actividades que

facilitaran la obtención de estos. Principalmente se realizaron reuniones con el
cliente, primero para revisar el objetivo general en función del alcance del sistema
previamente definido y posteriormente para refinar los requisitos.
Los objetivos establecidos en la práctica Determinar el alcance del sistema (PA1),

fueron de gran ayuda para obtener y escribir de manera más clara y precisa los
requisitos funcionales y no funcionales. Se obtuvo un total de 56 requisitos
funcionales y 16 requisitos no funcionales.
pág. 137
Una vez hecho esto, se elaboraron los casos de uso y se modelaron los datos a
través de un diagrama entidad – relación. Se integró el Documento del modelo de
requisitos.
Conclusión
Esta práctica particularmente fue muy útil porque sirvió como contrato ya que
analizar los requisitos, platicarlos con el cliente, aclarar cada punto y refinarlo, y
ejecutar la práctica Obtener aprobación de avance por el cliente (PA5), brindó
seguridad de que el trabajo que se haría estaría bien.
Retroalimentación
No hay.
Realizar el análisis del sistema (PD10).
Las prácticas anteriores como la 8 y 9 facilitaron obtener un análisis más a fondo

del sistema y en esta práctica se trató de visualizar la manera en que se van a
llevar a cabo los requisitos, para esto se realizaron los diagramas de entidad -
relación, diagrama de clases del análisis, casos de uso y documentación de casos
de uso.
Esta actividad tiene como objetivo determinar de qué forma se llevará a cabo el
cumplimiento de los requisitos. Las tareas que se desarrollaron fueron elaborar el
modelo entidad – relación, lo que permitió tener una idea de la base de datos.
El diagrama de clases del análisis se elaboró después de identificar las entidades

y sus relaciones, tratando de diagramar las clases conceptuales y sus relaciones
orientadas a responsabilidades.
Se elaboraron diagramas de casos de uso para mostrar las asociaciones entre los
actores, casos de usos y los requisitos del sistema. En la documentación de los
casos de uso se trató de mostrar paso a paso la especificación de requisitos y los
pág. 138
distintos escenarios para cada caso de uso. En esta práctica se elaboró el plan de
pruebas del sistema. Una de las actividades más importantes de esta práctica fue
diseñar y elaborar las interfaces, fue una actividad conjunta con la documentación
de casos de uso y el plan de pruebas del sistema.
En esta práctica además como parte de los productos desarrollados, se siguió

Profesional. Esta información se archivó en un documento denominado
Documento de análisis del sistema.
Conclusión
Realizar esta práctica sirvió para aprovechar mejor el tiempo y elaborar con más
claridad los diagramas de lo que más adelante se iba a construir. Un gran avance
en esta práctica fue el modelo de datos y el diseño de la interfaz. Los modelos
construidos en esta práctica son de gran utilidad para confirmar los requisitos con
el cliente además de hacerlo oportunamente al estar en una fase temprana del
desarrollo.
Retroalimentación
No hay.
El diseño de la base de datos fue creado a partir del modelo de datos del análisis.
Esta fue una actividad que llevó mucho tiempo, aquí se hicieron varias pruebas a
la base de datos hasta que se tuvo la seguridad de que el diseño estaba bien; una
de las razones de los retrasos y de las dificultades en esta actividad fue a causa
de la inexperiencia en la programación y la falta de práctica en las consultas de
bases de datos de los residentes.
Pero una vez hecho esto se pudo avanzar al diseño de la arquitectura del sistema,
tratando de organizar y agrupar los subsistemas e identificar las relaciones que
pág. 139
sirvió de guía en la estructura del sistema a la hora de la programación y de

diseñar el sistema pensando en el mantenimiento del mismo.
La siguiente actividad fue modelar los componentes y las interfaces a través del
diagrama de componentes. Se elaboró el diagrama de componentes de la capa
de presentación, que es donde se muestran todas las pantallas con las que
trabajará el sistema y la manera en que están organizadas; la siguiente capa, la
del negocio muestra las clases que va a utilizar el sistema; y por último la capa de
datos que es donde se encuentran los datos y se encarga de acceder a los
mismos.
El modelo de clases fue el siguiente diagrama que se hizo, en él se apreció con

claridad los métodos que se requerirían en las distintas clases y la forma en que
estas últimas se relacionaban entre sí.
Los diagramas de secuencia sirvieron para ver el flujo entre las diferentes clases
del sistema y donde entraban los métodos, sus parámetros y el flujo que había en
la ejecución del diagrama. La congruencia entre el diagrama de clases y el
diagrama de secuencia le fue dando forma al diseño.
El diccionario de datos fue una buena técnica para definir la información

involucrada, su tipo y características.
Se realizó la revisión del modelo del diseño de la interfaz.
Esta información se archivó en un documento denominado Documento de diseño.

Profesional.
En esta práctica se reportó el avance de la residencia así que los residentes

llenaron los Formatos de avance de Residencias Profesionales que se
pág. 140
proporcionan en la práctica Dar a conocer el manejo de estándares para el

proyecto (PA6).
En esta práctica fue necesario tomar decisiones acerca de la distribución del

sistema, por lo tanto se realizó el diagrama de distribución.
Conclusión
Es sin dudar una de las prácticas fundamentales porque es el diseño de cómo

construir el sistema, el tener una guía clara de los requisitos facilitó el proceso.
Una actividad importante en esta práctica fue el probar la base de datos y poder
confirmar el cumplimiento de los requisitos.
Retroalimentación
El diagrama de distribución, debe realizarse en esta práctica ya que de acuerdo a

su diseño también dependen decisiones de programación.
Como parte de la verificación se hizo una lista de comprobación (Humphrey,

Introducción al proceso software personal, 2001) para la revisión de código; es
muy importante la verificación, ya que ayuda a la corrección de un programa o a
su mejora.
Con base en el nivel de programación que tenía cada integrante se hizo la

repartición de los módulos.
Cada integrante documento su estilo de programación.
Se documentó el código para una mejor documentación, facilitar las

modificaciones y facilitar el mantenimiento.
pág. 141
El Estándar de documentación que se utilizó es el definido previamente en la

práctica Dar a conocer el manejo de estándares para el proyecto (PA6) para este
fin.
En esta práctica como parte de las pruebas, se calculó la complejidad ciclomática

como parte de las pruebas de cada componente, buscando con esto que el código
quedara más sencillo.
Se construyeron los módulos del sistema, cumpliendo con el diseño del prototipo
que se acordó con el cliente.

trabajando en el punto 1.8 del Documento Reporte final de la Residencia
Profesional.
Esta información se archivó en un documento denominado Documento de

construcción.
Conclusión
Para desarrollar esta práctica se usaron de guía los modelos que se desarrollaron
en las prácticas anteriores. El resultado de esta práctica es el sistema integrado.
El construir el sistema integrando incrementalmente resultó una buena práctica
tanto para la propia construcción como para su validación por parte de los
desarrolladores y del cliente.
Retroalimentación
Deben enfatizarse las ventajas del desarrollo integral incremental en el método.
Probar el sistema (PD13).
Se hicieron los planes de pruebas para realizar una serie de pruebas al sistema
ya terminado y encontrar los más errores posibles.
pág. 142
Se entregó el segundo Reporte de avance de Residencias Profesionales.
Se ejecutaron pruebas de requisitos para confirmar que cada requisito planteado

en el Documento de requisitos se cumplió.
Las pruebas de validación ejecutadas sirvieron para confirmar el correcto ingreso

de los datos.
Las pruebas de interfaz ayudaron a detectar errores en el diseño de la interfaz y

se aseguró el cumplimiento con el estándar de Shneiderman (Shneiderman,
2005).
Las pruebas de seguridad ayudaron a confirmar que si se cumplían las

operaciones que estaban proyectadas de acuerdo a los distintos usuarios.
Las pruebas alfa las llevó a cabo el cliente en la máquina de desarrollo y dio la
oportunidad de detectar fallas sin haber liberado el producto.
Las pruebas de recuperación confirmaron el buen comportamiento del sistema

después de un evento inesperado.
Se elaboraron el manual técnico y la ayuda del sistema.
Esta información se archivó en un documento denominado Documento de

pruebas.
Conclusión
Seguir una guía de pruebas fue mejor que hacer solo la depuración que
normalmente las residentes estaban acostumbradas a hacer. En esta actividad,
encontraron errores por ejemplo en la interfaz que ya se había dado por hecho
que no requerían cambios. Algunas pruebas no arrojaron errores pero otras si y
eso hizo que en las pruebas de aceptación fueran mínimos los errores. Sin seguir
una guía hay tipos de prueba que no se hubieran aplicado.
pág. 143
Retroalimentación
Es importante enfatizar dentro de la metodología porque aplicar las pruebas

necesarias y no probar de manera exhaustiva.
Se elaboró el plan de instalación y se instaló el sistema. El plan de instalación

respetó el formato marcado en el Documento de estándares.
El método de capacitación elegido fue el entrenamiento directo que es

capacitación personalizada, en el Laboratorio de Física, con el software instalado
ya en la máquina del cliente y trabajando con datos y operaciones reales. Los
alumnos que estuvieron durante la Residencia Profesional realizando su servicio
social están por concluirlo, y aun no se tiene identificado a los nuevos alumnos.
Si al momento de llevar a cabo la capacitación ya hay nuevos alumnos de servicio
social, se tiene contemplado incluirlos en una capacitación con el mismo método
y enfoque.
La conversión que se planeo fue, la conversión paralela, que es operar los dos
sistemas de información a la vez. Para esto se llenó el Formato de plan de
conversión marcado en el Documento de estándares.
La revisión post implantación se planteó teniendo como objetivo acompañar al

usuario inmediatamente después de la implantación. Por eso se buscó cumplir
con los siguientes puntos:
 Brindar consultoría a los usuarios.

 Resolver problemas que se presenten y dar solución inmediata.
 Comprobar que el sistema esté funcionando correctamente.
Esta información se guardó en un documento denominado Documento de

implantación.
pág. 144
Se realizó una junta de aceptación del sistema el día 07 de agosto del 2014, donde
el asesor externo e interno dieron por terminado el proyecto. Se elaboró la
evaluación a través del formato que proporciona la Institución.
Al final no se terminó esta práctica ya que como se mencionó anteriormente hubo

cambio de Jefe de Laboratorio y hasta el día de hoy no se han dado las
circunstancias de tiempo y hardware para que se realicen. Las características del
hardware que dispone el Laboratorio de Física no son las requeridas por el
sistema. Se está en espera de que se indique la llegada del equipo adecuado para
seguir con el proceso. El equipo se probó en el Laboratorio de Matemáticas y no
tuvo problemas en su funcionamiento.
Conclusión
Particularmente en esta residencia faltó el apoyo administrativo. Si bien hubo

cambio de Jefe de Laboratorio de Física, el Jefe del área de Ciencias Básicas
continuó siendo el mismo, hubiera sido de gran ayuda que él se hubiera
involucrado para una implantación y liberación exitosa.
Retroalimentación
Si hay apoyo por el dueño del sistema de principio a fin del proyecto, se pueden
tomar decisiones correctivas cuando se necesita para que el proyecto llegue a
feliz término.
Conclusión de la aplicación de BADESO
El resultado de la aplicación de BADESO se considera que fue satisfactoria en

términos del producto:
 Se cumplieron los requisitos planteados.

 El Jefe del Laboratorio de Física (el original que evaluó el producto hasta
el final junto con el nuevo Jefe de Laboratorio) quedó satisfecho.
pág. 145
 El sistema se pudo probar instalado y volver a probar. Si bien presentó

errores durante la instalación, al momento de las pruebas por parte del
cliente ya no presentó nuevos errores.
En cuanto al proceso la aplicación de BADESO logró su objetivo porque:
 Se cumplió con los tiempos planeados.

 Los reportes aplicados permitieron medir el avance del proyecto y
completar a tiempo los avances planeados.
BADESO contribuyó al logro del proyecto ya que:
 Las actividades y tareas planteadas ayudaron a terminar el proyecto.

 La relación entre las prácticas ayudó a manejar la complejidad del sistema.
 Las prácticas de desarrollo fueron una buena guía para la construcción del
producto.
 La calidad es presumiblemente buena hasta donde se pudo probar; la
batería de pruebas aplicada, la instalación lograda y las pruebas de
aceptación fueron exitosas.
En cuanto al personal de desarrollo, gracias a las prácticas propuestas en

BADESO se logró:
 Un buen equipo de trabajo y la mejor prueba de ello es que los productos

se lograron.
 La organización y los medios de comunicación establecidos fueron
eficientes.
Sin embargo dado que hasta el día de hoy el sistema aún no está implantado en
el Laboratorio de Física se está hablando de un proyecto fallido. ¿Qué falló? Falta
soporte por parte de la gerencia e interés por parte del nuevo Jefe del Laboratorio
de Física.
pág. 146
Si el soporte ejecutivo estuviera totalmente convencido del cambio no sería

problema de quien esté en la parte operativa; el proceso puede funcionar muy
bien; el problema es como en este caso, que la parte operativa era la parte
interesada y cuando la cambian, la parte administrativa y la nueva parte operativa
no están interesados en el sistema. El dueño no solamente es el dueño del
proyecto tiene una responsabilidad con él.
Fortalezas de BADESO
Las fortalezas del método son:
 Definir el alcance del sistema permite tener la visualización de los

requerimientos y de la arquitectura. Se establece una clara definición de
los límites, restricciones y alcance del sistema.
 Buscar participación activa del cliente por medio de la aprobación formal
de avances y de reuniones programadas y no programadas.
 Manejar la administración de cambios.
 Planear de forma no lineal lo que permite avanzar en varias actividades
aprovechando mejor el tiempo.
 Promover el trabajo en equipo fortalece la comunicación, definiendo
claramente responsabilidades y estableciendo formas de comunicación.
 Aplicar diferentes modelos, como diccionario de datos o diagramas de
UML, por ejemplo.
 Documentar continuamente desde la primera práctica. No en todas las
prácticas se documenta justamente porque se busca documentar hasta
tener información que sufra los menores cambios posibles.
 Construir el software mediante el desarrollo incremental integrado. Se
busca identificar los componentes del software e irlos construyendo como
subsistemas independientes construir, probar e integrar; hasta tener el
sistema completo.
pág. 147
 Construir código después de prácticas que promueven un claro

entendimiento de los requisitos
Debilidades de BADESO
o Susceptible a la capacidad de los residentes.
Es decir, se puede tener un método con las mejores prácticas pero si no se

tiene a la gente que tenga la capacidad y conocimiento en programación esto
se reflejará en el tiempo y la calidad del producto.
o Depende de las habilidades del administrador del proyecto para la

resolución de problemas.
Una forma de amortiguar esta debilidad podría ser a través del manejo de
riesgos.
o Requiere soporte administrativo de alto nivel para que el proyecto tenga

éxito.
Como cualquier cambio en una organización para implantar un sistema se

requiere del respaldo, interés, recursos y autoridad de la administración de alto
nivel para que el proyecto tenga éxito.
Mejoras
Para mejorar el método se pueden hacer varios ajustes en la siguiente aplicación

del método y estas son el resultado de la retroalimentación de ejecución de cada
una de las prácticas y del conjunto de las mismas. La siguiente aplicación del
método debe:
 Incluir métricas que ayudarían a fortalecer al método.
pág. 148
 Eliminar estándares en la práctica Dar a conocer el manejo de estándares

para el proyecto (PA6), ya que no todos los estándares para reportar
avances son necesarios, llenar más reportes hace que la actividad se torne
burocrática y se pierde el objetivo del estándar, que es ser un medio no un
fin.
 Las reuniones con el cliente deben ser hitos definidos previamente en la

práctica Dar a conocer el manejo de estándares para el proyecto (PA6).
 Replantear la forma de organización en el equipo en la práctica Organizar

el equipo (PE3), se propuso que se tomaran como base dos formas de
organización dependiendo del tamaño del equipo, SCRUM o TSP, sin
embargo al aplicar SCRUM durante la Residencia Profesional se pudieron
apreciar sus ventajas como metodología ágil.
 La presentación oral del avance del proyecto en la práctica Obtener

aprobación de avance por el cliente (PA5), realizarla solo al inicio y al final
fue una buena modificación, porque facilitó su ejecución y no se justificaba
el tiempo necesario para preparar presentaciones de manera formal en
todos y cada uno de los avances. Sin embargo, el tipo de presentación que
se exponga debe depender del tipo de reunión que se tenga, si es técnica
no es necesario llevar una presentación formal, si no lo es, entonces es
necesario prepararla.
 Modelar el negocio (PD8) es una práctica que se propuso como opcional,

sin embargo, se considera que para entender mejor los requisitos es
necesario conocer bien el sistema y su contexto y es precisamente el
objetivo de esta práctica. La premisa es que se debe asegurar que se
entienden los procesos, y para ello, el modelarlos es la mejor forma de
verificar que hay entendimiento y que el cliente está de acuerdo en la
interpretación del proceso en el modelo.
pág. 149
 El modelado del diseño físico que originalmente se propuso en la práctica

Construir el sistema (PD12) debe realizarse desde la práctica Diseñar el
sistema (PD11), ya que de acuerdo a su diseño dependen decisiones de
programación.
 Usar modelos inclusivos para mostrar los avances al cliente.
En la metodología no se enfatiza usar modelos inclusivos en las reuniones

de avance; aunque en la aplicación de la metodología se usaron modelos
inclusivos, no se especifica que es una buena práctica.
 Promover más el entorno de producción en el entorno de desarrollo.
BADESO 2.0
Sin embargo hay mejoras sustanciales del método con el objetivo de que sea
más claro y sencillo, pero además buscando que sea un método ágil.
 En la prácticas Diseñar el sistema (PD11) y Construir el sistema (PD12),

porque es aquí donde se pueden lograr actividades para agilizar el método.
 Evaluar la eficiencia de las métricas planteadas para decidir añadir métricas

faltantes, eliminar las que no sean eficientes y modificar las que lo ameriten.
 Hacer un análisis de las prácticas en busca de mejoras buscando que el

método sea más ágil.
El conjunto de estas pequeñas y grandes mejoras que se considera harán de

BADESO un método más claro y ágil.
pág. 150
Capítulo 6 Conclusiones
“En tiempos de cambio, quienes estén abiertos al aprendizaje se
adueñaran del futuro, mientras que aquellos que creen saberlo
todo estarán bien equipados para un mundo que ya no existe”,
Eric Hoffer.
Para plantear el método objeto de esta tesis, en el capítulo uno se describió el

contexto de la organización sobre la cual documentar las prácticas para construir
proyectos de software. Se inició describiendo los problemas que comúnmente se
presentan en una Residencia Profesional, se narró el proceso de desarrollo de la
misma, aclarando que la presente tesis se enfocaba para proyectos de desarrollo
de software. Se explicaron los beneficios que se obtienen al definir un método de
desarrollo. Se mostraron los alcances del método y se planteó la propuesta de
solución. Se hizo esto con la idea de situar al lector en una misma perspectiva, si
se tiene un método de desarrollo de proyectos de software, entonces los alumnos
junto con su asesor interno tendrán una guía para su Residencia Profesional y así
lograr un producto homogéneo y estandarizado.
En el segundo capítulo se habló de los fundamentos que sustentan esta tesis:

Ingeniería de Software y KUALI-BEH. Los conceptos básicos de administración
de proyectos de la Ingeniería de software. Se hizo un resumen acerca de KUALI-
BEH y en qué consiste. Este capítulo es el fundamento de esta tesis, por eso es
importante que el lector vea como los mismos conceptos que se manejan en
Ingeniería de software son los que fundamentan el modelo KUALI-BEH: y estos
conceptos al ser identificados y definidos, son los que permiten plantear el método
y sus prácticas.
pág. 151
En el capítulo tres se buscó mostrar precisamente como el método Básico de

Desarrollo de Software (BADESO) planteado y sus prácticas cumplen con el
modelo KUALI-BEH, mediante el cual se pueden definir prácticas y métodos de
desarrollo de proyectos de software. En un principio mostrando las características
del método; a continuación enumerando los conceptos comunes en los proyectos
de software y cómo están presentes en el método planteado; se definió el método
y se demostró como el método cumple con las tres propiedades de KUALI-BEH.
Una vez que BADESO está definido, en el cuarto capítulo se hizo la presentación
de las prácticas que conforman el método. Buscando mostrar la aportación e
importancia de cada una de ellas para el método y la interrelación entre las
mismas. Para definir una práctica es necesario detallar una serie de elementos a
través de la plantilla de KUALI-BEH para prácticas, que ayudan al ejecutar la
práctica ya que se tiene toda la información que se necesita. Además, que permite
ir documentando información del proceso lo que posteriormente sirve para hacer
el post mortem del proyecto o una retroalimentación del mismo.
En el capítulo 5 se mostró la aplicación del método en una residencia y sus

resultados. Se fue narrando el desarrollo de la experiencia en función de cada
práctica y al final se hizo una pequeña conclusión de la aplicación y una pequeña
retroalimentación si era el caso (no en todas las practicas se consideró necesario)
de cómo se podría mejorar la práctica. Al final del capítulo se escribió la conclusión
y también gracias a la aplicación del método se identificó lo que se consideró son
fortalezas y debilidades del método. Ya para terminar el capítulo se hace una
pequeña propuesta de lo que podría ser la siguiente versión de BADESO.
Las debilidades que se identificaron en BADESO son las siguientes:
o Susceptible a la capacidad de los residentes.

o Depende de las habilidades del administrador del proyecto para la
resolución de problemas.
pág. 152
o Requiere soporte administrativo de alto nivel para que el proyecto tenga

éxito.
Las anteriores más que ser debilidades del método BADESO son situaciones
inherentes a las personas que participan en los proyectos y a su experiencia; y se
presentan frecuentemente en la práctica de cualquier método; sin embargo, lo
importante es disminuir el riesgo de que ocurran. Particularmente en el contexto
de las Residencias Profesionales esto puede lograr con la aportación de la
experiencia de los asesores de Residencias Profesionales, ya que ellos pueden
coadyuvar y orientar a los residentes en fortalecer dichas debilidades.
Por otra parte existen créditos académicos extracurriculares en la carrera de

Ingeniería en Sistemas Computacionales que pueden aprovecharse para ofrecer
cursos que fortalezcan el trabajo en equipo, competencias de liderazgo,
aprendizaje en la práctica; en los cuales se busque fortalecer las habilidades que
históricamente han aquejado al desarrollo de proyectos de software.
Porque en conclusión las actividades que integran las prácticas pueden ser muy
eficientes, y por lo tanto conformar un método que la experiencia demuestre que
funciona para una determinada organización; sin embargo, no se debe olvidar que
las actividades son llevadas a cabo por las personas y las relaciones entre las
personas no son lógicas e incluso pueden tornarse tóxicas; y los proyectos de
software son manejados por las mismas personas y si estas no saben liderarlo o
no poseen las habilidades necesarias, el método por sí solo no será suficiente
para garantizar el éxito del proyecto.
Trabajos futuros
En el área de la Ingeniería de Software hay mucho por hacer, mucho por explorar
y mucho por aprender.
pág. 153
En la presente tesis el método se enfocó al contexto de las Residencias

Profesionales, sin embargo a partir del método se pueden plantear una serie de
prácticas para las materias del área de Ingeniería de software.
Trabajar con KUALI-BEH, para definir un método aplicable en las materias del
área de Ingeniería de Software para ejemplificar una metodología ágil para la
materia que lo amerite y ajustarlo para aplicar una metodología tradicional si es el
caso.
Un trabajo a futuro que se podría hacer también es trabajar en los estándares y

plantillas que se manejan en la presente tesis. Es decir, realizar una investigación
y análisis para optimizarlos, con el objetivo de que se planteen como técnicas para
dar soporte a las prácticas.
Trabajar con el manejo de pruebas de BADESO buscando definir una batería de

pruebas básicas que fortalezcan al método.
pág. 154
Bibliografía
Bibliografía
Agiles.org, p. (24 de Noviembre de 2014). proyectos agiles.org. Obtenido de
http://www.proyectosagiles.org/que-es-scrum
Barros, A. (6 de Diciembre de 2013). El escritorio de Alejandro Barros. Obtenido

de http://www.alejandrobarros.com/content/view/560804/Nuevas-
practicas-de-desarrollo-de-software.html
Beynon, D. (2007). Interpreting Capability Maturity model Integration(CMMI) for

business Development organizations in the Government andIndustrial
Business Sectors. Tech. Rep. Technical Note CMU/SEI-2007-NT-004.
Booch, G., Rumbaugh, J., & Ivar, J. (1999). El lenguaje unificado de modelado.
Madrid: Addison Wesley.
Braude, E. J. (2003). Ingeniería de Software una perspectiva orientada a objetos.

México: Alfaomega.
Brooks, F. (15 de Octubre de 2014). WIKIPEDIA. Obtenido de

http://es.wikipedia.org/wiki/No_hay_balas_de_plata
Brooks, F. P. (s.f.). Recuperado el 25 de 06 de 2014, de The University of

Nottigham:
http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html
Bruegge, B., & Dutoit, A. (2002). Ingenieria de Software orientado a objetos.

México: Pearson Educación.
Burch, J. G., & Strater, F. R. (1989). Sistemas de Informacion, Teoria y practica.

Mexico: LIMUSA.
Fairley, R. (1988). Ingeniería de Software. México: Mc Graw Hill.
pág. 155
Bibliografía
Fontela, C. (2011). UML, Modelado de software para profesionales. Argentina:

Alfaomega.
Gracia, J. (19 de Noviembre de 2013). IngenieroSoftware. Obtenido de

http://www.bimanki.com/2012/05/24/buenas-practicas-esenciales-en-el-
desarrollo-de-software/
Humphrey, W. S. (2001). Introducción al proceso software personal. En W. S.

Humphrey, Introducción al proceso software personal (págs. 198,199).
España: Addison Wesley.
iCenter, O. C. (2004). Best Practices & Benchmarking, MakingWorthwhile

Comparisons.
IEEE, C. S. (1993). IEEE Std. IEEE Software Engineering Standard: Glossary of

Software Engineering Terminology.
Informacion, C. T. (1 de diciembre de 2014). INDECOPI. Obtenido de

http://www.bvindecopi.gob.pe/normas/isoiec12207.pdf
Informática, P. (16 de Diciembre de 2013). Informática, PMO. Obtenido de

http://www.pmoinformatica.com/2012/10/plantillas-scrum-historias-de-
usuario.html
ITLP. (19 de Marzo de 2013). Página del Instituto Tecnológico de La Paz.

Recuperado el 19 de Marzo de 2013, de
http://www.itlp.edu.mx/imgDep/DivisionDeEstudios/Residencias/Informaci
%C3%B3n%20anteproyecto%20RP/Como%20estructurar%20tu%20infor
me%20final%20de%20residencias%20profesionales_2013.pdf.
ITLP, I. T. (02 de mayo de 2014). Pagina Web del ITLP. Obtenido de

http://www.itlp.edu.mx/seccion.php?CONTENIDO=Reglamento+Titulaci%
C3%B3n&id=10
pág. 156
Bibliografía
kaans, k. (16 de mayo de 2014). Grupo de Investigación en métodos de ingeniería

de software. Recuperado el 16 de 05 de 2014, de http://www.kuali-
kaans.mx/index.php/proyectos/kuali-beh
libre, W. L. (24 de noviembre de 2014). TSP. Obtenido de

http://es.wikipedia.org/wiki/Team_Software_Process
México, U. N. (23 de Noviembre de 2013). KUALI KAANS. Obtenido de

https://sites.google.com/a/kuali-kaans.mx/kuali-
kaans/productos/plantillasapdsms
Navegapolis. (19 de abril de 2014). www.navegapolis.net. Recuperado el 19 de

04 de 2014, de http://www.navegapolis.net/files/s/NST-010_01.pdf
Oktaba, H. J., Morales Trujillo, M. E., & Dávila Muñoz, M. (Noviembre de 2013).
SCRIBD. Recuperado el Noviembre de 2013, de
http://es.scribd.com/doc/150649695/Kuali-Beh-Software-Project-Common-
Concepts
PMBOK. (17 de Marzo de 2015). Universidad de Oviedo. Obtenido de

http://gio.uniovi.es/documentos/software/GUIA_PMBok.pdf
Sereno, M. (23 de Noviembre de 2013). BIMANKI. Obtenido de

http://www.bimanki.com/2012/05/24/buenas-practicas-esenciales-en-el-
desarrollo-de-software/
Shneiderman, B. (2005). Diseño de interfaces de usuario: estrategias para una

interacción: persona - computadora efectiva. México: Pearson.
Sommerville, I. (2005). Introducción. En I. Sommerville, Ingeniería del Software

(págs. 5-8, 10). Madrid: Pearson.
pág. 157
Bibliografía
tecnológicos., D. G. (2 de diciembre de 2013). Instituto Tecnológico de Mexicáli.

Recuperado el 02 de 02 de 2014, de
http://www.itmexicali.edu.mx/servicios1/ManualResidencias.pdf
TI.com, D. (4 de Diciembre de 2013). Diario TI.com. Obtenido de

http://diarioti.com/webinar-gratuito-kuali-beh-como-especificacion-formal-
del-object-management-group/67770
Weitzenfeld, A. (2004). Ingeniería de Software orientada a objetos con UML, JAVA

e INTERNET. México: THOMSON.
pág. 158

Método Básico de Desarrollo de Software

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Método Básico de Desarrollo de Software

Cargado por

Copyright:

Formatos disponibles

TECNOLÓGICO NACIONAL DE MÉXICO

Instituto Tecnológico de La Paz

“2015, Año del Generalísimo José María Morelos y Pavón”

INSTITUTO TECNOLÓGICO DE LA PAZ

Método Básico de Desarrollo de Software (BADESO) aplicando

QUE PARA OBTENER EL GRADO DE

La Paz, Baja California Sur, junio del 2015

A Dios, por todo lo que me ha dado.

A mi amada madre, mejor…imposible;

A mis adorados hijos, el motor de mi vida;

A mí querido hermano Carlos, no tengo palabras para describir todo lo bueno

que significa para mí.

A mi querida directora Lupita Ibargüengoitia, por su infinita paciencia, apoyo,

A mi estimada Iliana Castro siempre dispuesta a mostrarme el camino donde sea

A Armando Cárdenas por ser mi director de tesis y por las oportunidades de

A todas las personas que me permitieron el honor de ser su profesora y asesora

Los sistemas de información automatizados forman parte de las actividades

El objetivo de la presente tesis es proporcionar un método de desarrollo de

Para plantear el método objeto de esta tesis, en el capítulo uno se describe el

En el segundo capítulo se habla de los fundamentos que sustentan esta tesis:

En el capítulo 3 el objetivo es mostrar precisamente cómo el método Básico de

Una vez que BADESO está definido, en el cuarto capítulo se hace la

En el capítulo cinco se mostró la aplicación del método en una residencia y sus

El capítulo seis contiene la conclusión del trabajo y también gracias a la

The objective of this thesis is to provide a software development methodology

CAPÍTULO 1 PLANTEAMIENTO DEL PROBLEMA ......................................... 12

CAPÍTULO 2 INGENIERÍA DE SOFTWARE Y KUALI-BEH ............................. 21

CAPÍTULO 3 MÉTODO BÁSICO DE DESARROLLO DE SOFTWARE

CAPÍTULO 4 PRÁCTICAS DEL MÉTODO BÁSICO DE DESARROLLO DE

CAPÍTULO 5 APLICACIÓN DEL MÉTODO BADESO. ................................... 125

CAPÍTULO 6 CONCLUSIONES ...................................................................... 151

Trabajos futuros ........................................................................................ 153

Ilustración 2 Plantilla de proyecto de software. .................................................. 34

Ilustración 3 Plantilla para método...................................................................... 35

Ilustración 4 Plantilla para práctica. .................................................................... 36

Ilustración 5 Conceptos comunes de KUALI-BEH .............................................. 40

Ilustración 6 Método BADESO definido en KUALI-BEH ..................................... 43

Ilustración 7 Método Básico de Desarrollo de Software (BADESO). ................. 44

Ilustración 8 Conjunto coherente de prácticas en KUALI-BEH. .......................... 45

Ilustración 9 Modelar el negocio (PD8) ............................................................... 48

Ilustración 10 Obtener requisitos del sistema (PD9) y Realizar el análisis del

Ilustración 11 Diseñar el sistema (PD11). .......................................................... 51

Ilustración 12 Construir el sistema (PD12). ........................................................ 52

Ilustración 13 Probar el sistema (PD13). ............................................................ 53

Ilustración 14 Implantar el sistema (PD14). ........................................................ 54

Ilustración 15 Práctica Obtener aprobación de avance por el cliente (PA5) y su

Ilustración 16 Práctica Dar a conocer el manejo de estándares para el proyecto

Ilustración 17 Aplicación de Manejar cambios en el proyecto (PA7). ................. 58

Ilustración 18 Práctica Definir los mecanismos de comunicación del equipo (PE4)

Ilustración 20 Conjunto consistente de las prácticas de un método. .................. 62

Ilustración 21 Entradas y Salidas del método BADESO. .................................... 64

Ilustración 22 Entradas a la primera práctica del método. .................................. 65

Ilustración 23 Resultados de la última práctica del método, Implantar el sistema

Ilustración 24 De Determinar el alcance del sistema (PA1) Definir el alcance de

Ilustración 25 De Dar a conocer el manejo de estándares para el proyecto (PA6)

Ilustración 27 De Obtener requisitos del sistema (PD9) y Realizar el análisis del

Ilustración 28 De Construir el sistema (PD12) hasta obtener los resultados del

Ilustración 29 Conjunto completo de prácticas. .................................................. 75

“Los problemas... son diferentes para cada uno, y cada uno

“Utilizar mejores prácticas en los procesos de una organización, es un elemento

Descripción del problema

Los Proyectos de Residencias Profesionales involucran a los residentes, a los

Los Proyectos de Residencias Profesionales se realizan en un tiempo mínimo de

Cuando el alumno requiere realizar la Residencia Profesional, debe solicitarla a