1. 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é Antonio Rosales Barrales
Fecha en la cual el Fecha en la cual el profesor recibe la actividad:
profesor encarga la 17/07/2011
actividad:
02/07/2011

2. 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?

3. 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:

4. 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.
Herramientas CASE
Marco de Integración
Servicios de Portabilidad
Sistema Operativo
Plataforma Hardware
Arquitectura de Entorno
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.

5. 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

6. 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
ventaja
s 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.

7. .
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

8. 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

9.  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?

10. 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

11. 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.

12. 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

13. 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,

14. 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

15. 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.

16. 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.

17. 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.

18. 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ónmodelo 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.

19. Áreas de proceso de CMMI (Capability Maturity Model Integration)
Nivel de
Área de proceso Categoría 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

20. 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.

21. 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.

22.  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.