Actividades de primer semana de la materia de Ingenieria del Software II

1. Profesor:
MSC. José Antonio Rosales Barrales
Tema:
ACTIVIDADES PARA EVALUAR LA
MATERIA
PRESENTA:
Antonio de Jesús Solano Zarate
Especialidad:
Maestría en Sistemas Computacionales
Tuxtepec, Oax., julio de 2011

2. ACTIVIDAD I. PREGUNTAS FRECUENTES DE INGENIERIA DEL SOFTWARE
1.- ¿Qué es ingeniería?
R= Conjunto de técnicas que nos permiten llegar a un resultado mediante modelos y el ingenio humano
2.- ¿En qué consiste un Sistemas de Software?
R= Es un conjunto de instrucciones que nos permiten automatizar procesos de manera eficaz y eficiente
3.- ¿Cuáles son los objetivos de la Ingeniería del Software?
R=
Obtener resultados deseados
Eficientar costos
Automatizar procesos
Modelar sistemas que soporten y documenten los procesos a ejecutar dentro del sistema
Crear sistemas de calidad
4.- ¿Cuál es la diferencia entre Ingeniería del Software y Ciencias de la Computación?
R= Para llegar a obtener las Ciencias de la Computación hay que establecer todas las técnicas y modelos de la
ISW
5.- ¿Cuál es la diferencia entre Ingeniería de Software e Ingeniería en Sistemas?
R= La primera se refiere a un sw en particular y la otra a sistemas en los cuales son un conjunto de programas y
de técnicas en los que incluye arquitectura de computadoras, administración de computadoras etc…
6.- ¿Qué es un modelo de procesos de software?
R= Es tener las características y lineamientos previamente desarrollados para llegar a la Ing. del sw. Mejorar un
sistema mediante el modelo
7.- ¿Qué son los métodos de la ingeniería de software?
R= Son aquellos que permiten definir la organización de las actividades del proceso y además definir los
paradigmas del desarrollo
8.- ¿Cuáles son los costos de la Ingeniería de Software?
R= Los costos de la ISW son intrascendentes tomando en cuenta que al obtener un SW de calidad con su ayuda
garantiza obtener buenas utilidades.

3. 9.- ¿Cuáles son los elementos (capas) de una arquitectura Cliente Servidor?
R=
Presentación/Captación de Información
Procesos
Almacenamiento de la Información
10.- ¿Qué es CASE?
R= Son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software
reduciendo el coste de las mismas en términos de tiempo y de dinero.

4. ACTIVIDAD II. TRABAJANDO CON CMMI
TEMAS
1. Introducción a la calidad aplicada a empresas.
1.1 ¿Por qué calidad?
Porque es una herramienta básica para que con la ayuda de ella podamos tener parámetros para la
comparación de un producto de la misma especie.
La calidad puede definirse como la conformidad relativa con las especificaciones, a lo que al grado en
que un producto cumple las especificaciones del diseño, entre otras cosas, mayor su calidad o también
como comúnmente es encontrar la satisfacción en un producto cumpliendo todas las expectativas que
busca algún cliente, siendo así controlado por reglas las cuales deben salir al mercado para ser
inspeccionado y tenga los requerimientos estipulados por las organizaciones que hacen certificar algún
producto.
1.2 ¿Para qué sirve un Sistema de Gestión de Calidad en una empresa?
Cada vez más las exigencias de los consumidores en los actuales escenarios económicos es muy
relevante, especialmente por el rol que desempeña la calidad y en donde, las empresas exitosas están
plenamente identificadas que ello constituye un buena ventaja competitiva.
Es por ello que todas la empresa modernas sabes que para permanecer en la competencia día a día del
mercado se tiene que satisfacer las necesidades del cliente y un buen Sistema de Gestión de Calidad
nos ayuda a:
 Satisfacer plenamente las necesidades del cliente
 Cumplir las expectativas del cliente y algunas más
 Despertar nuevas necesidades del cliente
 Lograr productos y servicios con cero defectos
 Hacer bien las cosas desde la primera vez
 Diseñar, producir y entregar un producto de satisfacción total
 Producir un artículo o un servicio de acuerdo a las normas establecidas
 Dar respuesta inmediata a las solicitudes de los clientes
 Sonreír a pesar de las adversidades
 Una categoría tendiente siempre a la excelencia
 Calidad no es un problema, es una solución
 La calidad de un producto o servicio es la percepción que el cliente tiene del mismo.

