TAREA DE EL DÍA 02 DE JULIO DEL 2011.

DATOS GENERALES:

Materia: .INGENIERÍA DE SOFTWARE II Unidad y Tema:

Actividad (Numero y nombre): ACTIVIDADES DE LA SEMANA No. 1.

Matrícula(s):

Nombre (s): Jorge Cortés Domínguez

Profesor:MSC.JoséAntonioRosalesBarrales Fecha en la cual el profesor encarga la actividad: 02/07/2011

Fecha en la cual el profesor recibe la actividad: 17/07/2011

Preguntas Frecuentes de Ingeniería de software

¿Qué es ingeniería? Conjunto de técnicas que nos permiten llegar a un resultado mediante modelos y el ingenio humano, Ingeniería confluyen la ciencia, la técnica y la capacidad de unirlo (el ingenio) para solucionar cuestiones prácticas, concretas. ¿En qué consiste un sistema de software? Es un conjunto de instrucciones que nos permiten automatizar procesos de manera eficaz y eficiente. Son los programas usados para dirigir las funciones de un sistema de computación que tiene como objetivo gestionar los recursos del ordenador y facilitar el funcionamiento de otras aplicaciones. ¿Cuáles son los objetivos de una ingeniería de software? En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver los problemas, la informática aporta herramientas y procedimientos sobre los que se apoya la ingeniería de software. Mejorar la calidad de los productos de software Aumentar la productividad y trabajo de los ingenieros del software. Facilitar el control del proceso de desarrollo de software. Suministrar a los desarrolladores las bases para construir software de alta calidad en

una forma eficiente. Definir una disciplina que garantice la producción y el mantenimiento de los productos

software desarrollados en el plazo fijado y dentro del costo estimado. ¿Cuál es la diferencia entre ingeniería de software y ciencia de la computación? Esencialmente, la ciencia de la computación se refiere a las teorías y métodos subyacentes a las computadoras y los sistemas de software. Esta disciplina se ocupa del estudio de sistemas de cómputo incluyendo procesos algorítmicos y principios que involucran el diseño de software y hardware. Los profesionales en ciencias de la computación se encargan del diseño de algoritmos, lenguajes, herramientas y sistemas de software. Diseñan y construyen software, creando soluciones eficientes a problemas del mundo real en campos como la medicina, el comercio, la biología y los negocios; mientras que la ingeniería del software se refiere a los problemas prácticos de producir software. Los ingenieros de software combinan la experiencia en ciencias de la computación, ingeniería y matemáticas para diseñar, definir y organizar diversos aspectos de un producto software complejo. Los profesionales de esta disciplina están capacitados en todos los aspectos relacionados al ciclo de vida del software, incluyendo temas de costo del proceso de desarrollo. ¿Cuál es la diferencia entre ingeniería de software e ingeniería en sistemas? Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software ( Bohem, 1976). Ingeniería de sistemas es un modo de enfoque interdisciplinario que permite estudiar y comprender la realidad, con el propósito de implementar u optimizar sistemas complejos. ¿Qué es un modelo de procesos de software?

Los estándares establecen los diferentes procesos implicados a la hora de desarrollar y mantener un sistema desde que surge la idea o necesidad de desarrollar las aplicaciones hasta que éstas se retiran de explotación. Sin embargo, ninguno impone un modelo de procesos concreto (modelo de ciclo de vida) ni cómo realizar las diferentes actividades incluidas en cada proceso, por lo que cada empresa deberá utilizar los métodos, técnicas y herramientas que considere oportuno. Por su naturaleza, los modelos son simplificaciones; por lo tanto, un modelo de procesos del software es una simplificación o abstracción de un proceso real. Podemos definir un modelo de procesos del software como una representación abstracta de alto nivel de un proceso software. Cada modelo es una descripción de un proceso software que se presenta desde una perspectiva particular. ¿Qué son los métodos de la ingeniería de software? es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de información. Enfoques estructurados para el desarrollo de software que incluyen modelos de sistemas, notaciones, reglas, sugerencias de diseño y guías de procesos. ¿Cuáles son los costos de la ingeniería de software? Los costos del software a menudo dominan al costo del sistema. El costo del software en un PC es a menudo más caro que la PC. Los costos se identifican a los recursos tanto materiales como monetarios y recursos humanos, hasta que el sistema es terminado. Pero indiscutiblemente cuesta más mantener el software que desarrollarlo. Para sistemas con una larga vida, este costo se multiplica. Los datos industriales indican que entre el 50% y el 70% de todo el esfuerzo dedicado a un programa se realizará después de que se le haya entregado al cliente por primera vez y el 60% de los costos son de desarrollo, el 40% restante son de pruebas. En el caso del software personalizado.

