Universidad Simn Bolvar Ingeniera de Software 1 Desarrollo de Software de Tamao Moderado..

Desarrollo de software
de moderado y gran tamao
Alejandro Teruel
Versin 2.2 (8 de diciembre de 2014)
Versiones anteriores: 2.1 (7 de septiembre 2014), 2.0 (7 de junio 2014), 1.1 (23 de abril 2013)

Objetivo del curso

Introducir al estudiante a la problemtica y a las tcnicas de desarrollo de software de tamao
moderado representativas del enfoque disciplinado asociado con la Ingeniera de Software. Se
enfatizarn algunas tcnicas y herramientas sencillas que:
1. Incrementan la productividad del desarrollador de software;
2. Permiten reducir la complejidad de software de tamao moderado;
3. Facilitan el trabajo en equipo.

1. Qu es software de tamao moderado?

No existe una categorizacin estndar de los tamaos del software en la literatura. Sin embargo, a
efectos de este curso, distinguiremos entre software de tamao pequeo, moderado (o mediano) y
grande. Las fronteras entre estas categoras son difusas y pueden depender no slo de la cantidad de
cdigo sino tambin de otros factores como complejidad, eficiencia, exigencias y calidad del mismo,
pero, en general hoy en da, un software que contenga pocas centenas de lneas de cdigo fuente o
SLOC (abreviacin que viene del Ingls Source Lines Of Code) es considerado de tamao pequeo, un
software que contenga decenas o centenas de miles de SLOC es de tamao moderado, mientras que
aquel software que contenga ms de un milln de SLOC es considerado de tamao grande.

Qu tamao tiene el software que desarrollamos en los estudios de pregrado y el software que usamos?
El software desarrollado como parte de una asignacin en un curso introductorio de programacin no debera
sobrepasar los 200 SLOC y es claramente de tamao muy pequea. Considerando que una pgina de texto contiene
aproximadamente unas cuarenta lneas, significa que el cdigo fuente de este tipo de software puede llegar a ocupar
unas cinco pginas. Un programador profesional puede desarrollar software como ste por su cuenta en menos de
dos das de trabajo.
El tamao tpico de un software desarrollado como proyecto de laboratorio en un trimestre o semestre de la carrera
no debera sobrepasar 3 mil SLOC (3 KSLOC) -a menos que incluya cdigo desarrollado previamente por otro, en
cuyo caso pudiera llegar a duplicar este tamao. Este tipo de software todava est dentro del alcance de un solo
programador profesional y se considera de tamao pequeo. Para Alessandro Orso1, un proyecto pequeo puede

1 Software Development Life Cycles. Alessandro Orso, Georgia Tech. Udacity, 2014.
Universidad Simn Bolvar Ingeniera de Software 1 Desarrollo de Software de Tamao Moderado..2

