T E S I S QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS DE LA COMPUTACIÓN P R E S E N T A ING.ERÉNDIRA MIRIAM JIMÉNEZ HERNÁNDEZ

Tamaño: px
Comenzar la demostración a partir de la página:

Download "T E S I S QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS DE LA COMPUTACIÓN P R E S E N T A ING.ERÉNDIRA MIRIAM JIMÉNEZ HERNÁNDEZ"

Transcripción

1 Instituto Politécnico Nacional Centro de Investigación en Computación Secretaría de Investigación y Posgrado META (MEtodología Tradicional y Ágil), UNA METODOLOGÍA HÍBRIDA PARA DESARROLLO DE SOFTWARE WEB PROPUESTA PARA LAS EMPRESAS DE SOFTWARE EN MÉXICO T E S I S QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS DE LA COMPUTACIÓN P R E S E N T A ING.ERÉNDIRA MIRIAM JIMÉNEZ HERNÁNDEZ DIRECTOR DE TESIS: M. en C. SANDRA DINORA ORANTES JIMÉNEZ MÉXICO, D.F. OCTUBRE 2012

2

3

4 Resumen El desarrollo de software es una actividad no trivial, razón por la cual se ha intentado dar solución a dicha problemática a través del uso de metodologías, las cuales proporcionan procesos sistematizados sobre el desarrollo de software con el fin de mejorar la productividad y la calidad. En la actualidad, existen un gran número de metodologías para el desarrollo de software; estas se engloban en tres categorías: las metodologías tradicionales, las metodologías ágiles y las metodologías híbridas. Las metodologías tradicionales propician las buenas prácticas que existen dentro de la Ingeniería de Software; sin embargo, requieren de mucha disciplina para seguir con el riguroso proceso que éstas conllevan. Las metodologías ágiles presentan respuestas rápidas al cambio y son flexibles, aunque generan poca documentación y no hacen uso de métodos formales. Las metodologías híbridas son la nueva tendencia en el área de Ingeniería de Software, su principal característica es que incorporan algunas prácticas de las metodologías tradicionales y ágiles existentes, brindado así una gran ventaja. Este trabajo propone una metodología híbrida para desarrollo de proyectos de software Web, la cual es conocida como MEtodología Tradicional y Ágil (META por sus siglas en español) que combina algunas prácticas de las metodologías RUP (Rational Unified Process, Proceso Unificado de Racional), XP (extreme Programming, Programación Extrema) y Scrum. META se diseñó a partir de un estudio (que se realizó como parte de esta investigación), en el cual se comprobó que las empresas mexicanas dedicadas a desarrollar software son candidatas a utilizar una metodología híbrida. Finalmente META se probó en proyectos de desarrollo de software reales y se evaluó su calidad con la norma NMX-I-055-NYCE; de esta manera se presenta a META como una opción factible para desarrollo de software en México. Eréndira Miriam Jiménez Hernández Octubre 2012 ii

5 Abstract The software development is a nontrivial activity, this is the reason why it have been used methodologies for trying to solve this problem because they provide a systematic process for software development in order to improve productivity and quality. Currently, there are a lot of methodologies for software development, these falls into three broad categories: traditional methodologies, agile methodologies and hybrid methodologies. The traditional methodologies foster the best practices that exist within Software Engineering; however, they require a lot of discipline to continue the rigorous process that they entail. The agile methodologies have quick responses to change and they are flexible, but they generate little documentation and they do not make use of formal methods. The hybrid methodologies are the new trend in the area of Software Engineering, its main feature is that they incorporate some practices of the existing methodologies, providing a great advantage. This thesis proposes a hybrid methodology for software development of Web projects called META (MEtodología Tradicional y Ágil, Traditional and Agile Methodology), it combines some practices within others methodologies as RUP (Rational Unified Process), XP (extreme programming) and Scrum. META was designed from a study (which was conducted as part of this research), in which it was found that Mexican companies dedicated to developing software are candidates to use a hybrid methodology. Finally META was tested in real projects of software development and it was assessed its quality with the standard NMX-I-055-NYCE; thereby it presents META as a feasible option for software development in Mexico. Eréndira Miriam Jiménez Hernández Octubre 2012 iii

6 Agradecimientos. Al Instituto Politécnico Nacional. Por brindarme la oportunidad de pertenecer a una de las mejores instituciones de la República Mexicana, ofreciéndome una formación académica de calidad al servicio de mi país. Al Centro de Investigación en Computación. Por proporcionar los recursos humanos y materiales necesarios para la adecuada adquisición de conocimiento. A CONACYT. Por otorgarme una beca que significó un apoyo económico durante el tiempo que cursé la Maestría. A mi Asesora. Por haberme ayudado incondicionalmente y compartir su conocimiento conmigo. Al Comité Tutorial. Por su valiosa aportación en comentarios y recomendaciones que permitieron mejorar mi formación académica y aumentar la calidad de mi proyecto de tesis. A mi Papá. Que siempre me ha guiado y me ha sabido ofrecer sabios consejos en los momentos en que más lo he necesitado, además de ser el ejemplo que siempre me motiva a buscar más en la vida y a obrar con rectitud y congruencia. A mi Mamá. Que ha estado siempre al pendiente de mí brindándome su cariño y comprensión. A mis Hermanos. Mis amiguitos, que han estado a mi lado siempre dándole alegría a mi vida. A mi Novio. Que me anima y me apoya para alcanzar mis sueños y hacerlos realidad Y en general, a aquellas personas que han compartido momentos especiales de su vida conmigo que quedarán por siempre en mi memoria y por los cuales estaré agradecida toda la vida. Eréndira Miriam Jiménez Hernández Octubre 2012 iv

7 Índice Resumen... ii Abstract... iii Agradecimientos iv Glosario... ix 1 Introducción Planteamiento del problema Objetivos Objetivo General Objetivos Específicos Justificación Beneficios Esperados Límites y Alcances Organización de la Tesis Resumen Marco Teórico Introducción Estado del Arte Metodologías Tradicionales RUP Metodologías Ágiles XP Scrum Metodologías Híbridas EssUP Norma Mexicana NMX-I-055-NYCE Modelo de Calidad Interna y Externa Modelo de Calidad para la Calidad en Uso Resumen META Introducción Características de META Requerimientos y Requisitos para el Uso de META Capacitación para el uso de META Roles en META Principios Metodológicos de META Proceso de Desarrollo de META Planteamiento Preparación Construcción Implantación Componentes de META Eréndira Miriam Jiménez Hernández Octubre 2012 v

8 3.9 Ventajas de META Limitaciones de META Resumen Pruebas y Resultados obtenidos Introducción Evaluación de META Opinión respecto a META Resumen Conclusiones y Trabajos Futuros Bibliografía Referencias URL Apéndices Características de las Aplicaciones Web Plantilla General del Contrato Fólder del Proyecto Calidad Interna del Producto Calidad Externa del Producto Calidad en Uso del Producto Anexos Metodologías Híbridas para desarrollo de software: una opción factible para México (Revista Digital Universitaria) 2 META: a new hybrid methodology to software development created to suit the current needs in Mexico (ICTA 2011) 3 Metodología Híbrida para desarrollo de software en México (CICIC 2012) Eréndira Miriam Jiménez Hernández Octubre 2012 vi

9 Índice de Figuras Figura 1.1. Metodologías utilizadas en las empresas mexicanas Figura 1.2. Área bajo la curva de la distribución normal Figura 1.3. Intervalo de confianza Figura 2.1. Etapas de RUP Figura 2.2. Etapas de XP Figura 2.3. Proceso de Scrum Figura 2.4. Modelo para la calidad del producto Figura 2.5. Modelo para la calidad interna y externa Figura 2.6. Modelo para la calidad en uso Figura 3.1. Roles en META Figura 3.2. Ciclo de Deming Figura 3.3. Proceso de desarrollo de META Figura 3.4. Ejemplo de Diagrama Interfaz-Navegación de la página de inicio del sitio Figura 3.5. Ejemplo de Diagrama Interfaz-Navegación de la página principal de los Clientes Figura 3.6. Ejemplo de Diagrama Interfaz-Navegación de la página principal de las Tiendas Figura 3.7. Estimación con META-Software Figura 3.8. Generación de contrato con META-Software Figura 3.9. Plan de proyecto general para el mes de diciembre Figura Plan de proyecto general para el mes de enero Eréndira Miriam Jiménez Hernández Octubre 2012 vii

10 Índice de Tablas META (MEtodología Tradicional y Ágil), una metodología híbrida para Tabla 2.1. Metodologías Ágiles vs. Metodologías Tradicionales Tabla 3.1. Roles en META Tabla 3.2. Tabla de Actividad-Responsabilidad Tabla 3.3. Tabla de Gestión de Riesgos y Problemas Tabla 3.4. Componentes de META Tabla 4.1. Tabla de Normalización de las Métricas para la evaluación del Producto Tabla 4.2. Tabla Calidad Interna del Producto (Media aritmética y porcentaje) Tabla 4.3. Tabla Calidad Externa del Producto (Media aritmética y porcentaje) Tabla 4.4. Media Aritmética y Porcentaje de las Características de la Calidad Interna del Producto Tabla 4.5. Media Aritmética y Porcentaje de las Características de la Calidad Externa del Producto Tabla 4.6. Media Aritmética y Porcentaje de las Características de la Calidad en Uso del Producto Tabla 4.7. Calidad del Producto Eréndira Miriam Jiménez Hernández Octubre 2012 viii

11 Glosario Glosario de Términos Base de Datos Calidad Caso de Uso Evaluación de Calidad Híbrido Ingeniería de Software Metodología Métrica Puntos de Función Software Web Es una colección de datos interrelacionados almacenados conjuntamente en uno o más ficheros de computadora [IEE90]. Totalidad de las características de una entidad que nacen de su capacidad para satisfacer las necesidades explícitas e implícitas [NYC06]. Es una funcionalidad del sistema que proporciona al usuario un valor añadido [IBM11]. Examen sistemático del grado al cual una entidad es capaz de cumplir los requisitos especificados [NYC06]. Se dice de todo lo que es producto de elementos de distinta naturaleza [RAE01]. Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo operación (funcionamiento) y mantenimiento del software: es decir, la aplicación de Ingeniería al software [IEE93]. Conjunto de pasos y procedimientos que deben seguirse para desarrollar sistemas computacionales [SOM09]. Es una medida cuantitativa o cualitativa del grado en que un sistema, componente o proceso posee un atributo determinado [IEE93]. Es una métrica empleada para medir la funcionalidad que entrega un sistema a través del conocimiento del número de entradas externas, salidas externas, consultas externas, archivos lógicos internos y archivos de interfaz externos [ALB79]. Conjunto de programas, instrucciones y reglas informáticas para ejecutar ciertas tareas en una computadora [RAE01]. Protocolo basado en hipertexto, que permite conectar su contenido mediante hipervínculos, fue pensado como una fuente de material de sólo lectura, que se encontraba en una gran estructura de servidores cargados con miles de datos [BER96]. Eréndira Miriam Jiménez Hernández Octubre 2012 ix

12 Glosario de Acrónimos COCOMO CRC DSA INEGI META OMT PERT RUP UML UP XP COnstructive COst MOdel, Modelo Constructivo de Costos Class Responsibility-Collaboration, Clase Responsabilidad-Colaboración Development Software Adaptative, Desarrollo de Software Adaptativo Instituto Nacional de Estadística y Geografía MEtodología Tradicional y Ágil Object Modeling Technique, Técnica de Modelado de Objetos Program Evaluation and Review Technique, Técnica de Evaluación y Revisión de Programas Rational Unified Process, Proceso Unificado de Racional Unified Modeling Language, Lenguaje Unificado de Modelado Unified Process, Proceso Unificado extreme Programming, Programación Extrema Eréndira Miriam Jiménez Hernández Octubre 2012 x

13 1 Introducción El software se ha convertido en una tecnología indispensable en los negocios, la ciencia y la ingeniería; ha permitido la creación, la expansión y el fin de tecnologías. En la actualidad, el software está relacionado con sistemas de todo tipo: de transporte, médicos, de telecomunicaciones, militares, industriales, de entretenimiento, entre otros. A medida que la importancia del software ha crecido, la Ingeniería de Software ha intentado desarrollar tecnologías que faciliten y disminuyan el tiempo y el costo de construcción y mantenimiento del software; entre las cuales se pueden mencionar a las metodologías como una aportación que ha simplificado la labor no trivial de desarrollo de software. Una metodología para desarrollo de software, es un conjunto de pasos y procedimientos que deben seguirse para desarrollar sistemas computacionales [SOM09]. Por lo que se espera que al utilizar una metodología para desarrollo de software, ésta proporcione un conjunto de prácticas y herramientas que faciliten el proceso de desarrollo, obteniendo un producto con alta calidad, seguridad y que satisfaga las expectativas del cliente. 1.1 Planteamiento del Problema En México el 79% de las empresas desarrolladoras de software utilizan las metodologías conocidas como RUP (Rational Unified Process, Proceso Unificado de Racional), XP (extreme Programming, Programación Extrema) y Scrum [JIM12]. De manera específica, el 37% de las empresas utilizan RUP, el 26% utilizan XP y el 16% Scrum (véase Figura 1.1); considerando esta información se puede observar que el 42% de las empresas hacen uso de metodologías ágiles (porque XP y Scrum se consideran ágiles) y el 37% de una metodología tradicional (RUP); de este modo, al investigar cuál es la situación de esas empresas, permite plantear la posibilidad de diseño de una metodología que se adapte específicamente a sus necesidades porque no existe una metodología genérica que funcione para todos los proyectos y tanto RUP, XP y Scrum surgieron para el ámbito de desarrollo estadounidense y europeo, por lo cual al implantarlas en México no resultan ser siempre la mejor elección. Eréndira Miriam Jiménez Hernández Octubre

