CARRERA: SISTEMAS DE AUTOMATIZACIN

PROYECTO INTEGRADOR

Sistema gestin de cursos con sitio web informativa para en SITIO arquitectos

AUTOR:SERGIO FERNANDO MAITA CHAMBA

DOCENTE:ING. LORENA PUCHA

Loja Ecuador, Enero del 2016

INDICE GENERALContenidoCARTULA (Logo Carrera-Instituto, Tema, Ciclo, Estudiante(s), Docente, Fecha Entrega)TEMAINTRODUCCINNDICE DE CONTENIDOSNDICE DE FIGURASNDICE DE TABLASANTECEDENTESPROBLEMATIZACINJUSTIFICACINOBJETIVOS1.1 GENERAL1.2 ESPECFICOSMARCO TERICO METODOLOGA1.1 Modelo de Ingeniera de Software //descripcin terica de cada fasePROPUESTA DE ACCIN O DESARROLLO1.1 INGENIERA DE SOFTWARE1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 13.1. 1.1.1 Descripcin de la Empresa //donde desarrollar su proyecto1.1.2 mbitoa) Funcionesb) Rendimientoc) Restriccionesd) Interfacese) Fiabilidad1.1.3 Modelo de Ingeniera de Software //desglose de las actividades a realizar en cada fase enfocadas al desarrollo de su proyecto.1.1.4 Planificacin o Cronograma1.1.5 Recursos1.1.6 Identificacin de Riesgos1.1.7 Lineamientos considerados para el control de calidadRESPONSABLES Y PARTICIPANTESCRONOGRAMAPRESUPUESTOCONCLUSIONESRECOMENDACIONESBIBLIOGRAFAANEXOS

1. TEMASistema gestin de cursos con sitio web informativa para para en SITIO arquitectos

12. METODOLOGA.12.1 Modelo de ingeniera de software Metodologa gil Existen numerosas propuestas de metodologa para desarrollar software. Tradicionalmente estas metodologas se centran en el control del proceso, estableciendo rigurosamente las actividades, herramientas y notaciones al respecto, dado estas reglas estas metodologas se caracterizan por ser rgidos y dirigidos por la documentacin que se genera en cada una de las actividades desarrolladas. Este enfoque no resulta ser el ms adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. En este escenario, las metodologas giles emergen como una posible respuesta para llenar ese vaco metodolgico.

Metodologa XP (Programacin Extrema)

Es una metodologa gil, centrada a potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo con un equipo de proyecto pequeo, preocupndose por el aprendizaje de los desarrolladores, y proporcionando un buen clima de trabajo. La Metodologa XP se basa en la realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre 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.

Caractersticas de la metodologa XP Se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad. Se aplica de manera dinmica durante el ciclo de vida del software. Es capaz de adaptarse a los cambios de requisitos. Los individuos e interacciones son ms importantes que los procesos y herramientas. Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.La gente es el principal factor de xito de un proyecto software. Es ms importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automticamente. Es mejor crear el equipo y que ste configure su propio entorno de desarrollo en base a sus necesidades. Software que funcione es ms importante que documentacin exhaustiva. Desarrollar software que funciona ms que conseguir una buena documentacin.

Valores de la metodologa XPLos 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: SimplicidadLa 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 hace 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 auto-documentado. 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. 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. ComunicacinLa 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 cmo 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 programador esa 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 valentaMuchas 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 todo lo dems 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 ms fcilmente. Otro ejemplo de valenta es saber cundo 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.

Pasos de la metodologa XPLos Pasos fundamentales inmersos en las fases del mtodo son: Desarrollo iterativo e incremental: Pequeas mejoras, unas tras otras. Pruebas unitarias continuas: Son frecuentemente repetidas y automatizadas, incluyendo pruebas de regresin. Se aconseja escribir el cdigo de la prueba antes de la codificacin. Programacin en parejas: Se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que 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 compartido: 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 del 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.

Fases de la metodologa XP