5.  Conjunto de propiedades inherentes a un objeto que permiten apreciarlo como igual, mejor o
peor que el resto de objetos de los de su especie
 También se puede decir que la calidad es la Propiedad o conjunto de características de un
elemento que le dotan de una ventaja competitiva
1.3 Las PYME’s y el reconocimiento de su calidad
Hoy día muchas de las empresas que existen son micro o pequeñas con poco personal y con
presupuestos muy pequeños pero aun con esas limitantes sobresalen en el mercado por el trabajo que
desempeñan, pero ¿qué ocurre cuando el sentimentalismo familiar se sobrepone muy por delante de
la capacidad de tomar decisiones importantes para el correcto desempeño de la empresa?
Muchas de estas empresas, al ser familiares, llevan implícitos muchos detalles en el momento de
encontrar fallas en su estructura, ya sea operativa o administrativa, y es por ello que necesitan de un
departamento que pueda validar el procedimiento, por medio de competencias de calidad.
Del mismo modo, tenemos que tomar en cuenta, que para elevar la competitividad de una PYME en
nuestros tiempos, requiere de tiempo y de inversión, la cual difícilmente por su capacidad de captación
es limitada, pero se puede demostrar que con un buen sistema de calidad puede obtenerse una PYME
competitiva y obtener resultados favorables.
1.4 ¿Cuánto puede durar un proceso de certificación, acreditación o evaluación?
El proceso de certificación, acreditación o evaluación 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.
1.5 Calidad en el desarrollo software
Mantener un proceso de desarrollo controlado es la clave para generar un producto de software de
calidad. También comentaré un poco sobre los costos de la falta de calidad y lo beneficios de tenerla.
Cuando se habla de calidad, se refiere a los atributos mensurables de un producto.

6. En el caso del software lo que se pretende es controlar la variación del proceso que se aplica para el
desarrollo del mismo, los recursos que consumimos y los atributos de calidad del producto final. Para
ello nos basamos en tres ejes:
1. Concordancia con los requerimientos.
2. Cumplir con estándares especificados.
3. Requisitos implícitos.
1.6 Historia de la calidad
La calidad no es un tema nuevo ya que desde los tiempos de los jefes tribales, reyes y faraones han
existido los argumentos y parámetros sobre calidad. El Código de Hammurabi (1752 a. C.), declaraba:
“Si un albañil construye una casa para un hombre, y su trabajo no es fuerte y la casa se derrumba
matando a su dueño, el albañil será condenado a muerte”. Los inspectores fenicios, cortaban la mano a
quien hacía un producto defectuoso, aceptaban o rechazaban los productos y ponían en vigor las
especificaciones gubernamentales. Alrededor del año 1450 a. C., los inspectores egipcios comprobaban
las medidas de los bloques de piedra con un pedazo de cordel. Los mayas también usaron este
método. La mayoría de las civilizaciones antiguas daban gran importancia a la equidad en los negocios
y cómo resolver las quejas, aun cuando esto implicara condenar al responsable a la muerte, la tortura o
la mutilación.
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

7. distribución a gran escala, en la primera guerra mundial también se dio al control de la calidad del
capataz.
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.
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.
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.
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.
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.
En los años 1960 y 1970, Armand V. Feigenbaum fijó los principios básicos del control de la calidad
total (Total Quality Control, TQC): el control de la calidad existe en todas las áreas de los negocios,
desde el diseño hasta las ventas. Hasta ese momento todos los esfuerzos en la calidad habían estado
dirigidos a corregir actividades, no a prevenirlas. Es así que en 1958, un equipo japonés de estudio de
control de la calidad, dirigido por Kaoru Ishikawa, visitó a Feigenbaum en General Electric; al equipo le

