Modelo CMMI (página 2) - Monografias.com\nModelo CMMI (página 2)\nEnviado por Mat�as Fuentes Contreras\nUno de los propósitos de CMMI fue unir en forma coherente varios modelos que eran utilizados en conjunto dentro de una organización y que generaban repetición de contenido provocando que el proceso de mejora llevado a cabo en la organización fuera más difícil y costoso. Estos modelos integrados por CMMI, que serán descritos a continuación y que se ilustran en la Figura 1, eran modelos enfocados en el desarrollo de sistemas software (SW-CMM), en la ingeniería de sistemas (SECM) y en el desarrollo de productos integrados (IPD-CMM).\nFigura 2: Modelos Previos a CMMI\nCMM para Software\nTras su creación en 1984 el SEI comenzó la investigación para desarrollar un marco de mejora y evaluación de la calidad de las empresas desarrolladoras de software que prestaban servicios al Departamento de Defensa de los Estados Unidos. El resultado de la investigación se denominó "Capability Maturity Model for Software" (SW-CMM), cuya versión 1.0 se publicó en Agosto de 1991 [Pal06]. Posteriormente, como resultado de la retroalimentación generada por parte de la comunidad de software [Pau93], se desarrollaron las versiones 1.1 publicada en 1993 y 2.0 la cual agregaba y modificaba una serie de elementos al vigente CMM v1.1, principalmente que tienen relación con alcanzar la institucionalización en la organización. Esta versión se completó en 1997 y se denominó "Software CMM, Version 2.0 (Draft C)", pero nunca fue publicada [SEI97]. SW-CMM es un modelo de madurez de capacidades desarrollado para los procesos relativos a la producción y mantenimiento de sistemas software. De esta forma el SW-CMM puede emplearse con dos finalidades [Pal06]:\n1.\tGuía para mejorar procesos relativos a la producción y mantenimiento del software.\n2.\tCriterio para determinar el nivel de madurez de una organización que produce y mantiene software.\nLas organizaciones que usan SW-CMMI transitan por cinco niveles de madurez de capacidades donde se pueden encontrar al evaluar sus procesos. Estos niveles son: Inicial, donde no hay procesos; Repetible, en el cual los procesos relacionados a la gestión de proyectos y gestión de requerimientos son manejados de alguna manera para su repetición en proyectos distintos; definido, cuando los procesos están totalmente definidos y disponibles para todos los miembros de una organización; gestionado, donde se pueden medir los procesos cuantitativamente; y optimizado, en donde los procesos son mejorados continuamente según una serie de métricas definidas.\nSECM corresponde al esfuerzo conjunto de INCOSE - International Council on System Engineering (Consejo Internacional sobre Ingeniería de sistemas) – y EPIC Group – Enterprise Process Improvement Collaboration Group (Grupo de colaboración de mejora de procesos en la empresa) – para integrar sus dos modelos (SECAM y SE-CMM, respectivamente) en el denominado System Engineering Capability Model (SECM) o también llamado EIA/IS 731, que fue liberado en su versión 1.0 en 1998.\nSECM (Modelo de Capacidades de Ingeniería de Sistemas) fue elaborado con el objetivo de proveer una guía para efectuar, manejar y mejorar la ingeniería de sistemas [Sec07a]. El modelo describe un conjunto mínimo de actividades críticas para realizar ingeniería de sistemas o manejar tareas, tal como derivar y asignar requerimientos o manejar riesgos. El modelo también captura las actividades genéricas relacionadas a manejar o mejorar como una tarea específica es realizada [Sec07a]. Estas actividades son especificadas en cinco niveles secuenciales e incrementales (niveles de capacidad), los cuales proveen al usuario un método estructurado para lograr una mejora continua [Sec07a]. Los niveles fueron obtenidos sobre prácticas probadas experimentalmente y ellos son: Habilidad para desarrollar ingeniería de sistemas, Obteniendo control local, Compartiendo conocimiento a través de la organización, Medida cuantitativa de lo que se hace, y Mejora usando las medidas cuantitativas y objetivos organizacionales.\nEl primer predecesor de SECM descrito es SECAM (Systems Engineering Capability Assessment Model), traducido como Modelo de Evaluación de Capacidades de Ingeniería de Sistemas. Fue elaborado por CAWG – Capability Assessment Working Group on Systems Engineering (Grupo de trabajo de evaluación de capacidades en Ingeniería de sistemas) – y aprobado por INCOSE para ser liberado en 1996 [Inc96]. SECAM junto son su método de evaluación fue utilizado evaluar la capacidad de los procesos relacionados a la ingeniería de sistemas en una organización y trataba de determinar áreas de potencial mejora. El segundo predecesor es SE-CMM v1.1 – System Engineering Capability Maturity Model (Modelo de Madurez de Capacidad para Sistema de Ingeniería) – que fue creado por el SEI en el año 1995 y describe los elementos esenciales que deben existir para que los procesos de ingeniería de sistemas de una organización aseguren una buena ingeniería de sistemas [Bat95]. Junto con su método de evaluación tienen el objetivo de mejorar y evaluar los procesos asociados a la ingeniería de sistemas.\nIPD CMM – Integrated Product Development Capability Maturity Model (Modelo de madurez de capacidad para el desarrollo de productos integrados) – fue el elaborado y liberado en 1997 por el SEI. El modelo describe los elementos esenciales para el desarrollo de un producto integrado; una guía para el proceso de mejora del desarrollo del producto integrado; y una metodología de evaluación del proceso de desarrollo del producto integrado que es hecho por una organización [Sec07b].\nIPD CMM puede ser aplicado a cualquier tipo disciplina y abarca casi todo el ciclo de vida de un producto desde la selección de oportunidades de negocio hasta el retiro del producto del mercado, marginando la etapa de desarrollo del plan estratégico [Sec07b]. Fue diseñado con la idea de eliminar la duplicación de actividades del SW-CMM y el SE-CMM, los cuales al ser aplicados en una organización se traslapaban entre sí, y consta de 5 niveles de madurez de capacidad semejantes en su descripción a los niveles de SW-CMM y SE-CMM [Sec07b].\nCMMI Versión 1.2\nCapability Maturity Model® Integration (CMMI) es un modelo de aseguramiento de la calidad que busca la mejora continua de las organizaciones mediante el análisis y re-diseño de los procesos que subyacen en la organización. Fue creado por el SEI (Software Engineering Institute) de la Universidad de Carnegie-Mellon y patrocinado por el Ministerio de Defensa de los Estados Unidos. Con el propósito de lograr la mejora de los procesos, CMMI provee:\n•\tUna forma de integrar los elementos funcionales de una organización [SEI07b].\n•\tUn conjunto de mejores prácticas basadas en casos de éxito probado de organizaciones experimentadas en la mejora de procesos.\n•\tAyuda para identificar objetivos y prioridades para mejorar los procesos de la organización [SEI07b], dependiendo de las fortalezas y debilidades de la organización que son obtenidas mediante un método de evaluación.\n•\tUn apoyo para que las empresas complejas en actividades productivas puedan coordinar sus actividades en la mejora de los procesos.\n•\tUn punto de referencia para evaluar los procesos actuales de la organización [SEI07b].\nCMMI v1.2 corresponde a la tercera versión entregable del modelo CMMI, posterior a las versiones 1.02 (primera versión año 2000) y 1.1 (año 2002) [Chr06]. Las versiones previas sirvieron como retroalimentación para que los propios usuarios, evaluadores y evaluados hicieran acotaciones sobre posibles mejoras, las cuales fueron estudiadas, refinadas y algunas incluidas en la versión 1.2. CMMI v1.2 para desarrollo, que corresponde a una de tres constelaciones de prácticas, es una guía que ayuda a manejar, medir y monitorear procesos [SEI07a] utilizados en el desarrollo de productos y servicios de una organización, y contiene prácticas ligadas a la administración de proyectos, administración de procesos, ingeniería y soporte. Las otras dos constelaciones son CMMI para Adquisición que provee una guía para liderar la adquisición informada y decisiva [SEI07a], y CMMI para Servicios que proporciona una guía para la entrega de servicios a clientes internos y externos de la organización [SEI07a]. Ambas constelaciones se encuentran aún en desarrollo.\nJunto con CMMI se desarrolló y publicó el método de evaluación "Assessment Requirements for CMMI (ARC)" [SEI00] en el año 2000, el cual define los requerimientos considerados esenciales para realizar una evaluación de CMMI en una organización y "Standard CMMI Appraisal Method for Process Improvement", (SCAMPI) [SEI01], manual seguido por los evaluadores para medir el nivel de madurez de una organización. Estos dos documentos también se han actualizado como consecuencia de la retroalimentación de la comunidad involucrada en CMMI, generando la última versión 1.2 de SCAMPI [SEI06a] y ARC [SEI06b] ambas publicadas el año 2006.\nLa representación usada en CMMI entrega una guía para efectuar las actividades de mejora de los procesos y es utilizada en el método de evaluación. Según el modelo se tienen dos formas para mejorar. Una forma es mejorar un proceso específico o un conjunto de ellos usando la Representación Continua (Continuous Representation) y la otra es la mejora de la organización completa según los procesos definidos y ocupados usando la Representación Escalonada o por Etapas (Staged Representation). En la Tabla 1 se muestran los niveles para estos dos tipos de representaciones.\nLa representación continua se focaliza en la mejora de un proceso o un conjunto de ellos relacionado(s) estrechamente a un área de proceso en que una organización desea mejorar, por lo tanto una organización puede ser certificada para un área de proceso en cierto nivel de capacidad. Existen seis niveles de capacidad por donde transitan los procesos asociados a un área de proceso y cada nivel es construido sobre el nivel anterior, es decir para que un proceso alcance un nivel de capacidad necesariamente debe haber alcanzado el nivel anterior.\nTabla 1: Niveles de Representación continua y escalonada [Chr06].\nLos niveles de capacidad son:\nNivel 0 - Incompleto: Un proceso es denominado "proceso incompleto" cuando una o más objetivos específicos del área de proceso no son satisfechos.\nNivel 1 – Realizado: Un proceso es denominado "proceso realizado" cuando satisface todos los objetivos específicos del área de proceso. Soporta y permite el trabajo necesario para producir artefactos [Chr06].\nNivel 2 – Manejado: Un proceso es denominado como "proceso manejado" cuando tiene la infraestructura base para apoyar el proceso. El proceso es planeado y ejecutado en concordancia con la política, emplea gente calificada los cuales tienen recursos adecuados para producir salidas controladas; involucra partes interesadas; es monitoreado, controlado y revisado; y es evaluado según la descripción del proceso [Chr06].\nNivel 3 – Definido: Un proceso denominado "proceso definido" es adaptado desde el conjunto de procesos estándares de la organización de acuerdo a las guías de adaptación de la organización, y aporta artefactos, medidas, y otra información de mejora a los activos organizacionales [Chr06].\nNivel 4 – Manejado cuantitativamente: Un proceso denominado "proceso manejado cuantitativamente" es controlado usando técnicas estadísticas y otras técnicas cuantitativas. Objetivos cuantitativos para la calidad y realización del proceso son establecidos y usados como criterios para manejar el proceso [Chr06].\nNivel 5 – Optimización: Un proceso denominado "proceso optimización es mejorado basado en el entendimiento de causas comunes de variación del proceso. Un proceso en optimización se focaliza en la mejora continua del proceso realizado a través de mejoras incrementales y usando innovación tecnológica [Chr06].\nPara más información consultar [Kul03] y [Chr06].\nEn la representación escalonada o por etapas se ofrece un método estructurado y sistemático de mejoramiento de procesos, que implica mejorar por etapas o niveles. Al alcanzar un nivel, la organización se asegura de contar con una infraestructura robusta en términos de procesos para optar a alcanzar el nivel siguiente. Por lo tanto es una organización la que puede ser certificada bajo un nivel, en este caso llamado nivel de madurez. Según esta representación un nivel de madurez está compuesto por áreas de procesos (ver Tabla 2) en donde los objetivos asociados a ese nivel deben ser cumplidos para que la organización pueda certificarse en aquel nivel de madurez. Hay cinco niveles de madurez, los que son descritos a continuación:\nEn el nivel de madurez 1, la mayoría de los procesos son "ad-hoc" y caóticos. La organización usualmente no provee un ambiente estable para soportar los procesos. Éxitos en estas organizaciones se debe a la competencia y esfuerzos heroicos de la gente dentro de la organización y no al uso de procesos probados. A pesar de este caos, organizaciones pertenecientes al nivel de madurez 1 con frecuencia producen productos y servicios que funcionan; sin embargo, ellos frecuentemente exceden sus presupuestos y no cumplen sus planes. Estas organizaciones son caracterizadas por la tendencia a no cumplir sus compromisos, al abandono de procesos durante tiempos de crisis, y a la incapacidad para repetir sus éxitos [Chr06]. El Nivel 1 está caracterizado además por la realización de trabajo redundante, por personas que no comparten sus métodos de trabajo a lo largo de la organización y cuando una persona clave en un área de negocio específica dentro de la organización se marcha, su conocimiento se va con ella y se pierde para la organización. Es claro que el Nivel 1 es uno donde ninguna organización quiere estar y donde por lo general la mayoría que no tiene sus procesos definidos se encuentra.\nNivel 2: Manejado\nEn el nivel de madurez 2 se ordena el caos. En el nivel 2 las organizaciones se enfocan en tareas cotidianas referentes a la administración. Cada proyecto de la organización cuenta con una serie de procesos para llevarlo a cabo, los cuales son planeados y ejecutados de acuerdo con políticas establecidas; los proyectos utilizan gente capacitada quienes disponen de recursos para producir salidas controladas; se involucran a las partes interesadas; son monitoreados, controlados y revisados; y son evaluados según la descripción del proceso. La disciplina del proceso reflejada por el nivel de madurez 2 ayuda a asegurar que existen prácticas y los proyectos son realizados y manejados de acuerdo a los planes documentados. En el nivel de madurez 2 el estado de los artefactos y la entrega de los servicios siguen planes definidos. Acuerdos son establecidos entre partes interesadas y son revisados cuando sea necesario [Chr06]. Los artefactos y servicios son apropiadamente controlados. Estos además satisfacen sus descripciones especificadas, estándares, y procedimientos [Chr06].\nEn el nivel de madurez 3, procesos son caracterizados y entendidos de buena forma, y son descritos en estándares, procedimientos, herramientas, y métodos. El conjunto de procesos estándares de la organización, los cuales son la base para el nivel de madurez 3, es establecido y mejorado continuamente. Estos procesos estándares son usados para establecer consistencia a través de la organización. Los proyectos establecen sus procesos adaptando el conjunto de procesos estándares de la organización de acuerdo a guías de adaptación [Chr06].\nUna diferencia importante entre el nivel 2 y 3 es el alcance de los estándares: la descripción de procesos y los procedimientos. En el nivel de madurez 2, los estándares pueden ser un poco diferentes en cada instancia específica del proceso (por ejemplo sobre un proyecto particular). En el nivel de madurez 3, los estándares, descripción de procesos y procedimientos para un proyecto, son adaptados desde un conjunto de procesos estándares de la organización a un particular proyecto o unidad organizacional y así son más consistentes [Chr06]. Otra distinción crítica es que el nivel de madurez 3, los procesos son típicamente descritos más rigurosamente que en el nivel 2. Un proceso definido claramente plantea el propósito, entradas, criterios de entrada, actividades, roles, medidas, pasos de verificación, salidas y criterios de salida. En el nivel de madurez 3, procesos son manejados más proactivamente entendiendo las interrelaciones de las actividades y medidas detalladas del proceso, sus artefactos y sus servicios [Chr06].\nNivel 4: Manejado cuantitativamente\nEn el nivel de madurez 4, la organización y proyectos establecen objetivos cuantitativos para medir la calidad y realización de los procesos y los usa como criterios en el manejo de ellos. Los bjetivos cuantitativos son definidos en base a las necesidades de clientes, usuarios finales, organización, y actores de los procesos. La calidad y realización de procesos son entendidos en términos estadísticos y son manejados durante todo el ciclo de vida del proceso [Chr06]. Para subprocesos seleccionados, se recolectan y analizan estadísticamente medidas sobre la realización de procesos. Estas métricas son incorporadas en el repositorio de métricas de la organización para apoyar la toma de decisiones. Causas especiales de variación de procesos son identificadas y, cuando sea necesario, las fuentes de estas causas son corregidas para prevenir futuras ocurrencias.\nUna diferencia importante entre los niveles 3 y 4 es la capacidad de predicción de la realización del proceso. En el nivel de madurez 4, la realización de procesos es controlada usando técnicas estadísticas y cuantitativas, y el proceso es cuantitativamente predecible, en cambio en el nivel de madurez 3 la realización del proceso es sólo predecible cualitativamente [Chr06].\nEn el nivel de madurez 5, una organización mejora continuamente sus procesos basándose en el conocimiento de las causas comunes de variación inherente en los procesos. El nivel de madurez 5 se focaliza sobre la mejora continua de los procesos a través de mejoras continuas, incrementales y tecnológicas. Los objetivos de mejora cuantitativa de procesos para la organización son establecidos, continuamente revisados para reflejar cambios en los objetivos del negocio y usados como criterio en la mejora de procesos. Los efectos del empleo de las mejoras de procesos son medidos y evaluados contra los objetivos de mejora cuantitativa del proceso.\nUna diferencia importante entre el nivel de madurez 4 y 5 es el enfoque de la variación de los procesos. En el nivel de madurez 4, la organización está orientada a encontrar causas especiales de variación y proveer una predicción estadística de los resultados. Sin embargo, los resultados pueden ser insuficientes para alcanzar los objetivos establecidos. En el nivel de madurez 5 la organización está enfocada en las causas comunes de variación de procesos y modificar los procesos afectados para mejorar la realización de ellos y alcanzar los objetivos cuantitativos de mejora de procesos [Chr06].\nDado a que la organización con que se trabajará quiere certificarse en forma organizacional en Nivel de madurez 3, en adelante sólo se detallará el modelo según la Representación Escalonada.\nUn área de proceso es un conjunto de prácticas relacionadas que cuando son implementadas colectivamente, satisfacen un conjunto objetivos considerados importantes para mejorar esa área de proceso [Chr06]. Las áreas de proceso del modelo son 22. En la Tabla 2 se indica los nombres de las áreas de proceso junto con su abreviación. Cada una de ellas es implementada para alcanzar el nivel de madurez correspondiente y se agrupan de acuerdo a cuatro categorías: Administración de Procesos, Administración de Proyectos, Ingeniería y Soporte. Este agrupamiento es realizado para mostrar cómo se relaciona cada área de proceso dentro de una categoría. Sin embargo, áreas de procesos de distintas categorías pueden encontrarse relacionadas, pero dado que en este documento se desarrollarán sólo áreas de procesos de una misma categoría (Ingeniería) estas relaciones se desprecian.\nAnálisis y Resolución Causales (CAR)\nAnálisis y Resolución de Decisiones (DAR)\nAseguramiento de la Calidad de Procesos y Productos (PPQA)\nDefinición de Procesos Organizacionales +IPPD(OPD +IPPD)\nDesarrollo de Requerimientos (RD)\nAdministración Cuantitativa de Proyectos (QPM)\nAdministración de Acuerdos con Proveedores (SAM)\nAdministración de Requerimientos (REQM)\nAdministración de Riesgos (RSKM)\nAdministración de la Configuración (CM)\nAdministración Integral de Proyecto + IPD (IPM+IPPD) 1\nInnovación y Despliegue Organizacional (OID)\nIntegración de Producto (PI)\nMedición y Análisis (MA)\nMonitoreo y Control de Proyecto (PMC)\nPlanificación de Proyecto (PP)\nProcesos Orientados a la Organizacionales (OPF)\nRendimiento de Procesos Organizacionales (OPP)\nSolución Técnica (TS)\nTabla 2: Áreas de Proceso\nAunque los componentes son independientes de la representación elegida, se definirán de acuerdo al esquema propuesto por la Representación Escalonada que es la requerida por ORDEN Integración.\nComo se puede apreciar en Figura 3 un área de proceso está asociado a un nivel de madurez dentro de CMMI; tiene además un conjunto de objetivos específicos y uno o varios objetivos genéricos asociados, dependiendo del nivel de madurez al cual pertenece el área de proceso; los objetivos específicos y genéricos cuentan con un conjunto de prácticas específicas y genéricas respectivamente. CMMI define componentes requeridos, esperados e informativos. Los Componentes informativos, que se representadas por elipses en la Figura 3, no son referenciados ni descritos en este documento pues no son de interés para ORDEN Integración y sólo son una ayuda propuesta por el modelo para entender de mejor manera las componentes requeridas y esperadas.\nSon las componentes que obligatoriamente deben ser satisfechas y visiblemente implementadas para poder cumplir con un área de proceso. Una componente requerida es usada en las evaluaciones para ayudar a determinar si un área de proceso es satisfecho [Chr06]. Existen dos componentes requeridas:\n-\tObjetivo Específico (SG): Es un enunciado que describe la única característica que deber estar presente para satisfacer el área de proceso a la cual pertenece [Chr06]. Las SG son parte de un área de proceso.\n-\tObjetivo Genérico (GG): Es un enunciado que describe una característica que debe ser satisfechas por un conjunto de áreas de proceso según sea el caso. Las GG tienen el objetivo de institucionalizar los procesos que implementan un área de proceso y son comunes a un conjunto de áreas de proceso [Chr06].\nFigura 3: Componentes del CMMI – Representación Escalonada\nSon las componentes que pueden ser utilizadas para alcanzar una componente requerida, es decir se podrían implementar estas componentes o modificaciones válidas de ellas con el objetivo de alcanzar los objetivos genéricos o específicos. Las componentes esperadas pueden ser utilizadas como guías de mejora y de evaluación de procesos [Chr06]. Existen dos tipos de componentes esperadas:\n•\tPrácticas Específicas (SP): Una práctica específica es un enunciado que describe una actividad que es importante o esperada para alcanzar un objetivo específico de cierta área de proceso [Chr06].\n•\tPrácticas Genéricas (GP): Una práctica genérica es un enunciado que describe una actividad que es importante o esperada para alcanzar un objetivo genérico [Chr06].\nDescripción de las Áreas de Proceso\nA continuación se hará una breve descripción de cada área de proceso nombrada en Tabla 2. Explícitamente se nombra a productos pero también se puede aplicar las mismas definiciones a servicios.\n-\tAnálisis y Resolución Causales (CAR): Identifica la causa de defectos u otros problemas. Luego de ellos toma acciones correctivas para prevenir la ocurrencia de tales defectos o problemas en el futuro.\n-\tAnálisis y Resolución de Decisiones (DAR): Proporciona un proceso estructurado de toma de decisiones que asegura que las alternativas se comparan con criterios establecidos y objetivos para así tomar la mejor decisión posible.\n-\tAseguramiento de Calidad de Procesos y Productos (PPQA): Proporciona un conjunto de prácticas con el objetivo de evaluar productos, servicios, procesos y sus artefactos relacionados.\n-\tDefinición de Procesos Organizacionales (OPD): Establece y mantiene un conjunto de estándares tanto en procesos organizacionales como en ambientes de trabajo.\n-\tDesarrollo de Requerimientos (RD): Recopila las necesidades del cliente para convertirlas en requerimientos del producto esperado.\n-\tEntrenamiento Organizacional (OT): Permite a la gente de la organización obtener habilidades y conocimientos necesarios para que el trabajo realizado por ellos sea efectivo y eficiente.\n-\tAdministración Cuantitativa de Proyectos (QPM): Maneja métricas cuantitativas de los procesos con el objetivo de alcanzar los objetivos de calidad establecidos. Además mediante el análisis de estos datos permite identificar oportunidades de mejora para los procesos.\n-\tAdministración de Acuerdos con Proveedores (SAM): Gestiona la adquisición de productos de proveedores con los cuales exista un acuerdo formal [Rig06].\n-\tAdministración de Requerimientos (REQM): Gestiona los requerimientos del producto durante todo el ciclo de vida de él, identificando inconsistencias con los artefactos y planes de proyecto.\n-\tAdministración de Riesgos (RSKM): Identifica riesgos del proyecto para evaluarlos, priorizarlos y gestionarlos para prevenir su futura ocurrencia.\n-\tAdministración de la Configuración (CM): Establece y mantiene la integridad y consistencia de los artefactos [Rig06].\n-\tAdministración Integral de Proyecto (IPM): Adapta el conjunto de procesos estándares de la organización a procesos llevados a cabo para un proyecto en particular. Además maneja a las partes interesadas involucradas en el proyecto.\n-\tInnovación y Despliegue Organizacional (OID): Selecciona y despliega mejoras incrementales e innovadoras que mejoran en forma medida los procesos de la organización y tecnologías, para alcanzar los objetivos de calidad organizacional y de realización de procesos derivados de los objetivos de negocio de la organización [Chr06].\n-\tIntegración de Producto (PI): Ensambla las componentes del producto para producir un producto más complejo manteniendo el cumplimiento de los requerimientos establecidos.\n-\tMedición y Análisis (MA): Establece métricas con el objetivo de entregar resultados objetivos que sirvan como base para tomar decisiones informadas y correctivas.\n-\tMonitoreo y Control de proyecto (PMC): Analiza el proyecto con el objetivo de establecer un control y evaluación según lo planes establecidos, tomando acciones correctivas cuando es necesario.\n-\tPlanificación de Proyecto (PP): Desarrolla y mantiene planes del proyecto, compromisos adquiridos por parte de los participantes del proyecto y gestiona las partes interesadas del proyecto.\n-\tProcesos Orientados a la Organización (OPF): Ayuda a mantener un entendimiento de los procesos por parte de los miembros de la organización. También ayuda a identificar posibles mejoras de los procesos, que son evaluadas y eventualmente implementadas.\n-\tRendimiento de Procesos Organizacionales (OPP): Deriva objetivos cuantitativos de calidad y ejecución de lo procesos desde el conjunto de objetivos de negocio de la organización [Rig06].\n-\tSolución Técnica (TS): Diseña, desarrollo e implementa soluciones para los requerimientos del producto establecido.\n-\tValidación (VAL): Demuestra que el producto, componentes del producto y artefactos corresponden a lo esperado para su uso.\n-\tVerificación (VER): Demuestra que el producto, componentes del producto y artefactos cumplen con los requerimientos establecidos.\nUna evaluación de CMMI corresponde al estudio y análisis de uno o más procesos realizado por un equipo capacitado de profesionales, utilizando un modelo de referencia de evaluación como base para determinar, a lo menos, fortalezas y debilidades dentro de una organización. Un método de evaluación puede ser aplicado para distintos propósitos, incluyendo evaluaciones internas para mejora de los procesos, evaluaciones de capacidad de selección de proveedores, evaluaciones de monitoreo de procesos, entre otros enfoques.\nEl SEI ha publicado dos documentos guías que actualmente son utilizados para realizar una evaluación de CMMI:\n•\tAppraisal Requirements for CMMI (ARC) [SEI06b]\n•\tStandard CMMI Appraisal Method for Process Improvement (SCAMPI) [SEI06a].\nARC define un conjunto de requerimientos considerados esenciales para realizar una evaluación CMMI mientras que SCAMPI es la referencia para la evaluación. Se definen en ARC tres clases de evaluaciones: clase A, clase B y clase C. Las clases definen los requerimientos que debe cumplir una evaluación de cierta complejidad.\nLa clase A de ARC corresponde al método de evaluación que satisface el 100% de los requerimientos que el documento define y es la única evaluación que se considera oficial para otorgar un nivel de certificación de CMMI en una organización. Se denomina SCAMPI clase A. Este método permite comprender de mejor forma las capacidades de la organización, identificando fortalezas y debilidades en sus procesos y relacionar estas fortalezas y debilidades con el modelo de referencia CMMI. El método permite además enfocar la organización en el mejoramiento continuo de procesos y priorizar los planes de mejora; finalmente permite evaluar con una nota el nivel de madurez en el cual se encuentra una organización. SCAMPI clase A consta de tres fases: planificar y preparar la evaluación, llevar a cabo la evaluación y reportar resultados de la evaluación. Dentro de estas fases se ejecutan una serie de procesos. Algunos de ellos incluyen asignar responsabilidades, documentar el proceso, entrevistar a personas de la organización, agrupar los datos que se utilizarán, verificar y validar los procesos con el estándar, asignar notas o ratings, crear reportes. Se espera contar con un equipo evaluador de cómo mínimo requerido cuatro personas y un máximo recomendado de nueve, incluyendo al evaluador líder certificado en CMMI por el SEI.\nLas evaluación clase B está basada en la evaluación clase A. La evaluación clase B ayuda a una organización a comprender, con relativamente alto grado de confianza, el estado de los procesos relativos a CMMI. Generalmente se ejecuta una evaluación clase B cuando la organización necesita auto-evaluar sus procesos, con miras a una evaluación clase A para lograr el objetivo de la certificación. Esta clase de evaluación debe ser ejecutada por dos personas, incluyendo a un líder de CMMI y requiere mucho menos información que la evaluación clase A.\nMenos formal aún, de menor duración y con menos información requerida es la evaluación clase C que además es realizada por sólo una persona y tiene por objetivo evaluar pequeños aspectos de la organización que quieren apoyarse.\nRelaciones entre las áreas de proceso\nHay cuatro grupos o categorías de áreas de procesos que ayudan a guiar el proceso de mejora de la organización. Estos grupos están formados por áreas de proceso que se interrelacionan fuertemente y tienen características comunes asociadas a objetivos de negocio tradicionales. Estas categorías son las indicadas en la Tabla 2 para cada área de proceso: Administración de procesos, Administración de proyectos, Soporte e Ingeniería. A Continuación se describen brevemente las tres primeras categorías, para luego enfocarse en una descripción detallada de la categoría de Ingeniería que es la de interés en este documento.\nAdministración de procesos: Contiene áreas de proceso relacionadas con definir, planear, desplegar, implementar, monitorear, controlar, evaluar, medir y mejorar procesos [Chr06].\nAdministración de proyectos: Contiene áreas de proceso relacionadas con planeación, monitoreo y control de proyectos [Chr06].\nSoporte: Contiene áreas de proceso relacionadas con actividades que apoyan el desarrollo y mantenimiento del producto, y que están dirigidas a los procesos que son usados en el contexto del desarrollo de procesos pertenecientes a otras áreas [Chr06].\nIngeniería: Cubre actividades relacionadas al desarrollo y mantenimiento que son compartidas por toda la organización. Cualquier disciplina técnica involucrada en desarrollo de productos o servicios puede ocupar esta categoría para enfocar el proceso de mejora.\nÁreas de Proceso de Ingeniería\nLas áreas de proceso de Ingeniería pueden integrar los procesos asociados con diferentes disciplinas de ingeniería cuando el producto final es consecuencia de ellas, dando así un soporte para estrategias organizacionales orientas en el producto. Las áreas de proceso pertenecientes a la categoría de Ingeniería están indicadas en la Tabla 2 y ellas son:\n•\tDesarrollo de Requerimientos (RD).\n•\tGestión de Requerimientos (REQM).\n•\tSolución Técnica (TS).\n•\tIntegración de Productos (PI).\n•\tVerificación (VER).\n•\tValidación (VAL).\nLa Figura 4 muestra las relaciones existentes entre las distintas áreas de proceso de la categoría señalada.\nFigura 4: Relación entre Áreas de Proceso de Ingeniería\nRD identifica las necesidades de un cliente y las transforma en "requerimientos del producto". Luego, estos son analizados para producir "requerimientos de las componentes del producto", "requerimientos de interfaz de las componentes" y un modelo conceptual de alto nivel de la solución [Chr06].\nLos distintos requerimientos son suministrados a TS que produce una arquitectura del producto, un diseño del producto en componentes y diseño de las propias componentes. Además, TS desarrolla cada componente las cuales son suministradas a PI - donde las componentes son integradas verificando el cumplimiento de las interfaces que fueron definidas. TS utiliza a VER para realizar la verificación del diseño.\nREQM mantiene los requerimientos – describiendo actividades para obtener y controlar los cambios – y la trazabilidad de las necesidades del cliente al producto. Como REQM controla los cambios a los requerimientos que pueden tener como fuente todas las otras áreas de proceso de Ingeniería, esta área de proceso es recursiva, dinámica y transversal a la categoría.\nEl área de proceso VER asegura que los artefactos satisfacen los requerimientos especificados. VER es un área incremental, pues comienza con la verificación de las componentes del producto para terminar con la verificación del producto completo.\nVAL es un área de proceso incremental que valida el producto, las componentes del producto, los artefactos intermedios y los procesos con respecto a las necesidades de los clientes. Los conflictos que son descubiertos son usualmente resueltos en RD y TS.\nPI es el responsable de generar la mejor secuencia de integración de componentes posible, integrarlas y dar la aprobación para la entrega del producto al cliente. PI usa prácticas específicas de VER y VAL para implementar el proceso de integración del producto.\nA continuación se detalla cada una de las áreas de proceso de la categoría de Ingeniería del modelo CMMI. Esta información fue obtenida de la referencia del modelo, CMMI para Desarrollo v1.2 (ver [Chr06]).\nEl área de proceso Administración de Requerimientos (REQM) se encarga de administrar todos los requerimientos recibidos o generados por el proyecto, incluyendo tanto los técnicos y no-técnicos como los impuestos por la organización. Cuando un proyecto recibe requerimientos, estos son revisados con un proveedor para resolver inconsistencias y malentendidos antes de ser ingresados a los planes del proyecto. El jefe de proyecto administra los cambios en los requerimientos a medida que el proyecto avanza e identifica inconsistencias que ocurren entre planes, productos de trabajo y requerimientos.\nSG 1: Administrar Requerimientos\nObjetivo: "Los requerimientos deben ser administrados y las inconsistencias con el plan de proyecto y artefactos son identificadas"\nLos proyectos deben mantener actualizados y aprobados el conjunto de requerimientos durante el transcurso del proyecto para realizar lo siguiente:\n- Administrar todos los cambios en los requerimientos.\n- Mantener las relaciones entre los requerimientos, el plan del proyecto y los productos de trabajo.\n- Identificar las inconsistencias entre los requerimientos, el plan del proyecto y los productos de trabajo.\n- Tomar las acciones correctivas.\nSP 1 Obtener una comprensión de los requerimientos\nPráctica: "Desarrollar entendimiento común con los responsables de entregar los requerimientos sobre el significado y alcance de cada uno de ellos"\nA medida que el proyecto avanza y los requerimientos son derivados, todas las actividades o disciplinas recibirán requerimientos. Para evitar un flujo descontrolado de requerimientos, se establecen criterios para señalar las fuentes oficiales de las cuales recibirlos. Se debe asegurar un entendimiento compatible y compartido con los proveedores de requerimientos sobre el significado de cada uno de ellos. El resultado de este análisis y diálogo es un conjunto de requerimientos consensuado.\nSP 2 Obtener compromiso con los requerimientos\nPráctica: "Obtener compromiso de requerimientos por parte del los participantes del proyecto"\nMientras la práctica específica anterior se ocupa de alcanzar entendimiento con los proveedores de requerimientos, esta práctica específica se refiere a los acuerdos y compromisos de quienes tienen que cumplir con las actividades necesarias para implementar los requerimientos, es decir, el equipo de proyecto.\nA medida que los requerimientos evolucionan, esta práctica específica asegura que los participantes del proyecto se comprometan con los requerimientos aprobados y con los cambios resultantes en planes, actividades y artefactos.\nSP 3 Administrar cambios a los requerimientos\nPráctica: "Manejar cambios de requerimientos a medida que estos se desarrollan durante el proyecto"\nDurante el proyecto, los requerimientos cambian por distintas razones. A medida que las necesidades cambian y el trabajo avanza, se obtienen requerimientos adicionales y puede ser necesario modificar los existentes. Es esencial administrar estos requerimientos nuevos y modificados en forma efectiva y eficiente. Para analizar el impacto de los cambios de forma efectiva, es necesario que la fuente de cada requerimiento sea conocida y que el fundamento del cambio sea documentado. El Jefe de Proyecto puede, sin embargo, verificar métricas apropiadas de volatilidad de requerimientos para juzgar si se requieren nuevos controles o modificar los actuales.\nSP 4 Mantener trazabilidad bidireccional de los requerimientos\nPráctica: "Mantener trazabilidad bidireccional entre requerimientos y artefactos".\nEl propósito de esta SP es mantener la trazabilidad bidireccional por cada nivel de descomposición del producto final.\nCuando los requerimientos son bien administrados, la trazabilidad puede ser establecida desde la fuente del requerimiento a su nivel más bajo, y desde el nivel más bajo volver a sus orígenes. Dicha trazabilidad bidireccional ayuda a determinar que todos los requerimientos fuente han sido completamente abordados y que todos los requerimientos de más bajo nivel puedan ser relacionados con una fuente válida. La trazabilidad puede también cubrir relaciones horizontales, tales como interfaces y es particularmente necesaria al evaluar el impacto de cambios a requerimientos en los planes, actividades y productos de trabajo del proyecto.\nSP 5: Identificar inconsistencias entre artefactos del proyecto y los requerimientos\nPráctica: "Identificar inconsistencias entre los planes de proyecto y artefactos y los requerimientos"\nEsta práctica específica detecta las inconsistencias entre requerimientos y los planes de proyecto y artefactos, e inicia las acciones correctivas para solucionarlas.\nEl área de proceso de Desarrollo de Requerimientos (RD) se encarga de identificar las necesidades de los clientes y traducirlas en requerimientos. El conjunto de requerimientos de un proyecto es analizado para producir una solución conceptual de alto nivel. Estos requerimientos se destinan a ciertos componentes del producto final y son los que describen su rendimiento, características de diseño, su verificación, etc. para comprensión y utilización futura por parte de desarrolladores.\nSG 1: Desarrollar requerimientos del cliente\nObjetivo: "Necesidades de las partes interesadas, expectaciones, restricciones, e interfaces son recogidas y traducidas en requerimientos del cliente".\nLas necesidades de las partes interesadas (clientes, usuarios finales, proveedores, desarrolladores y encargados de prueba) son la base para determinar los requerimientos del cliente. Estas necesidades, expectativas, restricciones, interfaces, conceptos operacionales y conceptos de productos son analizados, matizados, refinados y elaborados para traducirlos en un conjunto de requerimientos del cliente. Frecuentemente estas son mal identificadas o contradictorias. Ya que las necesidades de actores, expectativas, restricciones y limitaciones deben ser claramente identificadas y entendidas, un proceso iterativo es usado durante todo el proyecto para conseguir este objetivo. Para facilitar la interacción requerida, un sustituto del usuario final o cliente es frecuentemente involucrado para representar las necesidades de éste y ayudar a resolver conflictos. Restricciones de ambiente, legales y otras debieran ser consideradas cuando se crea o resuelve el conjunto de requerimientos del cliente.\nSP 1: Obtener necesidades\nPráctica: "Identificar y recoger las necesidades, expectativas, restricciones e interfaces de las partes interesadas para todas las fases del ciclo de vida del producto".\nLa obtención va más allá de recopilar requerimientos, ya que implica buscar activamente la identificación de requerimientos que no hayan sido provistos explícitamente por el cliente. Los requerimientos adicionales debiesen abordar las diversas actividades del ciclo de vida del producto y su impacto en él.\nSP 2: Desarrollar los requerimientos del cliente\nPráctica: "Transformar las necesidades de las partes interesadas, expectativas, restricciones e interfaces en requerimientos del cliente".\nLas distintas entradas de las partes interesadas deben ser consolidadas, la información faltante debe ser obtenida y los conflictos deben ser resueltos al documentar el conjunto de requerimientos reconocidos por el cliente. Los requerimientos del cliente pueden incluir necesidades, expectativas y restricciones con respecto a verificación y validación.\nEn algunas situaciones, el cliente provee un conjunto de requerimientos al proyecto, o los requerimientos existen como una salida de actividades anteriores del proyecto. En estos casos, los requerimientos del cliente podrían contradecir las necesidades, expectativas, restricciones e interfaces de las partes interesadas y deberán ser transformadas en un conjunto de requerimientos reconocidos por el cliente, luego de resolver los conflictos adecuadamente.\nLas partes interesadas que forman parte de todas las etapas del ciclo de vida del producto debieran incluir funciones técnicas y de negocios. De esta manera, los conceptos de todos los procesos relacionados con el ciclo de vida del producto son considerados junto con el concepto del producto.\nSG 2: Desarrollar requerimientos de productos\nObjetivo: "Requerimientos del cliente son refinadas y elaboradas para desarrollar requerimientos del producto y componentes del producto".\nLos requerimientos del cliente son analizados en conjunto con el desarrollo del concepto operacional para obtener un conjunto de requerimientos más detallado y preciso y se le llama requerimientos del producto y de componentes del producto. Los requerimientos del producto y de componentes del producto abordan las necesidades asociadas con cada fase del ciclo de vida del producto. De los requerimientos obtenidos surgen de las restricciones, consideraciones de temas no explícitamente indicados en la línea base de requerimientos del cliente y factores introducidos por la arquitectura seleccionada, el diseño y las consideraciones específicas de negocio del desarrollador. Los requerimientos son revisados con nivel anterior de conjunto de requerimientos y arquitectura funcional, y el concepto preferido del producto es refinado.\nLos requerimientos son asociados a funciones y componentes del producto incluyendo objetos, personas y procesos. La trazabilidad de los requerimientos a funciones, objetos, pruebas, problemas u otras entidades es documentada. Los requerimientos asociados y las funciones son la base de la síntesis de la solución técnica. A medida que los componentes internos son desarrollados se definen interfaces adicionales y establecen los requerimientos de interfaz.\nSP 1: Establecer requerimientos del producto y de componentes del producto\nPráctica: "Establecer y mantener requerimientos del producto y componentes del producto, los cuales son basados en los requerimientos del cliente".\nLos requerimientos del cliente pueden ser expresados en los términos del cliente y pueden ser descripciones no técnicas. Los requerimientos del producto son la expresión de estos requerimientos en términos técnicos que pueden ser usados para decisiones de diseño.\nRequerimientos del producto y de componentes del producto abordan la satisfacción del cliente, los negocios, los objetivos del proyecto y los atributos asociados, tales como eficacia y economía. También abordan el costo y rendimiento de otras fases del ciclo de vida.\nLa modificación de requerimientos debido a la aprobación de cambios en estos es cubierta por funciones de mantenimiento de esta área de proceso; mientras que la administración de cambios de requerimientos es cubierta por el área de proceso de Administración de Requerimientos.\nSP 2: Destinar requerimientos de componentes del producto\nPráctica: "Destinar los requerimientos por cada componente del producto".\nLos requerimientos de componentes del producto incluyen el destino de éstos al comportamiento del producto final, el diseño de restricciones y el ajuste, formación y creación de funciones para satisfacer los requerimientos y facilitar la producción. En los casos donde los requerimientos de alto nivel especifiquen comportamiento que será responsabilidad de dos o más componentes del producto, este comportamiento debe ser dividido para ser asociado a cada componente de producto como requerimiento derivado.\nSP 3: Identificar requerimientos de interfaz\nPráctica: "Identificar requerimientos de interfaz".\nInterfaces entre funciones (o entre objetos) son identificadas. Interfaces funcionales pueden impulsar el desarrollo de soluciones alternativas. Los requerimientos de interfaces entre productos o entre componentes del producto identificados en la arquitectura del producto son definidos. Estos son controlados como parte de la integración del producto y componentes del producto y son parte integral de la definición de la arquitectura.\nSG 3: Analizar y validar requerimientos\nObjetivo: "Los requerimientos son analizados y validados, y una definición de la funcionalidad requerida es desarrollada".\nLas prácticas específicas de este objetivo específico apoyan el desarrollo de los requerimientos en los objetivos específicos 1 y 2. Las prácticas específicas asociadas con este objetivo cubren el análisis y validación de requerimientos con respecto al ambiente previsto por el usuario.\nLos análisis son desarrollados para determinar que impacto tendrá el ambiente operacional previsto en la habilidad para satisfacer las necesidades de las partes interesadas, sus expectativas, restricciones e interfaces. Aspectos como viabilidad, necesidades de misión corporativa, restricciones de costos, tamaño de potencial de mercado y estrategia de adquisición deben ser tomados en consideración dependiendo del contexto del producto.\nLos objetivos de los análisis son determinar requerimientos candidatos para conceptos de productos que van a satisfacer las necesidades, expectativas y restricciones de las partes interesadas y luego traducir estos conceptos a requerimientos. En paralelo con esta actividad, los parámetros que serán usados para evaluar la eficacia del producto son determinados basados en la información del cliente y el concepto preliminar del producto.\nLos requerimientos son validados para aumentar la probabilidad de que el producto resultante funcionará como se espera en el ambiente de producción.\nSP 1: Establecer conceptos operacionales y escenarios\nPráctica: "Establecer y mantener conceptos operacionales y escenarios asociados".\nUn escenario es típicamente una secuencia de eventos que pueden ocurrir en la utilización del producto, el cual es usado para hacer explicitas algunas de las necesidades de las partes interesadas. En contraste, un concepto operacional para un producto usualmente depende de la solución de diseño y del escenario. Ya que las soluciones alternativas no son usualmente definidas cuando se definen los conceptos operacionales iniciales, las soluciones conceptuales son desarrolladas para usarse cuando se analizan los requerimientos. Los conceptos operacionales son refinados a medida que las decisiones sobre la solución son tomadas y requerimientos de más bajo nivel detallados son desarrollados.\nAsí como una decisión de diseño para un producto puede convertirse en un requerimiento para componentes del producto, el concepto operacional puede convertirse en escenarios (requerimientos) para componentes del producto. Los conceptos operacionales y escenarios son desarrollados para facilitar la selección de soluciones para componentes del producto que podrán, cuando se implementen, satisfacer el uso esperado del producto. Los conceptos operacionales y escenarios documentan la interacción de los componentes del producto con el ambiente, los usuarios y otros componentes del producto independiente de la disciplina de ingeniería. Los escenarios pueden incluir secuencias operacionales, si éstas son una expresión de los requerimientos del cliente más que conceptos operacionales.\nSP 2: Establecer una definición de la funcionalidad requerida\nPráctica: "Establecer y mantener una definición de la funcionalidad requerida".\nLa definición de funcionalidad, también referida como "análisis funcional", es la descripción de lo que se pretende que el producto haga. La definición de funcionalidad puede incluir acciones, secuencias, entradas, salidas u otra información que dé a conocer la manera en la cual el producto va a ser usado.\nEl análisis funcional no es lo mismo que el análisis estructurado en Desarrollo de Software y no supone un diseño de software orientado a la funcionalidad. En el diseño de software orientado al objeto, se relaciona con definir los denominados "servicios" o "métodos". La definición de funciones, sus agrupaciones lógicas y sus asociaciones con requerimientos es referido como arquitectura funcional.\nSP 3: Analizar requerimientos\nPráctica: "Analizar requerimientos para asegurar que ellos son necesarios y suficientes".\nA la luz del concepto operacional y los escenarios, los requerimientos para un nivel de la jerarquía del producto son analizados para determinar si ellos son necesarios y suficientes para alcanzar los objetivos de niveles más altos de la jerarquía del producto. Los requerimientos analizados proveen la base para requerimientos más detallados y precisos en niveles inferiores de la jerarquía de productos.\nMientras los requerimientos son definidos, sus relaciones con requerimientos y la funcionalidad definida de más alto nivel deben ser entendidas. Otra de las acciones es la determinación de cuáles requerimientos claves serán usados para medir el avance. Por ejemplo, el peso de un producto o el tamaño de un software pueden ser monitoreados durante su desarrollo basándose en sus riesgos.\nSP 4: Analizar requerimientos para lograr balance\nPráctica: "Analizar requerimientos para balacear necesidades y restricciones de los Stakeholders".\nNecesidades y restricciones pueden abordar costos, cronogramas, funcionalidades, componentes reutilizables, mantenimiento o riesgos.\nSP 5: Validar requerimientos\nPráctica: "Los requerimientos se validan para asegurar que el producto resultante operará como está previsto en el ambiente del usuario"\nLa validación de requerimientos es realizada tempranamente con los usuarios para obtener certeza de que los requerimientos permitirán guiar el desarrollo que resulte en una validación final exitosa. Las organizaciones maduras típicamente realizarán validación de requerimientos de una manera más sofisticada aplicando diversas técnicas y ampliarán la base de la validación para incluir necesidades y expectativas de otras partes interesadas.\nEl PA de Solución Técnica (TS) tiene como propósito diseñar, desarrollar e implementar soluciones a requerimientos. Es aplicable a cualquier nivel de la arquitectura del producto y a cada producto, componente de producto y proceso relacionado con el ciclo de vida del producto. Estos procesos relacionados con el ciclo de vida del producto son desarrollados conjuntamente con el producto y los componentes del producto. Dicho desarrollo puede incluir la selección o adaptación de procesos existentes (procesos estándares) o el desarrollo de nuevos procesos.\nSG 1: Seleccionar soluciones para componentes del producto\nObjetivo: "Soluciones de producto o de componentes del producto son seleccionadas a partir de alternativas de solución".\nLas soluciones alternativas y sus ventajas relativas son consideradas antes de seleccionar una solución. Los requerimientos claves, los temas de diseño y las restricciones son establecidos para ser utilizados en el análisis de soluciones alternativas. Las características de la arquitectura que proveen una base para la mejora y evolución del producto son consideradas. El uso de componentes de producto tipo COTS (Commercial Off The Shelf) es considerado en relación con costos, cronograma, rendimiento y riesgos. Las alternativas tipo COTS pueden ser utilizadas con o sin adaptaciones. En ocasiones, dichos elementos requieren modificaciones en aspectos tales como interfaces o personalización de alguna de sus características para cumplir en mejor forma con los requerimientos del producto.\nUn indicador de buen proceso de diseño es que el diseño fue escogido después de compararlo y evaluarlo con soluciones alternativas. Las decisiones de arquitectura deben ser tomadas. Algunas de estas decisiones pueden requerir un proceso formal de toma de decisiones.\nEn general las soluciones son definidas como un conjunto. Esto significa que al definir la siguiente capa de componentes, la solución para cada uno de los componentes del conjunto es definida. Las soluciones alternativas no son sólo formas distintas de abordar los mismos requerimientos, sino también reflejan un destino diferente de requerimientos entre los componentes del producto que componen el conjunto solución. El objetivo es optimizar el conjunto de requerimientos como un todo y no sus partes.\nSP 1: Desarrollar soluciones alternativas y criterios de selección\nPráctica: "Desarrollar alternativas de solución y criterios de selección".\nLas alternativas de solución deben ser identificadas y analizadas para poder seleccionar una solución equilibrada a través del ciclo de vida del producto en términos de costos, cronograma y rendimiento. Estas soluciones se basan en arquitecturas de producto propuestas que abordan características críticas del producto y abarcan un conjunto de soluciones factibles.\nLas alternativas de soluciones frecuentemente comprenden asociaciones alternativas de requerimientos a diferentes componentes del producto. Dichas alternativas pueden incluir el uso de soluciones COTS en la arquitectura del producto.\nLas alternativas de soluciones cubren el rango aceptable de costo, cronograma y rendimiento. Los requerimientos de componentes del producto son recibidos y utilizados junto con problemas de diseño, restricciones, y criterios para desarrollar soluciones alternativas. Los criterios de selección abordarán típicamente costos (tiempo, recursos humanos y otros gastos) y riesgos (técnicos, de costo y cronograma). Las consideraciones para alternativas de soluciones y criterios de selección incluyen lo siguiente:\n-\tCosto de desarrollo, construcción, adquisición, mantenimiento, soporte, etc.\n-\tComplejidad de componentes del producto y de procesos relacionados con su ciclo de vida.\n-\tRobustez del producto en operación y condiciones de uso, modos de operación, ambientes y variaciones de los procesos relacionados con el ciclo de vida del producto.\n-\tExpansión y crecimiento del producto.\n-\tLimitantes de la tecnología.\n-\tSensibilidad a los métodos y materiales de construcción.\n-\tEvolución de requerimientos y tecnología.\n-\tDada de baja (eliminación) del producto.\n-\tCapacidades y limitantes de usuarios finales y operadores.\n-\tCaracterísticas de productos tipo COTS.\nLa anterior es una lista básica de consideraciones. Las organizaciones debieran hacer proyecciones para acortar la lista de alternativas que sean consistentes con sus objetivos de negocio. Los costos de ciclo de vida del producto pueden estar fuera del control de las organizaciones de desarrollo aunque sea un parámetro atractivo para minimizar costos. Un cliente puede no estar dispuesto a pagar por funciones que cuestan más en el corto plazo pero que en última instancia disminuyen el costo durante la vida útil del producto. En tales casos, los clientes debieran al menos estar informados de las posibilidades de reducir los costos durante la vida útil de un producto. Los criterios utilizados para seleccionar las soluciones finales debieran proveer un enfoque equilibrado de costos, beneficios y riesgos.\nSP 2: Seleccionar soluciones para componentes del producto\nPráctica: "Seleccionar las componentes del producto que mejor satisfacen los criterios establecidos".\nSeleccionar soluciones para componentes del producto que mejor satisfagan los criterios establecidos. Requerimientos de más bajo nivel son generados a partir de la alternativa seleccionada y utilizados para desarrollar el diseño de los componentes de producto. Los requerimientos de interfaz entre componentes de producto son funcionalmente descritos al inicio. Las descripciones de interfaz física son incluidas en la documentación de interfaces hacia elementos y actividades externas al producto.\nLa descripción de soluciones y los fundamentos de la selección son documentadas. La documentación evoluciona a medida que las soluciones y los diseños son detallados, desarrollados e implementados. El mantenimiento de un registro de fundamentos es crítico para la toma de decisiones.\nSG 2: Desarrollar el diseño\nObjetivo: "Diseños del producto y componentes del producto son desarrolladas"\nDiseños de productos o componentes de productos deben proveer el contenido apropiado no sólo para la implementación, sino también para otras fases del ciclo de vida del producto tales como modificación, adquisición, mantenimiento e instalación. La documentación de diseño provee una referencia para apoyar el entendimiento mutuo del diseño por parte de las partes interesadas y así apoyar futuros cambios al diseño ya sea durante el desarrollo como en las fases siguientes del ciclo de vida del producto. Una descripción completa del diseño es documentada incluyendo una completa gama de características y parámetros incluyendo forma, ajuste, función, interfaz, características del proceso de construcción y otros parámetros. Estándares establecidos de diseño de proyecto u organizacionales (listas, plantillas, estructura de objetos) forman la base para alcanzar un alto grado de definición y completitud en la documentación del diseño.\nSP 1: Diseñar el producto o los componentes del producto\nPráctica: "Desarrollar un diseño para el producto o componente del producto".\nEl diseño del producto consiste en dos extensas fases que pueden superponerse en ejecución: diseño preliminar y diseño detallado. El diseño preliminar establece las capacidades y la arquitectura del producto, incluyendo divisiones del producto, identificación de los componentes del producto, estados de sistemas y modos, interfaces principales e interfaces externas del producto. El diseño detallado define completamente la estructura y las capacidades de los componentes del producto.\nLa definición de la arquitectura es guiada a partir de un conjunto de requerimientos de arquitectura. Estos requerimientos expresan los elementos de calidad y rendimiento que son críticos para el éxito del producto. La arquitectura define los elementos estructurales y los mecanismos de coordinación que directamente satisfacen los requerimientos o apoyan su realización a medida que se establecen los detalles del diseño del producto. Las arquitecturas pueden incluir estándares y reglas de diseño que dirigen el desarrollo de los componentes del producto y sus interfaces, así como una guía para ayudar a sus desarrolladores.\nLos arquitectos postulan y desarrollan un modelo del producto, haciendo juicios sobre la asociación de requerimientos con los componentes del producto, incluyendo hardware y software. Múltiples arquitecturas que apoyan las soluciones alternativas pueden ser desarrolladas y analizadas para determinar las ventajas y desventajas en el contexto de los requerimientos de arquitectura.\nLos conceptos operacionales y escenarios son usados para generar casos de uso y escenarios de calidad que se usan para refinar la arquitectura. También son usados como un medio para evaluar qué tan apropiada es la arquitectura para el propósito previsto durante las evaluaciones, las cuales son realizadas periódicamente durante todo el diseño del producto.\nDurante el diseño detallado, los detalles de la arquitectura del producto son finalizados, los componentes del producto son definidos completamente y las interfaces son descritas en su totalidad. Los diseños de los componentes de productos pueden ser optimizados para ciertas características de rendimiento o calidad. A medida que el diseño madura, los requerimientos asignados a componentes de productos de más bajo nivel son monitoreados para asegurar que esos requerimientos son satisfechos.\nSP 2: Establecer un paquete de datos técnicos\nPráctica: "Establecer y mantener un paquete de datos técnicos".\nUn paquete de datos técnicos provee al desarrollador una descripción exhaustiva del producto o de sus componentes a medida que es desarrollado. Dicho paquete también provee flexibilidad de adquisiciones en diversas circunstancias, tales como "Performance-Based Contracting" (PBC) o "Build To Print".\nEl diseño es registrado en un paquete de datos técnicos creado durante el diseño preliminar para documentar la definición de la arquitectura. Este paquete de datos técnicos es mantenido durante toda la vida del producto para registrar detalles esenciales del diseño del producto. El paquete de datos técnicos provee la descripción del producto y sus componentes que apoyan la estrategia de adquisición, o la implementación, producción, ingeniería y fases de soporte logístico del ciclo de vida del producto. La descripción incluye la definición de la configuración requerida del diseño y procedimientos para asegurar el comportamiento adecuado del producto o de sus componentes. Esto incluye todos los datos técnicos aplicables como dibujos, listas asociadas, especificaciones, descripciones de diseño, bases de datos de diseño, estándares, requerimientos de rendimiento, provisiones de aseguramiento de calidad y detalles de empaquetamiento. El paquete de datos técnicos incluye una descripción de la solución alternativa seleccionada a ser implementada.\nUn paquete de datos técnicos debería incluir lo siguiente, si dicha información es apropiada para el tipo de producto y componentes del producto:\n-\tDescripción de arquitectura de producto.\n-\tRequerimientos asignados.\n-\tDescripción de componentes del producto.\n-\tDescripción de los procesos relacionados con el ciclo de vida del producto, si no es descrito como componentes de productos separados.\n-\tCaracterísticas de productos claves.\n-\tCaracterísticas físicas requeridas y restricciones.\n-\tRequerimientos de interfaz.\n-\tRequerimientos de materiales.\n-\tFabricación y requerimientos de manufactura.\n-\tCriterios de verificación usados para asegurar que los requerimientos han sido satisfechos.\n-\tCondiciones de uso (ambientes) y escenarios de uso / operación, modos y estados de operación, soporte, capacitación, manufactura, eliminación del producto y verificaciones a los largo de la vida útil del producto.\n-\tFundamentos de decisiones y características (requerimientos, asignación de requerimientos y opciones de diseño).\nDebido a que las descripciones de diseño pueden contener una gran cantidad de información y pueden ser cruciales para el desarrollo exitoso de los componentes del producto, es aconsejable establecer criterios para organizar y seleccionar la información. Es particularmente útil utilizar la arquitectura del producto como una manera de organizar la información y elaborar vistas claras y relevantes para un tema o característica de interés. Estas vistas incluyen lo siguiente:\n-\tEl ambiente.\n-\tEstados / modos.\nEstas vistas son documentadas en el paquete de datos técnicos.\nSP 3: Diseñar interfaces utilizando criterios\nPráctica: "Diseñar interfaces de componentes del producto utilizando los criterios establecidos".\nEstos diseños de interfaces incluyen lo siguiente:\n-\tEstímulos y características de datos para el software\n-\tCaracterísticas eléctricas, mecánicas y funcionales para hardware\n-\tLíneas de comunicación.\nEl criterio para interfaces frecuentemente refleja parámetros críticos que deben ser definidos, o al menos investigados, para asegurar su aplicabilidad. Estos parámetros son a menudo característicos de un cierto tipo de producto (software, mecánico, eléctrico, de servicio) y son a menudo asociados con seguridad, durabilidad y características de la misión crítica.


