iso 27001. unidad 2

ISO 27001. unidada 2

ISO 27001.

La información es un activo que como otros activos importantes tienen valor y requiere en consecuencia una protección adecuada.  La seguridad cibernética es un conjunto de tecnologías, procesos y prácticas diseñadas para proteger, computadores, programas y datos de algún ataque, daño o acceso no autorizado. Al pensar en las políticas, procedimientos y tecnologías necesarias para la ciber-seguridad queda claro que es un asunto complicado y hay quienes se peguntan si es posible llevarlo todo a cabo sin olvidar algo; efectivamente ISO 27001 es una norma internacional ampliamente aceptada que define la forma de gestionar la seguridad de la información y está posicionándose como el marco para proteger los activos digitales.

ISO-27001 es una norma internacional ampliamente aceptada que define la forma de gestionar la seguridad de la información y está posicionándose como el marco para proteger los activos digitales; dicha norma define cómo organizar la seguridad de la información en cualquier tipo de organización, constituye la base para la gestión de la seguridad de la información.

Este estándar internacional promueve la adopción de un enfoque del proceso para establecer, implementar, operar, monitorear, revisar, mantener y mejorar el SGSI de una organización.

Algunas de las ventajas al usar esta norma es que mejora la comprensión de las exigencias del negocio, protege la información ante las amenazas e identifica fácilmente las debilidades.

La norma ISO 27001 determina cómo gestionar la seguridad de la información a través de un sistema de gestión de seguridad de la información; el ciclo de estas cuatro fases nunca termina, todas las actividades deben ser implementadas cíclicamente para mantener la eficacia del SGSI. Las fases son las siguientes:

Para establecer y gestionar un Sistema de Gestión de la Seguridad de la Información en base a ISO 27001, se utiliza el ciclo continuo PDCA, tradicional en los sistemas de gestión de la calidad.

Plan (planificar): establecer el SGSI.

Do (hacer): implementar y utilizar el SGSI.

Check (verificar): monitorizar y revisar el SGSI.

Act (actuar): mantener y mejorar el SGSI.

Planificar: Establece política, objetivos, procesos y procedimientos SGSI relevantes para manejar el riesgo y mejorar la seguridad de la información para entregar resultados en concordancia con las políticas y objetivos generales de la organización.

Hacer: Implementar y operar la política, controles, procesos y procedimientos SGSI.

Verificar: Evaluar y, donde sea aplicable, medir el desempeño del proceso en comparación con la política, objetivos y experiencias prácticas SGSI y reportar los resultados a la gerencia para su revisión.

Actuar: Tomar acciones correctivas y preventivas, basadas en los resultados de la auditoría interna SGSI y la revisión gerencial u otra información relevante, para lograr el mejoramientos continuo del SGSI.

Esta norma abarca todos los tipos de organizaciones, especifica los requerimientos para la implementación de controles de seguridad personalizados para las necesidades de las organizaciones individuales o partes de ella.

caso de estudio unidad 2

De acuerdo con el caso de estudio, y a la lectura realizada, atender los siguientes cuestionamientos:

1.- Cuantas y cuáles son las etapas del CMMI:

7 etapas; implementación, desarrollo, proyecto, producto, nivel de madurez, áreas de proceso y prácticas. 

2.- Cuantas y cuáles son las etapas del modelo MOPROSOFT:

3.- ¿identificas alguna similitud, o alguna de las etapas son las mismas en los dos modelos? ¿Cuales?

4.-¿Cuales crees que fueron los motivos de la empresa para implementar CMMI apoyándose con MOPROSOFT y no quedarse solo en este ultimo?

5.- ¿Qué es un Indicador y para que se utilizan en la implementación de un Sistema de Calidad en desarrollo de Software?

6.-¿Quiénes son los Actores principales en la implementación de un Sistema de Gestión de Calidad?

7.-¿Tomando como base la lectura, como pudiera ser un Formato para llevar a cabo una Reunión dentro de la empresa? Elabóralo.

8.- De acuerdo a lo visto en clase, investigado y en el caso de estudio, ¿cual sería tu recomendación para una empresa de TI que quiera implementar un sistema de Gestión de la Calidad?

normas tcp unidad 1

Team Software Process (TSP). unidad 1

