• Author / Uploaded
• samdiaz10

Citation preview

ING. EN SISTEMAS COMPUTACIONALES

NOMBRE DEL ALUMNO: SAMUEL DIAZ MAY.

SEMESTRE: 6 GRUPO: “C”

PROFESOR(A): MARICRUZ TORRES GONZALEZ

MATERIA: INGENERIA DE SOFTWARE TURNO: VESPERTINO MARTES 11 DE maRZO DEL 2014

ING. EN SISTEMAS COMPUTACIONALES

METODOLOGIA GANAR GANAR Para la metodología del desarrollo del proyecto GA3 se utilizó principalmente el modelo reciente Ganar-ganar ya que con este existen ganancias para todas las partes implicadas en nuestro caso para el usuario en el aprendizaje del dialecto mazahua y la recuperación del mismo en la sociedad y para el desarrollador en cuestión monetaria y emocional ya que se obtiene una satisfacción al realizar un sistema que pueda salvar un dialecto tan importante como el mazahua, para poder entender porque fue que nos referimos a dar a conocer que este modelo es el indicado, se dará una breve explicación de lo que trata este modelo para justificar su uso en nuestro sistema GA3. El modelo Ganar-ganar establece las reglas para definir el proceso del desarrollo, tomando en cuenta las partes implicadas. Esta parte en si tiene mucho que ver con nuestro sistema GA3 porque para poder lograr hacer dicho sistema se tuvo que hacer un análisis de su desarrollo por medio de las encuestas y entrevistas con la gente a la cual iba dirigido dicho Diccionario y no solo a ellas sino también al público en general. El modelo Ganar-ganar no necesita mucho tiempo de gestión, lo que permite utilizarlo tanto en proyectos pequeños, como mayores. En el sistema GA3 nuestro proyecto es de término medio, pero con el futuro será un proyecto mayor, ya que se pretende hacer versiones y actualizaciones del Diccionario interactivo GA3 según se vea su crecimiento dentro de la sociedad. El modelo Ganar-ganar contiene cuatro ciclos y dentro de estas varias actividades las cuales son las siguientes: Ciclo 0. Grupo de aplicación. Se determina la viabilidad de un grupo apropiado de aplicaciones. En GA3 el ciclo 0 se refirió principalmente en la determinación del grupo de aplicación el cual se encuentra basado principalmente en las escuelas que tienen materias relacionadas con el dialecto mazahua que se basan principalmente en la traducción del dialecto mazahua a el idioma español. Ciclo 1. Objetivos del ciclo de vida de la aplicación. Se desarrollan objetivos del ciclo de vida, incluyendo prototipos, planes y especificaciones de aplicaciones individuales, y se verifica la existencia de al menos una arquitectura viable para cada aplicación. En el sistema GA3 se dieron a conocer los objetivos que deseamos alcanzar al igual que la forma en que podría ser nuestro sistema en cuestión de la interfaz de desarrollo, dicha interfaz tendría una arquitectura novedosa y entendible para la rápida y fácil utilización del sistema, para las aplicaciones individuales tendremos lo que son los juegos interactivos en los que se dará a conocer el nivel de aprendizaje del usuario. Y cada aplicación como son los juegos y la traducción serán de una manera uniforme y divertida para poder tener un entorno viable hacia el aprendizaje. Ciclo 2. Arquitectura del ciclo de vida de la aplicación. Se establece una arquitectura del ciclo de vida detallado, se verifica la viabilidad y determina que no existen riesgos mayores en satisfacer los planes y especificaciones.

ING. EN SISTEMAS COMPUTACIONALES