El diputado macrista Waldo Wolff quedó en offside: los errores tras su pedido a Massa por las denuncias en Formosa | El Destape\nEl diputado macrista Waldo Wolff quedó en offside: los errores tras su pedido a Massa por las denuncias en Formosa\nLa carta fue enviada al presidente de Diputados, Sergio Massa, pero la petición fue "improcedente". Los detalles.\n29 de enero, 2021 | 17.07\nDesde Juntos por el Cambio realizaron un pedido al presidente de la Cámara de Diputados, Sergio Massa, buscando que realicen visitas a la provincia para constatar el estado en que se encuentran los aislados en los centros para combatir el coronavirus. La idea de los legisladores es que las comisiones de Derechos Humanos y Libertad de Expresión sesionen en Formosa para, a su vez, poder debatir la situación local observando los hechos.\nLo cierto es que tras enviar este documento desde La Nación dieron a entender que el máximo mandatario de la Cámara Baja no respondió y que, al parecer, el pedido "no cuenta con posibilidades de obtener el visto bueno del líder del Frente Renovador", más allá de aclarar que no necesitan una autorización para viajar. Lo cierto es que esto no es verdad: según información de El Destape, la carta enviada por Waldo Wolff es improcedente porque la presentó en Secretaría Privada. Es decir, se equivocó en las formas.\nEste tipo de documentos deben presentarse en la Mesa de Entradas, como ocurre con cada proyecto de ley, declaración o resolución. Además, tampoco tiene lugar su pedido porque al ser el presidente de la Comisión de Libertad de Expresión debe consultar antes a sus integrantes y todos juntos resolver si están de acuerdo en que la reunión debe hacerse en la provincia de Formosa.\nAdemás cabe destacar que la Cámara de Diputados se encuentra en "Período Extraordinario". Esto significa que los legisladores se atienen al temario que presentó el Poder Ejecutivo de Alberto Fernández pero pueden convocarse reuniones informativas a través de las distintas comisiones. El inconveniente pasa porque Juntos por el Cambio no firmó el protocolo de Sesiones Mixtas, por lo que se desconoce de que manera se reúne la comisión del diputado macrista en cuestión.\n"Soy diputado y tengo inmunidad parlamentaria. Así como el secretario de Derechos Humanos pudo entrar y salir, haciéndome un hisopado el día previo, voy a poder entrar y salir de Formosa. Sería un escándalo que me detuvieran, no pueden hacerlo", dijo Waldo Wolff, en diálogo con FM Milenium, con actitud desafiante. A él se suman Mario Negri (UCR); Juan Manuel López (Coalición Cívica); Silvia Lospennato, Omar de Marchi y Álvaro González (PRO), y Brenda Austin y Miguel Bazze (UCR).\nWolff, en el ojo de la tormenta\nNo es la primera vez que se le critican las formas a Waldo Wolff. En su momento, a pesar de ser el presidente de la Comisión de Derechos Humanos y Libertad de Expresión, no respetó esto último y disparó fuertemente contra El Destape. En aquel momento denunció al director Roberto Navarro y a los periodistas del medio, Ari Lijalad y Franco Mizrahi por una supuesta filtración del contenido de un libro administrativo de la Agencia Federal de Inteligencia (AFI). Aquel material había sido incorporado como prueba en la causa de espionaje ilegal por parte del macrismo y por esto, la jueza federal María Servini desestimó el pedido.\nEn aquel momento, el diputado macrista fue uno de los temas más hablados en redes sociales y ante las trabas contra la libertad de expresión, mucha gente pidió la renuncia de la comisión que lleva adelante. Tanto cuando se conoció la denuncia como cuando se desestimó, lo acusaron de intentar censurar para tapar información referida a la gestión anterior de Mauricio Macri.\nDesestimaron la denuncia contra los periodistas de El Destape


