InforLas metodologías ágiles tienen un origen reciente en el entorno de la ingeniería de software comparada con las metodologías pesadas. Su origen está ligado a los constantes

7/23/2019 InforLas metodologías ágiles tienen un origen reciente en el entorno de la ingeniería de software comparada con l…

http://slidepdf.com/reader/full/inforlas-metodologias-agiles-tienen-un-origen-reciente-en-el-entorno-de-la 1/24

DEDICATORIA

A mis padres por el esfuerzo que significó por su apoyo incondicional, a mi familia que

siempre me apoya y en especial a una tía muy especial. Finalmente a Dios que lo hizo

posible.

A mis padres, a mi hermano y a mis amigos por todo el apoyo y confianza que han

depositado en mí.

Aldo Vargas H.

UNIVERSIDAD NACIONAL DE

ALUMNO: VARGAS HUAYAHURIMA ADOCENTE: ING. CRISTOBAL LARA R

Ciclo:

VELNEO



UN!"#$DAD NA%&NA' D" (UAN%A!"'%A FA'%U')AD D" N*"N"#A D" "'"%)#&N%A+ $$)"A$-"A D" $$)"A$

AGRADECIMIENTOS

)odos los /0itos conseguidos hasta ahora y los que se obtendr1n en el futuro tendr1ncomo primer responsable a la Uni2ersidad qui/n nos proporcionó las herramientas para

desempe3arnos adecuadamente en nuestra profesión, para ella son los primeros

agradecimientos.

i familia quien me apoya en mi formación uni2ersitario en todos los sentidos. $in su

apoyo no habría sido posible el logro de una meta tan importante como lo es formarme

profesionalmente, a ellos un sincero agradecimiento por su esfuerzo y dedicación.

Finalmente a mi docente que me impulsa en toda mi formación acad/mica.

ALUMNO: VARGAS HUAYAHURIMA ALDO 2




OBJETIVOS

OBJETIVO GENERAL.

#ealizar una aplicación pr1ctica con la metodología 1gil 4 a tra2/s del desarrollo deun soft5are orientado a una uni2ersidad.

OBJETIVOS ESPECÌFICOS

• %onsultar acerca de la metodología 4 para el desarrollo del soft5are.

• Dise3ar en compa3ía del cliente las iteraciones.

• Desarrollar las tareas planteadas en cada una de las iteraciones.

• #ealizar la documentación del proyecto seg6n la guía 4.

• %oncluir sobre la con2eniencia de la utilización de la metodología 4 en este

proyecto bas1ndose en los resultados obtenidos.





JUSTIFICACIÓN

Al ser recientes las metodologías 1giles 7a3os 89:s;, no han sido estudiadas

suficientemente por la comunidad acad/mica, generando desconocimiento de sus

bondades. 'a "scuela rofesional de ngeniería de $istemas de la Uni2ersidad

nacional de (uanca2elica no ha sido a<ena a este fenómeno en el sentido que no ha

realizado muchos estudios sobre el tema y menos aplicaciones pr1cticas que

in2olucren el paradigma de las metodologías 1giles. or tal moti2o se plantea la

necesidad de e0plorar a mayor profundidad dicho campo a tra2/s de e<ercicios

pr1cticos debidamente documentados. "n este orden de ideas es necesario analizar

aspectos puntuales tales como las características de los clientes, detalles t/cnicos de

las soluciones y prestar especial atención a la naturaleza cambiante de los

requerimientos.





INTRODUCCIÓN

'as metodologías 1giles tienen un origen reciente en el entorno de la ingeniería de

soft5are comparada con las metodologías pesadas. $u origen est1 ligado a los

constantes incon2enientes que se presentaban en proyectos con algunas

características, en los cuales la utilización de las metodologías pesadas era moti2o de

fracaso.

"n la d/cada de los 89, surge e4treme rogramming, me<or conocida como 4, una

nue2a metodología catalogada entre las 1giles por sus aportes al manifiesto 1gil. $u

creador, =ent >ec? se con2irtió en el padre de la programación e0trema.

"n er6, la programación e0trema no se ha profundizado debido a su reciente

aparición. )ambi/n cabe se3alar la escasez de documentación referente a la misma y