En el sistema GA3 se establecieron políticas y mantenimientos sobre las aplicaciones al igual que sus diferentes casos de uso de una forma detallada en caso de que existiera un error se consultarían dichos documentos, de esta forma prevenimos y damos a conocer diferentes formas para lograr obtener un producto de calidad y así satisfacer los planes y especiaciones del sistema. Ciclo 3. Capacidad de operación inicial. Alcanzar una capacidad operacional inicial para cada etapa crítica del proyecto en el ciclo de vida del software. En el sistema GA3 se basa principalmente en resolver los problemas que puedan surgir en el software y así poder tener un mejor producto y uso del mismo, para lograr esto se usaran los manuales de contingencia y de mantenimiento. Para justificar de una forma más exacta el uso de dicho modelo en el sistema GA3 es porque este modelo se basa principalmente del modelo espiral el cual tiene una secuencias de actividades como son el análisis, diseño, pruebas, implementación; el sistema GA3 utilizo todas estas actividades para poder ser realizado con esto podemos destacar que se podrán obtener a su vez las diferentes versiones que pueden ser realizadas por medio de dichas actividades, ya que nuestro sistema GA3 tendrá diferentes actualizaciones que se enfocan en las versiones de mismo. También podemos destacar que nuestro sistema se basa en la tecnología gratuita para el software y esto a su vez mejor la calidad del mismo, ya que el modelo Ganar-ganar se basa principalmente en la calidad y eficiencia de un sistema.

METODOLOGIA DE PROCESO UNIFICADO (UP) El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto. El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporationen 2003). El primer libro sobre el tema se denominó, en su versión española, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos también por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational

ING. EN SISTEMAS COMPUTACIONALES

utilizan el término Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.

METODOLOGIA DE INGENERIA WEB Es el proceso utilizado para crear, implantar y mantener aplicaciones y sistemas Web de alta calidad. La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en la World Wide Web. La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web está ocasionando un impacto en la sociedad y el nuevo manejo que se le está dando a la información en las diferentes áreas en que se presenta ha hecho que las personas tiendan a realizar todas sus actividades por esta vía. Desde que esto empezó a suceder el Internet se volvió más que una diversión y empezó a ser tomado más en serio, ya que el aumento de publicaciones y de informaciones hizo que la Web se volviera como un desafío para los (Ingeniería del software) ingenieros del software, a raíz de esto se crearon enfoques disciplinados, sistemáticos y metodologías donde tuvieron en cuenta aspectos específicos de este nuevo medio. Uno de los aspectos más tenidos en cuenta, en el desarrollo de sitios web es sin duda alguna el diseño gráfico y la organización estructural del contenido. En la actualidad la web está sufriendo grandes cambios, que han obligado a expertos en el tema a utilizar herramientas y técnicas basadas en la ingeniería del software, para poder garantizar el buen funcionamiento y administración de los sitios web. ´ Para garantizar el buen funcionamiento y mantenimiento de los sitios web, este debe contar con ciertos atributos y características que en conjunto forman un concepto muy importante, para alcanzar el éxito en cualquier organización, herramienta, y todo aquello que se pueda considerar como servicio. Dicho concepto es la calidad, que con atributos como, usabilidad, navegabilidad, seguridad, mantenibilidad, entre otros, hace posible por un lado la eficiencia del artefacto web y por ende la satisfacción del usuario final. Pero para tener artefactos de calidad, a esa misma se le debe planificar, programar y controlar, es decir la calidad no podrá ser agregada a un artefacto web o a cualquier otro producto, al final del proceso de desarrollo, si no que se deberá implementar durante todo el ciclo de vida del desarrollo. Para finalizar el resultado de un proceso de calidad, podría arrojar recomendaciones para introducir mejoras, y la decisión final podría consistir en lanzar una nueva versión del sitio web o en modificar algunos atributos ausentes o pobremente diseñados. Cabe destacar que la ingeniería de la web hace una diferencia entre un webSite y una aplicación, ya que la ingeniería de la web no se dedica a la construcción de sitios web si no a la construcción de aplicaciones web la principal característica que los distingue (aplicaciones de sitios web) es que los sitios web son sitios en la web en donde se publica contenido generalmente estático o un muy bajo nivel

ING. EN SISTEMAS COMPUTACIONALES

de interactividad con el usuario, mientras que las aplicaciones son lugares con alto contenido de interactividad y funcionalidades que bien podrían ser de un software convencional, la aplicación web más sencillo seria uno que contenga formularios y subiendo de nivel encontramos los que realizas conexión con bases de datos remotas, y administradores de contenidos entre otras. Entonces la ingeniería de la Web es la aplicación de metodologías sistemáticas, disciplinadas y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en la World Wide Web. En este sentido, la ingeniería de la Web hace referencia a las metodologías, técnicas y herramientas que se utilizan en el desarrollo de aplicaciones Web complejas y de gran dimensión en las que se apoya la evaluación, diseño, desarrollo, implementación y evolución de dichas aplicaciones.