8. gusto el nombre TQC y lo llevó consigo al Japón; sin embargo, el TQC japonés difiere del de
Feigenbaum.
En 1954, Joseph Juran fue invitado al Japón para explicar a administradores de nivel superior y medio
el papel que les tocada desempeñar en la obtención de las actividades del control de la calidad. Su
visita fue el inicio de una nueva era de la actividad del control de la calidad, dirigiendo la senda de las
actividades hacia esta y basadas tecnológicamente en fábricas hacia un interés global sobre la misma
en todos los aspectos de la administración en una organización. En uno de sus libros más importantes,
Managerial Breakthrough ("Adelanto Administrativo"), él responde la pregunta de muchos
administradores, “¿para qué estoy aquí?”. Él explica que los administradores tienen dos funciones
básicas:
a) Romper los procesos existentes para llegar a nuevos niveles de rendimiento, y
b) Mantener los procesos mejorados en sus nuevos niveles de rendimiento.
El final de los años 70´s y el principio de los 80´s fue marcado por un empeño en la calidad en todos los
aspectos de los negocios y organizaciones de servicios, incluyendo las finanzas, ventas, personal,
mantenimientos, administración, fabricación y servicio. La reducción en la productividad, los altos
costos, huelgas y alto desempleo hicieron que la administración se volviera hacia el mejoramientos en
la calidad como medio de supervivencia organizacional.
Hoy día muchas organizaciones se empeñan en lograr el mejoramiento de la calidad, incluyendo JUSE,
ASQC, EOQC (European Organization for Quality Control), e IAQ (International Academy for Quality).
Así mismo, varios centros de estudio han establecido sus propios investigaciones para estudiar este
concepto como: las Universidades de Miami, Wisconsin, Tennessee, el Centro MIT para el Estudio de
Ingeniería Avanzada y la Universidad Fordham.
Así mismo, La Organización Internacional de Normas ISO creada desde hace más de cinco décadas,
desde su fundación su propósito fue mejorar la calidad, aumentar la productividad, disminuir los costos
e impulsar el comercio internacional.
De este organismo surgen la familia de normas ISO 9000, que están integradas por un conjunto de
modelos y documentos sobre gestión de calidad. En 1987 se publicaron las normas internacionales
actuales sobre aseguramiento de la calidad. Por primera vez, cada una de ellas sirve como un modelo
de calidad dirigido a determinada área de la industria, la manufactura o los servicios. En la actualidad
cubren todas las funciones o posibilidades de desempeño, y tienen el objetivo de llevar la calidad o la
productividad de los productos o servicios que se oferten. Aunque los antecedentes más remotos de la
existencia de la norma ISO 9000 datan de hace más de 50 años, es importante destacar que la
aceptación internacional de la normalización ha tenido vigencia, sobre todo, a partir de la década de
1980.

9. 2. Normas ISO aplicadas al comercio electrónico.
2.1 Listado de estándares, métodos y guías.
 Ley 34/2002 de Servicios de la Sociedad de la Información y de Comercio Electrónico (LSSICE)
 Directiva 2000/31/CE del Parlamento Europeo y del Consejo de 8 de junio, relativa a determinados
aspectos de los servicios de la sociedad de la información, en particular, del comercio electrónico en el
mercado interior
 Ley Orgánica 15/9/1999 de 13 de Diciembre de Protección de Datos de carácter personal
 Directiva 2002/58/CE del Parlamento Europeo y del Consejo, de 12 de julio de 2002, relativa al
tratamiento de datos personales y a la protección de la intimidad en el sector de las comunicaciones
electrónicas (Directiva sobre privacidad y comunicaciones electrónicas).
 Otras leyes que también son de aplicación:
 Ley 7/96 de Ordenación del Comercio Minorista
 Ley 7/98 de Condiciones Generales de la Contratación
 Ley General de Publicidad, etc.
3. Modelos de mejora de procesos aplicados a PYME’s.
Modelo de referencia de procesos
 Organización funcional dirigida a la operación de la PYME.
Modelo de evaluación
 ISO/IEC 15504-­­5:2006