Team Software Process (TSP).

Todos tenemos una manera particular de trabajar, pero en las Tecnologías de la Información, debemos ser capaces de adaptarnos a estándares que nos permiten desempeñarnos en cualquier ambiente y en cualquier industria. Para ello existen normas como TSP. El TSP es una metodología para dirigir el trabajo de mejora y desarrollo de software además de establecer un entorno donde el trabajo efectivo de equipo sea normal y natural. Cuando fracasa un proyecto de software es, en la mayoría de los casos, por un problema de equipo y no por problemas técnicos, para eso el TSP nos ayuda a que esto no ocurra. Las herramientas y procesos del TSP procuran obtener medios para crear escalabilidad de los participantes, corregir desviaciones de cronograma y subsanar problemas de calidad, generados por los procesos utilizados por el grupo.

Los principales objetivos de este trabajo son, conocer bien la funcionalidad del TSP; para así poder implementarlo adecuadamente para obtener muy buenos resultados a la hora de aplicarlo a cualquier proyecto que queramos. Esta herramienta nos será de muy buena utilidad, por eso es muy importante el conocerla muy bien.

Comenzaremos por describir que es el TSP; es un conjunto de disciplinas que orientan el desarrollo del sistema de forma organizada dentro de procesos estructurados, con el propósito de obtener sistemas de la más alta calidad. Es un método de establecimiento y mejora del trabajo en equipo para procesos software.

Es un complemento del PSP puesto que, mientras el PSP es un conjunto de procesos aplicados en el ámbito individual, el TSP incluye todo el equipo.

TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que la organización pueda establecer prácticas de ingeniería avanzadas y así obtener productos eficientes, fiables y de calidad. El TSP tiene dos componentes principales: un componente de creación de equipo y un trabajo en equipo o componente de gestión.

Ofrece un contexto disciplinado para el trabajo de ingeniería. La motivación principal es que los ingenieros siguiendo esta metodología pueden hacer un excelente trabajo. Los ingenieros deben estar bien capacitados, bien entrenados y deben ser bien dirigidos por un miembro calificado que entienda bien la metodología del TSP. El objetivo principal del TSP es guiar debidamente esos equipos de ingenieros. Este proceso específica los pasos necesarios para establecer un ambiente de trabajo en equipo eficaz. Antes de que los miembros del equipo de trabajo puedan participar en el equipo de TSP, deben saber cómo organizar bien su trabajo. Se requiere que el equipo o el personal se entrene primero con el Personal Software Process (PSP).

TSP ha permitido resolver problemas típicos de negocio: predictibilidad de costo y tiempo, mejora de productividad y ciclos de desarrollo, mejora de calidad de productos; los equipos encuentran y reparan defectos en etapas tempranas del proceso de desarrollo. Esto reduce de manera importante el tiempo de pruebas.

Entornos:

Estructura de TSP:

Objetivos del TSP:

Generar un marco basado en PSP.

Desarrollar productos en varios ciclos.

Establecer estándares para medir la calidad y el comportamiento.

Proporcionar métricas para equipos.

Evaluar roles y equipos.

Guías para solución de problemas en equipos.

Metodología TSP.

Ciclo de vida de TSP:

Es una serie de ciclos que inician con la declaración de las necesidades del producto y terminan con la entrega del producto final.

Ø  Lanzamiento.

Ø  Estrategia.

Ø  Planeación.

Ø  Requerimientos.

Ø  Diseño.

Ø  Implementación.

Ø  Prueba.

Ø  Postmortem.

-          Lanzamiento: Durante esta fase, y siendo el primer ciclo, se realiza una revisión de los objetivos del curso.

-          Estrategia: Se crea un diseño conceptual del producto y se establece la estrategia de desarrollo decidiendo que se producirá en cada ciclo.

-          Planeación: Se propone además un plan de calidad que fije parámetros a ser alcanzados.

-          Requerimientos: Análisis de las necesidades del sistema y especificación de requisitos.

-          Diseño: Diseño de alto nivel, donde se especifica y examina cada parte identificada.

-          Implementación: Diseño detallado, producción de código, revisión, compilación y prueba unitaria.

-          Prueba: Se integran todos los programas. Fundamental contar con un plan de prueba con casos de prueba identificados.