METODOLOGIA AGILES Consiste en desarrollar una pequeña parte del software que se desea construir. De esta forma, el cliente nos indica si vamos por el buen camino, estableciendo aquellas partes que le son más relevantes y así juntos, nos aseguramos de que construimos una aplicación que añadirá valor a su negocio. 

La mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo



Las metodologías ágiles de desarrollo están especialmente indicadas en proyectos con requisitos poco definidos o cambiantes.



Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo



Entrega continua y en plazos breves de software funcional



Trabajo conjunto entre el cliente y el equipo de desarrollo



Importancia de la simplicidad, eliminado el trabajo innecesario



Atención continua a la excelencia técnica y al buen diseño



Mejora continua de los procesos y el equipo de desarrollo

El desarrollo ágil de software son métodos de ingeniería del software basado en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan mediante la colaboración de grupos autos organizados y multidisciplinarios. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en lapsos cortos. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener una «demo» (sin errores) al

ING. EN SISTEMAS COMPUTACIONALES

final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto. Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en inglés). La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica.

METODOLOGIA ERMEJENTES Primera aproximación a la aplicación de las metodologías SCRUM para mejorar la eficacia de los procesos de la Vigilancia e Inteligencia Competitiva, con la finalidad de obtener resultados pronto, con requisitos cambiantes o poco definidos, siendo la innovación, la competitividad, la flexibilidad y la productividad factores fundamentales. Metodologías de desarrollo Orientado a objetos, Diseño orientado a objetos (OOD) de Grady Booch, también conocido como Análisis y Diseño Orientado a Objetos (OOAD). El modelo incluye seis diagramas: de clase, objeto, estado de transición, la interacción, módulo, y el proceso. Top-down programming, evolucionado en la década de 1970 por el investigador de IBM Harlan Mills (y Niklaus Wirth) en Desarrollo Estructurado. Proceso Unificado, es una metodología de desarrollo de software, basado en UML. Organiza el desarrollo de software en cuatro fases, cada una de ellas con la ejecución de una o más iteraciones de desarrollo de software: creación, elaboración, construcción, y las directrices. Hay una serie de herramientas y productos diseñados para facilitar la aplicación. Una de las versiones más populares es la de Rational Unified Process.

REINGENERIA DE SOFTWARE La reingeniería del software es la tecnología que surge de aplicar las técnicas de Inteligencia Artificial y matemática sofisticada al análisis automatizado y modificación del código fuente de programas, para abreviarlo y hacerlo más eficiente. Actualmente la creación y modificación de programas de computadora es una tarea principalmente manual, y una tarea difícil e imprevisible. Los programas grandes suelen ser más complejos y más difíciles de depurar. Aunque la tecnología todavía está en su infancia, la reingeniería del software está empezando a tomar algunas tareas de programación, particularmente las tareas menos creativas, más repetitivas y las automatiza. Estos programas de reingeniería, escritos en idiomas especialmente diseñados, operan en el código fuente de los programas y realizan una variedad de análisis y modificaciones.

ING. EN SISTEMAS COMPUTACIONALES

Cuando una aplicación lleva siendo usada años, es fácil que esta aplicación se vuelva inestable como fruto de las múltiples correcciones, adaptaciones o mejoras que han podido surgir a lo largo del tiempo. Esto deriva en que cada vez que se pretende realizar un cambio se producen efectos colaterales inesperados y hasta de gravedad, por lo que se hace necesario, aplicar reingeniería a la misma, si se prevé que la aplicación seguirá siendo de utilidad. La Reingeniería de Software es una forma de modernización para mejorar las capacidades y/o mantenibilidad de los sistemas de información heredados mediante la aplicación de tecnologías y practicas modernas. La Reingeniería de Software ofrece una disciplina de preparación para migrar un sistema de información heredado hacia un sistema evolucionable. El proceso aplica principios de ingeniería para un sistema existente para encontrar nuevos requerimientos. PASOS PARA APLICAR LA REINGENIERÍA Una vez diagnosticado y seleccionado el proceso que tiene fallas, tomando en cuenta los aspectos anteriores, seguimos los siguientes pasos para aplicar la reingeniería en el proceso:    