diciembre 2016 - Página 2 de 2 - Radio Facenda\nLa aplicación de mensajería instantánea WhatsApp dejará de funcionar en dispositivos viejos, incluido el iPhone 3GS, a finales de este año, informa ‘The Independent’. El servicio, que pertenece a Facebook, ya no estará disponible en sistemas operativos ‘viejos’ como Windows Phone 7, Android 2.1 y Android 2.2. WhatsApp anunció el cambio a principios de año, […]\nLa vida extraterrestre podría existir en la atmósfera superior de las enanas marrones, objetos de transición entre las estrellas y los planetas, según un estudio de astrónomos de la Universidad de Edimburgo, Reino Unido, citado por la revista ‘Science’. En los últimos años, los expertos han detectado en las enanas marrones, bautizadas como ‘estrellas fallidas’ […]\nSi muchos ya están desesperados por que el 2016 termine, los científicos tienen malas noticias: este año durará un poco más de lo común. Según explica la revista ‘Popular Mechanics’, el 31 de diciembre se añadirá un segundo adicional, llamado intercalar, para compensar la ralentización de la rotación de la Tierra, y los relojes de […]\nLos vehículos con motores diésel desaparecerán de las calles de París, Ciudad de México y Madrid en 2025. Este es el acuerdo sin precedentes alcanzado el jueves por sus representantes municipales durante la Cumbre de Alcaldes que se está celebrando en Ciudad de México. Además, se han comprometido a incentivar el uso de vehículos alternativos […]\nCientíficos e investigadores de la Universidad Estatal de Dakota del Norte y del Instituto Smithsoniano de Washington, ambos en EE.UU., encontraron recientemente en la Antártida los fósiles congelados de dos alas de un insecto de 2,36 y 2,40 milímetros, informa Zoo Keys. Los análisis de los restos fosilizados, que fueron localizados cerca del glaciar Beardmore, […]


