INGENIERIA DEL SOFTWARE GRUPO 301404_23

APORTE TRABAJO COLABORATIVO 1

LEIDY ZORAIDA CANO SANTAMARIA. CDIGO: 1053327743 VICTOR CARRILLO PATERNINA CODIGO: 1052962492 DIANA MARCELA CORREDOR CODIGO:1052384692 JUAN CAMILO USAMA JOS ALBERTO CASTILLA

Presentado a: JAIRO MARTINEZ BANDA TUTOR Modulo: INGENIERA DE SOFTWARE

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA PROGRAMA INGENIERIA DE SISTEMAS 2011

INGENIERIA DEL SOFTWARE GRUPO 301404_23

CONTENIDO

INTRODUCCIN 1. OBJETIVOS 2. DESARROLLO DE ACTIVIDADES 2.1 ACTIVIDAD 1 2.2 ACTIVIDAD 2 3. CONCLUSIONES 4. BIBLIOGRAFA ANEXOS

INGENIERIA DEL SOFTWARE GRUPO 301404_23

INTRODUCCIN

Gracias a la realizacin de este proyecto logramos crear un equipo de trabajo y aunque al principio no se logro tener una reunin para asignacin de roles cada uno de los participantes asumi un papel y respondi por una tarea especfica. Con esta actividad no solo se logro el cumplimiento de una responsabilidad sino que vale la pena resaltar el aprendizaje tan magnfico que nos dejo los modelos de programacin especialmente extreme programming (xp), que es una metodologa que no debera ser utilizada solo en el diseo de productos sino en la vida diaria porque si se hubiera entendido desde el principio hubieras obtenido una asignacin de roles, el diseo de unas etapas y un producto de mejor calidad.

INGENIERIA DEL SOFTWARE GRUPO 301404_23

1. DESARROLLO DE LA ACTIVIDAD

1.1 ACTIVIDAD 1 LA PRIMERA ERA (1950-1965) Durante los primeros aos de la era de la computadora, el software se contemplaba como un aadido. La programacin de computadoras era un arte de andar por casa para el que exista pocos mtodos sistemticos. El desarrollo del software se realizaba virtualmente sin ninguna planificacin, hasta que los planes comenzaron a descalabrarse y los costos a correr. Los programadores trataban de hacer las cosas bien y con un esfuerzo heroico, a menudo salan con xito. Lo normal era que el hardware fuera de propsito general. Por otra parte, el software se diseaba a medida para cada aplicacin y tenan una distribucin relativamente pequea. El software como producto (es decir, programas desarrollados para ser vendidos a uno o ms clientes) estaba en su infancia. La mayora del software se desarrollaba y era utilizado por la misma persona u organizacin. La misma persona lo escriba, ejecutaba y si fallaba, lo depuraba. Debido a que la movilidad en el trabajo era baja, los ejecutivos estaban seguros de que esa persona estara all cuando se encontrara algn error. Debido a este entorno personalizado del software, el diseo era un proceso implcito, realizado en la mente de alguien, y la documentacin normalmente no exista. A lo largo de los primeros aos aprendimos mucho sobre la implementacin de sistemas informticos, pero relativamente poco sobre la ingeniera de las computadoras. Sin embargo, en honor de la verdad, debemos reconocer que durante esa era se desarrollaron muchos sistemas de informacin excepcionales. Algunos de ellos todava se siguen utilizando hoy, y por sus caractersticas, siguen siendo admirados con toda justicia. LA SEGUNDA ERA (1965 - 1972) Durante la dcada de los sesenta a los setenta surge la segunda era 4 que se caracteriz por el establecimiento del software como producto y el software ya se desarrollaba para tener una amplia distribucin en un mercado, dichos software se distribuan para computadoras grandes y para minicomputadoras, siendo estos: Multiusuario, Tiempo real, Bases de datos, Productos de Software. La segunda era en la evolucin de los sistemas de computadoras, se extiende desde la mitad de la poca de los sesenta hasta finales de los setenta. La multiprogramacin y los sistemas multiusuario introdujeron nuevos conceptos de

INGENIERIA DEL SOFTWARE GRUPO 301404_23