¿Cuáles son los elementos (capas) de una arquitectura Cliente Servidor? La arquitectura cliente/servidor genérica tiene dos tipos de nodos en la red: clientes y servidores. Consecuentemente estas arquitecturas genéricas se refieren a veces como arquitecturas de dos niveles o dos capas.

Algunas redes disponen de tres tipos de nodos:

Clientes que interactúan con los usuarios finales.

Servidores de aplicación que procesan los datos para los clientes.

Servidores de la base de datos que almacenan los datos para los servidores de aplicación.

Ésta configuración se llama una arquitectura de tres-capas.

Ventajas de las arquitecturas n-capas: La ventaja fundamental de una arquitectura n-capas comparado con una arquitectura de dos niveles (o una tres-capas con una de dos niveles) es que separa hacia fuera el proceso, eso ocurre para mejorar el balance la carga en los diversos servidores; es más escalable.

Desventajas de las arquitecturas de la n-capas:

Arquitectura de Entorno

Plataforma Hardware

Sistema Operativo

Servicios de Portabilidad

Marco de Integración

Herramientas CASE

1. Pone más carga en la red, debido a una mayor cantidad de tráfico de la red. 2. Es mucho más difícil programar y probar el software que en arquitectura de dos

niveles porque tienen que comunicarse más dispositivos para terminar la transacción de un usuario.

¿Qué es CASE? (Ingeniería del Software Asistida Por Computadora), Sistemas de software usadas en algunas fases del desarrollo del sistema de información incluyendo análisis, diseño y programación. Su objetivo fundamental es proveer un lenguaje para describir el sistema general que sea lo suficientemente explícito para generar todos los programas necesarios. La CASE supone la aplicación de principios científicos a través de una metodología que ayude a producir software de alta calidad en un tiempo mucho más reducido. La Ingeniería del Software Asistida por Computadora (CASE) puede ser tan simple como una herramienta que permite desarrollar una actividad específica, o tan compleja como un "entorno" que integre distintas herramientas, bases de datos, hardware, red, sistemas operativos, estándares y muchos otros componentes.

Bloques constitutivos del CASE

Herramientas CASE: Las herramientas CASE se pueden clasificar bajo diferentes enfoques: ♦ Por su función ♦ Por su papel como instrumentos para el personal técnico o los directivos. ♦ Por la arquitectura del entorno que las soporta (hardware y software) ♦ Origen

Marco de integración: Es un conjunto de programas especializados que permiten a cada herramienta CASE comunicarse con las demás. Servicios de portabilidad: Este conjunto constituye un puente entre las herramientas CASE, su marco de integración y la arquitectura de entorno. De esta forma permiten que las herramientas CASE y su marco de integración puedan migrar a través de diferentes plataformas de hardware y sistemas operativos sin problemas de adaptación.

Sistema operativo: Gestiona el hardware, la red y las herramientas; mantiene el entorno unido. Plataforma hardware: Son las estaciones de trabajo individuales interconectadas mediante la red para que los ingenieros del software puedan comunicarse de forma efectiva. Arquitectura de entorno: Es la base del CASE, en este bloque se construyen los entornos de la ingeniería del software, engloba los sistemas de software y hardware. Además considera los patrones del trabajo humano que se aplican durante el proceso de ingeniería del software.

VENTAJAS Y DESVENTAJAS DE LOS MODELOS DE PROCESO DE SOFTWARE

MODELO CASCADA O CLASICO Este es el primer modelo de ciclo de vida que se usó y probablemente el más usado. El software se desarrolla sin especificar requerimientos y sin diseño. es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.

Este modelo en cascada se utiliza correctamente para los ciclos de productos en los que se conoce muy bien el producto, y también cuando se está trabajando con metodologías técnicas conocidas. En estos casos el modelo en cascada ayuda a localizar errores en las primeras etapas de la realización del proyecto a un bajo coste.

.

En un modelo en cascada un proyecto progresa a través de un secuencia ordenada de pasos como se muestra en nuestra siguiente :

Las ventajas de este modelo

Por su sencillez solo utiliza los pasos intuitivos necesarios a la hora de desarrollar el software, además es muy entendible para el cliente.