Video-tutoriales de recetas de panes explicadas paso a paso\nPrepara tu propio pan casero\nHoy prepararemos un riquísimo Pan de Aceite. Anímate, te encantará!!\nUna textura tierna y un sabor a pan de toda la vida hace que esta receta sea ideal para hacerla\nPastel de verano de piña y atún\nVídeo receta de cómo hacer paso a paso un delicioso Pastel Frío de Piña y Atún con pan de molde,\nBocadillo de pollo y bacon\nBocadillos de Pollo y Bacon. En este video podrán ver cómo preparar un estupendo bocadillo de Bacon y Pollo. Es\nRollos al estilo Sándwich Croque Monsieur\nAprende con este vídeo cómo hacer unos Rollos al estilo Sándwich Croque-Monsieur con Jamón y Queso muy esponjosos. Disfruta de\nAprende con este vídeo cómo hacer un rico sándwich de pollo. La receta está explicada paso a paso y de\nAprende con este vídeo cómo hacer un Pastel Frío de Pollo con Pan de Molde, también conocido como Sandwichón de\nSi tienes ganas de un sándwich diferente, no te pierdas este increíble y sabroso sándwich de cebolla, champiñones y queso\nPastel de bacon y queso con pan de molde\nVídeo de cómo hacer paso a paso un pastel salado de bacon y queso con pan de molde. Es una\nSándwich al horno de queso, jamón y crema\nEn este video les mostraré paso a paso la receta para hacer un delicioso sándwich de crema, jamón y queso\nDobladitas. Pan especial\nExquisito Pan especial. Dobladitas... Fácil y delicioso!!!\nSándwich. Desayuno saludable y delicioso\nDesayuno saludable y delicioso!!\nEmpanada de pollo con masa de hojaldre\nEmpanada de pollo con masa de hojaldre, receta súper fácil. Ingredientes sencillos y un gran sabor. Si quieres llevarte la\nPincho de chaka (palitos de cangrejo)\nCon tan solo tres ingredientes vamos a preparar un pincho con mucho sabor. ¿El ingrediente principal? Chaka o palitos de\nSi algo es conocido en Valencia, es la horchata, y ¿Con qué se acompaña la horchata? ¡Con fartones! De hecho\nSi quieres hacer una empanada gallega casera, lo más importante es que la masa esté bien rica. Te enseño cómo\nEn este vídeo te enseño cómo hacer unas deliciosas tostadas con huevo y queso al horno. Una receta muy fácil\nEn esta vídeo-receta verán cómo hacer un delicioso y tierno pastel de pan de molde estilo pizza de jamón y