interaccin hombre-mquina. Las tcnicas interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de sofisticacin del Hardware y Software. Los sistemas de tiempo real podan recoger, analizar y transformar datos de mltiples fuentes, controlando as los procesos y produciendo salidas en milisegundos en lugar de minutos. Los avances en los dispositivos de almacenamiento en lnea condujeron a la primera generacin de sistemas de gestin de bases de datos. Esta era se caracterizo tambin por el establecimiento del software como producto y la llegada de las casas de software. El software ya se desarrollaba para tener una amplia distribucin en un mercado multidisciplinar, los programadores se distribuan para computadoras grandes y para mini computadoras, a cientos e incluso a miles de usuarios que as lo requeran. Las casas desarrollaban proyectos en los que se producan programas de decenas de miles de sentencias fuente. Los productos de software comprados al exterior incorporaban cientos de miles de nuevas sentencias, todos esos programas, todas esas sentencias fuentes tenan que ser corregidos cuando se detectaban fallas, haba que modificarlos cuando cambiaban los requisitos de los usuarios o adaptarlos a nuevos dispositivos hardware que se hubieren adquirido. Estas actividades se llamaron colectivamente mantenimiento del software. El esfuerzo gastado en el mantenimiento del software comenz a absorber recursos en una medida alarmante, an peor, la naturaleza personalizada de muchos programadores, los haca virtualmente imposibles de mantener (haba comenzado una crisis del software).

LA TERCERA ERA (1972 - 1989) En la evolucin de los sistemas de computadoras, comenz a mediados de los aos setenta y continu ms all de una dcada, esta era se caracteriz por cuatro grandes aspectos en la evolucin de software: Sistemas distribuidos, Incorporacin de Inteligencia, Hardware de bajo costo, Impacto en el consumo. Concluyendo en esta era con la llegada y amplio uso de los microprocesadores. La evolucin de los sistemas de computadora comenz a mediados de los aos setenta y continu ms all de una dcada. El sistema distribuido, mltiples computadoras, cada una ejecutando funciones concurrentemente y comunicndose con alguna otra, incremento notablemente la complejidad de los sistemas informticos. Las redes del rea local y de rea global, las comunicaciones digitales de alto ancho de banda y la creciente demanda de acceso instantneo a los datos, supusieron una fuerte presin sobre los desarrolladores de software. An ms, los sistemas y el software que lo permitan continuaron residiendo dentro de la industria y de la academia. En conclusin esta era se caracteriz por la llegada y

INGENIERIA DEL SOFTWARE GRUPO 301404_23

amplio uso de los microprocesadores los cuales han producido un extenso grupo de productos inteligentes desde automviles hasta robots industriales, pero ninguno ha sido ms importante que la computadora personal. LA CUARTA ERA DEL SOFTWARE (1989- hasta nuestros das) La cuarta era de la evolucin de sistemas informticos se aleja de las computadoras individuales y da los programas de computadoras, dirigindose al impacto colectivo de las computadoras individuales y de los programas de computadoras, dirigindose al impacto colectivo de las computadoras y del software. Potentes mquinas personales controladas por sistemas operativos sofisticados, en redes globales y locales, acompaadas por aplicaciones de software avanzadas se han convertido en la norma. Las arquitecturas informticas estn cambiando de entornos centralizados de grandes computadoras a entornos descentralizados cliente/servidor. Las redes de informacin en todo el mundo proporcionan una infraestructura que iguala a expertos y polticos en pensar sobre una superautopista de informacin y una conexin del ciberespacio. De hecho internet se puede observar como un software al que pueden acceder usuarios individuales. La industria del software ya es la cuna de la economa del mundo. Las decisiones tomadas por gigantes de la industria tales como Microsoft arriesgan billones de dlares. A medida que la cuarta generacin progresa, han comenzado a surgir nuevas tecnologas. Las tecnologas orientadas a objetos estn desplazando rpidamente los enfoques de desarrollo de software ms convencionales en muchas reas de aplicaciones. Aunque las predicciones de las computadoras de quinta generacin continan eludindonos, las tcnicas de cuarta generacin para el desarrollo del software estn cambiando en forma en que la comunidad del software construye programas informticos. Los sistemas expertos y el software de inteligencia artificial han salido del laboratorio para entrar en aplicaciones prcticas de una gran variedad de problemas del mundo real. El software de redes neuronales artificiales junto con la aplicacin de lgica difusa ha abierto posibilidades excitantes para el reconocimiento de patrones y habilidades de procesamiento de informacin de carcter humano. La programacin de realidad virtual y los sistemas multimedia ofrecen formas radicalmente diferentes de comunicar informacin al usuario final. Los algoritmos genricos ofrecen el potencial para el software que reside dentro de las computadoras biolgicas masivamente en paralelo. Sin embargo, un conjunto de problemas relacionados con el software ha persistido a travs de la evolucin de los sistemas basados en computadora, y estos problemas continan aumentado.