La planificación es sencilla, la calidad del producto resultante es alta y permite trabajar con personal poco cualificado.

.

Las desventajas de este modelo se basa en que los proyectos raramente siguen el flujo secuencial que propone el modelo cascada, hay iteraciones. Difícilmente un cliente va a establecer al principio todos los requerimientos necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases.

MODELO INCREMENTAL.

Es un modelo que relaciona el ciclo de vida en cascada con la filosofía interactiva de construcción de prototipos, Al final de cada ciclo le entregamos una versión al cliente que contiene una nueva funcionalidad. También nos permite realizar una entrega al cliente antes de terminar el proyecto.

Se realiza construyendo por módulos que cumplen las diferentes funciones del sistema. Esto permite ir aumentando gradualmente las capacidades del software.

El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añade personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.

El modelo de ciclo de vida incremental nos genera algunos beneficios tales como se describen a continuación:

Construir un sistema pequeño es menos riesgoso que un sistema grande

Como se desarrollan independiente las funcionalidades, es más fácil revelar los

requerimientos del usuario.

Si se detecta un error grave, sólo desechamos la última iteración

Nos es necesario disponer de los requerimientos de todas las funcionalidades en el, comienzo del proyecto y además facilita la labor del desarrollo con la filosofía de “divide y conquistarás”.

Las desventajas de este modelo es que es difícil evaluar el coste, es difícil de aplicar a sistemas transaccionales que tienden a ser integrados y a funcionar como un todo, requiere gestores experimentados, los errores de los requisitos se detectan tarde, Prioriza los requisitos del usuario y los requisitos de más alta prioridad se incluyen en los incrementos más tempranos, las primeras versiones son incompletas pero proporcionan al usuario la funcionalidad que precisa y una plataforma para la evaluación, Se necesitan pruebas de regresión, pueden aumentar el coste debido a las pruebas.

MODELO DE DESARROLLO EVOLUTIVO.

El desarrollo evolutivo se basa en la idea de desarrollar una implemenación inicial e ir refinándola a través de diferentes versiones hasta desarrollar un sistema software que satisfaga todos los requerimientos del cliente.

Un enfoque evolutivo para el desarrollo de software suele ser más efectivo que el desarrollo en cascada ya que desde un principio se le entrega al cliente una versión que satisface los requerimientos principales.

Ventajas del modelo

Combinación de modelos existentes

Se presta atención a las opciones que permiten reutilización de software

Se centra en la eliminación de errores y alternativas poco atractivas

No establece una diferenciación entre desarrollo y mantenimiento

Proporciona un marco estable para desarrollos Hardware - Software integrados

Desventajas del modelo

No es un ciclo de vida en sí mismo, sino una mejor representación de los modelos de ciclo de vida.

Puede llegar a ser muy tardado lo que incrementaría los costos, debido a que se cambian los requerimientos.

También el hecho de que los usuarios pueden cambiar los requerimientos en cualquier momento puede convertirse en una desventaja.

1. Introducción a la calidad aplicada a empresas. 1.1¿Por qué calidad?

Hacer las cosas con calidad significa hacer las cosas bien con el coste previsto, y preocuparse de hacer las cosas mejor en cada ocasión. ¿Y qué es “hacer las cosas bien”? Precisamente, conseguir que los objetivos se cumplan según los planes establecidos.

Cuando conseguimos dar el mejor servicio a nuestro “cliente”, según la percepción del “cliente”, gastando exclusivamente lo necesario para efectuar las tareas para dar el servicio, sin gastar de más en pensar a destiempo lo que podíamos haber previsto y planificado, sin gastar de más en corregir lo que debíamos haber hecho mejor, sin desperdiciar horas extra, recursos, enfados, sin gastar de más en cambiar lo que no explicamos correctamente al que lo tenía que hacer, estamos trabajando con Calidad.

Se puede pensar que conseguir todo esto es imposible, puesto que siempre habrá algo que se nos haya olvidado, algo que no se pueda prever, algo que fallará. Es verdad, por eso es siempre mejor tener todo lo que se pueda estructurado, planificado y coordinado, reduciendo riesgos y costes, que salir a la aventura para que nos falle lo inevitable y lo que deberíamos haber evitado, a la vez.

¿Y quién decide qué es lo que está bien y lo que no? Los servicios que damos tienen siempre un destinatario, es a éste al que hay que preguntar, observar y escuchar para saber qué espera, que entiende por “a tiempo”, desde qué plazo considera que es demasiado tarde, para averiguar qué más le falta, por qué se le queda corto lo que le damos con nuestra mejor intención y nuestro mejor saber hacer.