Modelo de mejora para guiar la mejora continua.
 Ligero y de fácil aplicación

10. La planificación de recursos de la empresa (en inglés, Enterprise Resource Planning o ERP) son sistemas
de gestión de información que integran y automatizan muchas de las prácticas de negocio asociadas a
los aspectos operativos o productivos de una organización. Estas soluciones empiezan a desplegarse
cada vez más en el mundo de las pymes, aunque todavía queda mucho camino por recorrer.
Dada la actual situación del mercado, donde el tiempo de respuesta en la toma de decisiones es cada
vez menor y no puede quedar margen para el error, las empresas se ven obligadas a ser cada vez más
competitivas. Para ello, la gestión de la información se convierte en uno de los activos más
importantes. Saber interpretar los datos, por tanto, es la clave para tomar las decisiones más
adecuadas. En este sentido, las Tecnologías de la Información pueden ayudar bastante.
Concretamente, las soluciones encargadas de administrar la información de las distintas áreas de una
compañía se conocen con el nombre genérico de ERP (Enterprise Resource Planning).
4. CMMI.
4.1 ¿Qué es CMMI?
Integración de Modelos de Madurez de Capacidades o Capability Maturity Model Integration (CMMI)
es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación
de sistemas de software.
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.

11. 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.
Las organizaciones no pueden ser certificadas CMMI. Por el contrario, una organización es evaluada
(por ejemplo, usando un método de evaluación como SCAMPI) y recibe una calificación de nivel 1-5 si
sigue los niveles de Madurez (si bien se comienza con el nivel 2). En caso de que quiera la organización,
puede coger áreas de proceso y en vez de por niveles de madurez puede obtener los niveles de
capacidad en cada una de las Áreas de Proceso, obteniendo el "Perfil de Capacidad" de la Organización.
4.2 Clasificación de CMMI.
A continuación se hará una breve descripción de cada área de proceso nombrada. Explícitamente se
nombra a productos pero también se puede aplicar las mismas definiciones a servicios.
 Análisis y Resolución Causales (CAR): Identifica la causa de defectos u otros problemas. Luego
de ellos toma acciones correctivas para prevenir la ocurrencia de tales defectos o problemas en
el futuro.
 Análisis y Resolución de Decisiones (DAR): Proporciona un proceso estructurado de toma de
decisiones que asegura que las alternativas se comparan con criterios establecidos y objetivos
para así tomar la mejor decisión posible.
 Aseguramiento de Calidad de Procesos y Productos (PPQA): Proporciona un conjunto de
prácticas con el objetivo de evaluar productos, servicios, procesos y sus artefactos relacionados.
 Definición de Procesos Organizacionales (OPD): Establece y mantiene un conjunto de
estándares tanto en procesos organizacionales como en ambientes de trabajo.

12.  Desarrollo de Requerimientos (RD): Recopila las necesidades del cliente para convertirlas en
requerimientos del producto esperado.
 Entrenamiento Organizacional (OT): Permite a la gente de la organización obtener habilidades y
conocimientos necesarios para que el trabajo realizado por ellos sea efectivo y eficiente.
 Administración Cuantitativa de Proyectos (QPM): Maneja métricas cuantitativas de los procesos
con el objetivo de alcanzar los objetivos de calidad establecidos. Además mediante el análisis
de estos datos permite identificar oportunidades de mejora para los procesos.
 Administración de Acuerdos con Proveedores (SAM): Gestiona la adquisición de productos de
proveedores con los cuales exista un acuerdo formal.
 Administración de Requerimientos (REQM): Gestiona los requerimientos del producto durante
todo el ciclo de vida de él, identificando inconsistencias con los artefactos y planes de proyecto.
 Administración de Riesgos (RSKM): Identifica riesgos del proyecto para evaluarlos, priorizarlos y
gestionarlos para prevenir su futura ocurrencia.
 Administración de la Configuración (CM): Establece y mantiene la integridad y consistencia de
los artefactos.
 Administración Integral de Proyecto (IPM): Adapta el conjunto de procesos estándares de la