INGENIERIA DEL SOFTWARE GRUPO 301404_23

LINEA DEL TIEMPO EVOLUCIN DEL SOFTWARE

1950

1960

1970

1980

1990

2000

Primera era Cuarta era

Segunda era

Tercera era

1957. primer lenguaje de programacin

1969. Desarroll o del sistema operativo UNIX

1972. Lenguaje de programa cin C

1975. leguaje de programaci n Basic por Steven Wosniak

1985. se publica Windows 1.0

1990. lenguaje de program acin Java

1994. Primera versin de Netscape navigator

INGENIERIA DEL SOFTWARE GRUPO 301404_23

1.2 ACTIVIDAD 2 TAREA 1.

EXTREME PROGRAMMING (XP) La programacin extrema o eXtreme Programming (XP) es un enfoque de la ingeniera de software formulado 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 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.

EXTREME PROGRAMMING (XP) XP es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico. Las Historias de Usuario Las historias de usuario son la tcnica utilizada en XP para especificar los requisitos del Software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las caractersticas que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinmico y flexible, en cualquier momento historias de usuario pueden romperse, reemplazarse por otras ms especficas o generales, aadirse nuevas o ser modificadas. Cada historia de

INGENIERIA DEL SOFTWARE GRUPO 301404_23

usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas. Las historias de usuario son descompuestas en tareas de programacin y asignadas a los programadores para ser implementadas durante una iteracin. Roles XP Aunque en otras fuentes de informacin aparecen algunas variaciones y extensiones de roles XP, en este apartado describiremos los roles de acuerdo con la propuesta original de Beck. Programador El programador escribe las pruebas unitarias y produce el cdigo del sistema. Debe existir una comunicacin y coordinacin adecuada entre los programadores y otros miembros del equipo. Cliente El cliente escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar mayor valor al negocio. El cliente es slo uno dentro del proyecto pero puede corresponder a un interlocutor que est representando a varias personas que se vern afectadas por el sistema. Encargado de pruebas (Tester) El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. Encargado de seguimiento (Tracker) El encargado de seguimiento proporciona realimentacin al equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones. Tambin realiza el seguimiento del progreso de cada iteracin y evala si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes. Determina cundo es necesario realizar algn cambio para lograr los objetivos de cada iteracin. Entrenador (Coach)

INGENIERIA DEL SOFTWARE GRUPO 301404_23

Es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para proveer guas a los miembros del equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente. Consultor Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto. Gua al equipo para resolver un problema especfico. Gestor (Big boss) Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin. Proceso XP Un proyecto XP tiene xito cuando el cliente selecciona el valor de negocio a implementar basado en la habilidad del equipo para medir la funcionalidad que puede entregar a travs del tiempo. El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos: 1. El cliente define el valor de negocio a implementar. 2. El programador estima el esfuerzo necesario para su implementacin. 3. El cliente selecciona qu construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4. El programador construye ese valor de negocio. 5. Vuelve al paso 1. En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar ms trabajo que el estimado, ya que se perder calidad en el software o no se cumplirn los plazos. De la misma forma el cliente tiene la obligacin de manejar el mbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteracin. El ciclo de vida ideal de XP consiste de seis fases: Exploracin, Planificacin de la Entrega (Release), Iteraciones, Produccin, Mantenimiento y Muerte del Proyecto. Fase I: Exploracin En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de inters para la primera entrega del producto. Al mismo tiempo el equipo de

INGENIERIA DEL SOFTWARE GRUPO 301404_23