14 1.2 Objetivos Figura 1.1. Metodologías utilizadas en las empresas mexicanas [JIM12] Objetivo General Diseñar una metodología que se adapte al contexto actual de las empresas de desarrollo de software en México, basada en la nueva tendencia en el área de Ingeniería de Software: metodologías híbridas Objetivos Específicos Identificar las necesidades y prácticas de Ingeniería de Software presentes en las empresas dedicadas a desarrollar software en México. Definir una metodología híbrida para desarrollo de software que tome en cuenta lo investigado en el punto anterior. Probar la utilidad de la metodología propuesta en algunas empresas dedicadas a desarrollar software en México. Eréndira Miriam Jiménez Hernández Octubre

15 1.3 Justificación META (MEtodología Tradicional y Ágil), una metodología híbrida para En México, más del 50% de las empresas dedicadas al desarrollo de software son candidatas a utilizar una metodología híbrida. Por lo cual, las metodologías existentes son tradicionales o ágiles y no se acoplan a las necesidades de las empresas [JIM12]. Por lo que el diseñar una metodología híbrida para que las empresas de desarrollo de software en México la puedan utilizar, es una buena opción para incrementar la productividad en dichas empresas. Lo anterior se comprobó a través de un estudio realizado con las empresas de software en México, dicho estudio se puede ver a detalle en el Artículo publicado en la Revista Digital Universitaria (véase Anexo 1). Para poder realizar el estudio se planteó una encuesta con 19 preguntas, con respuestas de opción múltiple (la cual se incluye en el Apéndice A del Anexo 1). También se recurrió a los datos estadísticos de INEGI (Instituto Nacional de Estadística y Geografía). Según INEGI, en el año 2010 se contabilizaron 9540 empresas en México dedicadas al desarrollo de software [INE11]. Para calcular el tamaño de la muestra, se aplicó la encuesta a un grupo piloto con 20 empresas y se obtuvo que: 40% se inclinaron por el uso de metodologías híbridas 60% no se inclinaron por el uso de metodologías híbridas Estos porcentajes representan los valores estadísticos de p y q respectivamente, mismos que se utilizaron para encontrar el tamaño de la muestra en la siguiente fórmula matemática [WAL99]: 2 Z pqn n = 2 2 NE + Z pq Donde: n es el tamaño de la muestra Z es el nivel de confianza p es la variabilidad positiva q es la variabilidad negativa N es el tamaño de la población E es la precisión o el error Eréndira Miriam Jiménez Hernández Octubre

16 Considerando una población de 9540 empresas, un nivel de confianza del 95% y un error estándar en experimentos científicos del 5% [COC84], se tiene: 2 (0.95) (0.40)(0.60)(9540) n = 2 (9540)(0.05) + (0.95)(0.40)(0.60) n = n 86 Por lo tanto, se seleccionaron aleatoriamente a 86 empresas de la lista que proporcionó el INEGI para que respondieran la encuesta. Si el porcentaje de error se hubiera disminuido, entonces el número de empresas a encuestar habría aumentado significativamente, incrementando los costos para obtener la información. Es importante mencionar que la selección de las empresas a las cuales se les aplicó la encuesta fue en forma aleatoria, que no todas las empresas señaladas por el INEGI se pudieron encontrar y que no todas mostraron interés en participar, de tal manera que en ese caso fueron sustituidas en forma aleatoria por otras empresas, hasta completar la muestra. Después de encuestar a las 86 empresas mexicanas dedicadas a desarrollar software, se obtuvieron los siguientes resultados de la tabla que se muestra en el Apéndice B del Anexo 1. En dicha tabla, sólo se muestra la información de las preguntas 3, 4, 6, 7, 8 y 13 de la encuesta; porque estas preguntas son las que permiten determinar el tipo de metodología utilizada por una determinada empresa para desarrollar software. (El nombre de las empresas que corresponden a los números de dicha tabla se encuentran en el Apéndice C del Anexo 1). Los valores que aparecen como respuesta a las preguntas fueron asignados dependiendo del tipo de metodología: Valor Tipo de metodología 1 Metodología Ágil 2 Metodología Híbrida 3 Metodología Tradicional Al analizar los datos, se encontró que el número de empresas que prefieren los tres tipos de metodologías se distribuyen de la siguiente manera: Tipo de metodología Número de empresas Metodologías Ágiles 22 Metodologías Híbridas 50 Metodologías Tradicionales 14 TOTAL 86 Eréndira Miriam Jiménez Hernández Octubre

17 Se puede observar que el número de empresas que prefieren metodologías híbridas es de 50 y no híbridas de 36. Tipo de Número de metodología empresas HIBRIDA 50 NO HIBRIDAS 36 Para determinar si una empresa tiene inclinación por usar una determinada metodología, no se empleó una sola pregunta, sino los valores de las preguntas que distinguen a dicha metodología. En las preguntas donde era permitido responder más de una opción, se sumó la puntuación y se dividió entre el número de respuestas para encontrar el promedio de una pregunta determinada. Tomando en cuenta los datos mencionados, se realizó una prueba de hipótesis con proporciones donde: p 1 : Proporción de empresas desarrolladoras de software con una inclinación hacia metodologías híbridas. Hipótesis H 0 : p H 1 : p 1 <0.50 La interpretación de la hipótesis es la siguiente: H 0 : H 1 : El 50% o más de las empresas desarrolladoras de software tienen una inclinación hacia el uso de metodologías híbridas. Menos del 50% de las empresas desarrolladoras de software tienen una inclinación hacia el uso de metodologías híbridas. El estadístico de prueba es [WAL99]: Donde: z p z = p p p( 1 p) n es el estadístico de prueba es la proporción de la muestra que tiene inclinación hacia el uso de metodologías híbridas p es la proporción de la población = 0.50 n tamaño de la muestra Eréndira Miriam Jiménez Hernández Octubre

18 Sustituyendo: z = (1 0.50) 86 = La información obtenida en el estudio tiene una distribución normal, de tal manera que con un nivel de significancia (o error) del 5% el área de rechazo o no rechazo de la hipótesis nula H 0 es como se muestra en la Figura 1.2: Figura 1.2. Área bajo la curva de la distribución normal NOTA: El valor del área bajo la curva normal (-1.645) se obtuvo de tablas estadísticas [WAL99] Se observa en la Figura 1.2 que el estadístico de prueba cae en la zona de no rechazo; por lo tanto, no se rechaza H 0 y se dice que: El 50% o más de las empresas desarrolladoras de software tiene una inclinación hacia el uso de metodologías híbridas. Para corroborar la prueba de hipótesis se realizó un intervalo de confianza, el cual podría no hacerse, pero como su nombre lo indica, proporciona mayor certeza al experimento; así que el intervalo de confianza se hizo para un nivel de significancia del 5% (porque la prueba de hipótesis se realizó con un error del 5% y se tiene que considerar la misma en el intervalo). Los límites de dicho intervalo se muestran a continuación (véase Figura 1.3): Eréndira Miriam Jiménez Hernández Octubre

19 z α 2 = z = z = 1.96 Figura 1.3. Intervalo de confianza [WAL99] Lo cual implica que con un error del 5% la proporción de desarrolladores de software que prefieren metodologías híbridas se encuentran entre el 47.77% y el 68.5% pq p zα < p < p+ z n 2 α 2 pq n < p < < p < En la investigación se puede observar que una metodología híbrida será de gran ayuda para las empresas desarrolladoras de Software de la República Mexicana, pero dadas las similitudes de México con los países latinoamericanos seguramente estos resultados se pueden extrapolar también para esos países, con las respectivas diferencias propias de cada una de esas naciones, empresas de desarrollo de software y grupos de trabajo. En resumen esta investigación mostró que es factible utilizar una metodología híbrida para desarrollar software en México. Además, proporcionó información útil para el diseño de la misma. Eréndira Miriam Jiménez Hernández Octubre

20 1.4 Beneficios Esperados Elaborar una Metodología Híbrida para desarrollar software que cumpla con las características de calidad de la Norma Mexicana NMX-I-055-NYCE Contribuir con la Ingeniería de Software con una nueva Metodología Híbrida para desarrollo de proyectos de software. 1.5 Limites y Alcances Cada etapa del proceso de desarrollo será definida como un conjunto de tareas generales, de tal forma que existirán actividades como la estimación de costos o la elaboración de diagramas de UML (Unified Modeling Language, Lenguaje Unificado de Modelado) que no serán especificados con detalle. La herramienta META-Software sólo proporcionará apoyo en la generación de documentación descrita dentro del proceso de desarrollo de META. La metodología será probada en proyectos reales dentro de empresas mexicanas para comparar resultados, los proyectos seleccionados deberán cumplir con las características para las cuales es ideal utilizar la metodología propuesta. 1.6 Organización de la Tesis Esta tesis está dividida en cinco capítulos, a continuación se describe cada uno de ellos: Capítulo 1. Introducción. Planteamiento general del problema, descripción y alcance del trabajo, objetivos y beneficios esperados. Capítulo 2. Marco Teórico. Metodologías existentes, definiciones, terminología y conceptos a ser manejados en el trabajo. Capítulo 3. Metodología Propuesta: META. Descripción de la metodología, así como de la herramienta de apoyo llamada META-Software. Capítulo 4. Pruebas y resultados obtenidos. Capítulo 5. Conclusiones y trabajos futuros. 1.7 Resumen Las metodologías se han convertido en un elemento clave para la producción de sistemas y productos de software con alta calidad; de esta manera y con el objetivo de contribuir en el crecimiento de la industria dedicada a desarrollar software en México, se presenta la propuesta de una metodología basada en la nueva tendencia en el área de Ingeniería de Software: las metodologías híbridas. Eréndira Miriam Jiménez Hernández Octubre

21 2 Marco Teórico 2.1 Introducción META (MEtodología Tradicional y Ágil), una metodología híbrida para De acuerdo con el Diccionario de la Real Academia Española, la palabra metodología es un conjunto de métodos que se siguen en una investigación científica o en una exposición doctrinal [RAE01]. En el área de Ingeniería de Software, el término metodología se refiere a un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo de sistemas computacionales [PRE05]. Actualmente hay dos tipos de metodologías: las tradicionales y las ágiles; aunque existe una nueva propuesta: las metodologías híbridas [JIH12]. Las metodologías de desarrollo de software han evolucionando a medida que los paradigmas de programación también lo han hecho, de tal manera que se acoplaron a ellos tratando de ajustarse a las nuevas necesidades; dichas metodologías han proporcionando herramientas y prácticas que ayudan en el proceso de desarrollo de software. Así que resulta de vital importancia revisar la evolución de las metodologías existentes para poder proponer una metodología híbrida que satisfaga las necesidades actuales de las empresas de desarrollo de software en México. 2.2 Estado del Arte Metodologías Tradicionales Existen dos tipos de metodologías tradicionales: las metodologías para el paradigma estructurado y las metodologías orientadas a objetos [BRA00]. Con el surgimiento del paradigma estructurado, nacieron algunas metodologías acordes a dicho paradigma; como la creada por Yourdon [YOU76], en la cual el uso de Diagramas de Flujos de Datos, Diagramas de Contexto, Diagramas de Transición de Estados y Diagramas de Entidad-Relación, aparecían como una constante en el modelado del sistema. Cuando el paradigma de programación orientado a objetos apareció, surgieron metodologías para esta nueva forma de programar también; como OMT (Object Modeling Technique, Técnica de Modelado de Objetos) [RUM90], Métrica 3 [MPE11], RUP (Rational Unified Process, Proceso Unificado de Racional) [IBM11], entre otras. Las metodologías orientadas a objetos contribuyeron positivamente a las metodologías tradicionales existentes, al ser incrementales e iterativas. Además promovieron la Eréndira Miriam Jiménez Hernández Octubre