organización a procesos llevados a cabo para un proyecto en particular. Además maneja a las
partes interesadas involucradas en el proyecto.
 Innovación y Despliegue Organizacional (OID): Selecciona y despliega mejoras incrementales e
innovadoras que mejoran en forma medida los procesos de la organización y tecnologías, para
alcanzar los objetivos de calidad organizacional y de realización de procesos derivados de los
objetivos de negocio de la organización.
 Integración de Producto (PI): Ensambla las componentes del producto para producir un
producto más complejo manteniendo el cumplimiento de los requerimientos establecidos.
 Medición y Análisis (MA): Establece métricas con el objetivo de entregar resultados objetivos
que sirvan como base para tomar decisiones informadas y correctivas.
 Monitoreo y Control de proyecto (PMC): Analiza el proyecto con el objetivo de establecer un
control y evaluación según lo planes establecidos, tomando acciones correctivas cuando es
necesario.

13.  Planificación de Proyecto (PP): Desarrolla y mantiene planes del proyecto, compromisos
adquiridos por parte de los participantes del proyecto y gestiona las partes interesadas del
proyecto.
 Procesos Orientados a la Organización (OPF): Ayuda a mantener un entendimiento de los
procesos por parte de los miembros de la organización. También ayuda a identificar posibles
mejoras de los procesos, que son evaluadas y eventualmente implementadas.
 Rendimiento de Procesos Organizacionales (OPP): Deriva objetivos cuantitativos de calidad y
ejecución de los procesos desde el conjunto de objetivos de negocio de la organización.
 Solución Técnica (TS): Diseña, desarrollo e implementa soluciones para los requerimientos del
producto establecido.
 Validación (VAL): Demuestra que el producto, componentes del producto y artefactos
corresponden a lo esperado para su uso.
 Verificación (VER): Demuestra que el producto, componentes del producto y artefactos
cumplen con los requerimientos establecidos.

14. ACTIVIDAD III. INVESTIGACION
¿Qué es IBM Rational?
El Rational Unified Process (RUP) es un proceso interactivo de desarrollo de software creado por Rational
Software Corporation, una división de IBM desde el año 2003. RUP no es un único proceso normativo concreto,
sino más bien un proceso adaptable, su intención es medir las organizaciones de desarrollo y los equipos de
proyectos de software para que seleccionen los elementos del proceso que son apropiados para sus
necesidades.
Historia
El Rational Unified Process (RUP) es un producto de procesos de software, desarrollado originalmente por
Rational Software, que fue adquirido por IBM en febrero de 2003. El producto incluye una base de
conocimientos con hipervínculos con la muestra de artefactos y descripciones detalladas de muchos tipos
diferentes de actividades. RUP está incluido en el IBM Rational Method Compositor (RMC) de productos que
permite la personalización del proceso. La combinación de la base de la experiencia de las empresas llevó a la
articulación de las seis mejores prácticas en ingeniería de software moderno:
1. Desarrollar de forma iterativa, con el riesgo de que el conductor iteración primaria
2. Gestionar los requisitos
3. Emplean una arquitectura basada en componentes
4. Modelo de software visual
5. Continuamente verificar la calidad
6. Cambios de control
Estas mejores prácticas impulsaron el desarrollo de productos de Rational, y fueron utilizados por los equipos de
campo de Rational para ayudar a los clientes a mejorar la calidad y la previsibilidad de sus esfuerzos de
desarrollo de software. Para hacer que este conocimiento sea más accesible, Philippe Kruchten , un techrep
racional, se le encargó el montaje de un marco de proceso explícito para la ingeniería de software moderno.
Este esfuerzo empleado del HTML, mecanismo basado en el proceso de entrega desarrollada por Objectory. El
resultado de "Rational Unified Process" (RUP) completó lo siguiente:
 un proceso tailorable que guiaron el desarrollo
 herramientas automatizadas que la aplicación de ese proceso
 servicio que aceleró la adopción tanto del proceso como de las herramientas