Posponen la reunión de Gobierno y prepagas datachaco.com ->\nPosponen la reunión de Gobierno y prepagas\nEl encuentro estaba previsto para este mediodía, luego de que las empresas anunciaron que a partir de enero comenzarían a cobrar copagos a los afiliados.\nEl encuentro estaba previsto para este mediodía.\nLa titular de la cartera sanitaria nacional, Carla Vizzotti suspendió la reunión que iba a tener este mediodía con prestadoras de salud, para dialogar sobre el cobro de un cargo extra a los afiliados. El encuentro se postergó para mañana martes, debido a que uno de los funcionarios claves en esta discusión no podía llegar a tiempo.\nSi bien, de acuerdo a la ley de medicina prepaga, el cobro de copagos no necesita de una aprobación del Gobierno para ser instrumentado, "el impacto está en la población", insistió en declaraciones a radio El Destape.\n"Lo que estamos tratando de hacer es de sentarnos con todos los actores que involucran este aumento para ver si podemos minimizar el impacto en la población", recalcó Vizzotti.\nLas prepagas comenzarán a cobrar un copago desde enero\nDesde FAPS aducen que la medida es por el "aumento de los costos operativos y la cobertura de nuevos tratamientos, con ingresos regulados y atrasados respecto a la inflación, que genera un desfasaje económico, poniendo en peligro la sostenibilidad del sistema".\nDe acuerdo al comunicado, esta situación “obliga a tener que buscar alternativas para financiar el pago de salarios”, a través del cobro de un copago “que quedará a cargo de cada paciente de Prepagas y Obras Sociales de Dirección".