22 asignación de roles dentro del equipo de desarrollo, facilitaron las división del sistema en varios subsistemas y fomentaron el rehúso de componentes. Así que de manera general, las metodologías tradicionales consideraron la importancia de documentar el sistema, permitiendo entender, extender y mantener el software; porque estas metodologías proveen una estructura bien definida y un orden. Sin embargo, también tienen algunas desventajas, entre las cuales se puede señalar que se requiere de un alto grado de disciplina, no se tiene respuesta rápida a cambios, se genera documentación innecesaria y se invierte mucho tiempo en el modelado del sistema. Además estás metodologías tienen un plan de proyecto muy riguroso. Por lo cual de manera general, no consideran que el análisis, el diseño y la construcción son impredecibles la mayoría de las veces RUP El Proceso Unificado de Racional, por sus siglas en inglés RUP, es un proceso de desarrollo de software que en conjunto con UML (Unified Modeling Language, Lenguaje Unificado de Modelado) [OMG11], constituye una de las metodologías estándar más utilizadas para el análisis, implementación y documentación de sistemas orientados a objetos y de información [PRE05]. Originalmente se diseñó una metodología genérica y de dominio público, UP (Unified Process, Proceso Unificado) [JAC05], sin embargo fue comprada por Rational Corporation de la empresa IBM, adoptando así el nombre de Rational Unified Process [IBM11], por lo cual para conocer RUP basta con aprender UP puesto que la esencia es la misma. RUP es una metodología creada por Ivar Jacobson, Grady Booch y James Rumbaugh. Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres características esenciales: a. Está dirigido por Casos de Uso. Un Caso de Uso es un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido; por lo que los Casos de Uso, representan los requisitos funcionales del sistema [IBM11]. En RUP los Casos de Uso no sólo son una herramienta de especificación de los requerimientos del sistema; también guían su diseño, implementación y prueba. Por lo que los Casos de Uso no sólo inician el proceso de desarrollo, sino que proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo. Eréndira Miriam Jiménez Hernández Octubre

23 b. Está centrado en la arquitectura. La arquitectura de un sistema es la organización o estructura de las partes consideradas relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva del sistema completo. La arquitectura involucra los aspectos estáticos y dinámicos significativos del sistema, está relacionada con la toma de decisiones que indican cómo tiene que ser construido el sistema y ayuda a determinar en qué orden; además, toma en cuenta los elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución. Por lo que RUP además de utilizar los Casos de Uso para guiar el proceso, presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactaba ante cambios posteriores durante la construcción y el mantenimiento. Cada producto tiene tanto una función como una forma y la función corresponde a la funcionalidad reflejada en los Casos de Uso y la forma proporciona la arquitectura. c. Es iterativo e incremental. RUP propone un proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, así durante todo el proceso de desarrollo. Cada mini proyecto puede verse como una iteración del cual se obtiene un incremento que produce un crecimiento del producto. Una iteración puede realizarse por medio de una cascada, es decir se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas). El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. RUP consta de 5 fases, las cuales se muestran en la Figura 2.1. Eréndira Miriam Jiménez Hernández Octubre

24 Figura 2.1. Etapas de RUP [PRE05] La fase de inicio abarca la comunicación con el cliente y las actividades de planeación. Al colaborar con los clientes y los usuarios finales se identifican los requisitos de negocios para el software, se propone una arquitectura aproximada para el sistema y se desarrolla un plan la naturaleza iterativa e incremental del sistema subsiguiente. La fase de elaboración abarca la comunicación con el cliente y las actividades de modelado del modelo genérico del proceso. La elaboración refina y expande los casos de uso preliminares que se desarrollan como una parte de la fase de inicio, además, expande la representación arquitectónica para incluir cinco visiones diferentes del software: el modelo de casos de uso, el modelo de análisis, el modelo de diseño, el modelo implementación y el modelo de despliegue. La fase de construcción es idéntica a la actividad de construcción definida para el proceso genérico del software. La fase de transición abarca las últimas etapas de la actividad genérica de construcción y la primera parte de la actividad genérica de despliegue. El software se entrega a los usuarios finales para realizar pruebas beta y la retroalimentación del usuario reporta tanto defectos como cambios necesarios. Además, el equipo de software crea la información de soporte necesaria (por ejemplo, manuales de usuarios, guía de resolución de problemas, procedimientos de instalación) para el lanzamiento. Al final de la fase de transición el incremento de software se convierte en un lanzamiento de software utilizable. Eréndira Miriam Jiménez Hernández Octubre

25 La fase de producción coincide con la actividad de despliegue del proceso genérico. Durante esta fase se monitorea el uso subsiguiente del software, se proporciona el soporte para el ambiente operativo (infraestructura) y se reciben y evalúan los informes de defectos y los requerimientos de cambios Metodologías Ágiles El esquema propuesto por las metodologías tradicionales ha demostrado ser efectivo y necesario en proyectos de gran tamaño (respecto a tiempo y recursos). Sin embargo, este enfoque no resulta ser totalmente adecuado para algunos proyectos actuales donde el entorno del sistema es cambiante y se exige reducir drásticamente los tiempos de desarrollo; en este escenario, nacieron las metodologías ágiles, que en esencia combinan una filosofía y un conjunto de directrices de desarrollo [SOM09]. La filosofía busca la satisfacción del cliente y la entrega temprana del software incremental; equipos de proyectos pequeños y con alta motivación; métodos informales; un mínimo de productos de trabajo y una simplicidad general de desarrollo. Las directrices de desarrollo resaltan la entrega sobre el análisis y el diseño, la comunicación activa y continúa entre los desarrolladores y los clientes. La agilidad es más que una respuesta efectiva al cambio; estimula las estructuras y actitudes de los equipos para que la comunicación (entre los miembros del equipo, los técnicos, la gente de negocios, los ingenieros de software y los clientes) sea menos complicada; resalta la entrega rápida del software; adopta al cliente como una parte del equipo de desarrollo y reconoce que la planeación tiene sus límites en un mundo incierto por lo cual el plan de trabajo debe ser flexible. Todas las metodologías ágiles se ajustan (en menor o mayor proporción) al manifiesto para el desarrollo de software y a los 12 principios señalados en la Alianza Ágil [PRE05]. Entre las metodologías ágiles pueden mencionarse: XP (extreme Programming, Programación Extrema) [BEC99], DSA (Development Software Adaptative, Desarrollo de Software Adaptativo) [HIG99], Scrum [SCR86] y Crystal [COC04]. Las metodologías ágiles, al igual que las metodologías tradicionales poseen ciertas ventajas y desventajas. Algunas de las ventajas es que presentan respuestas rápidas y efectivas al cambio. Tienen un plan de proyecto flexible y presentan una gran simplicidad de manera general en el desarrollo. Eréndira Miriam Jiménez Hernández Octubre

26 Sin embargo, las metodologías ágiles generan poca documentación. Y no hacen uso de métodos formales. En la Tabla 1 se realiza una comparación entre las principales características de las metodologías ágiles con las metodologías tradicionales. Tabla 2.1. Metodologías Ágiles vs. Metodologías Tradicionales [JIM11]. Metodologías Ágiles Basadas en heurísticas provenientes de prácticas de producción de código. Proceso menos controlado, con pocos principios. Pocos artefactos. Pocos roles. Menos énfasis en la arquitectura del software. Metodologías Tradicionales Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo. Proceso mucho más controlado, con numerosas políticas/normas. Más artefactos. Más roles. La arquitectura del software es esencial. Producen poca documentación. Producen una gran cantidad de documentación. Fáciles de aprender e implementar. No requieren mucha disciplina. Especialmente preparados para cambios durante el proyecto. No existe contrato tradicional o al menos es bastante flexible. Difíciles de aprender e implementar. Requieren mucha disciplina. Cierta resistencia a los cambios. Existe un contrato prefijado XP XP, por sus siglas en inglés, Programación Extrema, es el proceso ágil que más se utiliza en México (véase Anexo 1); el trabajo fundamental sobre XP fue publicado por Kent Beck, en XP se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad; considera que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. La Programación Extrema se basa en 12 principios básicos [BEC99] agrupados en cuatro categorías: Eréndira Miriam Jiménez Hernández Octubre

27 Retroalimentación a escala fina. o o o o El principio de pruebas: consiste en establecer un período de pruebas de aceptación del programa (llamado también período de caja negra), donde se definirán las entradas al sistema y los resultados esperados de estas entradas. XP recomienda automatizar estas pruebas para poder hacer varias simulaciones del sistema en funcionamiento. Proceso de planificación: en este principio, el usuario tendrá que escribir sus necesidades, definiendo las actividades que realizará el sistema, con esto se creará un documento llamado Historias del usuario. Se consideran suficientes entre 20 y 80 historias (todo dependiendo de la complejidad del problema) para formar el Plan de Liberación, el cual define de forma específica los tiempos de entrega de la aplicación para recibir retroalimentación por parte del usuario. Por regla general, cada una de las Historias del usuario suele necesitar de una a tres semanas de desarrollo. El cliente como parte del equipo: el cliente tiene la facultad de determinar los requerimientos, definir la funcionalidad, señalar las prioridades y responder preguntas de los programadores. Esta fuerte interacción cara a cara con el programador disminuye el tiempo de comunicación y la cantidad de documentación, junto con los altos costes de su creación y mantenimiento; razones por las cuales el cliente o el representante del cliente debe estar con el equipo de trabajo durante toda la realización del proyecto. Programación en parejas: es un concepto clave durante la actividad de codificación; XP recomienda que dos personas trabajen juntas en una misma computadora para crear el código de una historia. Esto es un mecanismo de resolución de problemas en tiempo real ( dos cabezas piensan mejor que una ) y el aseguramiento de la calidad en las mismas condiciones. Proceso continuo en lugar de por lotes. o o Integración continua: este principio permite al equipo hacer un rápido progreso implementando las nuevas características del software, en lugar de crear builds (o versiones) estables de acuerdo a un cronograma establecido. Los equipos de programadores XP pueden reunir su código y reconstruir el sistema varias veces al día, esto reduce los problemas de integración comunes en proyectos largos y estilo cascada. Refactorización: permite mejorar el diseño del sistema durante todo el proceso de desarrollo a los programadores XP, ellos evalúan continuamente el diseño y recodifican lo necesario, la finalidad es mantener un sistema enfocado a la minimización del código duplicado y/o ineficiente. Eréndira Miriam Jiménez Hernández Octubre

28 o Entregas pequeñas: este principio consiste en colocar un sistema en producción, el cual se actualiza de forma rápida y constante permitiendo que el producto sea evaluado en un ambiente real. Entendimiento compartido. o o Diseño simple: se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni más ni menos. Este proceso permite eliminar redundancias y rejuvenecer los diseños obsoletos. Metáfora: empleada por los programadores al inicio del proyecto, y se utiliza en la creación de las historias y las tarjetas CRC (Class Responsibility- Collaboration, Clase Responsabilidad-Colaboración). XP centra su construcción en historias, que son breves descripciones de una función de un sistema, en lugar de los tradicionales diagramas y modelos UML. Las tarjetas CRC ayudan a definir actividades durante el diseño del sistema. Cada tarjeta representa una clase en el paradigma de programación orientado a objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases (cómo se comunica con ellas). De esta manera la metáfora se utiliza como un recurso para describir los requerimientos del sistema. o o Propiedad colectiva del código: el principio señala que se debe generar un código con propiedad compartida; nadie es el propietario de nada, todos son el propietario de todo. Este método difiere en mucho a los métodos tradicionales en los que un programador posee un conjunto de código; XP señala que mientras haya más gente trabajando en un módulo, menos errores aparecerán. Estándar de codificación: es necesario definir las reglas para escribir y documentar el código desarrollado por diferentes equipos o personas; de tal manera que el código en el sistema se vea como si hubiera estado escrito por una sola persona. Bienestar del programador. o La semana de 40 horas: XP sostiene que los programadores cansados escriben código de menor calidad, por lo que es necesario minimizar las horas extras y mantener a los programadores frescos, de esta manera generarán código de mayor calidad; por lo cual XP sugiere que los programadores no laboren más de 40 horas a la semana. Eréndira Miriam Jiménez Hernández Octubre

29 XP está organizado como cuatro actividades del marco de trabajo (planeación, diseño, codificación y pruebas), tal como se puede observar en la Figura Scrum Figura 2.2. Etapas de XP [PRE05] Scrum o también conocida como Melé, es una metodología ágil que define un conjunto de prácticas y roles. Fue propuesta en 1986 por Hirotaka Takeuchi e Ikujiro Nonaka [SCR86]. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos) y el Team que incluye a los desarrolladores. Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Eréndira Miriam Jiménez Hernández Octubre

30 Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint. Además durante un sprint, se deben realizar las Reuniones de Melé. Estas son reuniones cortas (por lo general de 15 minutos) y están presentes todos los miembros del equipo. Existen 3 preguntas que plantean y responden todos los miembros: 1. Qué se realizó desde la última reunión? 2. Cuáles son los obstáculos se encontraron? 3. Qué se espera lograr para la siguiente reunión del equipo? El ScrumMaster, preside la reunión y evalúa las respuestas de cada persona. Cada reunión de Melé ayuda al equipo a descubrir problemas potenciales tan pronto como sea posible. Estas reuniones diarias también conducen a la socialización del conocimiento y, por ende, a promover una estructura con organización propia (véase Figura 2.3). Scrum permite la creación de equipos auto organizado impulsando la co-localización de todos los miembros del equipo y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto. Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn) y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes. Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras, hasta paquetes de software. Eréndira Miriam Jiménez Hernández Octubre