Bloques de construcción RUP
RUP se basa en un conjunto de bloques de construcción, o los elementos de contenido, describiendo lo que se
va a producir, los conocimientos necesarios y la explicación paso a paso que describe cómo los objetivos
específicos de desarrollo han de ser alcanzados. Los principales bloques de construcción, o los elementos de
contenido, son las siguientes:
 Funciones (que) - Un rol define un conjunto de habilidades relacionadas, competencias y
responsabilidades.

15.  Productos de trabajo (lo que) - Un producto de trabajo representa algo como resultado de una tarea,
incluyendo todos los documentos y modelos producidos mientras se trabaja en el proceso.
 Tareas (cómo) - Una tarea describe una unidad de trabajo asignada a una función que proporciona un
resultado significativo.
Dentro de cada iteración, las tareas se dividen en nueve disciplinas:
 Seis "disciplinas de la ingeniería"
 Modelos de negocio
 Requisitos
 Análisis y Diseño
 Ejecución
 Prueba
 Despliegue
 Tres disciplinas de apoyo
 Configuración y gestión del cambio
 Gestión de Proyectos
 Medio ambiente
Fases del Ciclo de Vida
El RUP ha determinado un ciclo de vida del proyecto, que consta de cuatro fases. Estas fases permiten que el
proceso que se presentará en un alto nivel de una manera similar a como un "estilo waterfall', el proyecto
podría ser presentado, aunque, en esencia, la clave del proceso radica en las iteraciones de desarrollo que se
encuentran en todas las fases. Además, cada fase tiene un objetivo fundamental y un hito en el extremo que
denota el objetivo cumplido. La visualización de las fases de RUP y disciplinas con el tiempo se conocen como la
joroba de RUP.

16. Fase de Inicio
El objetivo principal es el alcance del sistema de forma adecuada como base para la validación de un costo
inicial y los presupuestos. En esta fase, el modelo de negocio que incluye contexto de los negocios, los factores
de éxito (los ingresos previstos, el reconocimiento del mercado, etc), y las previsiones financieras se establece.
Para complementar el modelo de negocio, un modelo de casos de uso básicos, el plan del proyecto, evaluación
inicial de riesgos y descripción del proyecto (los requerimientos del proyecto básico, las limitaciones y
características principales) se generan. Después de que estos se hayan completado, el proyecto se comprueba
con los siguientes criterios:
 Los interesados en concurrencia definición del alcance y de las estimaciones de costo / horario.
 Los requisitos de conocimiento como lo demuestra la fidelidad de los casos de uso principales.
 Credibilidad de las estimaciones de costos / cronograma, las prioridades, los riesgos y el proceso de
desarrollo.
 Profundidad y la amplitud de cualquier prototipo de la arquitectura que se desarrolló.
 Establecer una base para comparar los gastos reales frente a los gastos previstos.
Si el proyecto no pasa este hito, llamado Milestone objetivo del ciclo de vida, que puede ser cancelado o
repetido después de haber sido rediseñado para responder mejor a los criterios.
Fase de elaboración
El objetivo principal es mitigar los elementos de riesgo identificados por el análisis hasta el final de esta fase. La
fase de elaboración es donde el proyecto comienza a tomar forma. En esta fase, el análisis del dominio del
problema se hace y la arquitectura del proyecto toma su forma básica.
Esta fase debe pasar el hito de la arquitectura del ciclo de vida mediante el cumplimiento de los siguientes
resultados:
 Un modelo de casos de uso en el que el los casos de uso y los actores han sido identificados y la mayoría
de las descripciones de casos de uso se desarrollan. El modelo de caso de uso debe ser un 80%.
 Una descripción de la arquitectura de software en un proceso de desarrollo de software del sistema.
 Una arquitectura ejecutable que se da cuenta de casos de uso arquitectónicamente significativos.
 Caso de negocio y la lista de riesgos que se revisan.
 Un plan de desarrollo para el proyecto en general.
 Prototipos que demostrar que mitigar cada riesgo identificado técnica.