desarrollo se familiariza con las herramientas, tecnologas y prcticas que se utilizarn en el proyecto. Se prueba la tecnologa y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploracin toma de pocas semanas a pocos meses, dependiendo del tamao y familiaridad que tengan los programadores con la tecnologa. Fase II: Planificacin de la Entrega En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimacin del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. Una entrega debera obtenerse en no ms de tres meses. Esta fase dura unos pocos das. Las estimaciones de esfuerzo asociado a la implementacin de las historias la establecen los programadores utilizando como medida el punto. Un punto, equivale a una semana ideal de programacin. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la velocidad de desarrollo, establecida en puntos por iteracin, basndose principalmente en la suma de puntos correspondientes las historias de usuario que fueron terminadas en la ltima iteracin. La planificacin se puede realizar basndose en el tiempo o el alcance. La velocidad del proyecto es utilizada para establecer cuntas historias se pueden implementar antes de una fecha determinada o cunto tiempo tomar implementar un conjunto de historias. Al planificar por tiempo, se multiplica el nmero de iteraciones por la velocidad del proyecto, determinndose cuntos puntos se pueden completar. Al planificar segn alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el nmero de iteraciones necesarias para su implementacin. Fase III: Iteraciones Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega est compuesto por iteraciones de no ms de tres semanas. En la primera iteracin se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creacin de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qu historias se implementarn en cada iteracin (para maximizar el valor de negocio). Al final de la ltima iteracin el sistema estar listo para entrar en produccin. Los elementos que deben tomarse en cuenta durante la elaboracin del Plan de la Iteracin son: historias de usuario no abordadas, velocidad del proyecto, pruebas

INGENIERIA DEL SOFTWARE GRUPO 301404_23

de aceptacin no superadas en la iteracin anterior y tareas no terminadas en la iteracin anterior. Todo el trabajo de la iteracin es expresado en tareas de programacin, cada una de ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas de programadores. Wake en [18] proporciona algunas guas tiles para realizar la planificacin de la entrega y de cada iteracin. Fase IV: Produccin La fase de produccin requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusin de nuevas caractersticas a la versin actual, debido a cambios durante esta fase. Es posible que se rebaje el tiempo que toma cada iteracin, de tres a una semana. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementacin (por ejemplo, durante la fase de mantenimiento). Fase V: Mantenimiento Mientras la primera versin se encuentra en produccin, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar despus de la puesta del sistema en produccin. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura. Fase VI: Muerte del Proyecto Es cuando el cliente no tiene ms historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentacin final del sistema y no se realizan ms cambios en la arquitectura. La muerte del proyecto tambin ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.

Los requerimientos no estn claros o cambian mucho: el cliente no tiene una idea clara de lo que el sistema debera hacer. Nuestro proyecto requera la reescritura de una plataforma existente, pero modificando la concepcin original de trabajo orientndola hacia las redes sociales y la web 2.0 Los riesgos son altos: si el cliente tiene una fecha tope o si el proyecto representa una novedad para el equipo de desarrollo.

INGENIERIA DEL SOFTWARE GRUPO 301404_23

La aplicacin a pesar de no ser innovadora en cuanto a sus herramientas, s era una novedad para los desarrolladores el uso de estndares del rea de educacin. As mismo, el nuevo enfoque que se le daba representaba una novedad para todo el equipo. (Realmente es y ser novedad para toda la comunidad).

se trabaja con un equipo de desarrollo pequeo: se recomienda equipos de entre 2 y 12 programadores. Somos 3. Se dispone de un equipo multidisciplinario: el equipo debe no solo ser de desarrolladores, sino tambin los gerentes y clientes, todos trabajando en conjunto. El equipo de soporte ofrecido constaba de gente con conocimientos en las reas de diseo, computacin y pedagoga. El cdigo debe poder ser probado: debe ser posible automatizar las pruebas unitarias y funcionales. Partamosde la idea de usar CakePHP como framework de desarrollo. Este nos ofreca una suite de pruebas automatizadas.