¿Son fiables los créditos rápidos? - Credito y Tarjetas\nmayo 23, 2018 junio 8, 2018 Creditos\n¿ Son fiables los créditos rápidos ? Esta es una pregunta que se hace mucha gente ya que las entidades de crédito que ofrecen dinero urgente no suelen estar sujetas a tantas regulaciones como los bancos tradicionales.\nAdemás, hay que tener en cuenta que un crédito rápido tiene menos barreras de entrada, es más fácil conseguirlos y eso es un hecho, pero ¿podemos fiarnos de las entidades que ofrecen estos créditos?\nEs posible que hace unos años este tipo de entidades estuviesen menos reguladas e incluso controladas, pero a medida que las necesidades de crédito han ido aumentando y que las empresas de crédito online han ido creciendo, también han ido creciendo los controles que se les aplican.\nHoy en día las empresas de crédito rápido por internet son muy fiables y nada tienen que ver con prestamistas tradicionales que se utilizaban hace años como último recurso para conseguir un microcrédito de forma urgente.\nEmpresas como Cofidis, IPF Digital (empresa matriz de Creditea) o 4Finance (empresa matriz de Vivus) son empresas sólidas y que nos pueden ofrecer las garantías de cualquier banco establecido.\nAlgunas empresas muy fiables de créditos rápidos\n¿Por qué sí son fiables los créditos rápidos?\nA la hora de evaluar si son fiables los créditos rápidos debemos tener en cuenta otro aspecto, y es el que como solicitantes de un crédito, nosotros no corremos ningún riesgo realmente, ya que somos los que recibimos el dinero en nuestra cuenta. El auténtico riesgo lo corren las empresas de crédito online, ya que antes de conceder un crédito, analizan los ratios de riesgo de cada solicitante.\nQué analizan las empresas antes de conceder un crédito rápido\nIngresos. En primer lugar comprueban si tienes ingresos estables y la cuantía de éstos. Normalmente si se cumplen el resto de requisitos, con tener unos ingresos de 900 Eur al mes no debería haber mayores problemas para que la solicitud de crédito online sea aceptada.\nEstabilidad laboral. Un contrato fijo suaviza el resto de requisitos, ya que la entidad de crédito asume que con ese contrato las posibilidades de que devolvamos los plazos del crédito son mucho mayores, y su riesgo disminuye.\nPatrimonio. Dependiendo de la cantidad de crédito que solicitemos en el préstamo puede que la empresa de crédito nos pida algún tipo de garantía con alguno de nuestros bienes. Como es lógico, cuanto mayor sea el valor de esa garantía, menor va a ser el riesgo que asuma la entidad financiera. En algunos casos, como el crédito por tu coche esta garantía es parte indispensable a la hora de obtener el préstamo online. Sin embargo, en el caso de los créditos rápidos no es muy habitual tener que aportar algún bien como garantía del préstamo.\nRegistro de morosos. Estos registros, como RAI o ASNEF pueden ser un obstáculo para que la solicitud de préstamo sea aceptada, pero por un lado, hay empresas que conceden crédito con ASNEF y por otro lado, si la deuda es pequeña, es posible que un número mayor de empresas decidan aceptar la solicitud de crédito. Estar en un registro de morosos no es lo más deseable, pero no es un obstáculo insalvable siempre que el resto de puntos sean positivos.\nCon los puntos anteriores la empresa que concede el crédito reduce su riesgo, con lo que no necesita aplicar mecanismos que les cubra este riesgo y que en algunos casos pueden llegar a ser un poco oscuros. Por eso, su actividad es mucho más transparente y podemos asumir que sí son fiables los créditos rápidos.\nPero hay otro punto que debemos tener en cuenta a la hora de evaluar si son fiables los créditos rápidos y es el hecho de que se solicitan por internet, sin que haya una presencia física de las partes.\nEsto disminuye la confianza, ya que el entorno es más impersonal, pero si cumplimos con las normas básicas de seguridad online, podemos contratar un crédito por internet con la misma confianza que si acudiéramos a una oficina física, con la comodidad de hacerlo desde casa y con la ventaja de poder disponer del dinero en minutos.\nEn este punto, no debemos cuestionarnos si son fiables los créditos rápidos, sino si cumplimos con las normas básicas de protección al operar online, y eso es algo que depende de cada uno. Los créditos son fiables por sí mismos y por eso se han convertido en uno de los instrumentos financieros más utilizados, al ofrecer soluciones a necesidades de dinero urgente en pocos minutos.\nCómo prevenir riesgos en créditos rápidos\nEstas son algunas normas recomendables para evitar o al menos minimizar las estafas al solicitar un crédito online\nMarcas de confianza. Siempre que sea posible, debemos utilizar marcas bien reconocidas y asentadas. Si estas empresas de crédito están operando desde hace años en el mercado es porque son fiables y sólidas y porque han pasado todos los controles de las autoridades económicas.\nEvitar webs falsas. Algunos timadores online intentan imitar webs auténticas para recoger los datos de los usuarios. Asegúrate que la dirección URL de la página comienza por https\nBusca entidades inscritas en el registro público. Esto debe estar especificado en los términos y condiciones, que normalmente se encuentran en un enlace al pie de página.\nNo respondas a emails de entidades bancarias. Hay muchos intentos de fraude que comienzan con un correo que imita al de un banco u otra entidad de crédito. Es lo que se conoce como phishing. Nunca vayas a la web que te indican pinchando en el enlace del correo. Tu entidad de crédito NUNCA va a pedirte que pongas tu usuario y contraseña desde un correo. Si tienes dudas o necesitas hacerlo, escribe directamente la web de tu entidad en el navegador y entra desde ahí.\nLlamadas de teléfono a números desconocidos. A veces desde un correo o desde una web intentan que llames a un número que tiene una tarificación especial para solicitar o informarte de un crédito, y una vez establecida la llamada intentarán mantenerte a la escucha el mayor tiempo posible. Con eso, los estafadores ganan dinero con el tiempo que te mantienen con esta llamada de tarificación muy alta activa.\nEstas son prácticas de seguridad a tener en cuenta no sólo con entidades financieras, sino en la utilización normal de internet. Cumpliendo estas normas, y dada la solvencia y controles que pasan las empresas de créditos, podemos concretar que sí son fiables los créditos rápidos. Sólo asegúrate de tener toda la información y comparar créditos antes de decidirte por solicitar alguno.\nCréditos, Finanzas créditos rápidos. Enlace permanente.


