Instituto Politcnico Nacional

Unidad Profesional Interdisciplinaria de Ingeniera y Ciencias Sociales y Administrativas.

Licenciatura en Ciencias de la Informtica

Herramientas Automatizadas

Catedrtico: Cuevas Escobar Susana

Secuencia: 2CM40

Metodologa de desarrollo incremental

Equipo #3: Cabrillas Hernndez Jazmn Castellanos Hernndez Allan Uriel Cruz Hernndez Paola Rosillo Cabrera Cristhian Enrique Torres Paz Juan Fernando

Mxico D. F. a 12 de Febrero de 2013

Desarrollo de software.
Un sistema informtico est compuesto por hardware y software. En cuanto al hardware, su produccin se realiza sistemticamente y la base de conocimiento para el desarrollo de dicha actividad est claramente definida. La fiabilidad del hardware es, en principio, equiparable a la de cualquier otra mquina construida por el hombre. Sin embargo, respecto del software, su construccin y resultados han sido histricamente cuestionados debido a los problemas asociados, entre ellos podemos destacar los siguientes: Los sistemas no responden a las expectativas de los usuarios. Los programas fallan con cierta frecuencia. Los costes del software son difciles de prever y normalmente superan las estimaciones. La modificacin del software es una tarea difcil y costosa. El software se suele presentar fuera del plazo establecido y con menos prestaciones de las consideradas inicialmente. Normalmente, es difcil cambiar de entorno hardware usando el mismo software. El aprovechamiento ptimo de los recursos (personas, tiempo, dinero, herramientas, etc.) no suele cumplirse.

El proceso de desarrollo del software Un proceso de desarrollo de software tiene como propsito la produccin eficaz y eficiente de un producto software que rena los requisitos del cliente. Dicho proceso, en trminos globales se muestra en la. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniera, en el desarrollo de software hay una serie de desafos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuacin se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construccin. Un producto software en s es complejo, es prcticamente inviable conseguir un 100% de confiabilidad de un programa por pequeo que sea. Existe una inmensa combinacin de factores que impiden una verificacin exhaustiva de las todas posibles situaciones de ejecucin que se puedan presentar (entradas, valores de variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.). Un producto software es intangible y por lo general muy abstracto, esto dificulta la definicin del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similar. Esto hace que los requisitos sean difciles de consolidar tempranamente. As, los cambios en los requisitos son inevitables, no slo despus de entregado en producto sino tambin durante el proceso de desarrollo.

Adems, de las dos anteriores, siempre puede sealarse la inmadurez de la ingeniera del software como disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniera. Sin embargo, esto no es ms que un intil consuelo. El proceso de desarrollo de software no es nico. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difcil automatizar todo un proceso de desarrollo de software. A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos: 1. Especificacin de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software. 2. Diseo e Implementacin: Se disea y construye el software de acuerdo a la especificacin. 3. Validacin: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente. 4. Evolucin: El software debe evolucionar, para adaptarse a las necesidades del cliente. Metodologa de desarrollo incremental. En un desarrollo iterativo e incremental el proyecto se planifica en diversos bloques temporales (en el caso de Scrum de un mes natural o hasta de dos semanas, si as se necesita) llamados iteraciones. Las iteraciones se pueden entender como mini proyectos: en todas las iteraciones se repite un proceso de trabajo similar (de ah el nombre iterativo) para proporcionar un resultado completo sobre producto final, de manera que el cliente pueda obtener los beneficios del proyecto de forma incremental. Para ello, cada requisito se debe completar en una nica iteracin: el equipo debe realizar todas las tareas necesarias para completarlo (incluyendo pruebas y documentacin) y que est preparado para ser entregado al cliente con el mnimo esfuerzo necesario. De esta manera no se deja para el final del proyecto ninguna actividad arriesgada relacionada con la entrega de requisitos. En cada iteracin el equipo evoluciona el producto (hace una entrega incremental) a partir de los resultados completados en las iteraciones anteriores, aadiendo nuevos objetivos/requisitos o mejorando los que ya fueron completados. Un aspecto fundamental para guiar el desarrollo iterativo e incremental es la priorizacin de los objetivos/requisitos en funcin del valor que aportan al cliente.

