PDF generado usando el kit de herramientas de fuente abierta mwlib. Ver http://code.pediapress.com/ para mayor informacin.

PDF generated at: Sun, 19 Jan 2014 18:16:06 UTC

Ingeniera de software
Unidad 1
Contenidos
Artculos
Desarrollo rpido de aplicaciones 1
Desarrollo gil de software 1
Modelo de prototipos 3
Programacin extrema 4
Referencias
Fuentes y contribuyentes del artculo 8
Fuentes de imagen, Licencias y contribuyentes 9
Licencias de artculos
Licencia 10
Desarrollo rpido de aplicaciones
1
Desarrollo rpido de aplicaciones
El desarrollo rpido de aplicaciones o RAD (acrnimo en ingls de rapid application development) es un proceso
de desarrollo de software, desarrollado inicialmente por James Maslow en 1980. El mtodo comprende el desarrollo
interactivo, la construccin de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering).
Tradicionalmente, el desarrollo rpido de aplicaciones tiende a englobar tambin la usabilidad, utilidad y la rapidez
de ejecucin.
[1]
Hoy en da se suele utilizar para referirnos al desarrollo rpido de interfaces grficas de usuario tales como Glade, o
entornos de desarrollo integrado completos. Algunas de las plataformas ms conocidas son Visual Studio, Lazarus,
Gambas, Delphi, Foxpro, Anjuta, Game Maker, Velneo o Clarion. En el rea de la autora multimedia, software
como Neosoft Neoboo y MediaChance Multimedia Builder proveen plataformas de desarrollo rpido de
aplicaciones, dentro de ciertos lmites.
Antecedentes
Comenzando con las ideas de Barry Boehm y Scott Shultz, Martin desarroll el Rapid Application Development
durante los aos 1980 en IBM y finalmente lo formaliz publicando un libro en 1990.
Referencias
[1] [1] Maurer and S. Martel. (2002). "Extreme Programming: Rapid Development for Web-Based Applications". IEEE Internet Computing, 6(1) pp
86-91 Enero/Febrero 2002.
Desarrollo gil de software
Esquema general de una metodologa gil para
desarrollo de software
El desarrollo gil de software son mtodos de ingeniera del software
basados en el desarrollo iterativo e incremental, donde los requisitos y
soluciones evolucionan mediante la colaboracin de grupos auto
organizados y multidisciplinarios. Existen muchos mtodos de
desarrollo gil; la mayora minimiza riesgos desarrollando software en
lapsos cortos. El software desarrollado en una unidad de tiempo es
llamado una iteracin, la cual debe durar de una a cuatro semanas.
Cada iteracin del ciclo de vida incluye: planificacin, anlisis de
requisitos, diseo, codificacin, revisin y documentacin. Una
iteracin no debe agregar demasiada funcionalidad para justificar el
lanzamiento del producto al mercado, sino que la meta es tener una demo (sin errores) al final de cada iteracin. Al
final de cada iteracin el equipo vuelve a evaluar las prioridades del proyecto.
Los mtodos giles enfatizan las comunicaciones cara a cara en vez de la documentacin. La mayora de los equipos
giles estn localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en
ingls). La oficina debe incluir revisores, escritores de documentacin y ayuda, diseadores de iteracin y directores
de proyecto. Los mtodos giles tambin enfatizan que el software funcional es la primera medida del progreso.
Combinado con la preferencia por las comunicaciones cara a cara, generalmente los mtodos giles son criticados y
tratados como "indisciplinados" por la falta de documentacin tcnica.
Desarrollo gil de software
2
Historia
La definicin moderna de desarrollo gil de software evolucion a mediados de la dcada de 1990 como parte de una
reaccin contra los mtodos de "pico pizado", muy estructurados y estrictos, extrados del modelo de desarrollo en
cascada. El proceso originado del uso del modelo en cascada era visto como burocrtico, lento, degradante e
inconsistente con las formas de desarrollo de software que realmente realizaban un trabajo eficiente.
Los mtodos de desarrollo giles e iterativos pueden ser vistos como un retroceso a las prcticas observadas en los
primeros aos del desarrollo de software (aunque en ese tiempo no haba metodologas formales). Inicialmente, los
mtodos giles fueron llamados mtodos de "peso liviano".
En el ao 2001, miembros prominentes de la comunidad se reunieron en Snowbird, Utah, y adoptaron el nombre de
"mtodos giles". Poco despus, algunas de estas personas formaron la "alianza gil", una organizacin sin fines de
lucro que promueve el desarrollo gil de aplicaciones. Muchos mtodos similares al gil fueron creados antes del
2000. Entre los ms notables se encuentran: Scrum (1986), Crystal Clear (cristal transparente), programacin
extrema (en ingls eXtreme Programming o XP, 1996), desarrollo de software adaptativo, feature driven
development, Mtodo de desarrollo de sistemas dinmicos (en ingls Dynamic Systems Development Method o
DSDM, 1995).
Kent Beck cre el mtodo de Programacin Extrema (usualmente conocida como XP) en 1996 como una forma de
rescatar el proyecto del Sistema exhaustivo de compensaciones de Chrysler (C3). Mientras Chrysler cancelaba ese
proyecto, el mtodo fue refinado por Ron Jeffries.
Mtodos giles
Algunos mtodos giles de desarrollo de software:
Adaptive Software Development (ASD).
Agile Unified Process (AUP).
Crystal_Clear.
Essential Unified Process (EssUP).
Feature Driven Development (FDD).
Lean Software Development (LSD).
Kanban.
Open Unified Process (OpenUP).
Programacin Extrema (XP).
Mtodo de desarrollo de sistemas dinmicos (DSDM).
Scrum.
G300.
Referencias
Bibliografa
Cockburn, Alistair. Agile Software Development. Highsmith Series.
Chin, Gary (2004). Agile Project Management: How to Succeed in the Face of Changing Project Requirements.
AMACOM.
Martinez, Gustavo (2011). Coding, quality check and documentation (300%): Get them from the same
development team!. VPD.
Desarrollo gil de software
3
Enlaces externos
Manifiesto para el desarrollo gil de software (http:/ / www. agilemanifesto. org/ iso/ es/ manifesto. html)
Recopilacin de artculos sobre metodologas giles (http:/ / www. javiergarzas. com/ metodologias-agiles)
Sitio web de la Comunidad Latinoamericana de Desarrollo gil de Software (http:/ / www. agiles. org)
Modelo de prototipos
El Modelo de prototipos, en Ingeniera de software, pertenece a los modelos de desarrollo evolutivo. El prototipo
debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos.
El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el cliente o
el usuario final. Este diseo conduce a la construccin de un prototipo, el cual es evaluado por el cliente para una
retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La interaccin ocurre
cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el
desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.
Etapas
Plan rpido
Modelado, diseo rpido
Construccin del Prototipo
Desarrollo, entrega y retroalimentacin
Comunicacin
Entrega del desarrollo final
Ventajas
Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no identifica los
requisitos detallados de entrada, procesamiento o salida.
Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro de la eficacia
de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin
humano-mquina.
La construccin de prototipos se puede utilizar como un modelo del proceso independiente, se emplea ms
comnmente como una tcnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del
proceso expuestos. Sin importar la forma en que ste se aplique, el paradigma de construccin de prototipos ayuda al
desarrollador de software y al cliente a entender de mejor manera cul ser el resultado de la construccin cuando los
requisitos estn satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente ms profundamente
para adquirir el producto.
Inconvenientes
El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la
intencin de crear un prototipo de forma rpida, se suelen desatender aspectos importantes, tales como la calidad
y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el
prototipo ha cumplido su funcin. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese
prototipo se construya el sistema final, lo que lo convertira en un prototipo evolutivo, pero partiendo de un
estado poco recomendado.
Modelo de prototipos
4
En aras de desarrollar rpidamente el prototipo, el desarrollador suele tomar algunas decisiones de
implementacin poco convenientes (por ejemplo, elegir un lenguaje de programacin incorrecto porque
proporcione un desarrollo ms rpido). Con el paso del tiempo, el desarrollador puede olvidarse de la razn que le
llev a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del
sistema final...
Conclusiones
A pesar de que tal vez surjan problemas, la construccin de prototipos puede ser un paradigma efectivo para la
ingeniera del software. La clave es definir las reglas del juego desde el principio; es decir, el cliente y el
desarrollador se deben poner de acuerdo en:
Que el prototipo se construya y sirva como un mecanismo para la definicin de requisitos.
Que el prototipo se descarte, al menos en parte.
Que despus se desarrolle el software real con un enfoque hacia la calidad.
Programacin extrema
La programacin extrema o eXtreme Programming (XP) es una metodologa de desarrollo de la ingeniera de
software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained:
Embrace Change (1999). Es el ms destacado de los procesos giles de desarrollo de software. Al igual que stos, la
programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la
adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los cambios de requisitos sobre la
marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de
adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms
realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los
cambios en los requisitos.
Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo de
acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de vida
del software.
Valores
Los valores originales de la programacin extrema son: simplicidad, comunicacin, retroalimentacin (feedback) y
coraje. Un quinto valor, respeto, fue aadido en la segunda edicin de Extreme Programming Explained. Los cinco
valores se detallan a continuacin:
Simplicidad
La simplicidad es la base de la programacin extrema. Se simplifica el diseo para agilizar el desarrollo y facilitar el
mantenimiento. Un diseo complejo del cdigo junto a sucesivas modificaciones por parte de diferentes
desarrolladores hacen que la complejidad aumente exponencialmente.
Para mantener la simplicidad es necesaria la refactorizacin del cdigo, sta es la manera de mantener el cdigo
simple a medida que crece.
Tambin se aplica la simplicidad en la documentacin, de esta manera el cdigo debe comentarse en su justa medida,
intentando eso s que el cdigo est autodocumentado. Para ello se deben elegir adecuadamente los nombres de las
variables, mtodos y clases. Los nombres largos no decrementan la eficiencia del cdigo ni el tiempo de desarrollo
gracias a las herramientas de autocompletado y refactorizacin que existen actualmente.
Programacin extrema
5
Aplicando la simplicidad junto con la autora colectiva del cdigo y la programacin por parejas se asegura que
cuanto ms grande se haga el proyecto, todo el equipo conocer ms y mejor el sistema completo.
Comunicacin
La comunicacin se realiza de diferentes formas. Para los programadores el cdigo comunica mejor cuanto ms
simple sea. Si el cdigo es complejo hay que esforzarse para hacerlo inteligible. El cdigo autodocumentado es ms
fiable que los comentarios ya que stos ltimos pronto quedan desfasados con el cdigo a medida que es modificado.
Debe comentarse slo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un
mtodo.
Las pruebas unitarias son otra forma de comunicacin ya que describen el diseo de las clases y los mtodos al
mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores se comunican constantemente
gracias a la programacin por parejas. La comunicacin con el cliente es fluida ya que el cliente forma parte del
equipo de desarrollo. El cliente decide qu caractersticas tienen prioridad y siempre debe estar disponible para
solucionar dudas.
Retroalimentacin (feedback)
Al estar el cliente integrado en el proyecto, su opinin sobre el estado del proyecto se conoce en tiempo real.
Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no
cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es ms importante.
Considrense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda
debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El cdigo tambin
es una fuente de retroalimentacin gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias
informan sobre el estado de salud del cdigo. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos
debidos a cambios recientes en el cdigo.
Coraje o valenta
Muchas de las prcticas implican valenta. Una de ellas es siempre disear y programar para hoy y no para maana.
Esto es un esfuerzo para evitar empantanarse en el diseo y requerir demasiado tiempo y trabajo para implementar el
resto del proyecto. La valenta le permite a los desarrolladores que se sientan cmodos con reconstruir su cdigo
cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se
implementaran mas fcilmente. Otro ejemplo de valenta es saber cuando desechar un cdigo: valenta para quitar
cdigo fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirti en crear ese cdigo. Adems, valenta
significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un da entero, y
luego lo resolver rpidamente al da siguiente, slo si es persistente.
Respeto
El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los
programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de
sus compaeros. Los miembros respetan su trabajo porque siempre estn luchando por la alta calidad en el producto
y buscando el diseo ptimo o ms eficiente para la solucin a travs de la refactorizacin del cdigo. Los miembros
del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo y elevando el
ritmo de produccin en el equipo.
Programacin extrema
6
Caractersticas fundamentales
Las caractersticas fundamentales del mtodo son:
Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresin. Se
aconseja escribir el cdigo de la prueba antes de la codificacin. Vase, por ejemplo, las herramientas de prueba
JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres
ltimas inspiradas en JUnit, la cual, a su vez, se insipir en SUnit, el primer framework orientado a realizar tests,
realizado para el lenguaje de programacin Smalltalk.
Programacin en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un
mismo puesto. La mayor calidad del cdigo escrito de esta manera -el cdigo es revisado y discutido mientras se
escribe- es ms importante que la posible prdida de productividad inmediata.
Frecuente integracin del equipo de programacin con el cliente o usuario. Se recomienda que un
representante del cliente trabaje junto al equipo de desarrollo.
Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas frecuentes.
Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y
mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorizacin no
se ha introducido ningn fallo.
Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de cada mdulo en
grupos de trabajo distintos, este mtodo promueve el que todo el personal pueda corregir y extender cualquier
parte del proyecto. Las frecuentes pruebas de regresin garantizan que los posibles errores sern detectados.
Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podr aadir
funcionalidad si es necesario. La programacin extrema apuesta que es ms sencillo hacer algo simple y tener un
poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca utilizarlo.
La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms comunicacin resulta ms
fcil identificar qu se debe y qu no se debe hacer. Cuanto ms simple es el sistema, menos tendr que comunicar
sobre ste, lo que lleva a una comunicacin ms completa, especialmente si se puede reducir el equipo de
programadores.
Roles
Programador
Escribe las pruebas unitarias y produce el cdigo del sistema.
Cliente
Escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Asigna la prioridad a las
historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar el mayor valor de
negocio.
Tester
Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los resultados en el equipo
y es responsable de las herramientas de soporte para pruebas.
Programacin extrema
7
Tracker
Es el encargado de seguimiento. Proporciona realimentacin al equipo. Debe verificar el grado de acierto entre las
estimaciones realizadas y el tiempo real dedicado, comunicano los resultados para mejorar futuras estimaciones.
Entrenador (coach)
Responsable del proceso global. Gua a los miembros del equipo para seguir el proceso correctamente.
Consultor
Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto. Ayuda
al equipo a resolver un problema especfico.
Gestor (Big boss)
Es el dueo del equipo y el vinculo entre clientes y programadores. Su labor esencial es la coordinacin.
Enlaces externos
Sitio dedicado a la divulgacin de la programacin extrema
[1]
(en espaol)
Sitio dedicado a la divulgacin de la programacin extrema
[2]
(en ingls)
Foro Yahoo Group creado para discutir XP en Espanol (200 miembros)
[3]
Resumen de programacin extrema
[4]
Referencias
[1] http:/ / www. programacionextrema.org/
[2] http:/ / www. extremeprogramming.org/
[3] http:/ / tech. groups. yahoo.com/ group/ xpspanish/
[4] http:/ / www. chuidiang.com/ ood/ metodologia/ extrema. php
Fuentes y contribuyentes del artculo
8
Fuentes y contribuyentes del artculo
Desarrollo rpido de aplicaciones Fuente: http://es.wikipedia.org/w/index.php?oldid=69773467 Contribuyentes: Adonis111, Adribeex, Amautitita, Anoryat, Biasoli, Bucho, Clementito,
Cristina.criado, Diegusjaimes, Eaco, Eamezaga, Ensada, Especiales, Ezequielmontes, HUB, Holmium, Jcaraballo, Jkbw, JoRgE-1987, Kotejante, Lasai, Lin linao, Locovich, ManoloKosh,
Mavirroco, Nbarreras2, Niuweme, Patxangas, Poco a poco, Rafa3040, Raystorm, Shooke, Spacebom, Spohlmann, Taichi, Terror, Tomatejc, Willicab, Zcastle, 106 ediciones annimas
Desarrollo gil de software Fuente: http://es.wikipedia.org/w/index.php?oldid=71654010 Contribuyentes: Alexav8, Arapajoe, Asierra, Avanto, Benzirpi, Blacki4, Bpk, Daniel G., Danieltellez,
David.Villa, DayL6, Delphidius, Diamondland, Dqueijo, EGA Futura, Etnas, Gabrielperez, GermanX, Hprmedina, Ilario, J.M.Domingo, JavierCantero, Jmbeas, Jonik, Juan.palacio, Lantius,
LazyFan, Ldfv, Lesthack, Magister Mathematicae, Marioe2000, Martingala, Mdd, PabloCastellano, Pieter, Poco a poco, Porao, Rafen, Santiagobas, Superandoni, Technopat, Tute,
Tyrannosaurusreflex, Unf, Veon, 76 ediciones annimas
Modelo de prototipos Fuente: http://es.wikipedia.org/w/index.php?oldid=70024149 Contribuyentes: Adribeex, Alexandermark, Alexhd, Alfredobi, Caucas, David.rgh, Diegusjaimes, Filipo,
Hanjin, Javierito92, Jkbw, Jose figueredo, Manw, Matdrodes, Netito777, Plux, Racso, Rakela, Rosarinagazo, Scap2000, Taichi, 65 ediciones annimas
Programacin extrema Fuente: http://es.wikipedia.org/w/index.php?oldid=71975104 Contribuyentes: Asierra, Bucephala, Camilo, Camoralesm, Danidsaster, Frutoseco, GermanX, Gonxoz,
Guille.hoardings, Idatacubo, Isha, J.delanoy, JCX, Jacm, Jaguar080, JavierCantero, Jmbeas, JorgeBerjano, Jorgechp, Juan.palacio, Jucapac, Kaizen2007, Kekkyojin, Maciek, ManuelGR, Mardolf,
Martingala, Miguel.lima, Mikel Gmez, Moriel, Murphy era un optimista, PabloCastellano, Pieter, Poco a poco, Porao, Rahkso, Rodrigo.pina, STANHMAL, Sabbut, Srgank, Tano4595, Tute,
Viko, Voise, Youssefsan, 104 ediciones annimas
Fuentes de imagen, Licencias y contribuyentes
9
Fuentes de imagen, Licencias y contribuyentes
File:Esquema general de una metodologia agil para desarrollo de software.png Fuente:
http://es.wikipedia.org/w/index.php?title=Archivo:Esquema_general_de_una_metodologia_agil_para_desarrollo_de_software.png Licencia: Creative Commons Attribution-Sharealike 3.0
Contribuyentes: User:Benzirpi
Licencia
10
Licencia
Creative Commons Attribution-Share Alike 3.0
//creativecommons.org/licenses/by-sa/3.0/