Qu ha salido bien y qu no? Para hacer la historia corta, enumerar algunos de los principales problemas que se han presentado. El trabajo multidisciplinario y en conjunto. Result que nuestro tutor es una persona muy ocupada y en varias ocasiones no asisti a las reuniones pautadas (lleg un punto en el que dimos por descontado su asistencia y dejamos de ir nosotros). As mismo, durante 6 meses las distintas personas que podran proveernos de la informacin necesaria para tomar decisiones de diseo importantes no pudieron asistir a las reuniones. Esto gener como resultado desmotivacin en los desarrolladores y estancamiento en la toma de decisiones. Dos aspectos importantes de esta, y cualquier otra, metodologa de desarrollo de software. Otro problema que caus estragos en nuestra planificacin fue relacionado al manejo de riesgos Riesgos altos Los primeros 3 meses fueron necesarios para implementar el primer mdulo de la aplicacin. Este mdulo es el encargado del presentacin de lecciones al estudiante. El estndar (SCORM) en el que se basaba ese mdulo es tan denso y complejo que fcilmente hubiese dado para un trabajo de grado completo.

INGENIERIA DEL SOFTWARE GRUPO 301404_23

Luego nos enteraramos que, gracias a la falta de comunicacin descrita antes, que los profesores que van a usar el sistema no tienen contenidos en el formato adecuado. La versin de SCORM que usan (1.2) no coincide con la que hemos desarrollado. (En una empresa hubiesen rodado cabezas, ac queran que la dedicaramos otros 3 meses a implementar dicha versin. Los dems puntos los hemos cumplido a cabalidad, el cdigo est en su mayora documentado y probado. Esto ltimo, las pruebas funcionales automatizadas, se han convertido en nuestra maya de seguridad invaluable. Aspectos Interesantes de XP La documentacin XP no hace previsiones para la documentacin, sin embargo es lgico que sea necesaria para que cualquier persona fuera del proyecto se ponga en contexto. Al final todo depender del proyecto y del equipo. Para este proyecto la documentacin es necesaria por una par de razones: al finalizar el proyecto sern otras personas quienes se encarguen del mantenimiento; y por otro lado, al ser un proyecto de grado es necesaria mucho ms la documentacin para convencer a los jurados. La propiedad compartida del cdigo Extreme programming aboga porque ninguna parte del cdigo sea propiedad exclusiva de alguno de los desarrolladores, esto con la intensin de disminuir la necesidad de documentacin hacia adentro del equipo de programadores. Adicionalmente esto permite evitar cuellos de botella que entorpecen el avance. Para lograrlo, XP exige dos cosas: mover a los desarrolladores de sus asignaciones a otras y desarrollar en parejas de modo que la toma de decisiones y el conocimiento sobre ellas no sea un secreto. Adicionalmente, cada da las reuniones permiten notificar estas decisiones al resto del grupo. En este apartado, puedo decir que en gran parte se ha logrado. El desarrollo en parejas puede ser perjudicial si no se mantiene la disciplina necesaria para concentrarse en el cdigo y no en la chchara TAREA 2 Describir cuatro (5) propuestas de proyectos de desarrollo de software que por sus caractersticas, sean adecuadas para desarrollarlas usando el modelo de proceso de software por Prototipos.

INGENIERIA DEL SOFTWARE GRUPO 301404_23

Justificar cada una de las propuestas en torno al porqu clasifica para el modelo por prototipos

Modelo de construccin de prototipos El paradigma de construccin de prototipos tiene tres pasos: 1. Escuchar al cliente. Recoleccin de requisitos. Se encuentran y definen los objetivos globales, se identifican los requisitos conocidos y las reas donde es obligatorio ms definicin. 2. Construir y revisar la maqueta (prototipo). 3. El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del software.

Modelo de construccin de prototipos Este modelo es til cuando:

El cliente no identifica los requisitos detallados. El responsable del desarrollo no est seguro de la eficiencia de un algoritmo, sistema operativo o de la interface hombre-mquina.

Su principal desventaja es que una vez que el cliente ha dado su aprobacin final al prototipo y cree que est a punto de recibir el proyecto final, se encuentra con que es necesario reescribir buena parte del prototipo para hacerlo funcional, porque lo ms seguro es que el desarrollador haya hecho compromisos de implementacin para hacer que el prototipo funcione rpidamente. Es posible que el prototipo sea muy lento, muy grande, no muy amigable en su uso, o incluso, que est escrito en un lenguaje de programacin inadecuado.

R/.WINDOWS 8 Hace parte de este sistema porque es un software dirigido a muchos usuarios que no tienen definidas sus necesidades, por lo tanto el analista entrega una versin

INGENIERIA DEL SOFTWARE GRUPO 301404_23

de prueba a algunos usuarios de los cuales obtiene realimentacin hasta obtener un producto estable y acorde a muchas de las necesidades. SISTEMAS DE INVENTARIO EN EMPRESAS

Estos diseos son califican dentro de este esquema ya que para obtener un buen resultado se deber trabajar mancomunadamente analista y usuario en un sistema de realimentacin y prueba para obtener el resultado exacto de un cliente. SISTEMA DE CONTROL DE VENTAS EN UN AUTOSERVICIO

Para poder disear un producto final de este tipo se necesita de gran interaccin entre el diseador y el usuario ya que un error podra provocar grandes prdidas por lo tanto la creacin de prototipos se encargara de dar al analista la obtencin de gran flujo de datos para realizar un trabajo final acorde y con la seguridad suficiente que necesita el usuario. DESARROLLO DE JUEGOS DE CONSOLA.

En el desarrollo de estos software la interaccin con el cliente es crucial y la comunicacin entre el analista y el usuario potencial quien le proporcionara una serie de datos para el desarrollo del sistema. DISEO DE AUTOCAD. ESTRUCTURAS ATRAVES DE SOFTWARE COMO

En este tipo de actividades se utiliza en todo su albor este sistema donde el usuario expresa su necesidad poco a poco y el analista y diseador le mostrara paso a paso como evoluciona el prototipo hasta el momento de obtener un producto con la aprobacin del usuario.

TAREA 3. El Procesador de textos como el Office Word, porque esta permite que cada vez los ingenieros desarrollen nuevas versiones ms completas, con mejores aplicaciones para el usuario. Antivirus, porque se crean nuevas versiones con ms caractersticas que permitan contrarrestar los virus que a diario crean. Una Base de datos, porque a medida que avanza el tiempo se van diseando nuevas aplicaciones que le dan ms facilidad al cliente y a sus requerimientos.

INGENIERIA DEL SOFTWARE GRUPO 301404_23

Requerimientos del sistema y las metodologas de desarrollo que soporta la herramienta CASE estudiada. ALLFusion Erwin Data Modeler REQUERIMIENTOS DEL SISTEMA REQUERIMIENTOS DE SOFTWARE Esta aplicacin requiere para su correcto funcionamiento las siguientes especificaciones MINIMAS de software: Plataformas: Windows 95, 98, 2000 SP3, NT 4.0, XP y 2003 server. Bases de datos: Advantage Ingres Enterprise Relational Database, Advantage CA-Clipper, DB2, dBASE, FoxPro, HiRDB, Informix, InterBase, Microsoft Access, Teradata, Microsoft SQL Server, ODBC 2.0, 3.0, Oracle, Paradox, Rdb, Red Brick Warehouse, SAS, SQL Anywhere, SQL Base y Sybase. REQUERIMIENTOS DE HARDWARE Esta aplicacin requiere para su correcto funcionamiento las siguientes especificaciones MINIMAS de hardware: 1 MB de espacio en disco. 500K de memoria RAM. Procesador Pentium. Monitor color 16 bits.

INGENIERIA DEL SOFTWARE GRUPO 301404_23

2. CONCLUSIONES

Gracias a la consulta de las metodologas agiles se pudo concluir que la metodologa mas eficaz e interesante para trabajar es la extreme programming (xp). Las metodologas agiles son metodologas que buscan facilitar el proceso de planeacin documentacin proceso e implementacin y adems de facilitar las tareas que conllevan el diseo de productos no garantizan satisfaccin y aceptacin del cliente o el beneficiario final.

Se llega a la conclusin que para crear productos es importante realizar un buen proceso y para ello es necesario optar por metologias de calidad como las metodolias agiles.

INGENIERIA DEL SOFTWARE GRUPO 301404_23

BIBLIOGRAFA E INFOGRAFA

http://eclases.tripod.com/id12.html http://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20Joskowicz.pdf http://www.esp.uem.es/jccortizo/xp.pdf http://www.esp.uem.es/jccortizo/xp.pdf

INGENIERIA DEL SOFTWARE GRUPO 301404_23

ANEXOS

Las producciones individuales estn incluidas en el trabajo final por lo tanto no fueron descritas.