Adems es una forma de reducir la repeticin del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema. Surge de la combinacin del Modelo de Cascada y Modelo Evolutivo. Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema. Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo. Aportaciones, beneficios y ventajas Se puede gestionar las expectativas del cliente (requisitos desarrollados, velocidad de desarrollo, calidad) de manera regular, puede tomar decisiones en cada iteracin. Esto es especialmente interesante cuando: El cliente no sabe exactamente qu es lo que necesita, lo va sabiendo conforme va viendo cuales son los resultados del proyecto. El cliente necesita hacer cambios a corto plazo (nuevos requisitos o a cambios en los ya realizados):
o

Cambios en las condiciones del mercado (por un cambio de necesidades, por un nuevo producto que ha lanzado la competencia, urgencias). La reaccin y aceptacin del mercado respecto al uso de los primeros resultados del proyecto. Cualquier cambio en el entorno (recursos, etc.), que pueda incluso finalizar el proyecto manteniendo como mnimo los resultados alcanzados hasta ese momento.

El equipo necesita saber si lo que ha entendido es lo que el cliente espera. El cliente puede comenzar el proyecto con requisitos de alto nivel, quizs no del todo completos, de manera que se vayan refinando en sucesivas iteraciones. Slo es necesario conocer con ms detalle los requisitos de las primeras iteraciones, los que ms valor aportan. No es necesario realizar una recoleccin completa y detallada de todos los requisitos antes de empezar el desarrollo del proyecto.

El cliente puede obtener resultados importantes y usables ya desde las primeras iteraciones. Se puede gestionar de manera natural los cambios que van apareciendo durante el proyecto. La finalizacin de cada iteracin es el lugar natural donde el cliente puede proporcionar su feedback tras examinar el resultado obtenido. Con esta informacin ya es posible planificar los cambios necesarios para alinearse con las expectativas del cliente desde las primeras iteraciones, de manera que al finalizar el proyecto el cliente obtenga los objetivos esperados. El cliente como mximo puede perder los recursos dedicados a una iteracin, no los de todo el proyecto. La finalizacin de cada iteracin es el lugar natural donde el equipo puede decidir cmo mejorar su proceso de trabajo, en funcin de la experiencia obtenida. Con esta informacin ya es posible planificar los cambios necesarios para aumentar la productividad y calidad desde las primeras iteraciones. Permite conocer el progreso real del proyecto desde las primeras iteraciones y extrapolar si su finalizacin es viable en la fecha prevista. El cliente puede decidir volver a ordenar los requisitos del proyecto, aadir nuevos equipos, cancelarlo, etc. Permite mitigar desde el inicio los riesgos del proyecto. Desde la primera iteracin el equipo tiene que gestionar los problemas que pueden aparecer en una entrega del proyecto. Al hacer patentes estos riesgos, es posible iniciar su mitigacin de manera anticipada. Permite gestionar la complejidad del proyecto.
o

En una iteracin slo se trabaja en los requisitos que aportan ms valor en ese momento. Se puede dividir la complejidad para que cada parte sea resuelta en diferentes iteraciones.

Dado que cada iteracin debe dar como resultado requisitos terminados, se minimiza el nmero de errores que se producen en el desarrollo y se aumentar la calidad.

Restricciones y desventajas.

La disponibilidad del cliente debe ser alta durante todo el proyecto dado que participa de manera continua:
o

El inicio de una iteracin, el cliente ha de detallar (o haber detallado previamente) los requisitos que se van a desarrollar.

En la finalizacin de cada iteracin, el cliente ha de revisar los requisitos desarrollados.

La relacin con el cliente ha de estar basada en los principios de colaboracin y ganar/ganar ms que tratarse de una relacin contractual en la cual cada parte nicamente defiende su beneficio a corto plazo. Cada iteracin debe dar como resultado requisitos terminados, de manera que el resultado sea realmente til para el cliente y no deje tareas pendientes para futuras iteraciones o para la finalizacin del proyecto. Cada iteracin ha de aportar un valor al cliente, entregar unos resultados cerrados que sean susceptibles de ser utilizados por l. Es necesario disponer de tcnicas y herramientas que permitan hacer cambios fcilmente en el producto, de manera que pueda crecer en cada iteracin de manera incremental sin hacer un gran esfuerzo adicional, manteniendo su complejidad minimizada y su calidad.