-          Postmortem: Análisis del producto, documentación el ciclo, generación de las evaluaciones del equipo, y presentación del estado del proyecto.

RESULTADOS:

Igual que cualquier modelo de administración de proyectos de software bien llevados, comienza con un proceso de inicio del proyecto en el que se establecen las estrategias, se establecen los objetivos, se establecen cuales son los roles y quiénes son los responsables de cada uno de esos roles en el proyecto, se establecen los planes individuales, se establecen las métricas que se van a llevar y se reparte el trabajo, se ejecuta el trabajo, se le da seguimiento y al final se determina que tan cerca o que tan lejos estuvimos en la ejecución de los planes y que tan buena o que tan mala fue la calidad del trabajo hecho.

El resultado que se debe de obtener con este trabajo es el claro entendimiento de lo que es el TSP, sus funcionalidades, su ciclo de vida, etapas y todas sus características.

CONCLUSIONES:

Es importante desarrollar proyectos de TI de forma estandarizada por la credibilidad por una parte, confianza y predictibilidad, siempre es relativamente fácil ejecutar un proyecto cuando tienes a un grupo de personas experimentadas en el ambiente concreto, en el negocio concreto, en las prácticas especificas que estas ejecutando.

Se aprendió que el TSP se basa en que los ingenieros deban conocer bien su trabajo y que puedan implementar un plan para poderlo realizar mejor, cuando el plan se implementa bien, pueden ahorrarse tiempo en realizar el trabajo, pueden obtener mejor calidad del producto. En México se requiere que más gente se interese por la calidad de nuestros productos, para su gente se involucre en ella y para ello se requiere adoptar una metodología de organización que nos lleve a ella. La implementación de una metodología organizacional permite a los ingenieros hacer mejor su trabajo, ahorrar tiempo y dinero, poder planear su trabajo y ofrecer mejor calidad.

NORMAS Y ESTÁNDARES DE CALIDAD PARA PROYECTOS DE T.I.

NORMAS Y ESTÁNDARES DE CALIDAD PARA PROYECTOS DE T.I.

Cuando una empresa enfrenta proyectos de desarrollo de proyectos de T.I., debemos tener presente que la calidad de un producto está vinculada directamente al proceso con que es generado. Se lleva a cabo u  proceso el cual es un conjunto de prácticas relacionadas entre sí, llevadas a cabo a través de roles y por elementos automatizados, que mediante recursos y a partir de insumos, producen un producto satisfactorio para el cliente. La madurez de un proceso es el nivel al cual está explícitamente documentado, gestionado, medido, controlado y continuamente mejorado.

En este marco, un modelo de procesos es un conjunto estructurado de elementos que describen las características de procesos efectivos y de calidad, indicando “qué hacer”, no “cómo hacer” ni “quién lo hace”.

Antes de hablar de las normas y estándares se tiene que conocer los conceptos.

Una norma es una especificación que reglamenta procesos y productos para garantizar la interoperabilidad. Una norma de calidad es una regla o directriz para las actividades, diseñada con el fin de conseguir un grado óptimo de orden en el contexto de la calidad. Las normas son documentos técnicos.

Los estándares. Son la redacción y aprobación de normas que se establecen para garantizar el acoplamiento de elementos construidos independientemente, así como garantizar el repuesto en caso de ser necesario, garantizar la calidad de los elementos fabricados y la seguridad de funcionamiento. Es el proceso de elaboración, aplicación y mejora de las normas que se aplican a distintas actividades científicas, industriales o económicas con el fin de ordenarlas y mejorarlas.

La diferencia es que una norma es un proceso que tiene que atravesar un producto para que cumpla con la ley mientras que el estándar es el grado de calidad con el que debe de contar un producto. La norma te da parámetros para hacer algo, mientras lo estándar es lo que comúnmente se hace.