de los traba<os realizados emple1ndola.

"l presente documento es la e0posición de una e0periencia pr1ctica en la cual se

empleó

"0treme rogramming. Debido al entorno acad/micas que rodearon al proyecto se

presentaron circunstancias especiales las cuales son detalladas en el cuerpo del

documento, por lo cual la metodología debió ser a<ustada.

"s importante aclarar que en ning6n momento se pretende hacer una e2aluación o

<uicio de la metodología empleada debido que no es posible tener conclusiones

generales a partir de un solo caso de estudio. $olo se hacen comentarios sobre la

e0periencia en particular y la forma como fue aplicada la metodología.





PROCESO DE DESARROLLO EN P

)odo proyecto de soft5are en 4 inicia con una o 2arias reuniones con el cliente,en las cuales se da claridad a la necesidad puntual del mismo a tra2/s de las

historias de usuario.

"stas tambi/n sir2en de base para crear una met1fora del sistema con el cual

todo el equipo de traba<o tendr1 una idea general de la aplicación a implementar.

%on base en las historias de usuario se crean las pruebas de aceptación las

cuales deben ser dise3adas antes de iniciar la codificación.

!. PLANEACIÓN

A continuación se describe la e0periencia obtenida en la realización del proyecto.

nicialmente se comenta sobre cada uno de los aspectos que 4 propone para

etapa de planeación. ara cada uno de los elementos se enuncia lo que la teoría

sobre 4 recomienda contrast1ndola con la e0periencia real en la realización del

proyecto. "ntre los elementos a discutir para esta parte se encuentran las

historias de usuario, el plan de entregas, lo relacionado con las iteraciones como

las modificaciones que se aplicaron a 4 para hacerla m1s adecuada para el

proyecto.

"n esta parte se encontrar1 la misma estructura de la sección de planeación delmarco teórico. ara cada apartado se 2er1 una serie de ideas que resumen la

teoría contrastada con la interpretación, aplicación y resultados en la pr1ctica.

!.!HISTORIAS DE USUARIO

Lo "#$ d%&$ Po "scritas por el usuario.

o )erminología del cliente.





o >a<o ni2el de detalle

o $ir2e de base para estimar los tiempos de implementación

E'($r%$)&%a

$i bien el cliente no fue quien escribió personalmente las historias deusuario, fue /l quien dise3ó su contenido y dirigió la redacción de las

mismas, debido a que no tenía los conocimientos necesarios en formato

para elaborarlas. A pesar de lo anterior, el propósito de las mismas no se

2io alterado de alguna forma, manteniendo no solamente la terminología

del cliente al punto en que este fuera autosuficiente en la comprensión de

su contenido, sino tambi/n su oficio como punto de partida en la

planificación del proyecto.

Desde el punto de 2ista del ni2el de detalle, se siguió la directi2a en el

sentido de no profundizar ni en descripciones ni en procesos,

manteni/ndolas de esta forma bre2e y clara. $in embargo se logró abstraer la información suficiente de ellas para realizar su implementación sin

requerir demasiadas aclaraciones por parte del cliente, siendo factor

fundamental para no ocasionar retrasos moti2ados por falta de claridad en

los requerimientos.

!.*VELOCIDAD DEL PRO+ECTO

Lo "#$ d%&$ Po N6mero de historias de usuario o tareas de programación

realizadas por iteración.

o $ir2e de ayuda para estimar la cantidad de historias de usuario aimplementar en una determinada iteración

E'($r%$)&%a"l n6mero de historias de usuario realizadas por iteración no fue una

buena medida de la 2elocidad del proyecto debido que no todas tenían el

mismo ni2el de dificultad y por tanto el mismo requerimiento de horas de

desarrollo. or esto se encontró que mientras en la segunda iteración se

traba<aron menos horas semanales en comparación con las dem1s.

!.,ENTREGAS PE-UEAS