Formulación de una estrategia: requisitos del mercado, identificando mercados a los cuales se sirven, productos y servicios que se ofrecen. Desarrollos de productos: es un insumo para producir nuevos diseños de productos. Desarrollo de capacidad de manufactura : Capacidad instalada en cuanto a recursos tecnológicos y humanos que se cuentan para el desarrollo del producto Comunicación con el cliente: A través de estudios hacia nuestros clientes, por medio de encuestas, estudios de mercado, etc., se trata de detectar las requerimientos de los clientes y tratar de estar un paso delante de lo que estos, puedan necesitar.

METODOLOGIA SCRUM Scrum define un proceso empírico, iterativo e incremental de desarrollo que intenta obtener ventajas respecto a los procesos definidos (cascada, espiral, prototipos, etc.) mediante la aceptación de la naturaleza caótica del desarrollo de software, y la utilización de prácticas tendientes a manejar la impredictibilidad y el riesgo a niveles aceptables. El mismo surge e n 1986 de un artículo de la Harvard Business Review titulado “The New New Product Development Game” de Hirotaka Takeuchi e Ikujiro Nonaka, que introducía las mejores prácticas más utilizadas en 10 compañías japonesas altamente innovadoras. A partir de ahí y tomando referencias al juego de rugby, Ken Scwaber y Jeff Sutherland formalizan el proceso conocido como Scrum en el año 1995. Scrum es un método iterativo e incremental que enfatiza prácticas y valores de Project management por sobre las demás disciplinas del desarrollo. Al principio del proyecto se define el Product Backlog, que contiene todos los requerimientos funcionales y no funcionales que deberá satisfacer el sistema a construir. Los mismos estarán especificados de acuerdo a las convenciones de la organización ya sea mediante: features, casos de uso, diagramas de flujo de datos, incidentes, tareas, etc. El Product Backlog será definido durante reuniones de planeamiento con los stakeholders. A partir de ahí se definirán las iteraciones, conocidas como Sprint en la juerga de Scrum, en las que se irá evolucionando la aplicación evolutivamente. Cada Sprint tendrá su propio Sprint

ING. EN SISTEMAS COMPUTACIONALES

Backlog que será un subconjunto del Product Backlog con los requerimientos a ser construidos en el Sprint correspondiente. La duración recomendada del Sprint es de un mes. Dentro de cada Sprint el Scrum Master (equivalente al Líder de Proyecto) llevará a cabo la gestión de la iteración, convocando diariamente al Scrum Daily Meeting que representa una reunión de avance diaria de no más de 15 minutos con el propósito de tener realimentación sobre las tareas de los recursos y los obstáculos que se presentan. Al final de cada Sprint, se realizará un Sprint Review para evaluar los artefactos construidos y comentar el planeamiento del próximo Sprint. Como se puede observar en la Figura Nº4 la metodología resulta sencilla definiendo algunos roles y artefactos que contribuyen a tener un proceso que maximiza el feedback para mitigar cualquier riesgo que pueda presentarse. A. Scrum aplicado al Desarrollo de Software Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software. Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. En el desarrollo de software Scrum está considerado como modelo ágil por la Agile Alliance

ING. EN SISTEMAS COMPUTACIONALES