alcanzar las mil SLOC y un proyecto de laboratorio puede ser del orden de las diez mil SLOC.
En el curso de una carrera de pregrado en Computacin, los estudiantes pueden llegar a desarrollar software
mediano en su proyecto de grado, en trabajos que se desarrollan durante ms de un trimestre y, excepcionalmente,
en asignaturas ms bien avanzadas en que los estudiantes del mismo se organiza como un equipo de equipos.
Tengo entendido (pero no confirmado) que hacia el ao 2000, el software de control para una red de cajeros
automticos en Venezuela era del orden de 100 KSLOC.
Mark Swick2 reporta que el sistema de software que rastrea las fuerzas militares amistosas (Blue Force Tracker
System) para el ejrcito estadounidense lleg a alcanzar unas 500 KSLOC.
La versin 5.14.2 del interpretador del lenguaje Perl (2011) alcanza unos 669 KSLOC3. En el desarrollo de esta
versin participaron 150 personas.
El manejador de bases de datos mySQL versin 5.5.17 (ao 2011) contiene 1.2 millones de SLOC4.
(http://blog.james.rcpt.to/2012/02/13/debian-wheezy-us19-billion-your-price-free/).
Para 1995, Microsoft Word inclua ms de 2 millones de SLOC5.
Se estima que Windows 8 (2012) contiene unos 80 millones de SLOC6. Debian 7.0 (2013) contiene 420 millones
de SLOC y contiene porciones escritas en 31 lenguajes diferentes de programacin7.

Un ejercicio de visualizacin
Supongamos que lo contratan para desarrollar un programa de 100 KLOC y supongamos que, para
poder competir exitosamente, ese programa tiene que estar listo en menos de un ao. Desarrollara Ud.
slo el programa?
Hagamos una cuenta optimista. Supongamos que Ud. es un programador fuera de serie y que logra
programar en promedio cien lneas de cdigo depurado al da. Sin tomar vacaciones, ni fines de
semana, sin enfermarse sino dedicando todos los das del ao a pensar, escribir, compilar y depurar cien
lneas diarias, terminara el proyecto en 2.73 aos...
Adems, si usted quiere disfrutar de una vida saludable, tampoco debe programar los 365 das del ao
-debera dejar de trabajar al menos los fines de semana (104 das) y tomarse 20 das hbiles de
vacaciones al ao. Lo cul significa que los 2.73 aos de desarrollo, se convertiran en 4,14 aos. Por
ende para cumplir slo con el ao de plazo dado por su cliente, debe escribir y depurar 400 lneas de
cdigo diariamente.
Pero, es realista pensar en programar cien o cuatrocientas lneas de cdigo al da en promedio? Los
estudios muestran que el programador profesional produce, en promedio, menos de diez lneas de
cdigo al da durante el desarrollo de un proyecto de tamao mediano o grande! Ms adelante veremos
el por qu de esta cifra que luce, a primera vista, escandalosamente baja.
Para tener una mejor idea de lo que son cien mil lneas de cdigo, consideremos qu espacio ocupa el
imprimirlas. Una pgina de un libro de texto tiene alrededor de 40 lneas por pgina. Por ende, si se
hacen los clculos, imprimir 100.000 SLOC produce 5 tomos de 500 pginas cada uno. Ni George R.

2 Fuente: Mark Swick: How to Leverage Open Architectures for Existing Systems. RTI Systems, E-Cast del 21 de agosto
2014. http://event.on24.com/r.htm?e=830086&s=1&k=BF6DC01D4350A4D22655D80CBED9B3C5
3 Fuente: http://blog.james.rcpt.to/2012/02/13/debian-wheezy-us19-billion-your-price-free/
4 Fuente: http://blog.james.rcpt.to/2012/02/13/debian-wheezy-us19-billion-your-price-free/
5 Fuente: http://www.wired.com/wired/archive/3.09/myhrvold.html
6 Fuente: http://www.cs.umd.edu/class/spring2014/cmsc122/Lec/122Spring14Lec31.pdf
7 Fuente: http://blog.james.rcpt.to/2012/02/13/debian-wheezy-us19-billion-your-price-free/
Universidad Simn Bolvar Ingeniera de Software 1 Desarrollo de Software de Tamao Moderado..3

R. Martin, el autor de la serie "Game of Thrones" es as de productivo!

Y eso no es todo. Ningn cliente sensato va a aceptar que usted produzca un cdigo que no pueda
mantener, es decir, que lo obligue a l a depender de usted para actualizarlo, ajustarlo, extenderlo o
incluso corregir estos pequeos defectos que quedaron despus de su asombroso esfuerzo. Para ello, el
cdigo debe estar documentado apropiadamente, para que otros desarrolladores puedan entenderlo.
Capers Jones report, hace ya unos aos, que, en promedio, en la industria americana de software se
elaboran cuatro pginas de documentos adicionales por cada 53 lneas de cdigo Java8. O sea que a los
cinco tomos de listado, hay que agregar unos 18 tomos adicionales de documentacin. En el 2001, en
los cursos de Ingeniera de Software en la USB, encontramos que ciertas metodologas de desarrollo
obligan a producir entre 300 y 500 pginas de documentacin para un software de 9.5 KLOC, lo que
extrapolado linealmente a 100 KLOC nos lleva a estimar que en tal proyecto pudieran tener que
elaborarse el equivalente a entre 6 y 10 tomos adicionales de documentos adicionales al listado de
cdigo fuente.
Qu contienen estas pginas? Entre otros aspectos: la arquitectura del software, la filosofa de diseo,
justificaciones de diseo, el diseo de la base de datos, las normas o estndares que aplican, las pruebas
que se disearon y el resultado de aplicarlas y el manual del usuario. Para un software de cierto tamao,
el manual del usuario, por si solo, puede llevarse varios tomos. Por ejemplo, la documentacin asociada
a los manuales de un sistema de operacin UNIX normalmente sobrepasa las mil pginas.
La nica manera que puedas desarrollar ese software de 100 KSLOC en un ao por tu cuenta es
basndote en algn cdigo similar desarrollado previamente. Sin embargo, entender un cdigo ajeno no
es sencillo. En 1989, Buckley sugiri que el tamao mximo de un programa que se puede entender
contiene entre 7 KLOC y 15 KLOC de cdigo fuente y estim que entender ese programa lo
suficientemente bien para modificarlo se llevara entre tres y seis meses de trabajo.
La conclusin es inescapable: para desarrollar un software de 100 KSLOC en un plazo competitivo
tienes que aprovechar cdigo confiable ya hecho y trabajar en equipo.

Un ejemplo de software exitoso y actual de tamao mediano

En 18 meses, tres ingenieros de software desarrollaron HipHop, un traductor de PHP a C++. Este software, ms
tarde transformado a una "mquina virtual de PHP" permiti mejorar el rendimiento de los servidores web de
Facebook de manera importante9.
El tiempo de desarrollo de un software de 500 KSLOC

En un webcast Mark Swick10 report que el sistema de software que rastrea las fuerzas militares amistosas (Blue
Force Tracker System) para el ejrcito estadounidense lleg a alcanzar unas 500 KSLOC despus de ocho aos de
desarrollo! No report el nmero de profesionales involucrados pero s mencion que se trataron de varios equipos
de desarrolladores.

8 Capers Jones: Assessment and Control of Software Risks, Prentice-Hall, 1994

9 Fuente: http://royal.pingdom.com/2010/06/18/the-software-behind-facebook/
10 Fuente: Mark Swick: How to Leverage Open Architectures for Existing Systems. RTI Systems, E-Cast del 21 de agosto
2014. http://event.on24.com/r.htm?e=830086&s=1&k=BF6DC01D4350A4D22655D80CBED9B3C5
Universidad Simn Bolvar Ingeniera de Software 1 Desarrollo de Software de Tamao Moderado..4

2. Por qu distinguimos entre software de tamao

pequeo, mediano y grande?
Estas tres categoras son interesantes en cuanto que requieren de tcnicas cualitativamente diferentes
para desarrollarlos. Por ejemplo es de particular inters que
Un software de pequeo tamao lo puede desarrollar un programador profesional en un tiempo
que puede llegar a ser de varias semanas;
Un software de tamao moderado ya requiere del esfuerzo de un equipo desarrollador
profesional conformado por varias personas que le dedicarn un tiempo que puede variar desde
varios meses a un par de aos. En otras palabras, un software puede considerarse de tamao
moderado si un equipo profesional, generalmente de entre dos y diez personas puede
desarrollarlo en no ms de uno o dos aos.
Un software de tamao grande requiere la cooperacin de decenas o centenas de profesionales
que se ven obligados a organizarse en varios equipos (es un equipo de equipos). Tal desarrollo
se lleva varios aos.
Supongamos que nuestro hiptetico cliente acepta que el software de 100.000 SLOC lo desarrolle un
equipo de hasta cuatro profesionales, liderizados por usted, siempre y cuando la entrega del producto
se haga en un ao. En qu se diferencia tal desarrollo en equipo de un desarrollo en solitario?
Para comenzar, tiene que organizar a su equipo: como jefe, usted se reserva la responsabilidad de
tomar todas las decisiones importantes11 en forma ejecutiva, o prefiere que las decisiones se tomen por
consenso? Todos hacen de todo, o cada quien toma un rol especializado (por ejemplo (1) arquitecto-
diseador (2) programador (3) responsable de pruebas (tester) y (4) responsable de herramientas de
apoyo (toolsmith)? En todo caso ahora usted tiene que invertir ms tiempo en comunicarse y ponerse de
acuerdo con los miembros de su equipo. Si opt por centralizar las decisiones importantes, le
interrumpirn para consultarle decisiones, o para que las aclare o para que las reconsidere; si por el
contrario opt por una organizacin ms consensual, dedicar ms tiempo a reuniones y discusiones
que busquen construir y mantener tal consenso. Alguien tiene que descomponer el trabajar en tareas,
asignar las tareas y cerciorarse que las tareas no se retrasen. Alguien tendr que estar pendiente de si
algn colega se desmotiva, se enferma o est pensando en renunciar al trabajo y a usted probablemente
le tocar buscar evitar o ponerle remedio a la situacin. Si comienza con otra persona inicialmente y
despus contrata o introduce ms gente en el proyecto, tendr que ver cmo hace para que esos nuevos
miembros se pongan al da y se integren rpidamente al proyecto, minimizando el tiempo que los viejos
miembros deban poner su trabajo de lado para poder poner a los nuevos al tanto de lo que se ha hecho,
qu queda por hacer y qu se espera que hagan. En resumen, usted y sus colegas tienen una serie de
labores administrativas o gerenciales que no tenan antes, por lo que encontrarn que tienen menos
tiempo que antes para dedicarle al desarrollo del proyecto en s. En resumen, hay todo un mundo de
gestin y dinmica interpersonal que no est presente cuando se trabaja en solitario. Claro que no todo
11 Y vaya si habrn decisiones importantes, decisiones sobre qu va a hacer el software y cmo lo va hacer, sobre qu
componentes va a tener, si se van a desarrollar de cero o si van a aprovechar componentes previamente desarrollados o
disponibles, sobre cmo se van a repartir las tareas entre los miembros del equipo y para cundo tienen que estar listas
esas tareas, sobre cmo alcanzar una calidad adecuada del software y cmo y cundo se sabr que la han alcanzado,
sobre la vocera y la relacin con el cliente, etc.
Universidad Simn Bolvar Ingeniera de Software 1 Desarrollo de Software de Tamao Moderado..5

es negativo; trabajar en equipo puede ser muy motivador y muy estimulante. Pueden surgir ideas que a
usted no se le hubieran ocurrido slo, pueden animarle cuando le hace falta y puede que la experiencia,
pericia e inteligencia de un colega evite que usted tome una decisin errada o que pierda tiempo
aprendiendo a hacer algo que l o ella ya sabe hacer muy bien y muy rpidamente.
A medida que crece el tamao (y la complejidad) del software, crecen las dificultades gerenciales. Al
pasar de software mediano a software grande, podemos estar trabajando con ms gente de la que cabe
en una sala de reuniones, con mltiples equipos por lo que a los retos de la dinmica interpersonal se
agregan retos de dinmicas intergrupales
A medida que crece el tamao y la complejidad del software puede que la operacin del software afecte
a ms gente, con intereses, perspectivas y propsitos muy diferentes y hasta encontrados respecto al
software. Un gerente de una empresa que contrata el desarrollo de un software quiere que se desarrolle
un artefacto que ayude a imponer su visin de cmo deben hacerse las cosas en esa empresa, otro
gerente tiene una visin diferente del rol del software y hasta de la empresa, y los empleados que
tendrn que usar el software en sus labores diarias estn decididos a resistir el uso de un software que
consideran una pretensin intolerable, errada y malintencionada por parte de ambos gerentes y que, a
su leal entender, compromete el futuro de la empresa. La fascinante y riesgosa dimensin poltica del
desarrollo de software no ser tratada en este curso.

Qu ocurre en la prctica?
Distintos estudios coinciden en concluir que muchos proyectos de desarrollo de software fracasan pues:
No llegan a entregar un producto (proyectos abandonados);
Entregan un producto pero mucho ms tarde que lo prometido, a un costo mucho mayor que el
acordado inicialmente, o que hace mucho menos que lo que se pidi originalmente (proyectos
parcialmente exitosos).
Entregan productos que no se usan, bien sea porque no cumplen con las expectativas y/o las
necesidades de los usuarios finales o los clientes o bien sea porque no son confiables, es decir,
presentan tasas de falla inaceptables.
As por ejemplo, el Grupo Standish reporta las siguientes tasas de xito, fracaso e indeterminacin12
para proyectos de desarrollo de software13:

12 Un proyecto en estado indeterminado (en Ingls polticamente correcto "a challenged project") es un proyecto que tiene
tantos problemas que no se puede considerar que est en camino de convertirse en exitoso, a la vez ni se termina de
cancelar ni genera suficiente motivacin para hacer un esfuerzo para reorganizarlo. Tpicamente (a)el proyecto ya est
atrasado, (b) la mayor parte de los miembros del equipo desarrollador estn descorazonados, desmotivados y estresados,
(c) el cdigo est acumulando defectos y la documentacin est desatendida o desactualizada., (d) los miembros del
equipo pasan mucho tiempo en reuniones improductivas centradas en la asignacin de culpas y (e) hay mucha presin
para que se entregue algo para acabar de una vez y (f) hay una creciente sensacin de desconexin entre el equipo y el
resto de la organizacin. Vase http://softwareandotherthings.blogspot.com/2012/10/challenges-of-challenged-
projects.html

13 Fuente: http://www.galorath.com/wp/software-project-failure-costs-billions-better-estimation-planning-can-help.php
Universidad Simn Bolvar Ingeniera de Software 1 Desarrollo de Software de Tamao Moderado..6

1994 1996 1998 2000 2002 2004 2009

Tasa de xito 16% 27% 26% 28% 34% 29% 32%
Tasa de fracaso 31% 40% 28% 23% 15% 18% 24%
Tasa de indeterminacin 53% 33% 46% 49% 51% 53% 44%

Una bsqueda de "software failures" o similar por la red le proporcionar ejemplos especficos de
fracasos, tanto de productos de software como de proyectos de desarrollo del mismo. Las fallas de
software han sido responsables de muertes, sobre-exposicin a radiacin, diagnsticos mdicos errados,
apagones, fallas en controladores de todo tipo de dispositivos, la prdida de reservaciones y equipaje,
as como retrasos en vuelos, paralizacin de operaciones, el corte de servicios y todo tipo de prdidas
monetarias. Varias empresas han ido a la quiebra a consecuencia de los efectos de tales fallas o el
fracaso de proyectos crticos de desarrollo. A continuacin una breve descripcin de los casos recientes
ms sonados14:
Ao Caso
2013 Una falla de software ocasion la interrupcin de los servicios de correo electrnico de
Hotmail (Outlook.com) durante 16 horas, afectando a un estimado de 2 millones de usuarios.
La falla afect el sistema de enfriamiento del centro de datos causando un incremento
repentino de temperatura que, a su vez, caus una falla de los servidores. No slo se
interrumpieron los servicios Microsoft sino que tambin fue afectado el servicio de
almacenamiento en la nube de Skydrive.

2012 El proyecto para desarrollar un sistema de gestin de cadena de suministros para la fuerza
area estadounidense (Expeditionary Combat Support System) fue cancelado en Noviembre
2012, despus de tres aos de desarrollo, dejando una prdida de alrededor de un millardo de
dlares. La alternativa, corregir lo hecho para que el sistema entrara en operacin en el 2020
-con un retraso de ocho aos a lo requerido- hubiera costado otro US$ 1,1 millardos de
dlares.
Este sistema es uno de seis, de los nueve sistemas de software planificados por el Pentgono
para mejorar deficiencias en su gestin financiera, que llevan un retraso de hasta 12 aos y
que estn costando US$ 6,9 millardos por encima de su estimacin original.
En enero 2013, un Comit del Senado estadounidense inici una investigacin sobre este
caso.15

2012 La baja calidad de la nueva aplicacin para iOS6 que lanz Apple para competir con Google
Maps. En la primera semana de operacin las quejas de los usuarios sobre errores en
direcciones, ubicaciones e instrucciones para llegar a diferentes localidades, adems de una
serie de fallas francamente bizarras, obligaron al presidente de Apple a disculparse
pblicamente y le cost el empleo al gerente encargado del desarrollo de la aplicacin16.

14 Una interesante lista de otros defectos puede encontrarse en http://en.wikipedia.org/wiki/List_of_software_bugs

15 Fuente: http://www.bloomberg.com/news/2013-01-24/senators-to-probe-air-force-s-1-billion-failed-software.html
16 Fuente: http://www.crn.com/slide-shows/applications-os/240144057/the-10-biggest-software-stories-of-
2012.htm;jsessionid=LK3dtH1K6dENn5toPu-ktw**.ecappj03?pgno=2
Universidad Simn Bolvar Ingeniera de Software 1 Desarrollo de Software de Tamao Moderado..7

2011 En septiembre, el gobierno del Reino Unido abandon un proyecto de desarrollo de un

sistema para llevar los registros digitales de salud de todos sus ciudadanos. El proyecto haba
comenzado a desarrollarse en el 2002, cost US$ 18,7 millardos y no lleg a producir un
sistema capaz de usarse. Se consider el proyecto de tecnologa informtico ms costoso
acometido por este gobierno17.

2011 AXA Rosenburg Group, un grupo dedicado a los servicios de inversin, no le inform a sus
clientes-inversores que el software que les proporcionaba para ayudar a gestionar sus carteras
de inversin y sus activos tena varios defectos. Los clientes se quejaron de algunas fallas,
pero la empresa les dijo que los problemas eran debido a la volatilidad del mercado
financiero. Una investigacin por parte del ente regulador de este mercado en Estados Unidos,
la Securities and Exchange Commission (SEC) determin que hubo fraude. Como
consecuencia de ello, la empresa tuvo que pagar una multa de US$ 25 millones y US $217
millones como compensacin a los clientes, por las prdidas en que incurrieron18.

3. El recurso del mtodo

La complejidad y tamao que alcanza el software y las exigencias que necesita cumplir obligan a
prestar particular atencin a la gestin del proceso de su desarrollo. Sin embargo, la gestin por si
misma no es suficiente. En 1968, ante la preocupacin de muchos especialistas en relacin a la calidad
del software que se pona en produccin, se acu el trmino de Ingeniera del Software. Los
especialistas argumentaban que se podan adoptar y adaptar las tcnicas y los enfoques propios de la
Ingeniera a la problemtica de la construccin de software fiable en plazos predecibles y costos
razonables.
La ingeniera desarrolla y aplica, en forma disciplinada, mtodos y tcnicas fundamentadas en
conocimientos cientficos a la elaboracin de artefactos tiles sujeto a restricciones de recursos.

El software es un artefacto "til" y el desarrollo de software est sujeto a restricciones de recursos

como tiempo, esfuerzo y dinero, por lo que la propuesta de los especialistas luca -y sigue luciendo-
prometedora19.
Pueden distinguirse actividades caractersticas en el desarrollo de cualquier proyecto de ingeniera. Por
ejemplo:

17 Fuente: http://www.computerworld.com/s/article/9222864/10_biggest_ERP_software_failures_of_2011
18 Fuente: http://www.kualitatem.com/9-latest-software-failures-in-enterprise-applications-2011-2012/
19 Qu conocimientos cientficos pudiesen sustentar tcnicas y mtodos ingenieriles para desarrollar software? Debido a
la naturaleza literalmente intangible del software, no pareca tener sentido fundamentar a esta nueva disciplina en ciencias
como la Fsica, la Qumica o la Biologa. Claramente exista y se poda desarrollar cierta fundamentacin matemtica, como
lo mostraba claramente la teora de complejidad y el desarrollo de la teora que subyace las tcnicas de compilacin de
lenguajes de programacin. En sus clases en la Universidad Simn Bolvar, el profesor Nagib Callaos propuso que la
diferencia de Ingeniera de la Computacin respecto a las ingenieras ms tradicionales era que se deba fundamentar en las
ciencias sociales como Psicologa, Sociologa y Poltica, una aguda intuicin de particular relevancia para el rea de
Sistemas de Informacin.
Universidad Simn Bolvar Ingeniera de Software 1 Desarrollo de Software de Tamao Moderado..8

Se llevan a cabo actividades de anlisis para precisar y, si hiciera falta reconciliar, el propsito
del artefacto y las propiedades que se le exige cumplir, para estimar si construir el artefacto es
factible tcnica y financieramente, para determinar su impacto socio-econmico y ambiental y
para estimar el orden de magnitud de lo que costara desarrollarlo.
Se realizan actividades de diseo, donde se exploran, bosquejan, modelan y evalan
cuidadosamente distintas opciones para que el artefacto cumpla satisfactoriamente con su
propsito y las restricciones legales, ambientales, de tiempo, dinero, esfuerzo u otros recursos
que puedan aplicar o exigirse.
Se planifican y ejecutan actividades de construccin o produccin del artefacto.
Se llevan a cabo actividades de inspeccin, verificacin o prueba para cerciorarse que el
artefacto se construy segn lo indicado por el diseo y que cumple con las propiedades y el
propsito exigidos.
Se realizan actividades de mantenimiento, ampliacin (o extensin) y de ajustes del artefacto a
condiciones y exigencias cambiantes.
Se realizan actividades gerenciales para organizar, asignar, documentar y hacerle el seguimiento
apropiado a las actividades anteriores, obtener de manera oportuna y eficiente los recursos que
puedan hacer falta, incorporar y mantener motivado el personal requerido, controlar los riesgos
del desarrollo y, en general, asegurar la buena marcha del proyecto de desarrollo del artefacto.
Todos estos tipos de actividades se han venido adaptando al software. Adicionalmente se han
desarrollado varios modelos de procesos de desarrollo, tales como el modelo de la cascada, Rational
Unified Process (RUP) y Scrum. Estos modelos proponen disciplinas de trabajo y formas de intercalar
y llevar a cabo estas actividades. Escapa del alcance de este curso presentar y comparar tales modelos;
por limitaciones de tiempo, centraremos nuestra atencin primordialmente en algunas actividades,
tcnicas y herramientas de diseo, construccin y verificacin en el marco de un proceso agil de
desarrollo. En particular desarrollaremos el curso con las siguientes preguntas en mente:
1. Cmo se disea software flexible? Esto es importante dado que algunas experiencias sugieren
que los requerimientos de un software cambian a una tasa promedio de 1% mensual durante el
perodo de desarrollo de un proyecto: as, al finalizar un proyecto de tres aos, la tercera parte
de los requerimientos finales surgieron o se modificaron en paralelo con el desarrollo del
mismo.
2. Cmo podemos desarrollar varios diseos que cumplan con unos requerimientos dados y cmo
se puede escoger entre ellos?
3. Qu podemos hacer para reducir el nmero de defectos en el software?
4. Cmo facilitamos el mantenimiento futuro del software desarrollado?
5. Cmo se puede facilitar el desarrollo de software en equipo?
Universidad Simn Bolvar Ingeniera de Software 1 Desarrollo de Software de Tamao Moderado..9

Lecturas adicionales
Lea y contraste esta introduccin con la entrada de Ingeniera de Software que se encuentra en
Wikipedia o con el captulo introductorio de algn texto del rea tal como lo son:
Roger S. Pressman: Software Engineering: A Practitioners Approach. 7 Edicin, McGraw-
Hill, 2010
Ian Sommerville: Software Engineering. 8 Edicin, 2007 (tambin puede consultar la novena
edicin).
Bernd Bruegge, Allen H. Dutoit: Object-Oriented Software Engineering Using UML, Patterns
and Java. Prentice-Hall, 2010.