Lo "#$ d%&$ Po "ntregas funcionales del proyecto frecuentemente

E'($r%$)&%a

Debido a que las iteraciones tenían unas duraciones largas, fue al

t/rmino de este plazo que se realizaron entregas, las cuales siempre





fueron funcionales, lo que quiere decir que al momento de la entrega

estaban en condiciones de ser puestas en funcionamiento en las

instalaciones del cliente. "sto representó un /0ito en el desarrollo del

proyecto ya que mantenía el inter/s del cliente en continuarlo debido a

que estaba 2iendo resultados en el corto plazo.

ara las entregas se fi<aron las siguientes fechas@

I/$ra&%0) F$&1a D#ra&%0)rimera 9 B C de diciembre C días

*. DISEO

A diferencia de las metodologías pesadas, el dise3o se realiza durante todo eltiempo de 2ida del proyecto, siendo constantemente re2isado y muy

probablemente modificado debido a cambios presentados durante el desarrollo.

"n esta parte se muestra una estructura similar a la anterior donde se obser2ar1

para cada uno de los elementos constituti2os de dicha etapa.

*.!SIMPLICIDAD

Lo "#$ d%&$ Po "l dise3o debe ser sencillo.

o $ólo se crear1n diagramas 6tiles.

E'($r%$)&%a

"n lo que respecta a la sencillez del dise3o, se acogió la recomendación

de 4, sólo in2irtiendo el tiempo e0clusi2amente necesario en elaboración

de diagramas y dise3o de interfaz gr1fica. A consecuencia de esta

decisión se debieron hacer algunos sacrificios. Al no haber hecho muchos

diagramas, la orientación a ob<etos no fue tan completa, sacrificando de

esta forma escalabilidad, 2ersatilidad y elegancia del dise3o, lo que fue

considerado un precio <usto a cambio del cumplimiento de los plazos.

Desde el punto de 2ista de las interfaces, tampoco se in2irtió mucho

tiempo en su dise3o, sin embargo se prestó mucha atención a ubicar loselementos tal y como el cliente las había solicitado y present1ndolos en

una forma elegante pero sencilla.

*.* MET2FORA DEL SISTEMA

Lo "#$ d%&$ Po lasmar la arquitectura del sistema en una Ehistoria.





o %on2ención de nombres para los ob<etos del sistema

E'($r%$)&%a

Debido que el programa es una aplicación sencilla y de f1cil comprensión

tanto para el desarrollador como para el cliente, no se requirió del empleo

de una met1fora, manteniendo todos los nombres en conte0to con unaaplicación.

"l poseer una met1fora que incluya una con2ención de nombres clara

facilita enormemente el logro del ob<eti2o de la propiedad colecti2a del

código ya que con solo 2er el nombre de un ob<eto o de un m/todo se

puede tener una claridad bastante amplia sobre la función que este

desempe3a y el lugar que ocupa dentro de todo el sistema.

*.,TARJETAS CRC

Lo "#$ d%&$ P

$u principal utilidad es de<ar el enfoque procedimental y entrar al modelo

orientado a ob<etos. )odo el desempe3o y participación en su

elaboración.

E'($r%$)&%a

Una de las principales piezas de dise3o empleada en el proyecto fueron

las tar<etas %#% que no sólo sir2ieron como columna 2ertebral de este,

sino que tambi/n fueron la base del modelo "ntidad #elación, elaborado

para modelar la base de datos. %ada )ar<eta %#% se con2irtió en unob<eto, sus responsabilidades en m/todos p6blicos y sus colaboradores

en llamados a otras clases."n el proceso de elaboración de las tar<etas %#% el miembro del equipo

estu2o presente manipul1ndolas, de modo tal que tanto el dise3o fue

producto de la participación del desarrollador, como el resultado del

mismo fue ampliamente asimilado, fa2oreciendo la propiedad colecti2a del

código.

,. CODIFICACION

"n metodologías pesadas, la codificación es un proceso al cual solo se llegadespu/s de largas fases de an1lisis y dise3o de las que queda una gran