31 Figura 2.3. Proceso de Scrum [SCR86] Metodologías Híbridas Como se puede observar, existen una gran diversidad de metodologías; sin embargo, todas ellas caen dentro de alguna de las dos clasificaciones mencionadas: ágiles o tradicionales. Así que partiendo del significado de la palabra híbrido, según el Diccionario de la Real Academia Española [RAE01]: Se dice de todo lo que es producto de elementos de distinta naturaleza. Las metodologías híbridas pretenden retomar las ventajas de las metodologías existentes, de tal forma que sean una combinación de las mejores prácticas descritas en cada una de ellas. Dentro las metodologías híbridas existentes se puede mencionar a EssUP (Essential Unified Process, Proceso Esencial Unificado) como la pionera [JAC10] EssUP EssUP es una metodología creada por Ivar Jacobson en el 2010, basada en el UP, los métodos ágiles y la madurez de procesos [JAC10]. EssUP intenta ser ágil porque no pretende imponer un proceso específico, además toma en cuenta que es necesario tener flexibilidad y respuestas rápidas ante los cambios; pero, si deja en claro que es necesario documentar y modelar en UML, con lo cual retoma una importante característica de las metodologías tradicionales orientadas a objetos. Por consiguiente es considerada una metodología híbrida conceptualmente, ya que en la práctica el equipo de desarrollo de software que pretenda utilizar esta metodología debe Eréndira Miriam Jiménez Hernández Octubre

32 seleccionar el modelo de ciclo de vida de desarrollo de software que mejor se adapte a sus necesidades, asignar los roles que crean convenientes y seleccionar las mejores prácticas. Con lo cual se presenta un problema que podría considerarse una desventaja de EssUp, se necesita experiencia y conocimiento suficiente para saber elegir las mejores prácticas dentro de la Ingeniería de Software y aplicarlas de manera adecuada en cada proyecto de software. EssUP presenta una nueva tendencia en metodologías para desarrollo de software, ya que intenta retomar algunas ventajas de las metodologías tradicionales y de las ágiles, convirtiéndola en la primera metodología considerada híbrida. 2.3 Norma Mexicana NMX-I-055-NYCE Esta norma está incluida dentro de las Normas Mexicanas para el área de Tecnología de la Información y es empleada en Ingeniería de Software para evaluar la Calidad de Producto (se utiliza para medir la calidad de las metodologías porque son un producto); está basada en la Norma Internacional ISO/IEC : 2001 [ISO01]. Esta Norma Mexicana describe un modelo para la calidad del producto constituido por dos partes (véase Figura 2.4): 1. Calidad interna y externa. 2. Calidad en uso. Figura 2.4. Modelo para la calidad del producto [NYC06]. La primera parte del modelo especifica seis características para la calidad interna y externa, las cuales están subdivididas a la vez en subcaracterísticas. Estas subcaracterísticas se manifiestan externamente cuando el producto se usa y son el resultado de los atributos internos del mismo. Eréndira Miriam Jiménez Hernández Octubre

33 La segunda parte del modelo especifica cuatro características de la calidad en uso, pero no elabora el modelo para la calidad en uso a un nivel inferior al de características, porque la calidad en uso es el efecto percibido por el usuario como el resultado de la combinación de las seis características de calidad del producto Modelo de Calidad Interna y Externa. Los atributos de calidad del producto se clasifican en seis características (funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad), las cuales son a su vez subdivididas en subcaracterísticas (véase Figura 2.5). Las subcaracterísticas se pueden medir mediante métricas internas o externas. Cada una de las características y subcaracterísticas se encuentran definidas en la norma. Figura 2.5. Modelo para la calidad interna y externa [NYC06] Modelo de Calidad para la Calidad en Uso. Los atributos de calidad en uso se clasifican en cuatro características: efectividad, productividad, seguridad y satisfacción (véase Figura 2.6). Estas características al igual que las de Calidad Interna y Externa, se encuentran definidas en la NMX-I-055-NYCE. Eréndira Miriam Jiménez Hernández Octubre

34 Figura 2.6. Modelo para la calidad en uso [NYC06]. 2.4 Resumen El desarrollo de software requiere de hacer uso de metodologías, las cuales proveen una guía al equipo de desarrollo para crear un sistema con calidad. Por lo que resulta importante conocer qué tipo de metodologías existen, para qué tipo de proyectos están diseñadas y cómo deben de aplicarse en el ambiente real de desarrollo. Eréndira Miriam Jiménez Hernández Octubre

35 3 Metodología Propuesta: META 3.1 Introducción Como resultado de la investigación realizada surge META (MEtodología Tradicional y Ágil), una metodología híbrida para desarrollo de proyectos de software. META fue creada a partir de un estudio realizado con empresas mexicanas desarrolladoras de software [JIM12]. Por esta razón, META se diseñó tomando en cuenta las necesidades actuales de esas empresas mexicanas; sin embargo puede aplicarse en empresas de otros países en las cuales se desee desarrollar proyectos de software que cumplan con las características para las cuales es ideal utilizar META. META en una metodología que combina algunas prácticas existentes dentro de las metodologías RUP (Rational Unified Process, Proceso Unificado de Racional), XP (extreme Programming, Programación Extrema) y Scrum; por lo cual es un híbrido entre lo tradicional y lo ágil. 3.2 Características de META META es una metodología diseñada para desarrollar proyectos de software con las siguientes características: Proyectos de desarrollo de aplicaciones Web (en el Apéndice 1 se pueden ver las características de una aplicación Web). Proyectos que se desarrollen en un lapso de 2 a 6 meses. Equipos de desarrollo conformados a lo más por 10 integrantes (sin contar a los usuarios y al cliente). 3.3 Requerimientos y Requisitos para el Uso de META Es necesario contar y cumplir con los tres siguientes requerimientos y requisitos para hacer uso de META: 1. Requerimientos Materiales: Papel rotafolio. Notas adhesivas. Cinta adhesiva. Marcadores de colores. Carpetas o Folders. Hojas blancas. Eréndira Miriam Jiménez Hernández Octubre

36 2. Requisitos de Conocimientos Previos: Saber realizar Diagramas en UML (Unified Modeling Language, Lenguaje Unificado de Modelado) [OMG11]. Saber realizar Diagramas Entidad-Relación [ROS08]. Saber realizar Estimaciones de Costos. Saber realizar Prototipos de software. Saber programar en el lenguaje a utilizar con META. 3. Requisitos de la Empresa: Seleccionar proyectos de desarrollo de software que cumplan con las características para las cuales es ideal utilizar META (véase Sección 3.2) Tener los equipos de cómputo necesarios para que cada integrante del equipo META pueda desarrollar su función adecuadamente. Proporcionar al equipo de desarrollo un espacio de trabajo dentro de las instalaciones de la empresa que les permita estar co-localizados. 3.4 Capacitación para el uso de META Para utilizar META es necesario contar con los requerimientos y conocer: 1. Los roles que deben existir. 2. Los principios metodológicos de META. 3. El proceso de desarrollo de META. 3.5 Roles en META En META se plantea que deben existir los siguientes roles o papeles dentro del equipo de desarrollo, véase Tabla 3.1: Tabla 3.1. Roles en META ROL Cliente Líder del proyecto DESCRIPCION Especifica los requerimientos y es quién financia el proyecto de software. Se encarga de buscar nuevos proyectos, recopilar la información necesaria para establecer los requerimientos y negociar los proyectos; por lo que es el integrante del equipo de desarrollo que tiene más relación con el cliente/usuarios, así que debe tener facilidad para comunicarse con ellos en términos que el cliente/usuarios comprendan. Es además, el intermediario entre el cliente y el administrador del proyecto, por lo cual debe de saber cómo se realiza el Eréndira Miriam Jiménez Hernández Octubre

37 Administrador del proyecto Programadores Probador Documentador META (MEtodología Tradicional y Ágil), una metodología híbrida para software también. Debe de tener la habilidad de unir ideas, personas y recursos; así como tener facilidad para la toma de decisiones. Se encarga de coordinar a los programadores, al probador y al documentador. Además organiza las reuniones necesarias para analizar los requerimientos, realizar el diseño, el plan de proyecto y las pruebas. Debe acompañar al líder del proyecto en las reuniones con el cliente. Son los responsables de codificar el diseño. Se encarga de realizar las pruebas en todo momento. Es decir, verifica que se realizan las actividades de manera adecuada en cada fase del proceso de desarrollo de software. Además deberá cumplir con la tarea de asegurar la calidad, haciendo uso del Ciclo y los 14 Principios de Deming. Su función principal es generar los documentos que respalden y documenten lo que se va generando a lo largo del proceso de software. Usuarios finales Son las personas que interactúan con el software una vez que se libera para su uso productivo. META retoma una importante característica de las metodologías ágiles: incluir a los usuarios finales y al cliente como parte del equipo de desarrollo. Esto ayuda en gran medida a lograr el éxito del proyecto, ya que son ellos quienes saben lo que quieren, por lo tanto, se debe tener el cuidado de propiciar un ambiente de confianza y colaboración con ellos. Si el equipo de desarrollo es menor a 5 integrantes, es decir que no se pueda asignar al menos un rol a cada integrante (Líder del Proyecto, Administrador del Proyecto, Programador, Probador y Documentador), pueden hacerse las adecuaciones necesarias para que una persona cumpla con uno o dos roles; aunque se sugiere que una persona sea destinada a cumplir sólo un rol. De manera general, se puede resumir el flujo de comunicación entre los integrantes del equipo de desarrollo tal como se muestra en la Figura 3.1. Eréndira Miriam Jiménez Hernández Octubre

38 Figura 3.1. Roles en META * * El diagrama utilizado para representar el flujo de comunicación es un diagrama con simbología propia, así como otros diagramas utilizados en este capítulo, en caso contrario llevan la referencia respectiva a su autor. 3.6 Principios Metodológicos de META Para poder utilizar adecuadamente META se deben conocer los siguientes principios metodológicos: Hacer uso de papel rotafolio. Es un papel bond de medidas 63.5cm x 77.47cm aproximadamente. Es usado como una herramienta de comunicación para aplicarse durante el trabajo cara a cara porque facilita la interacción y el debate. Se puede utilizar en exposiciones, con explicaciones dialogadas u observaciones, así como en la presentación de resultados de un trabajo en equipo o para realizar lluvias de ideas temáticas. Es conveniente el uso de este tipo de papel porque tiene un bajo costo, es fácil de transportar, propicia la participación en un grupo y se pueden retomar los contenidos debido a la permanencia del mensaje, lo cual no se asegura si se escribe en un pizarrón por ejemplo. Eréndira Miriam Jiménez Hernández Octubre

39 Además se sugiere hacer uso de marcadores o plumones de distintos colores para tratar de proporcionar mayor presentación a lo escrito en el rotafolio. Realizar lluvias de ideas durante las juntas. Esta técnica consiste en la reunión del equipo de trabajo para intentar descubrir cuál es el problema, cuál es la causa de un problema y cómo resolverlo; a través de la participación de cada miembro con sus ideas. El proceso que se sigue para esta técnica es el siguiente: a) Seleccionar el tema. b) Generar la lluvia de ideas a través de la participación de los involucrados. c) Realizar el análisis de las ideas. d) Seleccionar las mejores ideas. Para obtener mejores resultados se recomienda seguir las siguientes reglas: 1) El líder debe analizar con anterioridad los puntos a tratar, de manera que presente sólo opciones a los demás. 2) Todos los presentes en la reunión deben participar. 3) Se deben anotar las ideas en el papel rotafolio. 4) Se deben analizar las ideas; sin embargo, el líder del proyecto será quien tome las decisiones finales tomando en cuenta la experiencia de los demás miembros del equipo. Hacer uso del Ciclo de Deming [DEM90] para la Gestión de Riesgos durante todo el proceso de desarrollo de META. Durante el proceso de desarrollo del software, se tendrán que prevenir riesgos y eliminarlos, resultando conveniente hacer uso del Ciclo de Deming, véase Figura 3.2. Como parte de los documentos que se deben elaborar, se tiene un apartado de documentación para la gestión de riesgos y problemas, mismos que se explicarán en la sección del Proceso de Desarrollo de META; sin embargo aquí se describe el método adecuado para realizar dichas gestiones. Eréndira Miriam Jiménez Hernández Octubre

40 Figura 3.2. Ciclo de Deming [DEM90] En el Ciclo de Deming se identifican 4 actividades primordiales, las cuales se describen a continuación: Planear: se requiere identificar los objetivos y procesos que se requieren mejorar; para después recopilar los datos para profundizar en el conocimiento del proceso. Posteriormente se deben analizar e interpretar los datos, establecer los objetivos de mejora, detallar las especificaciones de los resultados esperados y definir los procesos necesarios para conseguir estos objetivos. Hacer: Implementar los procesos necesarios para llevar a cabo el plan elaborado con anterioridad. Verificar: Comprobar que se implementaron las cosas según lo planeado. Actuar: Documentar el ciclo para tener presente cómo mejorar la próxima vez. Considerar los 14 Principios de Calidad de Deming [DEM90], para garantizar calidad en el proceso y en el producto de software. Los 14 principios han sido adecuados para ser empleados en una empresa de desarrollo de software. La razón por la cual se consideró el Ciclo y los Principios de Deming como una opción viable para ser incluida en META, fue porque la mayoría de los estándares internacionales de calidad adoptan el Sistema Deming como punto de referencia en sus propuestas; esto se determinó después de realizar una estancia de investigación Eréndira Miriam Jiménez Hernández Octubre