Fase I - Planificacin del proyecto Historias de usuario: El primer paso de cualquier proyecto que siga la metodologa XP es definir las historias de usuario con el cliente. Las historias de usuario tienen la misma finalidad que los casos de uso pero con algunas diferencias: Constan de 3 4 lneas escritas por el cliente en un lenguaje no tcnico sin hacer mucho hincapi en los detalles; no se debe hablar ni de posibles algoritmos para su implementacin ni de diseos de base de datos adecuados, etc. Son usadas para estimar tiempos de desarrollo de la parte de la aplicacin que describen. Tambin se utilizan en la fase de pruebas, para verificar si el programa cumple con lo que especifica la historia de usuario. Cuando llega la hora de implementar una historia de usuario, el cliente y los desarrolladores se renen para concretar y detallar lo que tiene que hacer dicha historia. El tiempo de desarrollo ideal para una historia de usuario es entre 1 y 3 semanas. Release Planning: Despus de tener ya definidas las historias de usuario es necesario crear un plan de publicaciones, en ingls "Release plan", donde se indiquen las historias de usuario que se crearn para cada versin del programa y las fechas en las que se publicarn estas versiones. Un "Release plan" es una planificacin donde los desarrolladores y clientes establecen los tiempos de implementacin ideales de las historias de usuario, la prioridad con la que sern implementadas y las historias que sern implementadas en cada versin del programa. Despus de un "Release plan" tienen que estar claros estos cuatro factores: los objetivos que se deben cumplir (que son principalmente las historias que se deben desarrollar en cada versin), el tiempo que tardarn en desarrollarse y publicarse las versiones del programa, el nmero de personas que trabajarn en el desarrollo y cmo se evaluar la calidad del trabajo realizado. (*Release plan: Planificacin de publicaciones). Iteraciones: Todo proyecto que siga la metodologa X.P. se ha de dividir en iteraciones de aproximadamente 3 semanas de duracin. Al comienzo de cada iteracin los clientes deben seleccionar las historias de usuario definidas en el "Release planning" que sern implementadas. Tambin se seleccionan las historias de usuario que no pasaron el test de aceptacin que se realiz al terminar la iteracin anterior. Estas historias de usuario son divididas en tareas de entre 1 y 3 das de duracin que se asignarn a los programadores. La Velocidad del Proyecto: Es una medida que representa la rapidez con la que se desarrolla el proyecto; estimarla es muy sencillo, basta con contar el nmero de historias de usuario que se pueden implementar en una iteracin; de esta forma, se sabr el cupo de historias que se pueden desarrollar en las distintas iteraciones. Usando la velocidad del proyecto controlaremos que todas las tareas se puedan desarrollar en el tiempo del que dispone la iteracin. Es conveniente reevaluar esta medida cada 3 4 iteraciones y si se aprecia que no es adecuada hay que negociar con el cliente un nuevo "Release Plan". Programacin en Parejas: La metodologa X.P. aconseja la programacin en parejas pues incrementa la productividad y la calidad del software desarrollado. El trabajo en pareja involucra a dos programadores trabajando en el mismo equipo; mientras uno codifica haciendo hincapi en la calidad de la funcin o mtodo que est implementando, el otro analiza si ese mtodo o funcin es adecuado y est bien diseado. De esta forma se consigue un cdigo y diseo con gran calidad. Reuniones Diarias: Es necesario que los desarrolladores se renan diariamente y expongan sus problemas, soluciones e ideas de forma conjunta. Las reuniones tienen que ser fluidas y todo el mundo tiene que tener voz y voto.

Fase II - Diseo Diseos Simples: La metodologa XP sugiere que hay que conseguir diseos simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un diseo fcilmente entendible e implemntable que a la larga costar menos tiempo y esfuerzo desarrollar.