cantidad de documentación a partir de la cual el proceso de codificación es

relati2amente sencillo. "n 4 el proceso es muy diferente. r1cticamente desde

un principio se inicia con la codificación, fa2oreciendo el logro del ob<eti2o de

estar haciendo entregas frecuentemente al cliente.





Algunos de los elementos m1s importantes en cuanto a la codificación son que,

el cliente siempre debe estar presente en esta, se debe traba<ar en pare<as y

debe haber una propiedad colecti2a del código.

,.!CLIENTE SIEMPRE PRESENTE

Lo "#$ d%&$ Po "l cliente debe estar disponible en el sitio de traba<o

o "l cliente es fundamental para solucionar dudas cara a cara

E'($r%$)&%a

'a idea de tener al cliente, un representante de /ste o a un usuario no es

f1cil de asimilar si se consideran los costos que esto representa. "n el

caso de este proyecto, el cliente no podía desplazarse a ninguno de los

lugares de traba<o del desarrollador dado que debía estar al de su cargo.

,.*CODIFICAR PRIMERO LA PRUEBA Lo "#$ d%&$ P

o "scribir primero la prueba que el código.

o "l tiempo de escribir una prueba y luego el código del programa

para dicha prueba es menor que solo escribir el código.o "scribir pruebas primero permite identificar los casos especiales

que deber1 pasar el código.

E'($r%$)&%a

)odos los elementos presentan obst1culos en el desarrollo de las

pruebas, y plantearon una inquietud importante sobre el alcance del

concepto Ecodificar primero las pruebas. G$e trata de codificar $"#"una prueba antes que el código, o solo aquellas clases encargadas de

realizar la lógica del negocioH Debido que 4 no tiene una respuesta clara

a esta inquietud el grupo de desarrollo optó por probar solo aquellas

clases que e<ecutan la lógica del negocio, que en definiti2a son las m1s

importantes y de las cuales se debe tener garantía de estar muy bien

construidas.

,.,TODA LA PRODUCCIÓN DE CÓDIGO DEBE SER HECHA ENPAREJAS

Lo "#$ d%&$ Po )oda la producción de código debe ser hecha en pare<as sentadas

frente a un 6nico computador.o Al traba<ar en pare<as se tiene un dise3o de me<or calidad y un

código m1s organizado.o Al traba<ar en pare<as se solucionan los problemas m1s f1cilmente.

ALUMNO: VARGAS HUAYAHURIMA ALDO10




E'($r%$)&%a

"l no contar con una permanente comunicación complico seriamente el

cumplimiento del ob<eti2o de programar en pare<as. or otro lado al solo haber

una pare<a de programadores se hacía completamente imposible cumplir con el

ob<eti2o de tener 2arias pare<as de programadores traba<ando uniformemente.

3. PRUEBAS

4 enfatiza en la realización de un sin n6mero de pruebas a lo largo del

proyecto, con el fin de asegurar en todo momento la realización de lo planteado

en el dise3o. "n este proceso no sólo participa el equipo de desarrollo, tambi/n

es importante los aportes del cliente, sobre todo en las pruebas de aceptación.

"sta parte se di2ide en partes que corresponden a las pruebas unitarias, de

aceptación y qu/ hacer cuando se encuentra un error.

3.! PRUEBAS UNITARIAS

Lo "#$ d%&$ Po 'as pruebas deben ser escritas antes que los m/todos.

o $u implementación y e<ecución deben consumir el menor tiempo

posible.

E'($r%$)&%a

'a creación de pruebas fue una e0periencia nue2a para el desarrollador

al ser una de las reglas de la metodología 4 que no se había llegado autilizar en proyectos anteriores. Debido a esto, la realización de pruebas al

principio del proyecto fue traum1tica y demandó m1s tiempo de lo

planeado, lo cual no fue con2eniente ya que la metodología intenta

disminuir los cuellos de botella, no aumentarlos.

$eg6n 4, se deben crear todas las pruebas de una clase antes de