41 con el Dr. Francisco Ortiz Zaragoza en la Universidad Politécnica de Cartagena, en España. Los 14 principios se describen a continuación: 1) Crear constancia, con la finalidad de ser más competitivos y permanecer en el mercado. En este punto se tratan las mejoras a la compañía, como son el tener y hacer uso de tecnología actualizada, contar con equipo de buena calidad, procesos y procedimientos adecuados para la elaboración del producto de software; con lo cual se garantizará la permanencia en el mercado de la empresa. 2) Comprender y adoptar la nueva filosofía. La calidad debe convertirse en la nueva cultura. Ante el reto de la competitividad internacional, es necesario que todos los miembros del equipo tengan consciencia de eliminar errores, defectos, mala calidad y malas prácticas. De esta manera, un servicio confiable reduce los costos, las demoras y los errores. Para el logro de la calidad se tendrá que concientizar a todos los integrantes del equipo de desarrollo. Ya que la calidad debe ser compromiso de todos. 3) Terminar con la dependencia de la inspección masiva. Es necesario acabar con las inspecciones de volúmenes grandes de información o de grandes módulos, ya que esto resulta costo y no necesariamente es acertado. A cambio de esto, es necesario concientizar a los integrantes del equipo que deben obtener desde un principio pequeños módulos o productos de software de calidad. 4) Terminar con la práctica de hacer negocios con base al precio. Antes de adquirir hardware o software, se debe asegurar que cuentan con la calidad que se requiere, en lugar de comprar porque tienen el menor costo. 5) Encontrar y resolver problemas para mejorar el sistema de desarrollo de software, constante y permanentemente. Es necesario que el equipo esté preparado para afrontar los problemas que se presenten día a día. Con esta pauta, se analizarán y se detectarán los Eréndira Miriam Jiménez Hernández Octubre

42 problemas, para su corrección y prevención. Para lo cual se debe hacer uso del Ciclo de Deming descrito anteriormente. 6) Instruir métodos modernos de adiestramiento. Es de suma importancia que a los integrantes del equipo se les destine recursos, tanto de tiempo como de dinero, para que puedan adquirir un adiestramiento adecuado y les sea más sencillo acoplarse a la empresa de desarrollo de software y al equipo con el cual trabajarán. 7) Adoptar e implantar el liderazgo. Dentro de la empresa como dentro del equipo de desarrollo, debe existir el liderazgo. Un buen líder (como lo define Deming), crea confianza e impulsa a los demás para que busquen nuevas maneras para hacer las cosas. Además dirige los cambios, busca modelos de acción para hacer lo que está bien y opera con los recursos emocionales de los integrantes del equipo, con valores, compromisos y aspiraciones. Es decir, un buen líder hace sentir a los demás integrantes un alto nivel de realización, mostrándoles cómo contribuye su trabajo a la realización de las metas del proyecto; con lo cual se estimula la necesidad humana de: sentirse importante, diferente y útil. 8) Expulsar el miedo dentro del equipo de desarrollo. Los integrantes necesitan trabajar en un ambiente estable y seguro, que ofrezca apoyo y no amenazas. Por esta razón, se deberá tener cuidado en los siguientes aspectos para evitar el temor: a) Posibilidad de perder el empleo b) Posibilidad de sufrir algún daño físico. c) Evaluación del desempeño. d) Fracasos en la capacitación. e) Mala supervisión. f) Falta de definiciones operacionales. 9) Romper las barreras entre los integrantes del equipo. Es muy importante que todos los integrantes del equipo de desarrollo estén interrelacionados entre sí, que formen un equipo con un fin común, que es el de producir un producto de software de excelente calidad y entregarlo a Eréndira Miriam Jiménez Hernández Octubre

43 tiempo. Por lo cual es importante quitar las barreras que impiden la comunicación. Los factores más comunes de las barreras son: a) Mala comunicación o ausencia de la comunicación b) Desconocimiento de las metas c) Decisiones o políticas confusas y que requieren interpretación d) Cuotas y normas de trabajo e) Celos por posiciones y salarios f) Problemas interpersonales Es importante tener en cuenta que la duración y el éxito de una empresa y/o equipo de desarrollo, estará condicionado por las buenas relaciones, la comunicación y la confianza que se les profese. Para lo cual, se tiene que cambiar la actitud de los miembros del equipo o de la empresa; entendiéndose que todos deben estar abiertos a la comunicación y dar apoyo completo para realizar las tareas necesarias. 10) Eliminar las metas numéricas. Las metas numéricas que se fijan para los integrantes del equipo de desarrollo, sin ofrecer una guía que lleve a la meta, son contra producentes, ya que generan frustración y resentimiento. Algunos ejemplos de carteles y metas numéricas son: a) Hacerlo bien la primera vez. b) Nuestro trabajo es la calidad. c) Incrementar las ventas en un 10% el siguiente año. 11) Eliminar estándares de trabajo que estipulen cantidad y no calidad. Las cuotas numéricas sólo toman en cuenta los números, no la calidad ni los métodos. Porque estimulan a la gente para que produzcan cantidad en vez de calidad. Por lo que no se debe recurrir a las cuotas cuando lo que se requiere es liderazgo. Los objetivos no son malos; el problema es cuando se fijan objetivos sin proveer los medios para alcanzarlos, o cuando los mismos son utilizados con criterio de inspección final. Eréndira Miriam Jiménez Hernández Octubre

44 Un estándar de trabajo apropiado definirá lo que es y lo que no es aceptable en cuanto a calidad, para lo cual sugiere Deming que se estudie el trabajo y que se definan los límites del trabajo. 12) Eliminar las barreras que impiden al integrante del equipo estar orgulloso de su labor. Es importante que los miembros del equipo de desarrollo estén enterados de cuál trabajo es aceptable y cuál no; ya que esto los motivará a hacer las cosas bien y les permite hacer una autoevaluación. Para esto es recomendable: a) Proporcionar a los integrantes del equipo y de la empresa, materiales, herramientas y métodos apropiados. b) Atender las necesidades básicas de los integrantes. c) Cerciorarse de que los integrantes entienden la gran importancia que desempeñan dentro del proceso de desarrollo del software. 13) Educación y entrenamiento. Esto permitirá adaptar a las personas a nuevos proyectos y nuevas responsabilidades. Además, permite la superación, el desenvolvimiento y la confianza del integrante del equipo. 14) Crear una estructura que impulse día a día los trece puntos anteriores. Esto se requiere para tener un proceso de calidad que genere productos de software que satisfagan las expectativas del cliente, cumplan lo pactado en tiempo y recursos. Por lo que con dichos principios se guían las actividades dentro del proceso de desarrollo de META. 3.7 Proceso de Desarrollo de META Dentro de META se tienen 4 fases o etapas principales (Planteamiento, Preparación, Construcción e Implantación), tal como se puede apreciar en la Figura 3.3, las cuales se describirán más adelante: Eréndira Miriam Jiménez Hernández Octubre

45 Figura 3.3. Proceso de desarrollo de META El proceso de manera general se puede comparar con lo que pasa en una carrera de obstáculos, en donde todo el equipo de desarrollo corre como un solo individuo hasta llegar Eréndira Miriam Jiménez Hernández Octubre

46 a la meta; haciendo la analogía, cada una de las etapas son obstáculos que el equipo debe pasar. Pero, a diferencia de lo que pasa en una carrera de obstáculos, si no se puede brincar una etapa en un primer intento, existe un camino alternativo que permite realizar una serie de iteraciones para poder estar preparados y saltar para continuar con la siguiente fase Planteamiento En esta etapa se deben cumplir los siguientes objetivos: Definir los requerimientos del proyecto que se va a desarrollar. Esto se hace en constante comunicación entre el líder y el cliente a través de reuniones con lluvias de ideas. Es recomendable que el administrador del proyecto también esté presente para poder brindar una asesoría técnica en caso de ser necesario. Las propuestas o ideas deben escribirse en un papel rotafolio de tal manera que sea visible para todos los involucrados lo que se plantea; se sugiere que el líder sea quien escriba las ideas, aunque si el cliente o el administrador desean escribir personalmente algo es válido. Para esta actividad en particular, se sugiere que se le dé al cliente la oportunidad de expresar sus ideas, porque en muchas de las ocasiones los desarrolladores creen saber lo que él cliente quiere y se puede cometer el error de diseñar algo que no se desea. Después de escuchar lo que el cliente desea, se deben elaborar los Diagramas de Casos de Uso tal como los plantea UML [OMG11], los cuales describirán la funcionalidad del sistema a desarrollar para corroborar así, que se comprendió lo que el cliente desea. Además, se debe(n) elaborar el Diagrama de Interfaz-Navegación de la(s) ventana(s) principal(es), con la intención de tener una referencia del diseño que tendrán las demás ventanas. Estos diagramas permitirán al cliente visualizar el software, por lo que son de gran ayuda al momento de definir lo requerimientos. Una pauta a considerar para saber cuántas ventanas deben dibujarse a través de un Diagrama de Interfaz-Navegación, es tomando en cuenta el número de actores diferentes o usuarios del sistema. Por ejemplo se pueden ver los Diagramas de Interfaz-Navegación de las Figuras 3.4, 3.5 y 3.6, en ellas se muestran los elementos que incluirán la ventana principal o la página de inicio del sitio, y se indican hacia a dónde se dirigen los botones con Eréndira Miriam Jiménez Hernández Octubre

47 números encerrados en círculos de color verde; este ejemplo muestra cómo deben de especificarse estos diagramas en el papel rotafolio. Figura 3.4. Ejemplo de Diagrama Interfaz-Navegación de la página de inicio del sitio. Figura 3.5. Ejemplo de Diagrama Interfaz-Navegación de la página principal de los Clientes. Eréndira Miriam Jiménez Hernández Octubre

Metodologías híbridas para desarrollo de software: una opción factible para México Eréndira Miriam Jiménez Hernández y Sandra Dinora Orantes Jiménez

Metodologías híbridas para desarrollo de software: una opción factible para México Eréndira Miriam Jiménez Hernández y Sandra Dinora Orantes Jiménez Revista Digital Universitaria 1 de enero 2012 Volumen 13 Número 1 ISSN: 1067-6079 Metodologías híbridas para desarrollo de software: una opción factible para México Eréndira Miriam Jiménez Hernández y

Más detalles

DESARROLLO AGIL ING. MA. MARGARITA LABASTIDA ROLDÁN

DESARROLLO AGIL ING. MA. MARGARITA LABASTIDA ROLDÁN DESARROLLO AGIL ING. MA. MARGARITA LABASTIDA ROLDÁN CONTENIDO Qué es un proceso agil Proceso Ágil Otros modelos ágiles de proceso Programación extrema Desarrollo adaptativo de software Método de desarrollo

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

Más detalles

GERENCIA DE INTEGRACIÓN

GERENCIA DE INTEGRACIÓN GERENCIA DE INTEGRACIÓN CONTENIDO Desarrollo del plan Ejecución del plan Control de cambios INTRODUCCIÓN La gerencia de integración del proyecto incluye los procesos requeridos para asegurar que los diversos

Más detalles

El Proceso Unificado Rational para el Desarrollo de Software.

El Proceso Unificado Rational para el Desarrollo de Software. Instituto de Electrónica y Computación El Proceso Unificado Rational para el Desarrollo de Software. Carlos Alberto Fernández y Fernández Huajuapan de León, Oaxaca 26 de octubre de 2000 Objetivo Proporcionar

Más detalles

Actividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos.

Actividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos. Apéndice C. Glosario A Actividades de coordinación entre grupos. Son dinámicas y canales de comunicación cuyo objetivo es facilitar el trabajo entre los distintos equipos del proyecto. Actividades integradas

Más detalles

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual Introducción Algunas de las personas que trabajan con SGBD relacionales parecen preguntarse porqué deberían preocuparse del diseño de las bases de datos que utilizan. Después de todo, la mayoría de los

Más detalles

Norma ISO 9001:2015. Cuáles son los cambios presentados en la actualización de la Norma?

Norma ISO 9001:2015. Cuáles son los cambios presentados en la actualización de la Norma? Norma ISO 9001:2015 Cuáles son los cambios presentados en la actualización de la Norma? Norma ISO 9001:2015 Contenido Introducción Perspectiva de la norma ISO 9001 Cambios de la norma ISO 9001 Cambios

Más detalles

DESARROLLO DE SOFTWARE DEFINICIÓN GENERAL DEL PROCESO GABY LORENA GUERRERO LEYDI ROCIO ERAZO PABLO FELIPE MIRANDA WALTER ALEXIS ANTE