Si el proyecto no puede pasar este hito, aún hay tiempo para que sea declarado nulo o rediseñados. Sin
embargo, después de salir de esta fase, las transiciones del proyecto en una operación de alto riesgo, donde los
cambios son mucho más difíciles y perjudiciales cuando se hace.
El análisis en el dominio clave para la elaboración es la arquitectura del sistema.
Fase de Construcción
El objetivo principal es construir el sistema de software. En esta fase, la atención se centra en el desarrollo de
componentes y otras características del sistema. Esta es la fase en la que la mayor parte de la codificación se

17. lleva a cabo. En proyectos más grandes, de varias iteraciones de construcción pueden ser desarrollados en un
esfuerzo por dividir a los casos de uso en segmentos manejables que producen prototipos demostrable.
Esta fase produce la primera versión externa del software. Su conclusión está marcada por el hito de la
capacidad operativa inicial.
Fase de Transición
El objetivo principal es la de "tránsito" del sistema de desarrollo en la producción, puesta a disposición y
comprensión para el usuario final. Las actividades de esta fase incluyen la formación de los usuarios finales y
técnicos de mantenimiento y las pruebas beta del sistema para validar frente a las expectativas de los usuarios
finales. El producto también se compara con el nivel de calidad establecidos en la fase inicial.
Si todos los objetivos se cumplen, el hito de lanzamiento del producto se alcanza y se termina el ciclo de
desarrollo.
Los productos de IBM Rational Method Composer
El producto IBM Rational Method Composer es una herramienta para crear, configurar, visualizar, y los procesos
de publicación. Ver IBM Rational Method Composer y una versión de código abierto Eclipse Proceso Marco
(EPF) del proyecto para más detalles.
Certificación
En enero de 2007, el examen RUP nueva certificación para el Diseñador de IBM Certified Solution - Rational
Unified Process 7.0 fue lanzado, que sustituye a la versión anterior del curso llamado IBM Rational Especialista
Certificado -. Rational Unified Process. El nuevo examen no sólo del examen de conocimientos relacionados con
el contenido RUP, sino también a la estructura de los elementos del proceso.
Para aprobar el examen RUP nueva certificación, una persona debe tomar el examen de IBM 839: v7.0 Rational
Unified Process. Se le da 75 minutos para tomar el examen de la pregunta 52. El puntaje de aprobación es del
62%
Seis Mejores Prácticas
Seis Mejores Prácticas como se describe en el Rational Unified Process es un paradigma en la ingeniería de
software , que enumera seis ideas para seguir en el diseño de cualquier proyecto de software para minimizar
errores y aumentar la productividad. Estas prácticas son las siguientes:
 Desarrollar iterativamente
Es mejor saber de antemano con todos los requisitos, sin embargo, a menudo éste no es el caso. Varios
procesos de desarrollo de software existentes que se ocupan de la provisión de soluciones sobre la manera de
minimizar el coste en términos de fases de desarrollo.

18.  Gestionar los requisitos
Siempre tenga en cuenta los requisitos establecidos por los usuarios.
 Utilizar los componentes
El desglose de un proyecto avanzado no sólo es sugerido, pero inevitable, de hecho. Esto favorece la posibilidad
de probar los componentes individuales antes de que se integren en un sistema mayor. Además, la reutilización
de código es una gran ventaja y se puede lograr con mayor facilidad a través del uso de la programación
orientada a objetos.
 Modelo visual
Utilizar los diagramas para representar a todos los componentes principales, los usuarios y su interacción.
"UML", abreviatura de Lenguaje de Modelado Unificado , es una herramienta que puede ser utilizado para hacer
esta tarea más factible.
 Verificar la calidad
Siempre que el análisis sea una parte importante del proyecto en cualquier punto del tiempo. Las pruebas se
hace más pesada que el proyecto avanza, pero debe ser una constante en la creación de cualquier producto de
software.
 Cambios de control
Muchos proyectos son creados por muchos equipos, a veces en varios lugares, diferentes plataformas se
pueden utilizar, etc. Como resultado de ello, es esencial para asegurarse de que los cambios realizados en un
sistema están sincronizados y verificar constantemente.