comenzar a desarrollar los m/todos. "n la e0periencia fue con2eniente

realizar las pruebas indi2idualmente, debido a que se producían errores al

e<ecutar todas las pruebas en un solo llamado. $e descubrió que este

incon2eniente estaba relacionado con la base de datos y no con los

m/todos, lo que al principio del proyecto aplicó dificultad al e2aluar si un

m/todo había pasado o no la prueba. Una 2ez que se descubrió este error

se empezó a e<ecutar las pruebas por grupos en lugar de e<ecutarlas

todas de una 2ez. De esta forma no había problemas de comunicación

con la >D y se garantizaba que si una prueba fallaba era solo por errores

de lógica.





3.* Pr#$4as d$ a&$(/a&%0)

Lo "#$ d%&$ P.o $e deben dise3ar las pruebas de aceptación con base en las

historias de usuario

E'($r%$)&%a.

)res elementos permitieron al grupo de desarrollo dise3ar las pruebas de

aceptación. "n primer lugar el tipo de sistema implementado era

suficientemente sencillo y conocido por el desarrollador, principalmente

porque el desarrollador tiene contacto permanente con el cliente. "n

segundo lugar las reuniones de las cuales se obtu2ieron las historias de

usuario fueron plasmadas con lo cual fue posible la reconstrucción de las

pruebas de aceptación por parte del desarrollador sin toda la inter2ención

del cliente. "n tercer lugar el cliente aceptó el delegar esta función de

dise3o de las pruebas debido que su disponibilidad de tiempo, como ya es

mencionada en otros apartados del documento, se lo impidió.

3.,C#a)do s$ $)&#$)/ra #) $rror

Lo "#$ d%&$ Po Al encontrar un error debe escribirse primero la prueba antes que

corregirlo.

E'($r%$)&%a%omo se mencionó antes, no se crearon unidades de prueba para los

errores de las interfaces gr1ficas, estos tipos de incon2enientes fueron

solucionados mediante pruebas manuales, es decir, sin la ayuda de la

herramienta IUnit debido que el A no soporta este tipo de pruebas.

"stas pruebas manuales consistían en ca<as negras donde se 2erificaba

la solución del problema mediante la e<ecución del programa.





CONCLUSIONES'a e0periencia del desarrollo del proyecto resultó satisfactoria. 'a elección y aplicación

de dicha metodología dadas las características del problema arro<ó resultados positi2os

en t/rminos de satisfacción del cliente, cumplimiento de los plazos y buen ambiente de

traba<o. $e encontró que la metodología se a<ustó muy bien no solo al tipo de cliente y

a las características del problema, tambi/n resultó adecuada para el entorno de traba<o

y las características del desarrollador.





ANEOS





HISTORIAS DE USUARIO

Tabla 1.1 Historia de Usuario Registro docentes.

Historia ! Us"ario

N#$!ro: 1 Us"ario: Ad!"!#$%&d'%

No$br! %istoria: R()!#$%' d( *'# d&$'# d( d'+("$(#,