Norma/Estándar.	Organismo que regula.	Aplicación.
IEEE 610.12-1990.	IEEE.	Identifica los términos que se utilizan actualmente en el campo de la ingeniería de software.
ISO/IEC/IEEE.	IEEE.	Establece un marco común para los procesos de ciclo de vida del software, con una terminología bien definida.
CMMI.	ISO.	Mejora de procesos de construcción de software.
PSP.	ISO.	Permite estimar cuanto se tarda un individuo en realizar una aplicación de software.
PSP-TSP.	ISO.	Predice el tiempo y tamaño del software administración del tiempo.
ISO 9000-2000.	ISO.	Establece sistemas de calidad, documenta, mide, controla y mejora los procesos de una organización.
NORMA ISO9001.	ISO.	Son requisitos para una organización que necesita demostrar su capacidad para proporcionar de forma coherente productos que satisfagan los requisitos del cliente.
NORMA ISO 9126.	ISO.	Permite a determinados usuarios, alcanzar objetivos especificados con la efectividad, la productividad, la seguridad de uso y la satisfacción.
SCE.	CMMI.	Éste es el método desarrollado para evaluar los procesos software de una organización con el objetivo de determinar su capacidad.

Conclusión:

Día con día las organizaciones oficiales y los consorcios de fabricantes están gestando estándares con el fin de optimizar la vida diaria. En la industria global de redes, los fabricantes que puedan adoptar los estándares a sus tecnologías serán los que predominen en el mercado. Los fabricantes tienen dos grandes razones para invertir en estándares.

NORMAS Y ESTÁNDARES DE CALIDAD PARA EL DESARROLLO DE SOFTWARE UNIDAD 1

NORMAS Y ESTÁNDARES DE CALIDAD PARA EL DESARROLLO DE SOFTWARE

Modelo EFQM (European Foundation for Quality Management):

La Fundación Europea para la Gestión de la Calidad (EFQM) fue fundada en 1988 con el objetivo de elevar la calidad de los procesos.

La EFQM constituye un marcho de trabajo propicio para la autoevaluación de las organizaciones y la mejora continua de la calidad de los productos; no se considera un estándar propiamente de validación, verificación y calidad de software ya que fue creado inicialmente para gestionar la calidad de cualquier producto, sistema o servicio.

Este es un modelo de excelencia que se aplica a los procesos industriales en general, pero en materia de calidad pude ser aplicado a los procesos de desarrollo de software ya que tienen en cuenta un rol clave; la mejora de la efectividad y la eficiencia de las organizaciones al reforzar la importancia de la calidad en todos los aspectos de sus actividades.

También contribuye asistiendo y estimulando el desarrollo de políticas para el mejoramiento de la calidad.

El modelo europeo es un modelo no normativo que sirve a las organizaciones como una autoevaluación y mejora continua de la calidad de sus productos.

Modelo FMEA (Failure mode and effects analysis):

El desafío es diseñar con calidad y confiabilidad temprano en el ciclo de desarrollo de software, el análisis de los modos y de los efectos de fallo (FMEA) es una metodología para analizar problemas potenciales de la confiabilidad temprano en el ciclo de desarrollo donde es más fácil tomar acciones para superar estas ediciones, de tal modo realzando confiabilidad con diseño.

FMEA se utiliza para identificar modos de fallos potenciales en los sistemas, para determinar su efecto sobre la operación del producto, y para identificar acciones correctivas para atenuar las faltas.

Por lo que se recomienda el uso temprano y constante de FMEA en el proceso del diseño para que el ingeniero diseñe sin faltas y produzca productos agradables, confiables, seguros, y de alta calidad.

FMEA también nos ayuda a capturar la información histórica que se convertirán en métricas para el uso en la mejora futura del producto.

Hay varios tipos de FMEA, algunas se utilizan mucho más que otras.

FMEA debe ser hecho siempre que las faltas significaran daño o lesión potencial al usuario del sistema que es diseñado.

Estándar ISO 9126 del IEEE y la Mantenibilidad:

El modelo de calidad establecido en la primera parte del estándar ISO 9126-1 ha sido desarrollado en un intento de identificar los atributos claves de calidad para el software:

funcionabilidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad.

Estos atributos son mencionados en muchos de los estándares, pero el IEEE (Instituto de Ingeniería de Electricidad y Electrónica) lo hace de una forma clara precisando en cada uno de los atributos que características del software deben ser revisados, además se identifican para cada atributo los subatributos logrando un estándar dentro de los modelos para la validación, verificación y calidad de software.