19. ACTIVIDAD IV. LA IMPORTANCIA DE LA SEGURIDAD Y REQUISITOS RELACIONADOS
CON LA SEGURIDAD
En el presente ensayo se extrajo de la primera parte de tres de un artículo que muestra la importancia de la
seguridad y los requisitos relacionados con ella misma, cabe mencionar que unos de los principales problemas
que se presentan en repetidas ocasiones en que los ingenieros de requisitos tienden a centrarse casi
exclusivamente en los requisitos funcionales y en gran medida hacen caso omiso a los requisitos llamados no
funcionales tales como los datos, la interfaz, los requisitos de la calidad y en las limitaciones técnicas,
desgraciadamente esta omisión hace que los ingenieros pasen por alto los requisitos de importancia crítica, con
una arquitectura significativa, los requisitos de calidad mínimos que especifican cantidades aceptables de
calidad, tales como disponibilidad, interoperabilidad, rendimiento, portabilidad, confiabilidad, seguridad,
seguridad y facilidad de uso.
Los requisitos de la calidad son esenciales para obtener la arquitectura del sistema y su aceptación, sin embargo
los requisitos funcionales son fundamentales para la aceptación por parte de los interesados. La ingeniería tiene
técnicas de requerimientos tales como el modelado de los casos de uso, que son eficaces para analizar e
identificar las necesidades funcionales. Desafortunadamente estas técnicas son insuficientes e inadecuadas
para los requisitos no funcionales, que incluyen los requisitos de calidad, así como los requisitos de interfaz y de
información, y las limitaciones de la arquitectura / diseño.
Sin modelos de calidad relativamente completos, las partes interesadas y los desarrolladores tienden a pasar por
alto los muchos tipos de calidad que existen, también es difícil para algunas partes interesadas definir el nivel
necesario de las cualidades requeridas ya que los ingenieros de requerimientos en muy raras ocasiones recibe
capacitación en la identificación y especificación de los requisitos de calidad y por eso tienen menos experiencia.
Los requisitos del sistema rara vez se especifica la forma segura de un sistema debe ser para defender
adecuadamente en sí y sus activos asociados (personas, los bienes, el medio ambiente, y servicios) de cualquier
daño. Con demasiada frecuencia, los requisitos no se especifica lo que los accidentes y los ataques deben ser
prevenidos, los tipos de vulnerabilidades del sistema no tiene que incorporar, cuáles son los peligros y amenazas
que deben defenderse, y lo que son la máxima seguridad aceptable y los riesgos de seguridad.
¿Qué tan grande es este problema? En proyectos de producción, los requisitos de pobres llevar a excesos de
presupuesto y el calendario, se perdió o aplicación incorrecta de la funcionalidad y los sistemas que se entregan,
pero nunca ha sido utilizada. De acuerdo con Nancy Leveson , un respetado experto en seguridad de software,
hasta el 90 por ciento de los accidentes son causados, al menos en parte, por los pobres requisitos que se
utilizan para la elaboración de productos de calidad:
En los requisitos también rara vez se especifica que el sistema debe detectar cuando estas con la seguridad y los
eventos relacionados con la seguridad se producen o existen condiciones. Asimismo, los requisitos a menudo no
especifican lo que debe hacer el sistema cuando los detecta. En resumen, los requisitos por lo general no
especifica adecuadamente la seguridad y los problemas relacionados con la seguridad, el sistema debe prevenir,
la detección del sistema de estos problemas, y cómo el sistema debe reaccionar a su detección.
Como conclusión podemos mencionar que gran parte del problema que existe en la falta de seguridad y calidad
en los productos de software se debe a que los desarrolladores se centran más en los requisitos funcionales esto
debido a que no cuentan con una capacitación previa para poder determinar de forma segura y eficiente estos
requisitos y esto a su vez sucede porque no existen lineamientos estandarizados para la obtención de dichos

20. requisitos, esto aunado a que la parte interesada no sabe exactamente qué es lo que quiere en materia de
calidad nos arroja productos de poca calidad y deficientes en seguridad, es por ellos que estos dos puntos son
de mayor importancia en el desarrollo de sistemas de información y en la creación de software nuevos