El camino de la Calidad es largo, pero en cada paso nos da una mejora, un ahorro, una satisfacción.

1.2¿Para qué sirve un Sistema de Gestión de Calidad en una empresa? Un sistema de gestión de la calidad ISO 9001 es un sistema de gestión documentado, compuesto de Manual de Calidad, procedimientos, instrucciones técnicas y registros, que describe un modelo de organización y gestión de la calidad, basado en el cumplimiento de los principios y de los requisitos que establece la Norma ISO 9001:2000.

Dicho sistema pude ser certificado por un tercer organismo externo: Entidad u Organismo acreditado de Certificación, que acredita frente a terceros que el sistema cumple con los requisitos establecidos, para lo cual emite el correspondiente Certificado de empresa Registrada para la Norma ISO 9001. 1.3 Las PYMEs y el reconocimiento de su calidad. Actualmente las PyMES son un tema de moda, ya que la gran mayoría de negocios en nuestro país, son micro o pequeños, con plantillas de personal pequeñas y con presupuestos bajos, pero con esas limitantes, sobresalen en el mercado por el tipo de trabajo que desempeñan. Pero que ocurre cuando el sentimentalismo familiar es más poderoso que el ejecutar una decisión importante. Si nos remontamos al nacimiento de este grupo de empresas denominadas PyMES, encontramos dos formas, de surgimiento de las mismas. Por un lado, aquellas que se originan como empresas propiamente dichas, es decir, en las que se puede distinguir

correctamente una organización y una estructura, donde existe una gestión empresarial (propietario de la firma) y el trabajo remunerado.

El entorno globalizado que ha permitido la entrada de nuevos competidores, así como las graves crisis económicas por las que atravesó nuestro país, han puesto en riesgo la existencia de las PyMES por la falta de factores indispensables para el buen funcionamiento de la organización, que se consideran necesarios para evitar la pérdida de mercados internos, y necesarios para acceder a mercados externos. Leva (2004) sostiene que la capacidad para operar de forma global tiene que ser producida, al igual que la capacidad de coordinación y de control que implican las nuevas tecnologías de la información Efectivamente, la liberalización y los efectos de la competitividad internacional perjudicaron en mayor medida a las pequeñas empresas, mostrando una indudable rentabilidad baja o bien en el cierre de ellas.

Obtener un sello de calidad o una certificación no es cuestión de grandes empresas. De hecho en México hay muchas pymes, de diversos sectores, certificadas, cuya evidencia es un mayor acceso a mercados y una organización de procesos más eficiente.

Cualquiera podría pensar que este es un instrumento demasiado engorroso y costoso y prácticamente inalcanzable. Pues bien. Es cierto que no es una tarea sencilla. "Lo más difícil es cambiar la cultura empresarial", afirma la administradora de empresas y consultora en gestión de calidad Elsa Mejía, quien sostiene que después de cumplirse con las distintas etapas previas a la certificación sólo se obtienen beneficios.

1.4 ¿Cuánto puede durar un proceso de certificación, acreditación o evaluación? El proceso de certificación en cuanto a la norma ISO/IEC 27001 puede durar tanto como dure las auditorías internas y/o externas, generalmente es aconsejable que dure entre 6 a 12 meses ya que si se deja pasar más tiempo las políticas implementadas al principio podrían verse como vencidas o no relevantes y tocaría volver a empezar la renovación, por tal motivo se recomienda este lapso de tiempo. Dependiendo del ramo al que pertenece la empresa se identifica que para el modelo nacional tiene una duración de uno a tres años. Y esto va a depender de la normalización o reglamentación que existe. Al terminar ese tiempo se empieza de nuevo todo el proceso. 1.5 Calidad en el desarrollo software. Desde el punto de vista del cliente, calidad del software es el grado en que un cliente o usuario percibe que el producto software satisface sus necesidades. Vista desde el punto industrial del producto, calidad del software es la habilidad de un producto software de satisfacer una especificación de requerimientos.

A la hora de definir la calidad del software es importante diferenciar entre la calidad del PRODUCTO software y la calidad del PROCESO de desarrollo de éste (calidad de diseño y fabricación). Las metas que se establezcan para la calidad del producto van a determinar las que se establecen para la calidad del proceso de desarrollo, a la vez que la calidad que se espera del producto está determinada por la calidad de los procesos.