El estándar provee un entorno para que las organizaciones definan un modelo de calidad para el producto software; no obstante, cada organización tendrá la tarea de especificar precisamente su propio modelo.

Esto debería ser hecho especificando los objetivos a alcanzar según las métricas de calidad, las cuales evalúan el grado de presencia de los atributos de calidad.

ISO 9126 distingue entre fallos y no conformidad, siendo un fallo el no cumplimiento de los requisitos previos, mientras que la no conformidad afecta a los requisitos especificados.

Una distinción similar es hecha entre la validación y la verificación.

Este estándar está pensado para los desarrolladores, adquirentes, personal que asegure la calidad y evaluadores independientes, responsables de especificar y evaluar la calidad del producto software, por tanto, puede servir para validar la completitud de una definición de requisitos, identificar requisitos de calidad de software, objetivos de diseño y prueba, criterios de aseguramiento de la calidad.

La calidad de cualquier proceso del ciclo de vida del software influye en la calidad del producto software que, a su vez, contribuye a mejorar la calidad en el uso del producto.

Normas ISO:

Las normas ISO (Organización Internacional para los Estándares) han desarrollado una serie de norma y modelos para la evaluación de la calidad de productos aplicables a productos generales, adaptándose casuísticamente al área de producción de software, en las que se exponen los conceptos de calidad para aplicarlos mejor al producto terminado (software) que al proceso de desarrollo.

CMM:

El CMM (Capability Maturity Model for Software), es decir, Modelo de Madurez de Capacidades. Fue creado por el Software Engineering Institute (SEI) y tiene como Meta el describir los elementos principales para llegar a cabo los procesos de software de una forma efectivos. El CMM consiste en una serie de procedimientos destinados a evaluar y mejorar los procesos de desarrollo, implementación y mantenimiento del software. Aunque aún está envías desarrollo, es un estándar que la industria acepta para evaluar y garantizar la calidad y madurez de sus aplicaciones.

Beneficios de la implantación del modelo CMM:

Mayor efectividad en la detección de errores a lo largo del ciclo de vida del desarrollo del software, reduciendo drásticamente el número de defectos.

Reducción de las desviaciones en plazo de los proyectos.

Mayor tolerancia al cambio e incremento de la capacidad de adopción y adaptación de nuevas Tecnologías.

Mejora en la rapidez y efectividad de respuesta ante exigencias del negocio.

Mejora en la colaboración y comunicación.

Mitigación de Riesgo.

Reducción de los costes del proyecto.

SPICE:

SPICE es un acrónimo inglés de Simulation Program with Integrated Circuits Emphasis (Programa de simulación con énfasis en circuitos integrados). Es un estándar internacional cuyo objetivo es simular circuitos electrónicos analógicos compuestos por resistencias, condensadores, diodos, transistores, etc. El Software Process Assessment (SPA) y el proyecto SPICE tienen sus orígenes en el creciente uso y dependencia de la Tecnología de Información que en consecuencia dio el incremento de frustración e incumplimiento de expectativas por parte de los desarrolladores y los usuarios de software. Al principio de los 80´s, los militares de E.U. y del Reino Unido se propusieron mejorar el mecanismo de selección de proveedores de software con el objetivo de detener el creciente costo de software, reducir riesgos en su desarrollo y mejorar la calidad de los productos de software. También se le conoce como norma ISO/IEC 15504 que es un emergente estándar internacional de evaluación y determinación de la capacidad y mejora continua de procesos de ingeniería del software, con la filosofía de desarrollar un conjunto de medidas de capacidad estructuradas para todos los procesos del ciclo de vida y para todos los participantes. Es el resultado de un esfuerzo internacional de trabajo y colaboración y tiene la innovación, en comparación con otros modelos, del proceso paralelo de evaluación empírica del resultado.

Características:

En el desarrollo de software se centro en los proyectos de construcción que presentan características particulares.

Metodología:

Relativas a la estrategia.

Relativas a la gestión.

Relativas al alcance.

Relativas al tiempo.

Relativas al costo.

Relativas a los recursos.

Relativas a la persona.

Relativas a la comunicación.

Relativas al riesgo.

Relativas a los aprovisionamientos.

NORMAS APLICABLES PARA PROYECTOS TI

Noma ISO.

Norma MOPROSOFT.

Norma NYCE.