Figura Nº4. Descripción de Roles, artefactos, reuniones y proceso de desarrollo de Scrum. La intención de Scrum es la de maximizar la realimentación sobre el desarrollo pudiendo corregir problemas y mitigar riesgos de forma temprana. Su uso se está extendiendo cada vez más dentro de la comunidad de Metodologías Ágiles, siendo combinado con otras – como XP – para completar sus carencias. Cabe mencionar que Scrum no propone el uso de ninguna práctica de desarrollo en particular; sin embargo, es habitual emplearlo como un framework ágil de administración de proyectos que puede ser combinado con cualquiera de las metodologías mencionadas. B. Ciclo de Vida de Scrum El ciclo de vida de Scrum es el siguiente: 1. Pre-Juego: Planeamiento. El propósito es establecer la visión, definir expectativas y asegurarse la financiación. Las actividades son la escritura de la visión, el presupuesto, el registro de acumulación o retraso (backlog) del producto inicial y los ítems estimados, así como la arquitectura de alto nivel, el diseño exploratorio y los prototipos. El registro de acumulación es de alto nivel de abstracción. 2. 2Pre-Juego: Montaje (Staging). El propósito es identificar más requerimientos y priorizar las tareas para la primera iteración. Las actividades son planificación, diseño exploratorio y prototipos. 3. Juego o Desarrollo. El propósito es implementar un sistema listo para entrega en una serie de iteraciones de treinta días llamadas “corridas” (sprints). Las actividades son un encuentro de planeamiento de corridas en cada iteración, la definición del registro de acumulación de corridas y los estimados, y encuentros diarios de Scrum. 4. Pos-Juego: Liberación. El propósito es el despliegue operacional. Las actividades, documentación, entrenamiento, mercadeo y venta. Usualmente los registros de acumulación se llevan en planillas de cálculo comunes, antes que en una herramienta sofisticada de gestión de proyectos. Los elementos del registro pueden ser prestaciones del software, funciones, corrección de bugs, mejoras requeridas y actualizaciones de tecnología. Hay un registro total del producto y otro específico para cada corrida de 30 días. En la jerga de Scrum se llaman “paquetes” a los objetos o componentes que necesitan cambiarse en la siguiente iteración.

ING. EN SISTEMAS COMPUTACIONALES

Figura Nº5. Ciclo de Carrera o de Vida (Sprint) de Scrum. La lista de Acumulación del Producto contiene todos los rasgos, tecnología, mejoras y lista de bugs que, a medida que se desenvuelven, constituyen las futuras entregas del producto. Los rasgos más urgentes merecerán mayor detalle, los que pueden esperar se tratarán de manera más sumaria. La lista se origina a partir de una variedad de fuentes. El grupo de mercadeo genera los rasgos y la función; la gente de ventas genera elementos que harán que el producto sea más competitivo; los de ingeniería aportarán paquetes que lo harán más robusto; el cliente ingresará debilidades o problemas que deberán resolverse. El propietario de la administración y el control del backlog en productos comerciales bien puede ser el product manager; para desarrollos in-house podría ser el project manager, o alguien designado por él. Se recomienda que una sola persona defina la prioridad de una tarea; si alguien tiene otra opinión, deberá convencer al responsable. Se estima que priorizar adecuadamente una lista de producto puede resultar dificultosa al principio del desarrollo, pero deviene más fácil con el correr del tiempo. Al fin de cada iteración de treinta días hay una demostración a cargo del Scrum Master. Las presentaciones en PowerPoint están prohibidas. En los encuentros diarios, las gallinas deben estar fuera del círculo. Todos tienen que ser puntuales; si alguien llega tarde, se le cobra una multa que se destinará a obras de caridad. Es permitido usar artefactos de los métodos a los que Scrum acompañe, por ejemplo Listas de Riesgos si se utiliza UP, Planguage si el método es Evo, o los Planes de Proyecto sugeridos en la disciplina de Gestión de Proyectos de Microsoft Solutions Framework. No es legal, en cambio, el uso de instrumentos tales como diagramas PERT, porque éstos parten del supuesto de que las tareas de un proyecto se pueden identificar y ordenar; en Scrum el supuesto dominante es que el desarrollo es semi-caótico, cambiante y tiene demasiado ruido como para que se le aplique un proceso definido.

Algunos textos sobre Scrum establecen una arquitectura global en la fase de pre-juego; otros dicen que no hay una arquitectura global en Scrum, sino que la arquitectura y el diseño emanan de múltiples corridas. No hay una ingeniería del software prescripta para Scrum; cada quien puede escoger entonces las prácticas de automatización, inspección de código, prueba unitaria, análisis o programación en pares que le resulten adecuadas. Como ya se ha mencionado antes, es muy habitual que Scrum se complemente con XP; en estos casos, Scrum suministra un marco de management basado en patrones organizacionales, mientras XP constituye la práctica de programación, usualmente orientada a objetos y con fuerte uso de patrones de diseño. Uno de los nombres que se utiliza para esta alianza es XP@Scrum. También son viables los híbridos con otras metodologías ágiles.