DESARROLLO DE SOFTWARE DEFINICIÓN GENERAL DEL PROCESO GABY LORENA GUERRERO LEYDI ROCIO ERAZO PABLO FELIPE MIRANDA WALTER ALEXIS ANTE DESARROLLO DE SOFTWARE DEFINICIÓN GENERAL DEL PROCESO GABY LORENA GUERRERO LEYDI ROCIO ERAZO PABLO FELIPE MIRANDA WALTER ALEXIS ANTE UNIVERSIDAD DEL CAUCA FACULTAD DE INGENIERÍA ELECTRÓNICA Y TELECOMUNICACIONES

Más detalles

MODELOS DE CALIDAD EN EL DESARROLLO DE SOFTWARE

MODELOS DE CALIDAD EN EL DESARROLLO DE SOFTWARE MODELOS DE CALIDAD EN EL DESARROLLO DE SOFTWARE INTRODUCCIÓN Los Modelos de Calidad son herramientas que guían a las Organizaciones a la Mejora Continua y la Competitividad dando les especificaciones de

Más detalles

Propiedad Colectiva del Código y Estándares de Codificación.

Propiedad Colectiva del Código y Estándares de Codificación. Propiedad Colectiva del Código y Estándares de Codificación. Carlos R. Becerra Castro. Ing. Civil Informática UTFSM. Introducción. n. En este trabajo se presentan específicamente dos prácticas de XP: Collective

Más detalles

El proceso unificado en pocas palabras

El proceso unificado en pocas palabras El Proceso Unificado de Desarrollo de Software Ivar Jacobson Grady Booch James Rumbaugh Addison Wesley Resumen Capítulo 1. El proceso unificado: dirigido por casos de uso, centrado en la arquitectura,

Más detalles

Unidad VI: Supervisión y Revisión del proyecto

Unidad VI: Supervisión y Revisión del proyecto Unidad VI: Supervisión y Revisión del proyecto 61. Administración de recursos La administración de recursos es el intento por determinar cuánto, dinero, esfuerzo, recursos y tiempo que tomará construir

Más detalles

Guía breve para la. administración de la capacitación en las. entidades públicas. Versión abreviada del Manual para la. entidades públicas

Guía breve para la. administración de la capacitación en las. entidades públicas. Versión abreviada del Manual para la. entidades públicas Guía breve para la administración de la en las entidades públicas Versión abreviada del Manual para la administración de la en las entidades públicas Noviembre 2012 sentando bases para una gestión pública

Más detalles

Fundamentos de Ingeniería del Software. Capítulo 8. Introducción a los métodos de desarrollo de software

Fundamentos de Ingeniería del Software. Capítulo 8. Introducción a los métodos de desarrollo de software Fundamentos de Ingeniería del Software Capítulo 8. Introducción a los métodos de desarrollo de software Introducción a los métodos de desarrollo de software. Estructura 1. Definición. 2. Beneficios. 3.

Más detalles

Caso práctico de Cuadro de Mando con Tablas Dinámicas

Caso práctico de Cuadro de Mando con Tablas Dinámicas 1 Caso práctico de Cuadro de Mando con Tablas Dinámicas Luis Muñiz Socio Director de SisConGes & Estrategia Introducción Hay una frase célebre que nos permite decir que: Lo que no se mide no se puede controlar

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

Para llegar a conseguir este objetivo hay una serie de líneas a seguir:

Para llegar a conseguir este objetivo hay una serie de líneas a seguir: INTRODUCCIÓN La Gestión de la Calidad Total se puede definir como la gestión integral de la empresa centrada en la calidad. Por lo tanto, el adjetivo total debería aplicarse a la gestión antes que a la

Más detalles

INGENIERÍA DEL SOFTWARE

INGENIERÍA DEL SOFTWARE INGENIERÍA DEL SOFTWARE Sesión No. 2 Nombre: Procesos de ingeniería del software INGENIERÍA DEL SOFTWARE 1 Contextualización La ingeniería de software actualmente es muy importante, pues con los avances

Más detalles

GUÍA TÉCNICA PARA LA DEFINICIÓN DE COMPROMISOS DE CALIDAD Y SUS INDICADORES

GUÍA TÉCNICA PARA LA DEFINICIÓN DE COMPROMISOS DE CALIDAD Y SUS INDICADORES GUÍA TÉCNICA PARA LA DEFINICIÓN DE COMPROMISOS DE CALIDAD Y SUS INDICADORES Tema: Cartas de Servicios Primera versión: 2008 Datos de contacto: Evaluación y Calidad. Gobierno de Navarra. evaluacionycalidad@navarra.es

Más detalles

Bloque I: Conceptos básicos y fundamentos de la Dirección de Proyectos.

Bloque I: Conceptos básicos y fundamentos de la Dirección de Proyectos. 1.- Objeto. Presentar y fomentar la existencia de metodologías en Dirección de Proyectos o Project Management a través de experiencias, documentos, normas y estándares nacionales e internacionales. Ofrecer

Más detalles

ENTRENAMIENTO Y DESARROLLO DEL PERSONAL OBJETIVOS Los principales objetivos del entrenamiento son: 1.- Preparar al personal para la ejecución inmediata de las diversas tareas del cargo. 2.- Proporcionar

Más detalles

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

Más detalles

Proceso Unificado de Rational

Proceso Unificado de Rational RUP: El Proceso Unificado de Rational XP: Programacion Extrema EAP: Computación Científica Ciencia de la Computación V Prof. Oscar Brnito Pacheco Proceso Unificado de Rational Orígenes Modelo original

Más detalles

Qué es Scrum? Basado en el texto Explicando Scrum a mi abuela de Jorge Serrano - MVP Visual Developer - Visual Basic

Qué es Scrum? Basado en el texto Explicando Scrum a mi abuela de Jorge Serrano - MVP Visual Developer - Visual Basic Qué es Scrum? Basado en el texto Explicando Scrum a mi abuela de Jorge Serrano - MVP Visual Developer - Visual Basic http://geeks.ms/blogs/jorge/archive/2007/05/09/explicando-scrum-a-mi-abuela.aspx Por

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para

Más detalles

En este capítulo se describe las herramientas, así como los procesos involucrados en el análisis y desarrollo de sistemas de información, por otro

En este capítulo se describe las herramientas, así como los procesos involucrados en el análisis y desarrollo de sistemas de información, por otro CAPITULO 5 TEORIA SOBRE ANALISIS Y DISEÑO DE SISTEMAS DE INFORMACION En este capítulo se describe las herramientas, así como los procesos involucrados en el análisis y desarrollo de sistemas de información,

Más detalles

Metodología básica de gestión de proyectos. Octubre de 2003

Metodología básica de gestión de proyectos. Octubre de 2003 Metodología básica de gestión de proyectos Octubre de 2003 Dentro de la metodología utilizada en la gestión de proyectos el desarrollo de éstos se estructura en tres fases diferenciadas: Fase de Éjecución

Más detalles

Grupo de Trabajo del Tratado de Cooperación en materia de Patentes (PCT)

Grupo de Trabajo del Tratado de Cooperación en materia de Patentes (PCT) S PCT/WG/8/7 ORIGINAL: INGLÉS FECHA: 12 DE MARZ0 DE 2015 Grupo de Trabajo del Tratado de Cooperación en materia de Patentes (PCT) Octava reunión Ginebra, 26 a 29 de mayo de 2015 FORMACIÓN DE EXAMINADORES

Más detalles

LA REVOLUCIÓN DE LOS SISTEMAS DE INFORMACIÓN (S.I.) Introducción PORQUÉ SISTEMAS DE INFORMACIÓN? El Competitivo Entorno de los Negocios

LA REVOLUCIÓN DE LOS SISTEMAS DE INFORMACIÓN (S.I.) Introducción PORQUÉ SISTEMAS DE INFORMACIÓN? El Competitivo Entorno de los Negocios LA REVOLUCIÓN DE LOS SISTEMAS DE INFORMACIÓN (S.I.) Introducción Tanto empresas grandes como pequeñas usan Sistemas de Información y Redes para realizar una mayor proporción de sus actividades electrónicamente,

Más detalles

ISO 17799: La gestión de la seguridad de la información

ISO 17799: La gestión de la seguridad de la información 1 ISO 17799: La gestión de la seguridad de la información En la actualidad las empresas son conscientes de la gran importancia que tiene para el desarrollo de sus actividades proteger de forma adecuada

Más detalles

4.1.1_Reunión de Planificación de Sprint (Sprint Planning Meeting) 4.1.2_Objetivo del Sprint (Sprint Goal) 4.1.4_Revisión de Sprint (Sprint Review)

4.1.1_Reunión de Planificación de Sprint (Sprint Planning Meeting) 4.1.2_Objetivo del Sprint (Sprint Goal) 4.1.4_Revisión de Sprint (Sprint Review) 1_Visión general de SCRUM 2_Teoría de Scrum 3_El Equipo Scrum (Scrum Team) 3.1_El Dueño de Producto (Product Owner) 3.2_El Equipo de Desarrollo (Development Team) 3.3_El Scrum Master 4_Eventos de Scrum

Más detalles

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0 Centro Ideoinformática Universidad de las Ciencias Informáticas Carretera a San Antonio Km 2 ½. Torrens. Boyeros. Ciudad de La Habana. Cuba Teléfono: + 53 (7)

Más detalles

CAPÍTULO 2 IMPORTANCIA DE LA ASIGNATURA OUTSOURCING EN TECNOLOGÍAS DE INFORMACIÓN

CAPÍTULO 2 IMPORTANCIA DE LA ASIGNATURA OUTSOURCING EN TECNOLOGÍAS DE INFORMACIÓN CAPÍTULO 2 IMPORTANCIA DE LA ASIGNATURA OUTSOURCING EN TECNOLOGÍAS DE INFORMACIÓN CAPÍTULO 2 IMPORTANCIA DE LA ASIGNATURA OUTSOURCING EN TECNOLOGÍAS DE INFORMACIÓN 2.1 INTRODUCCIÓN. En este capítulo se

Más detalles

Las 10 preguntas clave sobre la implantación del Cuadro de Mando Luis Muñiz Economista y Consultor de empresas

Las 10 preguntas clave sobre la implantación del Cuadro de Mando Luis Muñiz Economista y Consultor de empresas Las 10 preguntas clave sobre la implantación del Cuadro de Mando Luis Muñiz Economista y Consultor de empresas La herramienta clave para implementar la estrategia y medir los resultados conseguidos Es

Más detalles

Prof. Juan José Díaz Nerio. Foro de Tecnología : Gestión de la Calidad del Software. Domingo 16 Noviembre 2014

Prof. Juan José Díaz Nerio. Foro de Tecnología : Gestión de la Calidad del Software. Domingo 16 Noviembre 2014 Prof. Juan José Díaz Nerio. Foro de Tecnología : Gestión de la Calidad del Software. Domingo 16 Noviembre 2014 Agenda La Crisis del Software Conceptos asociados a Calidad Atributos de Calidad Funciones

Más detalles

Curso: Arquitectura Empresarial basado en TOGAF

Curso: Arquitectura Empresarial basado en TOGAF Metodología para desarrollo de Arquitecturas (ADM) El ADM TOGAF es el resultado de las contribuciones continuas de un gran número de practicantes de arquitectura. Este describe un método para el desarrollo

Más detalles

Figure 16-1: Phase H: Architecture Change Management

Figure 16-1: Phase H: Architecture Change Management Fase H Administración del cambio en la Arquitectura Figure 16-1: Phase H: Architecture Change Management Objetivos Los objetivos de la Fase H son: Asegurarse de que el ciclo de vida de arquitectura se

Más detalles

LOS RETOS DE LA ENSEÑANZA EN LA INGENIERÍA 1

LOS RETOS DE LA ENSEÑANZA EN LA INGENIERÍA 1 LOS RETOS DE LA ENSEÑANZA EN LA INGENIERÍA 1 Horacio Ramírez de Alba* En este escrito se presenta un panorama de la profesión de la ingeniería y su relación con el desarrollo del país, y a partir de ello

Más detalles

2. LOS SISTEMAS DE COSTOS

2. LOS SISTEMAS DE COSTOS 2. LOS SISTEMAS DE COSTOS En el actual desarrollo de las técnicas y sistemas de costos se persiguen tres importantes objetivos: La medición de los costos, la más correcta y precisa asignación de costos

Más detalles

DIAGRAMA DE CLASES EN UML

DIAGRAMA DE CLASES EN UML DIAGRAMA DE CLASES EN UML Mg. Juan José Flores Cueto jflores@usmp.edu.pe Ing. Carmen Bertolotti Zuñiga cbertolotti@usmp.edu.pe INTRODUCCIÓN UML (Unified Modeling Language) es un lenguaje que permite modelar,

Más detalles

COMPETENCIAS BÁSICAS: DIEZ CLAVES

COMPETENCIAS BÁSICAS: DIEZ CLAVES COMPETENCIAS BÁSICAS: DIEZ CLAVES Este documento ha sido elaborado por un amplio grupo de educadores y educadoras de la Comunidad Autónoma de Canarias, pertenecientes a distintos servicios, con el fin