Glosarios de Trminos: Usar glosarios de trminos y una correcta especificacin de los nombres de mtodos y clases ayudar a comprender el diseo y facilitar sus posteriores ampliaciones y la reutilizacin del cdigo. Riesgos: Si surgen problemas potenciales durante el diseo, XP sugiere utilizar una pareja de desarrolladores para que investiguen y reduzcan al mximo el riesgo que supone ese problema. Funcionabilidad extra: Nunca se debe aadir funcionalidad extra al programa aunque se piense que en un futuro ser utilizada. Slo el 10% de la misma es utilizada, lo que implica que el desarrollo de funcionalidad extra es un desperdicio de tiempo y recursos. Refactorizar: Refactorizar es mejorar y modificar la estructura y codificacin de cdigos ya creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos cdigos para procurar optimizar su funcionamiento. Es muy comn rehusar cdigos ya creados que contienen funcionalidades que no sern usadas y diseos obsoletos.

Fase III - CodificacinComo ya se dijo en la introduccin, el cliente es una parte ms del equipo de desarrollo; su presencia es indispensable en las distintas fases de XP. A la hora de codificar una historia de usuario su presencia es an ms necesaria. No olvidemos que los clientes son los que crean las historias de usuario y negocian los tiempos en los que sern implementadas. Antes del desarrollo de cada historia de usuario el cliente debe especificar detalladamente lo que sta har y tambin tendr que estar presente cuando se realicen los test que verifiquen que la historia implementada cumple la funcionalidad especificada. La codificacin debe hacerse ateniendo a estndares de codificacin ya creados. Programar bajo estndares mantiene el cdigo consistente y facilita su comprensin y escalabilidad. Fase IV - PruebasUno de los pilares de la metodologa XP es el uso de test para comprobar el funcionamiento de los cdigos que vayamos implementando. El uso de los test en XP es el siguiente: Se deben crear las aplicaciones que realizarn los test con un entorno de desarrollo especfico para test. Hay que someter a tests las distintas clases del sistema omitiendo los mtodos ms triviales. Se deben crear los test que pasarn los cdigos antes de implementarlos; en el apartado anterior se explic la importancia de crear antes los test que el cdigo. Un punto importante es crear test que no tengan ninguna dependencia del cdigo que en un futuro evaluar. Como se coment anteriormente los distintos test se deben subir al repositorio de cdigo acompaados del cdigo que verifican. Test de aceptacin. Los test mencionados anteriormente sirven para evaluar las distintas tareas en las que ha sido dividida una historia de usuario. Al ser las distintas funcionalidades de nuestra aplicacin no demasiado extensas, no se harn test que analicen partes de las mismas, sino que las pruebas se realizarn para las funcionalidades generales que debe cumplir el programa especificado en la descripcin de requisitos.13. PROPUESTA DE ACCIN DE DESARROLLO13.1 Descripcin de la Empresa.Es un equipo de trabajo que investiga y experimenta arquitectura optimizando recursos para valorizar el hbitat del ser humano. Se encarga de Diseo Arquitectnico / Urbano, Construccin / Fiscalizacin, Planificacin / Factibilidad de proyectos.

13.1.1 mbitoFunciones: Modulo Pgina InformativaReferenciaFuncinCategora

R1Los usuarios no registrados podrn acceder a informacin bsica, artculos, repositorios, contactos, galera de imgenes, redes sociales.Evidente

R2El portal web permitir mostrara artculos Evidente

R3El portal web permitir Iniciar Sesin y acceder a la zona restringida del portal.Evidente

R4El portal web permitir acceder a la zona de registroEvidente

R5El portal web permitir acceder a la zona de galera de imgenesEvidente

Modulo AdministradorReferenciaFuncinCategora

R6El administrador podr obtener informacin de las cuentas, as como sus accesosEvidente

R7El administrador podr obtener modificar el tipo de perfil de un usuarioEvidente

R8El administrador podr gestionar los roles de cada tipo como su accesoEvidente

R9El administrador podr obtener informe general de los cursos creadosEvidente

R10El administrador podr crear modificar eliminar categoras para los cursosEvidente

Modulo EstudianteReferenciaFuncinCategora

R11El Estudiante podr modificar su informacin, as como darse de bajaEvidente

R12El Estudiante podr acceder a la zona restringida de la lista de categoras de cursos.Evidente

R13El Estudiante reservar un cupo de acuerdo al curso seleccionado, o darse de baja.Evidente