√Update Link Enlace Video La Niña Araña Video Viral @babybeka101 En Twitter￼ – immaku.com - Aocewe.com\n√Update Link Enlace Video La Niña Araña Video Viral @babybeka101 En Twitter￼ – immaku.com\nLink Relacionados Enlace Video La Niña Araña Video Viral @babybeka101 En Twitter\nNew Video La Niña Araña Video Viral @babybeka101 En Twitter\nGallery for Update Link Enlace Video La Niña Araña Video Viral @babybeka101 En Twitter￼\nImmaku.com – Update Link Enlace Video La Niña Araña Video Viral @babybeka101 En Twitter Información viral más reciente.\nHola amigo, reúnase de nuevo aquí con el administrador que le proporcionará la información más reciente e interesante, es decir Update Link Enlace Video La Niña Araña Video Viral @babybeka101 En Twitter\nEn esta discusión hay una continuación de la información de administración que se ha discutido anteriormente. Donde Video La Niña Araña Video Viral @babybeka101 En Twitter esto se ha convertido en el objetivo de muchas personas\nEn la discusión anterior donde Video La Niña Araña Video Viral @babybeka101 En Twitter circula en otras redes sociales, como Twitter y también varios otros\nDe vuelta esta vez viene su última historia de Video La Niña Araña Video Viral @babybeka101 En Twitter, que circuló en una de las redes sociales Twitter.\nPor supuesto, si circula en Twitter, será el objetivo de los internautas que no están al tanto de la nueva información o que han discutido administradores anteriores.\nBueno, ciertamente, a partir de la existencia de esta información más reciente, muchas personas quieren saber y también quieren poder obtener el enlace más reciente Video La Niña Araña Video Viral @babybeka101 En Twitter aqui.\nPor supuesto, lo anterior es un breve vídeo tanyanga se refiere a sus premisas virales New Video La Niña Araña Video Viral @babybeka101 En Twitter bueno, si desea un video que pueda satisfacer el reclamo, por supuesto, el administrador le recomendará las últimas palabras clave originales en Internet.\nVídeo viral de New Video La Niña Araña Video Viral @babybeka101 En Twitter esto hace que todos los usuarios de Internet estén muy ansiosos por verlo.\nPara eso, a continuación, adamin compartirá algunas palabras clave que pueden ayudarlo a obtener la información más reciente en Internet.\nPalabras Clave Más Recientes Video La Niña Araña Video Viral @babybeka101 En Twitter\nBueno, por supuesto, lo anterior es la última palabra clave, por supuesto, esto le permitirá conocer la información que ahora es la más reciente nuevamente.\nPor supuesto, eso es todo lo que el administrador puede discutir sobre la viralnya de este video, bueno, si no se siente satisfecho, utilice el enlace que sin duda le dará al administrador. Para que pueda conocer los videos que algunos de ustedes pueden no conocer.