Más detalles

Programa en Microsoft Visual Basic 6.0 para el análisis de riesgos eléctricos en oficinas y centros de cómputo. López Rosales, Juan Carlo.

Programa en Microsoft Visual Basic 6.0 para el análisis de riesgos eléctricos en oficinas y centros de cómputo. López Rosales, Juan Carlo. CAPÍTULO IV PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE 4.1 Concepto del Proceso Unificado de Desarrollo de Software Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar

Más detalles

NORMA ISO 31000 DE RIESGOS CORPORATIVOS

NORMA ISO 31000 DE RIESGOS CORPORATIVOS NORMA ISO 31000 DE RIESGOS CORPORATIVOS La norma ISO 31000 establece principios y guías para el diseño, implementación y mantenimiento de la gestión de riesgos en forma sistemática y transparente de toda

Más detalles

6 Anexos: 6.1 Definición de Rup:

6 Anexos: 6.1 Definición de Rup: 6 Anexos: 6.1 Definición de Rup: Es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo.

Más detalles

La automatización de malos procesos sólo agrava más la ineficiencia" [HAMMER; 90].

La automatización de malos procesos sólo agrava más la ineficiencia [HAMMER; 90]. CAPITULO 1. INTRODUCCION La automatización de malos procesos sólo agrava más la ineficiencia" [HAMMER; 90]. La tecnología en la actualidad avanza a pasos cada vez más grandes y difíciles de rastrear. Tanto

Más detalles

Análisis y cuantificación del Riesgo

Análisis y cuantificación del Riesgo Análisis y cuantificación del Riesgo 1 Qué es el análisis del Riesgo? 2. Métodos M de Análisis de riesgos 3. Método M de Montecarlo 4. Modelo de Análisis de Riesgos 5. Qué pasos de deben seguir para el

Más detalles

INDICADORES. PROBLEMAS ASOCIADOS A SU SELECCIÓN PARA MEDIR SUSTENTABILIDAD Y EFICIENCIA AMBIENTAL

INDICADORES. PROBLEMAS ASOCIADOS A SU SELECCIÓN PARA MEDIR SUSTENTABILIDAD Y EFICIENCIA AMBIENTAL FUNDACION NEXUS ciencias sociales medio ambiente salud INDICADORES. PROBLEMAS ASOCIADOS A SU SELECCIÓN PARA MEDIR SUSTENTABILIDAD Y EFICIENCIA AMBIENTAL Por Daniel Fernández Dillon Ingeniería Sanitaria

Más detalles

Experiencia en la IMPLANTACIÓN DE UN SISTEMA DE CALIDAD en la Facultad de Ciencias Agrotecnológicas de la Universidad Autónoma de Chihuahua

Experiencia en la IMPLANTACIÓN DE UN SISTEMA DE CALIDAD en la Facultad de Ciencias Agrotecnológicas de la Universidad Autónoma de Chihuahua 46 SynthesiS PUNTO DE VISTA Experiencia en la IMPLANTACIÓN DE UN SISTEMA DE CALIDAD en la Facultad de Ciencias Agrotecnológicas de la Universidad Autónoma de Chihuahua AÍDA RODRÍGUEZ ANDUJO, JULIO CÉSAR

Más detalles

MANTENIMIENTO Y SOPORTE

MANTENIMIENTO Y SOPORTE MANTENIMIENTO Y SOPORTE Copyright 2014 Magalink SA Todos los derechos reservados. Este documento no puede ser reproducido de ninguna manera sin el consentimiento explícito de Magalink S.A. La información

Más detalles

RECOMENDACIONES DE INVESTIGACIÓN FUTURA.

RECOMENDACIONES DE INVESTIGACIÓN FUTURA. Capítulo 6 CONCLUSIONES Y RECOMENDACIONES DE INVESTIGACIÓN FUTURA. 212 METODOLOGÍA PARA LA DETECCIÓN DE REQUERIMIENTOS SUBJETIVOS EN EL DISEÑO DE PRODUCTO. CAPÍTULO 6. CONCLUSIONES, APORTACIONES Y RECOMENDACIONES.

Más detalles

CAPÍTULO III. MARCO METODOLÓGICO. del Hotel y Restaurante El Mandarín S.A. de C.V. en la ciudad de San Miguel.

CAPÍTULO III. MARCO METODOLÓGICO. del Hotel y Restaurante El Mandarín S.A. de C.V. en la ciudad de San Miguel. CAPÍTULO III. MARCO METODOLÓGICO. III.A. HIPÓTESIS. III.A.1. HIPÓTESIS GENERAL. H 1 La elaboración de un diseño de Plan Estratégico contribuye a mejorar la competitividad del Hotel y Restaurante El Mandarín

Más detalles

Diferencias entre nivel 2 y nivel 3 y una estrategia de implantación

Diferencias entre nivel 2 y nivel 3 y una estrategia de implantación CMMI DEV Diferencias entre nivel 2 y nivel 3 y una estrategia de implantación Cecilia Rigoni Gerente de Caelum, Information & Quality Technologies. Vocal del Comité CSTIC de la AEC El modelo CMMI DEV,

Más detalles

UNIVERSIDAD DE OTAVALO

UNIVERSIDAD DE OTAVALO ESQUEMA EXPLICATIVO PARA LOS PRODUCTOS FINALES PREVIA A LA GRADUACION Para el producto final de grado se podrá optar, indistintamente de la carrera, por dos tipos de trabajos académicos que son el proyecto

Más detalles

Sistemas de Calidad Empresarial

Sistemas de Calidad Empresarial Portal Empresarial Aljaraque Empresarial Sistemas de Calidad Empresarial 1 ÍNDICE 1. INTRODUCCIÓN. 2. CONCEPTO DE CALIDAD Y SU SISTEMA. 3. MÉTODO PARA IMPLANTAR UN SISTEMA DE GESTIÓN DE LA CALIDAD. 4.

Más detalles

CAPÍTULO III MARCO TEÓRICO. Cada día cambian las condiciones de los mercados debido a diferentes factores como: el

CAPÍTULO III MARCO TEÓRICO. Cada día cambian las condiciones de los mercados debido a diferentes factores como: el CAPÍTULO III MARCO TEÓRICO 3.1 Introducción Cada día cambian las condiciones de los mercados debido a diferentes factores como: el incremento de la competencia, la globalización, la dinámica de la economía,

Más detalles

Aprender español vía proyectos en niveles avanzados: una experiencia docente

Aprender español vía proyectos en niveles avanzados: una experiencia docente Aprender español vía proyectos en niveles avanzados: una experiencia docente Anett Zábráczki Instituto AKG de Budapest, Hungría Parte teórica Qué es un proyecto? «El nombre de trabajo por proyectos se

Más detalles

TEMA 3. PROCESO Y TÉCNICAS DE ASESORAMIENTO Y CONSULTA 1. EL PROCESO DE ASESORAMIENTO

TEMA 3. PROCESO Y TÉCNICAS DE ASESORAMIENTO Y CONSULTA 1. EL PROCESO DE ASESORAMIENTO 1 TEMA 3. PROCESO Y TÉCNICAS DE ASESORAMIENTO Y CONSULTA 1. EL PROCESO DE ASESORAMIENTO Origen del proceso Se inicia cuando un consultante se dirige a un consultor en busca de ayuda (asesoramiento) respecto

Más detalles

Curso Auditor Interno Calidad

Curso Auditor Interno Calidad Curso Auditor Interno Calidad 4. Fases de una auditoria OBJETIVOS Fases de una auditoria 1 / 10 OBJETIVOS Al finalizar esta unidad didáctica será capaz: Conocer las fases de una auditoria interna. Conocer

Más detalles

Unidad I: Introducción a la gestión de proyectos

Unidad I: Introducción a la gestión de proyectos Unidad I: Introducción a la gestión de proyectos 1.1. Conceptos básicos para la gestión de proyectos Qué es un proyecto? Un proyecto es una secuencia de tareas con un principio y un final limitados por

Más detalles

Informe de Servicio Social. actividades tienen en la población meta y acerca del aprendizaje obtenido por el prestador de

Informe de Servicio Social. actividades tienen en la población meta y acerca del aprendizaje obtenido por el prestador de Informe de Servicio Social Definición En este documento se reportan las actividades realizadas como parte del servicio social, así como los resultados obtenidos. Generalmente incluye una reflexión acerca

Más detalles

10. La organización de las niñas y de los niños. 10.1 Criterios para la organización de las niñas y de los niños

10. La organización de las niñas y de los niños. 10.1 Criterios para la organización de las niñas y de los niños 10. La organización de las niñas y de los niños Las investigaciones sociales han comprobado que a medida que crecen las niñas y los niños aumenta el interés por tener amigos y disminuyen significativamente

Más detalles

COMO REALIZAR UN DIAGNÓSTICO INICIAL Y DEFINIR LA POLITICA DE SEGURIDAD PARA EL SISTEMA DE GESTIÓN EN CONTROL Y SEGURIDAD BASC

COMO REALIZAR UN DIAGNÓSTICO INICIAL Y DEFINIR LA POLITICA DE SEGURIDAD PARA EL SISTEMA DE GESTIÓN EN CONTROL Y SEGURIDAD BASC COMO REALIZAR UN DIAGNÓSTICO INICIAL Y DEFINIR LA POLITICA DE SEGURIDAD PARA EL SISTEMA DE GESTIÓN EN CONTROL Y SEGURIDAD BASC AL FINALIZAR EL CURSO.. Estaremos en capacidad de: Conocer la metodología

Más detalles

SECRETARÍA DE EDUCACIÓN PÚBLICA SUBSECRETARÍA DE EDUCACIÓN SUPERIOR COORDINACIÓN GENERAL DE UNIVERSIDADES TECNOLÓGICAS

SECRETARÍA DE EDUCACIÓN PÚBLICA SUBSECRETARÍA DE EDUCACIÓN SUPERIOR COORDINACIÓN GENERAL DE UNIVERSIDADES TECNOLÓGICAS SECRETARÍA DE EDUCACIÓN PÚBLICA SUBSECRETARÍA DE EDUCACIÓN SUPERIOR COORDINACIÓN GENERAL DE UNIVERSIDADES TECNOLÓGICAS CRITERIOS GENERALES PARA LA PLANEACIÓN, EL DESARROLLO Y LA EVALUACIÓN, EN LA IMPLANTACIÓN

Más detalles

<Generador de exámenes> Visión preliminar

<Generador de exámenes> Visión preliminar 1. Introducción Proyecto Final del curso Técnicas de Producción de Sistemas Visión preliminar Para la evaluación de algunos temas de las materias que se imparten en diferentes niveles,

Más detalles

Tema 3. Procesos ligeros de desarrollo de software.

Tema 3. Procesos ligeros de desarrollo de software. Ingeniería del Software II 2011 Tema 3. Procesos ligeros de desarrollo de software. Tipos de procesos ligeros. Tipos de procesos ligeros: Desarrollo Rápido de Software. Desarrollo Ágil. Programación Extrema.

Más detalles

TEMA 3: EN QUÉ CONSISTE?

TEMA 3: EN QUÉ CONSISTE? Módulo 7 Sesión 3 5/16 TEMA 3: EN QUÉ CONSISTE? La metodología seguida para aplicar correctamente la técnica de RGT se basa en cuatro fases (Figura 1). En la primera de ellas, se seleccionan los elementos

Más detalles

LA PLANIFICACIÓN ESTRATÉGICA EN MATERIA TIC EN EL ÁMBITO DE LA AGE

LA PLANIFICACIÓN ESTRATÉGICA EN MATERIA TIC EN EL ÁMBITO DE LA AGE LA PLANIFICACIÓN ESTRATÉGICA EN MATERIA TIC EN EL ÁMBITO DE LA AGE Subdirector General de Planificación y Coordinación Informática Ministerio de Trabajo y Asuntos Sociales Palabras clave Planificación

Más detalles

Inter American Accreditation Cooperation. Grupo de prácticas de auditoría de acreditación Directriz sobre:

Inter American Accreditation Cooperation. Grupo de prácticas de auditoría de acreditación Directriz sobre: Grupo de prácticas de auditoría de acreditación Directriz sobre: Auditando la competencia de los auditores y equipos de auditores de organismos de certificación / registro de Sistemas de Gestión de Calidad

Más detalles

ENFOQUE: (10 puntos)... 18 IMPLANTACIÓN: (10 puntos)... 18 DATOS Y FUENTES DE LA INFORMACIÓN (5 puntos)... 18 RESULTADOS: (15 puntos)...

ENFOQUE: (10 puntos)... 18 IMPLANTACIÓN: (10 puntos)... 18 DATOS Y FUENTES DE LA INFORMACIÓN (5 puntos)... 18 RESULTADOS: (15 puntos)... Bases 2014 Anexo 1 ÍNDICE CAPÍTULO 1: OBJETIVOS (160 puntos)... 5 LIDERAZGO... 5 LIDERAZGO ENFOCADO A OBJETIVOS: (30 puntos)... 5 ENFOQUE EN LOS OBJETIVOS DEL LIDERAZGO: (60 puntos)... 5 IMPLANTACIÓN:

Más detalles

Capítulo 11. Conclusiones y trabajo futuro

Capítulo 11. Conclusiones y trabajo futuro Capítulo 11. Conclusiones y trabajo futuro En esta tesis ha realizado un entorno de desarrollo Web que proporciona herramientas para la mejora de la calidad del código de los desarrolladores. Para conseguir

Más detalles

MANUAL DE GESTIÓN: SISTEMA DE GESTIÓN DE LA CALIDAD EN LA UNIDAD de FORMACIÓN DE LA DIPUTACION DE MALAGA

MANUAL DE GESTIÓN: SISTEMA DE GESTIÓN DE LA CALIDAD EN LA UNIDAD de FORMACIÓN DE LA DIPUTACION DE MALAGA Página 1 de 17 MANUAL DE GESTIÓN: SISTEMA DE GESTIÓN DE LA CALIDAD EN LA UNIDAD de FORMACIÓN DE LA DIPUTACION DE MALAGA Página 2 de 17 1 ÍNDICE DEL DOCUMENTO 1 ÍNDICE DEL DOCUMENTO... 2 2 PRESENTACIÓN

Más detalles

2.1 Planificación del Alcance

2.1 Planificación del Alcance 2. Gestión del Alcance del Proyecto La Gestión del Alcance del Proyecto incluye los procesos necesarios para asegurarse que el incluya todo el trabajo requerido, y sólo el trabajo requerido, para completar

Más detalles

ANÁLISIS DE PROPUESTAS CURRICULARES. El planteamiento curricular presenta varios aspectos interesantes, como por ejemplo:

ANÁLISIS DE PROPUESTAS CURRICULARES. El planteamiento curricular presenta varios aspectos interesantes, como por ejemplo: ANÁLISIS DE PROPUESTAS CURRICULARES Ontario Resumen La propuesta curricular de Canadá presenta la Literatura integrada con el curso de Inglés, articulándola a través de sus cuatro componentes: Comunicación

Más detalles

Instructivo para la elaboración de un Manual Técnico

Instructivo para la elaboración de un Manual Técnico Instructivo para la elaboración de un Manual Técnico Autora: Ing. Alena González Reyes. (agonzalez@ceis.cujae.edu.cu) Ciudad de la Habana, Cuba Marzo, 2010 Índice 1. Introducción... 3 2. Confección...

Más detalles

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE 3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE Software Configuration Management (SCM) es una disciplina de la Ingeniería de Software que se preocupa de [Ber92] [Ber84] [Bou98] [Mik97]: Identificar y documentar

Más detalles

Evaluación de la Continuidad de Negocio en los Sistemas de Pagos de Latinoamérica y el Caribe. Octubre, 2010

Evaluación de la Continuidad de Negocio en los Sistemas de Pagos de Latinoamérica y el Caribe. Octubre, 2010 Evaluación de la Continuidad de Negocio en los Sistemas de Pagos de Latinoamérica y el Caribe Octubre, 2010 Contenido Introducción Cuestionario Evaluación 2010 Resultados cuantitativos Fortalezas Oportunidades

Más detalles

Uso de las tecnologias de la informacion en las PyMES de los municipios de Comalcalco y Cunduacán

Uso de las tecnologias de la informacion en las PyMES de los municipios de Comalcalco y Cunduacán Uso de las tecnologias de la informacion en las PyMES de los municipios de Comalcalco y Cunduacán M.A. María del Carmen Vásquez García M.C. Marbella Araceli Gómez Lemus Pasante Edwin Fabián Hernández Pérez

Más detalles

Diplomado: Formación de habilidades de liderazgo y supervisión

Diplomado: Formación de habilidades de liderazgo y supervisión Diplomado: Formación de habilidades de liderazgo y supervisión 1 DIPLOMADO Formación de habilidades de liderazgo y supervisión Introducción al programa Las empresas son más que la suma de personas y metas

Más detalles

LA METODOLOGÍA DEL BANCO PROVINCIA

LA METODOLOGÍA DEL BANCO PROVINCIA 20 LA METODOLOGÍA DEL BANCO PROVINCIA Cómo gestionar activos de información? En 2007, el Banco Central de la República Argentina (BCRA) planteó algunas exigencias financieras para el sistema financiero

Más detalles

Planeación y evaluación: desarrollo de Indicadores

Planeación y evaluación: desarrollo de Indicadores + + ESTADOS GOBIERNO ABIERTO CO CREACIÓN DESDE LO LOCAL Planeación y evaluación: desarrollo de Indicadores Índice Conceptos Generales Gestión para Resultados (GpR) Ciclo de GpR Planeación Estratégica Diferencias

Más detalles

UNIVERSIDAD TECNOLÓGICA DE PANAMÁ SECRETARÍA GENERAL FACULTAD DE INGENIERÍA DE SISTEMAS COMPUTACIONALES DESCRIPCIÓN DE CURSO DE LA CARRERA DE

UNIVERSIDAD TECNOLÓGICA DE PANAMÁ SECRETARÍA GENERAL FACULTAD DE INGENIERÍA DE SISTEMAS COMPUTACIONALES DESCRIPCIÓN DE CURSO DE LA CARRERA DE UNIVERSIDAD TECNOLÓGICA DE PANAMÁ SECRETARÍA GENERAL FACULTAD DE INGENIERÍA DE SISTEMAS COMPUTACIONALES DESCRIPCIÓN DE CURSO DE LA CARRERA DE MAESTRÍA Y POSTGRADO EN INGENIERÍA DE SOFTWARE 2015 APROBADO

Más detalles

Metodología Híbrida para Desarrollo de Software en México. CICIC 2012

Metodología Híbrida para Desarrollo de Software en México. CICIC 2012 Metodología Híbrida para Desarrollo de Software en México. CICIC 2012 Eréndira M Jiménez-Hernández Tecnología de Software y Bases de Datos, Centro de Investigación en Computación (CIC), IPN. Ciudad de

Más detalles

Por qué es importante la planificación?

Por qué es importante la planificación? Por qué es importante la planificación? La planificación ayuda a los empresarios a mejorar las probabilidades de que la empresa logre sus objetivos. Así como también a identificar problemas claves, oportunidades

Más detalles

Orientación Diseño Industrial Asignatura: DIRECCION DE PROYECTOS 6 año

Orientación Diseño Industrial Asignatura: DIRECCION DE PROYECTOS 6 año Orientación Diseño Industrial Asignatura: DIRECCION DE PROYECTOS 6 año CONCEPTOS BASICOS pag. 1/6 Objetivos: Conocer los principales conceptos relacionados con la gestión de proyectos. Bibliografía: PMBOK

Más detalles

Instituto Tecnológico de Costa Rica

Instituto Tecnológico de Costa Rica Instituto Tecnológico de Costa Rica Escuela de Ingeniería en Computación Proyecto Programado: Revisión de Utilización Médica: Aplicación Web para el control de pacientes en hospitales de Puerto Rico Práctica

Más detalles

4 Teoría de diseño de Experimentos

4 Teoría de diseño de Experimentos 4 Teoría de diseño de Experimentos 4.1 Introducción En los capítulos anteriores se habló de PLC y de ruido, debido a la inquietud por saber si en una instalación eléctrica casera que cuente con el servicio

Más detalles

153. a SESIÓN DEL COMITÉ EJECUTIVO

153. a SESIÓN DEL COMITÉ EJECUTIVO ORGANIZACIÓN PANAMERICANA DE LA SALUD ORGANIZACIÓN MUNDIAL DE LA SALUD 153. a SESIÓN DEL COMITÉ EJECUTIVO Washington, D.C., EUA, 4 de octubre del 2013 Punto 5.2 del orden del día provisional CE153/5 (Esp.)

Más detalles

ENCUESTA DE SATISFACCIÓN I ED. MÁSTER DE UNIDADES CLÍNICAS

ENCUESTA DE SATISFACCIÓN I ED. MÁSTER DE UNIDADES CLÍNICAS ENCUESTA DE SATISFACCIÓN I ED. MÁSTER DE UNIDADES CLÍNICAS Ha concluido la fase lectiva del Máster en Dirección de Unidades Clínicas. Como en otros máster se ha procedido a realizar una encuesta de satisfacción

Más detalles

ISO14001:2015. - disponer de un certificado bajo la versión de 2008 en vigor - superar una auditoria bajo los requisitos de la nueva versión

ISO14001:2015. - disponer de un certificado bajo la versión de 2008 en vigor - superar una auditoria bajo los requisitos de la nueva versión ISO14001:2015 PLAN DE TRANSICIÓN Tras la publicación de la nueva versión de la norma ISO14001 el pasado mes de septiembre se inicia un periodo de convivencia entre las dos versiones de la norma. Este periodo

Más detalles

CUESTIONARIO DE AUTOEVALUACIÓN

CUESTIONARIO DE AUTOEVALUACIÓN CUESTIONARIO DE AUTOEVALUACIÓN El presente Cuestionario permite conocer en qué estado de madurez se encuentra el Sistema de Gestión Ambiental (en adelante, SGA) de su organización, de acuerdo a los requisitos

Más detalles

puede aumentar la innovación en la cartera de productos?

puede aumentar la innovación en la cartera de productos? RESUMEN DE LA SOLUCIÓN Soluciones de gestión de proyectos y carteras para la innovación de productos puede aumentar la innovación en la cartera de productos? you can Las soluciones de gestión de productos

Más detalles

Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere.

Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere. UNIVERSIDAD DE CARABOBO FACULTAD DE CIENCIA Y TECNOLOGÍA DIRECCION DE EXTENSION COORDINACION DE PASANTIAS Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere. Pasante:

Más detalles

Aprendizaje cooperativo (Del libro Aprendizaje inteligente Montserrat del Pozo. Oct 2009)

Aprendizaje cooperativo (Del libro Aprendizaje inteligente Montserrat del Pozo. Oct 2009) Aprendizaje cooperativo (Del libro Aprendizaje inteligente Montserrat del Pozo. Oct 2009) Introducción El aprendizaje cooperativo es para los hermanos Johnson el empleo didáctico de grupos reducidos en

Más detalles

DOCUMENTO VISIÓN SISTEMA DE VENTAS Y PRÉSTAMOS DE LA CINEMATECA BOLIVIANA PAWI. Versión 1.0. Aruquipa Mamani Rolando Willy

DOCUMENTO VISIÓN SISTEMA DE VENTAS Y PRÉSTAMOS DE LA CINEMATECA BOLIVIANA PAWI. Versión 1.0. Aruquipa Mamani Rolando Willy DOCUMENTO VISIÓN SISTEMA DE VENTAS Y PRÉSTAMOS DE LA CINEMATECA BOLIVIANA PAWI Versión 1.0 Integrantes: Aruquipa Mamani Rolando Willy Layme Ordoñez Roxana Paola Módulos Venta de Material y Facturación

Más detalles

GESTIÓN Y CONTROL DEL DESARROLLO E IMPLANTACIÓN DE APLICACIONES

GESTIÓN Y CONTROL DEL DESARROLLO E IMPLANTACIÓN DE APLICACIONES Ciclo Formativo: Módulo: Desarrollo de Aplicaciones Informáticas Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión Unidad de Trabajo 10: GESTIÓN Y CONTROL DEL DESARROLLO E IMPLANTACIÓN

Más detalles

Su éxito se mide por la pertinencia y la oportunidad de la solución, su eficacia y eficiencia.

Su éxito se mide por la pertinencia y la oportunidad de la solución, su eficacia y eficiencia. APUNTES PARA EL CURSO PROCESOS COGNITIVOS: RESOLUCIÓN DE PROBLEMAS Y TOMA DE DECISIONES Elaborado por Vicente Sisto Campos. Se trata de la confluencia de la capacidad analítica del equipo de identificar

Más detalles

Consejo Económico y Social

Consejo Económico y Social Naciones Unidas E/CN.3/2013/18 Consejo Económico y Social Distr. general 19 de diciembre de 2012 Español Original: inglés Comisión de Estadística 44º período de sesiones 26 de febrero a 1 de marzo de 2013

Más detalles

RESUMEN EJECUTIVO DEL INFORME DEL PROYECTO EMPRENDEDORES

RESUMEN EJECUTIVO DEL INFORME DEL PROYECTO EMPRENDEDORES RESUMEN EJECUTIVO DEL INFORME DEL PROYECTO EMPRENDEDORES 1. Por qué este documento? El Proyecto Educar el Talento Emprendedor se enmarca dentro del plan de actuación de la Fundación Príncipe de Girona

Más detalles

Sistema de Mensajería Empresarial para generación Masiva de DTE

Sistema de Mensajería Empresarial para generación Masiva de DTE Sistema de Mensajería Empresarial para generación Masiva de DTE TIPO DE DOCUMENTO: OFERTA TÉCNICA Y COMERCIAL VERSIÓN 1.0, 7 de Mayo de 2008 CONTENIDO 1 INTRODUCCIÓN 4 2 DESCRIPCIÓN DE ARQUITECTURA DE

Más detalles