R14El estudiante inscrito al curso, podr acceder a material de apoyo al iniciar al curso hasta que este finalice.Evidente

Modulo TutorReferenciaFuncinCategora

R15El tutor podr acceder a la zona restringida del portal.Evidente

R16El tutor podr crear cursos, registrarlos a una categora, as mismo como eliminarlo.Evidente

R17El tutor podr obtener un informe del estado actual de su curso como, Estudiantes inscritos o reservados por cupo.Evidente

Rendimiento: Todos el cdigo, de cualquier formato relacionado a texto ya sea .css .php .js estarn comprimidas y reducidas sus lneas de cdigo as mismo como su peso, para una carga ms limpia. Optimizacin Imgenes JPG PNG peso y pixelado por programa. Mdulo Registro: 2seg por accion Mdulo Matriculacin: 2seg por accion Mdulo Cuenta: 2seg por accion Mdulo Cursos: 2seg por accion Mdulo Artculos: 2seg por accin

Restricciones:Para dicha aplicacin, durante el tiempo de desarrollo de contara con un hosting de pago Banahosting: Disco ilimitado Ancho de banda ilimitado para una buena cantidad de usuarios en lnea soportados al mismo tiempo Discos SSD. CPU 2.4Ghz Capanel PHP 5.3 . 5.6 Base de datos ilimitadoDentro de aplicaciones y frameworks Usadas estn las siguientes.Potoshop CS5CodeigniterBootstrap

Interfaces:Interfaz Informativa 1 Programado desde 0

Interfaz Informativa 2 Programado desde 0

Interfaz Informativa 3 Programado desde 0

Interfaz Login Programado desde 0

Interfaz Panel Administrador Inicio Programado desde 0

Interfaz Panel Administrador Registro Programado desde 0

Interfaz Panel Administrador Cuenta Programado desde 0

a) Fiabilidad: Seguridad acceso a inicio de sesin encriptacin contraseas MD5. Respaldos diarios automticos en la nube, archivos de la aplicacin y base de datos.

14. RIESGOSRiesgosCategoraProbabilidadImpactoRSGR

El cliente cambia los requerimientos constantementePlanificacin Temporal70%Critico

Falta de colaboracin del usuario dentro de los horarios preestablecidosPlanificacin Temporal30%Critico

Rendimiento inadecuado hostingRendimiento30%Critico

Eleccin inadecuada de herramientas desarrollar el softwarePlanificacin Temporal30%Marginal

Presupuest insuficiente para gastos empleado en el desarrollo del sistemaPlanificacin Temporal30%Marginal

Cronograma de actividades mal preestablecidoPlanificacin Temporal60%Critico

Identificacin requerimientos mal gestionadaPlanificacin Temporal50%Catastrfico

Perdida de informacin por falta de respaldoSoporte30%Catastrfico

Final del proyecto el usuario pida cambios drsticosPlanificacin Temporal40%Catastrfico

La informacin brindada por el usuario no es la adecuadaPlanificacin Temporal40%Critico

base de datos mal estructuradaSoporte20%Catastrfico

RIESGOSESTRATEGIAS DE REDUCCIONESTRATEGIAS DE SUPERVICIONESTRATEGIAS DE GESTIONRESPONSABILIDD

El cliente cambia los requerimientos constantemente

Falta de colaboracin del usuario dentro de los horarios preestablecidos

Rendimiento inadecuado hosting

Eleccin inadecuada de herramientas desarrollar el software

Presupuest insuficiente para gastos empleado en el desarrollo del sistema

Cronograma de actividades mal preestablecido

Identificacin requerimientos mal gestionada

Perdida de informacin por falta de respaldo

Final del proyecto el usuario pida cambios drsticos

La informacin brindada por el usuario no es la adecuada

base de datos mal estructurada

BIBLIOGRAFIA Bustamante Dayana, Rodrguez Jean C. (2014).Metodologa Actual Metodologa XP[archivo PDF]. Disponible en ttp://blogs.unellez.edu.ve/dsilva/files/2014/07/Metodologia-XP.pdfpg. 22