Usos y aplicacin. Para la obtencin de buenos resultados es recomendable utilizar iteraciones cortas de 2 a 4 semanas a la hora incrementa la productividad del proyecto, dado que el equipo trabaja de forma ms eficiente cuando tiene objetivos a corto plazo. As mismo, con iteraciones cortas la precisin de las estimaciones aumenta. El tamao depende de:
o o o

Los condicionantes del proyecto. La necesidad de tener feedback ms o menos rpido. Que no se degrade la relacin trabajo til / gestin operativa (por ejemplo reuniones, actividades necesarias que no producen valor directo, etc.).

Adems de utilizar iteraciones regulares, de manera que todas sean un timebox de la misma duracin. Al mismo tiempo que el equipo aprenda a calcular la velocidad de desarrollo, la cantidad de trabajo que puede hacer en una iteracin (sin tener que hacer extrapolaciones si las iteraciones no fuesen regulares). El cliente puede proyectar cuantas iteraciones se necesitan para tener cada entrega, en funcin de la velocidad de desarrollo del equipo (el trabajo que pudo completar en iteraciones anteriores del mismo tamao), y tomar decisiones al respecto. Permite gestionar y sincronizar de manera sencilla las necesidades del proyecto con respecto a las de otros proyectos (integracin con el trabajo realizado por otros equipos, comparticin de personas que son difciles de asignar a un nico equipo). Las iteraciones coincidiendo con meses naturales permiten sincronizar el trabajo del equipo con el de otros departamentos y con el resto de la organizacin (por ejemplo, la

organizacin puede tener medidas de resultados y objetivos a nivel trimestral o cuatrimestral). Finalmente podemos concluir que el modelo incremental es un desarrollo de tipo medular, con entregas parciales del sistema. Estas partes son llamadas incrementos y son escogidos con base a las prioridades que se establecen. El modelo permite una implementacin y refinamientos sucesivos. Con cada incrementos de agrega nueva funcionalidad o se cubren nuevos requisitos. En todos los casos se mejora la versin previamente implementada del software, ya que ese es el objetivo de este modelo.

Ejemplo.

El cliente quiere desplazarse sin tener que caminar, para ello quiere un vehculo que le ayude a llegar a destinos de una forma ms cmoda. Necesidades:

Vehculo sobre ruedas No mojarse Poder orientar la direccin Cmodo Rpido Fcil de llevar Mantener temperatura ambiente

Est pensando en un coche a medida, pero nuestro objetivo es resolver sus necesidades de una forma iterativa e incremental, resolviendo su necesidad de la forma ms sencilla y funcional sin olvidarnos de optimizar el coste/valor de cada entrega. Primer incremento. Descartando el patinete convencional o patines, decidimos entregar al cliente un patn con manillar para que pueda desplazarse sobre ruedas, es ms cmodo que ir caminando, resolvemos la necesidad de desplazarse. Cmo no quiere mojarse en caso de lluvia le ofrecemos un impermeable. El cliente, tras hacer uso de la primera entrega, nos expone sus impresiones; impulsarse con un pie es complicado, no es muy cmodo tener que ir de pie y el impermeable que le hemos entregado no transpira, por lo que acaba mojado por la condensacin. El vehculo est muy bien, pero cuando tiene que detener el vehculo le supone un esfuerzo. Segundo incremento. Entregamos al cliente una bicicleta, de esta forma se puede desplazar sentado, va ms cmodo ya que la forma de impulsar en el vehculo se ha mejorado y le provisionamos de unos frenos que le permite frenar con mayor comodidad. Sustituimos el impermeable barato por uno pensado para hacer deporte, ayuda a transpirar y no mojarse por la condensacin. El cliente nos indica que va mucho ms cmodo que con el patinete, observa que puede alcanzar mayor velocidad pero que an as se cansa cuando se desplaza. Al coger mayor velocidad debido al esfuerzo que le supone acaba mojado, esta vez no tanto por la condensacin si no por sudar. Tercer incremento. Entregamos al cliente una bicicleta elctrica, la cual le permite moverse sin tener que hacer tanto esfuerzo, lo que le evitar sudar. El cliente, agradece no tener que sudar tanto, pero que le gustara ir ms cmodo y evitar tener que moverse para que el vehculo se impulse.