&rioria !' '!(ocio: A*$& Ri!s(o !' !sarrollo: A*$&

&"'tos !sti$aos: 1 It!raci)' asi('aa: 1

&ro(ra$aor r!s*o'sabl!: A*d' V&%)&#

D!scri*ci)': -(%!$!% !"#(%$&% *'# d&$'# d( d'+("$(# (" *& &.*!+&+!/",

Obs!r+acio'!s: L& !"'%&+!/" d( "'%( (# +'' %&#)' "!+' d(

&$("$!+&+!/" d(* .(%#'"&* d'+("$(,

Tabla 1., Historia de Usuario búsqueda del docente.

Historia ! Us"ario

N#$!ro: , Us"ario: Ad!"!#$%&d'%

No$br! %istoria: #(d& d( *'# d&$'# .(%#'"&*(# d( d'+("$(#,

&rioria !' '!(ocio: M(d!& Ri!s(o !' !sarrollo: M(d!&







D!scri*ci)': -(%!$!% %(&*!&% *& #(d& d( *'# d&$'# d( d'+("$(# (" *&

&.*!+&+!/",

Obs!r+acio'!s:

Tabla 1.3 Historia de Usuario registro de alumnos.

Historia ! Us"ario

N#$!ro: - Us"ario: Ad!"!#$%&d'%

No$br! %istoria: R()!#$%' d( d&$'# d( &*"'#,


&"'tos !sti$aos: 0,5 It!raci)' asi('aa: 1


D!scri*ci)': -'d% &$("$!+&%#( (" (* #!#$(& (d!&"$( (* +/d!)' d(

&%%&# d( +&%"($ ' DNI %()!#$%&"d' *& '%& d( ("$%&d& ; #&*!d&,

Obs!r+acio'!s: S'*' .'d% **(<&% +%#'# (* (#$d!&"$( .%(<!'

&*&+("&!("$' (" *& &#( d( d&$'# d( *& &.*!+&+!/",

Tabla 1.4 Historia de Usuario búsqueda de alumnos.

Historia ! Us"ario

N#$!ro: Us"ario: Ad!"!#$%&d'%,

No$br! %istoria: #(d& d( *'# d&$'# .(%#'"&*(# d( &*"'#,




D!scri*ci)': -(%!$!% %(&*!&% *& #(d& d( *'# d&$'# d( &*"'# (" *&&.*!+&+!/"Obs!r+acio'!s:

Tabla 1.5 Historia de Usuario registro de cursos

Historia ! Us"ario

N#$!ro: / Us"ario: Ad!"!#$%&d'%

No$br! %istoria: R()!#$%' d( d&$'# d( *'# +%#'#,




D!scri*ci)': #( %()!#$%& *'# +%#'# d(.("d( &* .*&" d( (#$d!'#,

Obs!r+acio'!s:

Tabla 1.6 Historia de Usuario búsqueda de cursos





Historia ! Us"ario

N#$!ro: 0 Us"ario: Ad!"!#$%&d'%,

No$br! %istoria: #(d& d( +%#'#,


&"'tos !sti$aos: 0,4 It!raci)' asi('aa: 1&ro(ra$aor r!s*o'sabl!: A*d' V&%)&#

D!scri*ci)': -(%!$!% %(&*!&% *& #(d& d( *'# d&$'# d( *'# +%#'# (" *&

&.*!+&+!/"

Obs!r+acio'!s:

Tabla 1.7 Historia de Usuario registro de ciclos.

Historia ! Us"ario

N#$!ro: Us"ario: Ad!"!#$%&d'%,

No$br! %istoria: R()!#$%' d( +!+*'#,




D!scri*ci)': #( %()!#$%& *'# +!+*'# d( I &#$& (* =,

Obs!r+acio'!s:

Tabla 1.8 Historia de Usuario búsqueda de ciclos.

Historia ! Us"ario

N#$!ro: 2 Us"ario: Ad!"!#$%&d'%,

No$br! %istoria: #(d& d( +!+*'#




D!scri*ci)': -(%!$!% %(&*!&% *& #(d& d( *'# +!+*'# (" *& &.*!+&+!/"

Obs!r+acio'!s: L'# d&$'# +'%%(#.'"d!("$(# & *'# +!+*'# #'*' #(%" d( I & =,

It!racio'!s





U"& <( !d("$!+&d&# *&# !#$'%!&# d( #&%!'# d(* #!#$(& ; (#$!&d' (* (#(%'d(d!+&d' & *& %(&*!&+!/" d( +&d& "& d( (#$&# #( .%'+(d( & *& .*&"!+&+!/" d( *&($&.& d( !.*(("$&+!/" d(* .%';(+$', D( &+(%d' & *' ("+!'"&d' &"$(%!'%("$(#( d(+!d!/ %(&*!&% d!+& .*&"!+&+!/" (" "& #'*& !$(%&+!/":Tar!as

Tabla 1.9 Tarea Registro de los datos de docentes

Tar!a

N#$!ro Tar!a: 1 N#$!ro Historia: 1

No$br! Tar!a: R()!#$%' d( *'# d&$'# d( d'+("$(# ; (#$d!&"$(#,

Ti*o ! Tar!a: D(#&%%'**' &"'tos Esti$aos: 0,4

3!c%a I'icio: 01>12>15 3!c%a 3i': 02 >12> 15

&ro(ra$aor R!s*o'sabl!: A*d' V&%)&#D!scri*ci)': S( d!#(?&% *& !"$(%& .&%& !"#(%$&% *'# d&$'# d( d'+("$(#

d'"d( #( (#$%(" $'d'# *'# d&$'# ( #( &*&+("&" (" *& &.*!+&+!/",

Tabla 1.10 Tarea Registro de los datos de docentes

Tar!a


No$br! Tar!a: R()!#$%' d( *'# d&$'# d( d'+("$(#,


3!c%a I'icio: 03>12>15 3!c%a 3i': 04 >12> 15

&ro(ra$aor R!s*o'sabl!: A*d' V&%)&#D!scri*ci)': S( .%')%&&% (* !"#(%$&% d( *'# d&$'# d( d'+("$(# ; #(

&*&+("&% (" *& &.*!+&+!/",

Tabla 1.11 Tarea búsqueda de docente

Tar!a


No$br! Tar!a: #(d& d( *'# d&$'# d( d'+("$(#,


3!c%a I'icio: 05>12>15 3!c%a 3i': 06 >12> 15

&ro(ra$aor R!s*o'sabl!: A*d' V&%)&#D!scri*ci)': S( .%')%&&% *& #(d& d( d&$'# d( d'+("$( &*&+("&d&

(" *& &.*!+&+!/",

Tabla 1.12 Tarea registro de alumnos

Tar!a


No$br! Tar!a: R()!#$%' d( d&$'# d( &*"'#,






3!c%a I'icio: 07>12>15 3!c%a 3i': 08 >12> 15

&ro(ra$aor R!s*o'sabl!: A*d' V&%)&#

D!scri*ci)': S( d!#(?&% *& !"$(%& .&%& !"#(%$&% *'# d&$'# d( &*"'#

d'"d( #( (#$%(" $'d'# *'# d&$'# ( #( &*&+("&" (" *& &.*!+&+!/",

Tabla 1.13 Tarea registro de alumnos

Tar!a


No$br! Tar!a: R()!#$%' d( d&$'# d( &*"'#,


3!c%a I'icio: 09>12>15 3!c%a 3i': 10 >12> 15&ro(ra$aor R!s*o'sabl!: A*d' V&%)&#

D!scri*ci)': S( .%')%&&% (* !"#(%$&% d( *'# d&$'# d( &*"'# ; #(

&*&+("&% (" *& &.*!+&+!/",

Tabla 1.14 Tarea búsqueda de alumnos

Tar!a


No$br! Tar!a: #(d& d( *'# d&$'# d( &*"'#,


3!c%a I'icio: 11>12>15 3!c%a 3i': 12 >12> 15&ro(ra$aor R!s*o'sabl!: A*d' V&%)&#D!scri*ci)': S( .%')%&&% *& #(d& d( d&$'# d( &*"'# &*&+("&d&

(" *& &.*!+&+!/",

Tabla 1.15 Tarea Registro de cursos

Tar!a


No$br! Tar!a: R()!#$%' d( +%#'#,

Ti*o ! Tar!a: D(#&%%'**', &"'tos Esti$aos: 0,1

3!c%a I'icio: 13>10>11 3!c%a 3i': 14 >10> 11


D!scri*ci)': S( d!#(?&% *& !"$(%& .&%& !"#(%$&% *'# d&$'# d( *'# +%#'#

d'"d( #( (#$%(" $'d'# *'# d&$'# ( #( &*&+("&" (" *& &.*!+&+!/",

Tabla 1.16 Tarea Registro de cursos





Tar!a


No$br! Tar!a: R()!#$%' d( +%#'#,

Ti*o ! Tar!a: D(#&%%'**', &"'tos Esti$aos: 0,1

3!c%a I'icio: 15>12>15 3!c%a 3i': 16>12> 15

&ro(ra$aor R!s*o'sabl!: A*d' V&%)&#D!scri*ci)': S( .%')%&&% (* !"#(%$&% d( *'# d&$'# d( +%#'# ; #(

&*&+("&% (" *& &.*!+&+!/",

Tabla 1.17 Tarea búsqueda de cursos

Tar!a


No$br! Tar!a: #(d& d( *'# d&$'# d( +%#'#,


3!c%a I'icio: 17>12>15 3!c%a 3i': 18 >12> 15


D!scri*ci)': S( .%')%&&% *& #(d& d( d&$'# d( *'# +%#'# &*&+("&d&(" *& &.*!+&+!/",

Tabla 1.18 Tarea Registro de ciclos

Tar!a


No$br! Tar!a: R()!#$%' d( +!+*'#,


3!c%a I'icio: 19>12>15 3!c%a 3i': 20 >12> 15


D!scri*ci)': S( d!#(?&% *& !"$(%& .&%& !"#(%$&% *'# d&$'# d( *'# +!+*'#d'"d( #( (#$%(" $'d'# *'# d&$'# ( #( &*&+("&" (" *& &.*!+&+!/",

Tabla 1.19 Tarea Registro de ciclos

Tar!a


No$br! Tar!a: R()!#$%' d( +!+*'#,


3!c%a I'icio: 21>12>15 3!c%a 3i': 22>12> 15

&ro(ra$aor R!s*o'sabl!: A*d' V&%)&#D!scri*ci)': S( .%')%&&% (* !"#(%$&% d( *'# d&$'# d( +%#'# ; #(

&*&+("&% (" *& &.*!+&+!/",

Tabla 1.20 Tarea búsqueda de ciclos

Tar!a


No$br! Tar!a: #(d& d( *'# d&$'# d( +!+*'#,






3!c%a I'icio: 23>12>15 3!c%a 3i': 24 >12> 15

&ro(ra$aor R!s*o'sabl!: A*d' V&%)&#D!scri*ci)': S( .%')%&&% *& #(d& d( d&$'# d( *'# +!+*'# &*&+("&d&

(" *& &.*!+&+!/",

&la' ! D"raci)' ! las It!racio'!s

C'' .&%$( d(* +!+*' d( <!d& d( " .%';(+$' $!*!&"d' *& ($'d'*')@& =- #( +%(& (*.*&" d( d%&+!/" d( *&# !$(%&+!'"(# #()" *'# (!.'# d( d(#&%%'**' +'" ( #(+("$( (" (#$( +&#' #( &+( .&%& (* "!+' (!.' d( d(#&%%'**' ( #( $!("(, E#$(.*&" #( ("+&%)& d( '#$%&% *&# !#$'%!&# d( #&%!'# ( #(%" !.*(("$&d&# ("+&d& "& d( *&# !$(%&+!'"(# &#@ +'' *& d%&+!/" (#$!&d& d( +&d& "& ; (* '%d("

(" ( #( !.*(("$&%",

MODELO RELACIONAL

MODELO ENTIDAD5RELACIÓN FINAL

Do&$)/$sdDocente

NumAlumnos

INTERFACES DE LA APLICACIÓN

I)/$r6a7 d$ %)%&%o


C#rsosid%ursos

NumAlumnos

Al#8)osdAlumno

nombre

nombre%urso

nombreDocente

ciclo

condicion

descripcion

foto

C%&losd%iclo

Nombre




Ma)/$)%8%$)/o d$ Do&$)/$s

B9s"#$da d$ do&$)/$s

Ma)/$)%8%$)/o d$ Al#8)os





B9s"#$da d$ Al#8)os

Ma)/$)%8%$)/o d$ C#rsos

B9s"#$da d$ do&$)/$s






Documents

InforLas metodologías ágiles tienen un origen reciente en el entorno de la ingeniería de software comparada con las metodologías pesadas. Su origen está ligado a los constantes