En 2002 la Secretaría de Economía (SE) inició el Programa para el Desarrollo de la

Industria de Software (PROSOFT), que tiene como objetivo Fortalecer a la Industria de Software en México.

Las estrategias del PROSOFT son:

1. Promover exportaciones y la atracción de inversiones 2. Educación y formación de personal competente 3. Contar con un marco legal promotor de la industria 4. Desarrollar el mercado interno 5. Fortalecer a la industria local 6. Alcanzar niveles internacionales en capacidad de procesos 7. Promover la construcción de infraestructura física y de telecomunicaciones

La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenimiento y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software.

La política establecida debe estar sustentada sobre tres principios básicos: tecnológico, administrativo y ergonómico.

El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del software.

El principio administrativo contempla las funciones de planificación y control del desarrollo del software, así como la organización del ambiente o centro de ingeniería de software.

El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado.

La adopción de una buena política contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación.

1.6 Historia de la calidad. La calidad es una herramienta que contribuye a la supervivencia de cualquier empresa, ya que con el transcurrir del tiempo se amplían las exigencias de los clientes que buscan mejores ofertas, precios razonables y excelencia en la atención; razón por la cual no solo se debe tener en cuenta la calidad en la prestación de servicio sino también en su eficiencia y celeridad. En el siglo XIII empezaron a existir los aprendices y los gremios, por lo que los artesanos se convirtieron tanto en instructores como en inspectores, ya que conocían a fondo su trabajo,

sus productos y sus clientes, y se empeñaban en que hubiera calidad en lo que hacían, a este proceso se le denominó control de calidad del operario. El gobierno fijaba y proporcionaba normas y, en la mayor parte de los casos, un individuo podía examinar todos los productos y establecer un patrón de calidad único. Este estado de los parámetros de aplicación de la calidad podía florecer en un mundo pequeño y local, pero el crecimiento de la población mundial exigió más productos y, por consecuencia, una mayor distribución a gran escala, en la primera guerra mundial también se dio al control de la calidad del capataz. Es así que con la ayuda de la Revolución industrial, la producción en masa de productos manufacturados se hizo posible mediante la división del trabajo y la creación de partes intercambiables; sin embargo, esto creó problemas para los que estaban acostumbrados a que sus productos fueran hechos a la medida. El sistema industrial moderno comenzó a surgir a fines del siglo XIX en los Estados Unidos, donde Frederick Taylor fue el pionero de la Administración Científica; suprimió la planificación del trabajo como parte de las responsabilidades de los trabajadores y capataces y la puso en manos de los Ingenieros Industriales, que se les conoce como Ingenieros de Métodos y Tiempos. En el siglo XX se desarrolló una era tecnológica que permitió que las masas obtuvieran productos hasta entonces reservados sólo para las clases privilegiadas. Fue en este siglo cuando Henry Ford introdujo en la producción de la Ford Motor Company la línea de ensamblaje en movimiento. La producción de la línea de ensamblaje dividió operaciones complejas en procedimientos sencillos, capaces de ser ejecutados por obreros no especializados, dando como resultado productos de gran tecnología a bajo costo. Parte de este proceso fue una inspección para separar los productos aceptables de los no aceptables. Fue entonces cuando la calidad era sólo la responsabilidad del departamento de fabricación. Muy pronto se hizo evidente que la prioridad del director de la producción era cumplir con los plazos fijados para fabricación en lugar de preocuparse por la calidad. Perdería su trabajo si no cumplía con las demandas de la producción, mientras que sólo recibiría una sanción si la calidad era inferior. Eventualmente la alta dirección llegó a comprender que la calidad sufría a causa de este sistema, de modo que se creó un puesto separado para un inspector jefe. Entre 1920 y 1940 la tecnología industrial cambió rápidamente. La Bell System y su subsidiaria manufacturera, la Western Electric, estuvieron a la cabeza en el control de la calidad instituyendo un departamento de ingeniería de inspección que se ocupara de los problemas creados por los defectos en sus productos y la falta de coordinación entre su departamentos. George Edwards y Walter A. Shewhart, como miembros de dicho departamento, fueron sus líderes. Edwards declaró: “Existe el control de la calidad cuando artículos comerciales sucesivos tienen sus características más cercanas al resto de sus compañeros y más aproximadamente a la intención del diseñador de lo que sería el caso si no se hiciera la aplicación. Para mi, cualquier procedimiento, estadístico u otro que obtenga los resultados que acabo de mencionar es control de calidad, cualquier otro que no obtenga estos resultados no los es“. Edwards acuñó la frase «seguridad en la calidad» y la defendía como parte de la responsabilidad de la administración. En 1924 el matemático Walter A. Shewhart introdujo el Control de la Calidad Estadístico, lo cual proporcionó un método para controlar económicamente la calidad en medios de producción en masa. Shewhart se interesó en muchos aspectos del control de la calidad. Aunque su interés primordial eran los métodos estadísticos, también estaba muy consciente los principios de la ciencia de la administración y del comportamiento, siendo él la primera persona en hablar de los aspectos filosóficos de la calidad. El punto de vista de que la