Cuarto incremento. Entregamos al cliente una motocicleta, la cual le permite moverse ahora a mayor velocidad, el asiento es ms cmodo y no tiene que moverse para lograr el movimiento. Mejoramos su equipamiento para la lluvia. El cliente, contento por no tener que hacer esfuerzo, ahora se mueve ms rpido y tarda menos en su desplazamiento, pero el casco de la moto es una faena y tener que andar con el equipo de lluvia encima y parar para equiparse cuando llueve es molesto. Quinto incremento. Entregamos al cliente, una motocicleta con habitculo protegido, de estas que tienen parte de carrocera por encima de la cabeza del motorista, haciendo no necesario el uso del casco, y evitando que se moje. El cliente, est contento por la evolucin del producto, ahora se desplaza ms cmodo, pero en lluvia y en circunstancias adversas el desplazarse en dos ruedas puede ser un problema de estabilidad. Sexto incremento. Entregamos al cliente, el mismo vehculo que antes, pero el tren delantero est equipado con dos ruedas, mejorando la estabilidad del vehculo. El cliente, est contento por haber mejorado la estabilidad, pero el est pensando en un alguno cerrado para protegerse del frio/calor y poder transportar a personas y bultos. Sptimo incremento. Entregamos al cliente un coche de segmento pequeo equipado con climatizador. El cliente est contento, ya que su producto ha evolucionado. Ahora se protege de la lluvia, no lleva casco, no suda, no hace esfuerzo y es ms estable. Pero, es un coche gasolina que consume mucho y tiene un maletero muy pequeo. Octavo incremento. Entregamos al cliente un coche del segmento intermedio, esta vez est equipado con un motor elctrico para ahorrar en consumo. El cliente, ahora ahorra en el consumo pero el coche no supera los 60 km/h y le cuesta encontrar sitios donde recargar la batera. El aumento del tamao del vehculo le ha parecido razonable. Noveno incremento. Entregamos al cliente un coche hbrido, que cuando andamos por ciudad utilizamos las bateras en caso de tener energa o si no utilizamos el motor que esta vez es diesel y consume menos combustible. En el momento que excedes los 60 km/h se usa el motor diesel. El cliente, la solucin de utilizar un motor en caso de no tener batera es genial, ms si el consumo se ha reducido al pasar de gasolina a diesel, pero sigue con el

problema de que no encuentra muchos sitios donde poder utilizar la batera y le est suponiendo un problema. Dcimo incremento. Como no podemos dotar al cliente de puntos de recarga en todos sus trayectos por coste, lo que hacemos es que el motor a combustin recargue las bateras. El cliente, tiene un vehculo que resuelve sus necesidades, y aunque en un principio estaba pensando en un coche deportivo por esttica ahora se ha dado cuenta que el que tiene es mejor de lo que l esperaba, prctico y econmico.

Conclusiones:

En todas las entregas tiene producto funcional Se toma en cuenta en todo momento el coste/valor Siempre se aporta un producto viable para poder desplazarse Jams se pierde de vista el objetivo y en cada incremento se implementa lo que se necesitaba, no lo que crea o supona.

Referencias.

Ingeniera de software. Ian Sommerville. Pearson Education, 2005. Sptima edicin. Pginas: 66-68 Introduccin a la ingeniera del software Fernando Alonso Amo. Loic Martnez Normand. Francisco Javier Segovia Prez Editorial Delta, 2005. Primera edicin. Pginas: 338-348 http://ldc.usb.ve/~abianc/materias/ci4712/ProcesoSW-Letelier.pdf