Propone fomento de Semillas para reforestación - Vanguardia del Pueblo\n12 junio 2018 11:31 pm\nEl ministro de Medio Ambiente y Recursos Naturales, Ángel Estévez exhortó a los países centroamericanos a fomentar los bancos de semillas para la reforestación y preservación de la vida en el planeta.\nEstévez dió la bienvenida a representantes de los países centroamericanos y Norteamérica al encuentro en la sede principal del Ministerio en Santo Domingo para intercambiar experiencia entre los bancos de semilla de los países miembros del DR-CAFTA.\nEn el marco de la iniciativa, que se realiza en la semana del 11 al 16 de Junio, intercambiarán experiencias los representantes de bancos de semillas o viveros de los países miembros del DR-CAFTA y el Banco de Semillas de Boca de Nigua. Participarán técnicos forestales y gerentes de bancos de semillas de Costa Rica, Guatemala, El Salvador, Honduras y Nicaragua y contará con el apoyo técnico de dos peritos del Laboratorio Nacional de Semillas del Servicio Forestal de EEUU.\nSe busca fortalecer a los productores de semillas y las iniciativas de reforestación de la región, a través de la sistematización de conocimientos, protocolos y políticas, el desarrollo de mejores prácticas, y de alianzas regionales.\nLos delegados se trasladan el miércoles 13 en la tarde al Jardín Botánico Nacional para verificar en el terreno “sobre la conservación de especies endémicas en la República Dominicana, y el jueves y el viernes irán al Banco de Semilla de Boca de Nigua, San Cristóbal, donde harán un recorrido por las instalaciones, conocerán los protocolos y medidas de conservación y restauración.\nEstévez agradeció a los Estados Unidos por el apoyo que le ha dado a la República Dominicana y destacó los esfuerzos y acciones llevadas a cabo en coordinación con los países de Centroamérica en materia de promoción y ejecución de proyectos forestales.\nLiteratura y juego para el fomento de la lectura


DГ©jame contarte mГЎs acerca de CГіmo funciona eDarling? – Zom Logistics Company\nY es los cuales con mГЎs en 8 aГ±os do historia, eDarling sera la web de contactos lГder en buen parte del planeta y cuenta en la actualidad con millones en usuarios los cuales buscan votre perfecciГіn durante forma do pareja disadvantage la los cuales conseguir sustentar la relaciГіn seria y estable. Una do las cosas los cuales consiguen dentro de comГєn las personas los cuales se ven en la web en contactos parece el hecho de que se trata do personas riguroso los cuales buscan el amor en su vida; o al menos alguien con el fin de pretender una relaciГіn; puesto que estГЎn seguros de- lo que quieren y estГЎn dispuestos the cualquier cosa con tal de- conseguirlo! Esto existe la posibilidad de gracias al realizado de que las personas los cuales se registran en se encuentra website de- contactos deberГВЎ realizar un experiment de personalidad disadvantage el que posteriormente se realizarГЎ un bon examination en compatibilidad con el www.datingranking.net/es/match-review/ resto en usuarios.


El ayuntamiento de Palos de La Frontera recibe un premio por su gestión deportiva\nUsted está en:Portada»Deportes»El ayuntamiento de Palos de La Frontera recibe un premio por su gestión deportiva\n1 mayo 2013 Deportes, Polideportivo\nPremio a la gestión deportiva al Ayuntamiento de Palos de La Frontera.\nEl pasado viernes el Ayuntamiento de Palos de la Frontera fue galardonado con el Premio a la Mejor Entidad Local de Andalucía otorgado por la Asociación Andaluza de Gestores del Deporte. Esta entidad convoca anualmente sus premios Agesport con el objetivo de distinguir a las personas y entidades que más hayan destacado por su contribución en la gestión del deporte andaluz. Palos de la Frontera, ha sido según el jurado, la localidad andaluza de entre 7.500 y 15.000 habitantes que ha acreditado más méritos, en cuanto a actividades, programas, planes, infraestructuras y recursos en general, dedicados a la promoción y fomento del deporte. El Alcalde, Carmelo Romero, recogió la distinción y se mostró muy satisfecho por el reconocimiento al trabajo que se realiza en su localidad.\nFueron doce los premiados en las distintas categorías convocadas. El sevillano Ignacio Revuelta se llevó el Premio al Mejor Gestor de 2012 y el Gran Premio de España de Motociclismo de Jerez, se hizo con el que se destina al Mejor Evento Deportivo Celebrado en Andalucía. Cajamar se llevó el premio a la Mejor Empresa Patrocinadora del Deporte y también hubo premios para la Mejor Publicación; la Mejor actividad, Programa o Plan Deportivo, que se llevó la Diputación de Almería o; para la Mejor Iniciativa o Innovación. Benalmádena, Gabias y Doña Mencía fueron también galardonadas como entidades locales con buena gestión deportiva.\nTambién hubo menciones especiales, el ayuntamiento de Granada por ejemplo por la Política Deportiva Social en los programas que desarrolla con los discapacitados y con los jóvenes en riesgo de exclusión social. Un premio a la gestión Deportiva que recogió su alcalde D. José Torres Hurtado, con el que al primer edil Palermo pudo conversar distendidamente. La Asociación Andaluza de Gestores del Deporte y la Federación Española de Asociaciones de Gestores Deportivos (FAGDE) entregaron sus premios anuales en una gala celebrada en el Carmen de los Mártires, en Granada.\nGracias al trabajo realizado durante todos estos años y a la inversión realizada tanto en recursos materiales, como humanos y económicos, Palos de la Frontera ha conseguido ofrecer unos servicios deportivos de primer nivel equiparables con los de cualquier gran ciudad. En Palos se puede practicar casi todos los deportes. El Coordinador municipal de actividades deportivas, Juan Daniel Romero , también estuvo presente en el acto y alabó la gestión que desde el Gobierno se hace en pro del deporte Palermo. Por último, el alcalde puso en valor el trabajo constante e incansable del personal del Polideportivo que con su esfuerzo y dedicación hacen posible este tipo de éxitos.\n“Por méritos propios”\nLas ocho escuelas deportivas municipales de Ajedrez, Balonmano, Gimnasia Rítmica, Tenis, Baloncesto, Fútbol, Kárate y Vela, acogen a niños en categorías desde prebenjamín hasta juvenil o en grupos de Iniciación o Perfeccionamiento. En natación se imparten cada año unos 10 cursos en los que se inscriben aproximadamente 350 personas. A las clases de natación pueden asistir desde bebes a personas mayores; hay natación terapéutica y de rehabilitación, natación para niños, para adultos y para preescolar. Se abarca a toda la población que tenga esta inquietud.\nA los cursos de natación, se suman otra veintena de actividades deportivas, entre las que destaca por su aceptación en los últimos tiempos el Ciclo Indoor, con cinco turnos y más de 150 plazas ofertadas este año. Además el Ayuntamiento ofrece clases de aeróbic, gimnasia correctiva, mantenimiento masculino y femenino, Pilates, Body fitness system y psicomotricidad.\nComo actividades más puntuales mencionar la Media Maratón “Palos de la Frontera Cepsa” de la que se han celebrado ya 14 ediciones y en la que los participantes, que rondan el millar, recorren 21 kilómetros. También destaca la Regata Palos-Lagos. Cada mes hay un acontecimiento deportivo, el día del Aeróbic; el Torneo de Ajedrez; el Día de la Bici, el Día del Balonmano, el Torneo de Rítmica, el Día del Baloncesto, el Circuito Ciclista, el Torneo de kárate, y el Torneo de Skate, entre otros. También están en la agenda la clausura de los Juegos Deportivos municipales y el Verano Deportivo AIQB.\nEn diciembre la pista de hielo reúne a más de 5.000 personas que disfrutan del patinaje durante el periodo vacacional navideño. No debemos olvidar las actividades en el medio natural que se desarrollan en el término de Palos de la Frontera. La costa de Mazagón ofrece la posibilidad de la práctica del kitesurf y surf y los acantilados arenosos posibilitan la práctica del vuelo en parapente y paramotor.\nCon respecto a las actividades náuticas destaca la escuela de vela que cuenta con una veintena de barcos de vela ligera que sirven para formar cada año a varios centenares de niños y adultos. Asimismo en Mazagón, y en verano se instalan en la playa las infraestructuras necesarias para la práctica deportiva en la costa.\nPalos de la Frontera cuentan entre sus instalaciones deportivas, con un pabellón de usos múltiples, una pista polideportiva exterior, pistas de tenis, pádel y skate, un recódromo, 1 piscina climatizada, 2 piscinas de verano, 3 campos de fútbol (una de césped natural y, dos de césped artificial uno de fútbol 11 y otro de fútbol 7), un circuito de bicicross, y dos pabellones. Este complejo deportivo pronto se ampliará con una pista de atletismo y un spa. Palos de la Frontera a través de su concejalía de deportes ofrecen a sus ciudadanos una gran variedad de actividades deportivas y de ocio, todas ellas a un precio muy asequible.


Hoteles cerca Parque Valle Waimea, Haleiwa - Hoteles.com\nHoteles en Parque Valle Waimea - Haleiwa\nHoteles cerca Parque Valle Waimea\nBuscar Hoteles cerca Parque Valle Waimea\n¿Cuándo viajarás a Haleiwa?\nBuscar Hoteles en Parque Valle Waimea, Hawai en el mapa\nHoteles en Parque Valle Waimea\n¿Buscas un hotel cerca de Parque Valle Waimea? ¡Encuéntralo fácilmente en Hoteles.com! Con cientos de miles de hoteles al alcance de tu mano y bolsillo, sin duda, encontrarás entre nuestros 66 hoteles la mejor opción en Haleiwa cerca de Parque Valle Waimea.\nEstos son los 3 hoteles en Parque Valle Waimea más reservados en el último minuto:\nHoteles cercanos Parque Valle Waimea\nParque Valle Waimea es uno de los príncipales puntos turísticos de Haleiwa, y qué mejor que hospedarse lo más cerca posible y estar justo en el centro de la acción. Ya sea que se trate de un evento, museo, teatro o monumento, en Hoteles.com encontrarás una infinidad de opciones que se ajustan a tus necesidades y presupuesto. Haz tu búsqueda y elige entre hoteles con el mejor precio.\nLos hoteles cerca de Parque Valle Waimea ofrecen una larga lista de servicios y amenidades para satisfacer tus necesidades durante tu estancia, como wifi gratuito, teléfono, televisión o refrigerador. Algunos cuentan con balcones o terraza, que te permitirán admirar las atracciones de Haleiwa desde tu habitación.\nToma en cuenta que Parque Valle Waimea puede ser una atracción muy visitada, especialmente en temporada alta, y muchos clientes prefieren hospedarse cerca. Reserva con anticipación, para garantizar tu hotel cerca de Parque Valle Waimea y evitar contratiempos. Hoteles.com te ofrece la mejor opción de hoteles en Haleiwa, para que elijas el establecimiento ideal, con el mayor beneficio.\nCómo ahorrar al reservar hoteles cerca Parque Valle Waimea