calidad tiene múltiples dimensiones es atribuible únicamente a Shewhart. En 1935, E. S. Pearson desarrolló el British Standard 600 para la aceptación de muestras del material de entrada, el cual fue sucedido por el British Standard 1008, adaptación del 4l U.S. Z –1 Standard desarrollado durante la Segunda Guerra Mundial. La Segunda Guerra Mundial apresuró el paso de la tecnología de la calidad. La necesidad de mejorar la calidad del producto dio por resultado un aumento en el estudio de la tecnología del control de la calidad. Fue en este medio ambiente donde se expandieron rápidamente los conceptos básicos del control de la calidad. Muchas compañías pusieron en vigor programas de certificación del vendedor. Los profesionistas de la seguridad en la calidad desarrollaron técnicas de análisis de fracasos para solucionar problemas; los técnicos de la calidad comenzaron a involucrarse en las primeras fases del diseño del producto y se iniciaron las pruebas del comportamiento ambiental de los productos. En 1946 se instituyó la ASQC (American Society for Quality Control) y su presidente electo, George Edwards, declaró en aquella oportunidad: “La calidad va a desempeñar un papel cada vez más importante junto a la competencia en el costo y precio de venta, y toda compañía que falle en obtener algún tipo de arreglo para asegurar el control efectivo de la calidad se verá forzada, a fin de cuentas, a verse frente a frente a una clase de competencia de la que no podrá salir triunfante”. En se mismo año, Kenichi Koyanagi fundó la JUSE (Union of Japanese Scientists and Engineers) con Ichiro Ishikawa como su primer presiente. Una de las primeras actividades de la JUSE fue formar el Grupo de Investigación del Control de la Calidad (Quality Control Research Group: QCRG) cuyos miembros principales fueron Shigeru Mizuno, Kaoru Ishikawa y Tetsuichi Asaka, quienes desarrollaron y dirigieron el control de la calidad japonés, incluyendo el nacimiento de los círculos de la calidad. La Normalización de Piezas: (Samuel Colt, 1820), que consistía en el diseño de un producto estándar, con piezas también estándares, que pueden utilizarse indistintamente, independientemente de la unidad de producto en las que se empleen. Esta normalización podía plantear algún problema, como el que las piezas no ajustaran adecuadamente debido a tolerancias en sus dimensiones. Este problema se resolvía mediante los ajustes manuales oportunos por parte del operario, durante el proceso de montaje. La cadena de producción: Introducida por Henry Ford. En el entorno de una cadena de producción, el operario ya no tiene la oportunidad de hacer las correcciones manuales correspondientes a una pieza o componente que no se ajuste a las especificaciones, ya que esto supondría bloquear el funcionamiento de la cadena. Al implantarse la cadena de producción aparece el primer problema de calidad. Es imprescindible que las piezas producidas sean conformes con su especificación ya que, de otro modo, no es posible su montaje en el aparato o dispositivo correspondiente en la cadena de producción, lo que obliga a realizar un reproceso posterior de la pieza defectuosa o a desecharla directamente como chatarra, lo que se traduce en el incremento del coste del producto. La cadena de producción: Introducida por Henry Ford. En el entorno de una cadena de producción, el operario ya no tiene la oportunidad de hacer las correcciones manuales correspondientes a una pieza o componente que no se ajuste a las especificaciones, ya que esto supondría bloquear el funcionamiento de la cadena.

Al implantarse la cadena de producción aparece el primer problema de calidad. Es imprescindible que las piezas producidas sean conformes con su especificación ya que, de otro modo, no es posible su montaje en el aparato o dispositivo correspondiente en la cadena de producción, lo que obliga a realizar un reproceso posterior de la pieza defectuosa o a desecharla directamente como chatarra, lo que se traduce en el incremento del coste del producto.

Lo anterior los llevó a perfeccionar el concepto de calidad. Para ellos debería haber calidad desde el diseño hasta la entrega del producto al consumidor, pasando por todas las acciones, no sólo las que incluyen el proceso de manufactura del producto, sino también las actividades administrativas y comerciales, en especial las que tienen que ver con el ciclo de atención al cliente incluyendo todo servicio posterior.

2. Normas ISO aplicadas al comercio electrónico. 2.1 Listado de estándares, métodos y guías.

3. Modelos de mejora de procesos aplicados a PYMEs.

4. CMMI. 4.1 ¿Qué es CMMI?

El gobierno de defensa americano, para asegurarse que sus proveedores cumplen unos criterios mínimos de calidad, exige que estén certificados en CMM. Dato el éxito del modelo, se extendió a otras disciplinas como la ingeniería de sistema, adquisición de material, etc. creándose variaciones de CMM.

Como todo en esta vida, las metodologías cambian CMM se ha ampliado y ahora ha aparecido CMMI que es una evolución de CMM y que integra las distintos modelos de calidad.

Integración de Modelos de Madurez de Capacidades del Software. Capability Maturity Model for Software (SW-CMM) v2.0 draft C,

Estándar provisional de la alianza de industrias electrónicas. Electronic Industries Alliance Interim Standard (EIA/IS) 731

Desarrollo de productos integrados – Capacidad de madurez del modelo. Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98.

Disciplinas en CMMI CMMI se aplica a 4disciplinas distintas y nosotros podemos elegir una de ellas para centrarnos es aspectos específicos.

Ingeniería de Sistema - Cubre la construcción de un sistema con o sin software

Ingeniería de Software - Cubre la construcción de soluciones software

Integración de productos y procesos de desarrollo - Cubre la relación a largo plazo con el cliente.

Relación con proveedores - Cubre los procesos relacionados con la subcontratación de partes del sistema

Modelos de madurez en CMMI CMMI propone 5 distintos modelos de madurez de las organizaciones:

1. Inicial - Estado inicial donde el desarrollo se basa en la heroicidad y responsabilidad de los individuos.

o Los procedimientos son inexistentes o localizados a áreas concretas.

o No existen plantillas definidas a nivel corporativo.

2. Gestionado - Se normalizan las buenas prácticas en el desarrollo de proyectos (en base a la experiencia y al método).

o En este nivel consolidado, las buenas prácticas se mantienen en los momentos de estrés.

o Están definidos los productos a realizar.

o Se definen hitos para la revisión de los productos.

3. Definido - La organización entera participa en el proceso eficiente de proyecto software.

o Se conoce de antemano los procesos de construcción de software.

o Existen métodos y plantillas bien definidas y documentados.

o Los procesos no solo afectan a los equipos de desarrollo sino a toda la organización relacionada.

o Los proyectos se pueden definir cualitativamente.

4. Cuantitativamente Gestionado

o Se puede seguir con indicadores numéricos (estadísticos) la evolución de los proyectos.

o Las estadísticas son almacenadas para aprovechar su aportación en siguientes proyectos.

o Los proyectos se pueden pedir cuantitativamente.

5. Optimizado

o En base a criterios cuantitativos se pueden determinar las desviaciones más comunes y optimizar procesos.

o En los siguientes proyectos se produce una reducción de costes gracias a la anticipación de problemas y la continua revisión de procesos conflictivos.

4.2 Clasificación de CMMI.

Las mejores prácticas CMMI se publican en los documentos llamados modelos. En la actualidad hay tres áreas de interés cubiertas por los modelos de CMMI: Desarrollo, Adquisición y Servicios.

La versión actual de CMMI es la versión 1.3, liberada el 1 de noviembre de 2010. Hay tres constelaciones de la versión 1.2 disponible:

CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), Versión 1.2 fue liberado en agosto de 2006. En él se tratan procesos de desarrollo de productos y servicios.

CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition), Versión 1.2 fue liberado en noviembre de 2007. En él se tratan la gestión de la cadena de suministro, adquisición y contratación externa en los procesos del gobierno y la industria.

CMMI para servicios (CMMI-SVC o CMMI for Services), está diseñado para cubrir todas las actividades que requieren gestionar, establecer y entregar Servicios.

Dentro de la constelación CMMI-DEV, existen dos modelos:

CMMI-DEV

CMMI-DEV + IPPD (Integrated Product and Process Development)

Independientemente de la constelación\modelo que opta una organización, las prácticas CMMI deben adaptarse a cada organización en función de sus objetivos de negocio.

Áreas de proceso

Conjunto de prácticas relacionadas que son ejecutadas de forma conjunta para conseguir un conjunto de objetivos

Las áreas de proceso que ayuda a mejorar o evaluar CMMI son 25

Se agrupan en 4 categorías según su finalidad:

Gestión de proyectos

Ingeniería

Gestión de procesos

Soporte a las otras categorías.

Áreas de proceso de CMMI (Capability Maturity Model Integration)

Área de proceso Categoría Nivel de madurez

Análisis y resolución de problemas Soporte 5

Gestión de la configuración Soporte 2

Análisis y resolución de decisiones Soporte 3

Gestión integral de proyecto Gestión de proyectos 3

Gestión integral de proveedores Gestión de proyectos 3

Gestión de equipos Gestión de proyectos 3

Medición y análisis Soporte 2

Entorno organizativo para integración Soporte 3

Innovación y desarrollo Gestión de procesos 5

Definición de procesos Gestión de procesos 3

Procesos orientados a la organización Gestión de procesos 3

Rendimiento de los procesos de la org. Gestión de procesos 4

Formación Gestión de procesos 3

Integración de producto Ingeniería 3

Monitorización y control de proyecto Gestión de proyectos 2

Planificación de proyecto Gestión de proyectos 2

Gestión calidad procesos y productos Soporte 2

Gestión cuantitativa de proyectos Gestión de proyectos 4

Desarrollo de requisitos Ingeniería 3

Gestión de requisitos Ingeniería 2

Gestión de riesgos Gestión de proyectos 3

Gestión y acuerdo con proveedores Gestión de proyectos 2

Solución técnica Ingeniería 3

Validación Ingeniería 3

Verificación Ingeniería 3

Niveles de capacidad de los procesos (representación continua). Los 6 niveles definidos en CMMI para medir la capacidad de los procesos son:

1. Incompleto: El proceso no se realiza, o no se consiguen sus objetivos.

2. Ejecutado: El proceso se ejecuta y se logra su objetivo. 3. Gestionado: Además de ejecutarse, el proceso se planifica, se revisa y se

evalúa para comprobar que cumple los requisitos. 4. Definido: Además de ser un proceso "gestionado" se ajusta a la política de

procesos que existe en la organización, alineada con las directivas de la empresa.

5. Cuantitativamente gestionado: Además de ser un proceso definido se controla utilizando técnicas cuantitativas.

6. Optimizado: Además de ser un proceso cuantitativamente gestionado, de forma sistemática se revisa y modifica o cambia para adaptarlo a los objetivos del negocio.

Componentes. Componentes Requeridos

Objetivo genérico: Los objetivos genéricos asociados a un nivel de capacidad establecen lo que una organización debe alcanzar en ese nivel de capacidad.

Objetivo específico: Los objetivos específicos se aplican a una única área de proceso y localizan las particularidades que describen que se debe implementar para satisfacer el propósito del área de proceso.

Componentes Esperados Práctica genérica: Una práctica genérica se aplica a cualquier área de proceso

porque puede mejorar el funcionamiento y el control de cualquier proceso.

Práctica específica: Una práctica específica es una actividad que se considera importante en la realización del objetivo específico al cual está asociado. Las prácticas específicas describen las actividades esperadas para

lograr la meta específica de un área de proceso Componentes Informativos

Propósito Notas introductorias Nombres Tablas de relaciones práctica - objetivo Prácticas Productos típicos Sub-prácticas: Una sub-práctica es una descripción detallada que sirve como

guía para la interpretación de una práctica genérica o especifica. Ampliaciones de disciplina: Las ampliaciones contienen información

relevante de una disciplina particular y relacionada con una práctica específica. Elaboraciones de prácticas genéricas: Una elaboración de una práctica

genérica es una guía de cómo la práctica genérica debe aplicarse al área de proceso.

¿Que es IBM Rational?

IBM Rational es una suite de soluciones de software diseñadas para administrar el ciclo de vida de desarrollo de aplicaciones. Permite tomar el control del ciclo completo de desarrollo, aportando gobernabilidad, mientras se reducen costos y aumenta la productividad. No importa si el desarrollo de las aplicaciones se hace internamente, por terceros o empaquetadas.