Ingeniera de Software

Proyecto exitoso
-

Tiempo Estimado
Presupuesto estimado
Cumple con funcionalidad requerida
Que se use

Si se cumplen los 3 primeros el proyecto/producto se considera exitoso de lo contrario es

deficiente
Por qu no son exitosos:
-

Eleccin errnea de los stakeholders

Deficiencias en las habilidades de los desarrollos
Estimacin de esfuerzo y tiempo errneos
Escaza gestin de la calidad del producto de software
Seleccin de tecnologas errneas
Otros

Segn el Chaos Report de 2010 solo un 30% de los proyectos de software son exitosos. Y si se
aportan ms de 10M de dlares ningn proyecto es exitoso.
Ingeniera de software: Disciplina formada por herramientas, mtodos y tcnicas que se usan en
el desarrollo de software. Busca que el desarrollo de los proyectos sean efectivos (calidad) y
eficientes (costo). Tambin permite guiar de manera sistemtica todo el proceso de desarrollo de
software.
Software:
-

Producto intangible que se compone de un conjunto de datos, programas, documentos y

configuraciones.
Nos entrega informacin
Masificacin de produccin y uso de software en los ltimos aos.
No es posible medir los efectos culturales que tiene la masificacin del software.
El software se desarrolla o se construye no se manufactura en el sentido clsico.
El software no se desgasta, se deteriora debido a los cambios introducidos.
La mayora se construye a medida.

Tipos de software:
-

De Sistemas: Sistemas operativos, dentro de S.O. (winzip, etc)

De aplicacin: gestin (bancos, gestin de clientes, hospital, supermercado, etc)
De ingeniera y cientfico: Matlab, autocad.
Empotrado (embedidos): microondas
De lneas de producto: se van agregando y sacando cosas.
Aplicacin web: Facebook, google drive.
De IA: fundir cobre, maquinaria automatizada.

Mitos del desarrollo de software:

-

Ya tengo un libro con procesos s todo.

Atrasado, agregar ms gente
Enunciados generales sin especificar sirven
Los requerimientos cambian con facilidad, el software es flexible, cambiar es fcil.
Cuando se termina de escribir un programa y est funcionando el trabajo est terminado.

Proyecto de Software
-

Objetivos simples y cuando estos objetivos son acabados el proyecto est completo
(Divide y vencers)
Plan de trabajo + Equipo de trabajo + estimacin de tiempo= Carta Gantt

Roles:
1. JP:

2.
3.
4.
5.
6.
7.
8.
9.

a. Liderazgo
b. Capacidad de comunicacin y trabajo en equipo.
c. Dominio del tema
d. Capacidad de gestin
e. Poder de decisin.
Stakeholder:
a. Participa o ha participado en los procesos que se quieran automatizar.
Analista: Anlisis del problema, entiende el problema y plantea posible solucin
Diseador: Soluciones tcnicas del problema
Constructor: Recibe las soluciones del diseador
Documentador: Documenta el proyecto, estndares a seguir, tiempos, etc.
QA: Asegura calidad del proyecto a lo largo del desarrollo, testers.
Arquitecto de software: Disea las tecnologas, un diseador senior.
DBA: Administra las BDD entre el diseador y constructor.

Etapas:
1. Especificacin de requisitos: es lo que tiene que hacer el software.
a. Entrevistas, reuniones, documentos, diagramas y revisiones.
2. Anlisis: Planteamos un problema y vemos una posible solucin para poder cumplir los
requisitos.
a. Identificar las necesidades del cliente.
b. Anlisis de la organizacin, como el entorno del sistema.
c. Modelar la solucin propuesta.
3. Diseo: plantear solucin en especificaciones tcnicas.
a. Reflejo del anlisis
b. Facilitar etapas futuras.
c. Debe ser documentado.
d. Relaciones.
e. Lenguaje de programacin, aplicaciones existentes, volumen de datos.
f. Estado actual de los datos (normalizacin, encriptacin, etc.)
g. Proyeccin de crecimiento
4. Construccin: Programar lo que da el diseador.
5. Pruebas.
6. Implantacin: Llevar el software ya construido y probado a las instalaciones del cliente.
7. Mantencin: Soporte, posibles correcciones, agregar nuevas funcionalidades, capacitar a
los usuarios del software.
Trazabilidad: Registro que lleva el documentador indica dnde las especificaciones de
requisitos se llevan en el anlisis, registro del desarrollo de software.
Metodologas de Desarrollo de Software
1. Cascada: Proceso de desarrollo secuencial, tambin denominando desarrollo lineal o
clsico.
a. Comunicacin: Inicio del proyecto, recopilacin de requisitos.
b. Planificacin: Estimacin, itinerario, seguimiento.
c. Modelado: Anlisis Diseo.
d. Construccin: Cdigo, pruebas.
e. Despliegue: Entrega, soporte.
- Ventajas:
o Muy utilizado para adaptaciones o mejoras de sistemas existentes.
o til cuando los requisitos estn fijos.
- Desventajas:
o Es raro que los proyectos reales sigan el flujo secuencial.
o Es difcil que el cliente sepa de manera explcita todos los requisitos.
o El cliente debe tener paciencia.
2. Incremental: Aplica secuencias del modelo de cascada de manera iterativa.
o El primer incremento corresponde al producto esencial
o El plan se va modificando al entregar cada incremento, para cubrir de mejor
manera las necesidades del cliente.

I.

o Se entrega un producto operacional al finalizar cada iteracin.

o til cuando no se tiene todo el personal necesario para el desarrollo del proyecto.
Modelos Evolutivos:
1. Prototipo:
a. Se basa en la produccin de una versin operacional del software, para un
conjunto de requisitos limitado (excluyndose parte de la funcionabilidad)
b. Existen dos principales metodologas:
i. Prototipo Desechable
ii. Prototipo evolutivo.
o Ventajas:
Los usuarios tienen la posibilidad de interactuar con el prototipo y
realimentar a los desarrolladores.
Para los usuarios es ms confortable enfrentarse a un prototipo que a una
especificacin.
Decrece el esfuerzo de desarrollo entre un 40% y 70%. Un diseo rpido
es posible cuando los requisitos son claros.
o Desventajas:
Se puede adicionar funcionalidad intrascendente bajo presiones de uso
normal.
Posibilidad de pensar que es en s una especificacin (slo es parte).
Puede demostrar funcionalidad que no es posible bajo apremios reales.
El usuario puede creer que tiene frente a s el sistema completo y
operable.
Posibilidad de subestimar el proyecto, ya que las salidas estn pronto
disponibles.

2. Modelo Espiral: Se basa en un acercamiento orientado a la determinacin del

riesgo en la evolucin del software.
a. Planificacin
b. Anlisis de riesgo
c. Ingeniera
d. Evaluacin de cliente
o Ventajas:
Demanda una consideracin directa de los riesgos tcnicos en todas las
etapas del proyecto.
Permite la utilizacin de la creacin de prototipos como un mecanismo de
reduccin del riesgo.
Permite utilizar el enfoque de creacin de prototipos en cualquier etapa
de evolucin del producto.
o Desventajas:
Criticidad del anlisis de riesgo.
Difcil de vender como algo controlable.

Especificacin de Requisitos:
Proceso sistemtico de definicin, comprensin, anlisis y documentacin de los requisitos.
Los requisitos definen los servicios que el sistema debe proporcionar a los usuarios; y las
restricciones y condiciones de uso de los mismos.
Tipos de requisitos:
1. De carcter general, pueden ser vistos en trminos amplios como lo que el
sistema debe hacer.
2. Funcionales, definen las funcionalidades del sistema.
3. No funcionales, definen caractersticas del rendimiento y de la implementacin
Dado que los requisitos son de diversos tipos no es posible definir un nico procedimiento
estndar de especificacin de los mismos.
Principios para una buena especificacin:
La especificacin debe separar funcionalidad de implementacin.
La especificacin necesita utilizar un lenguaje de especificacin orientado a procesos.
La especificacin debe abarcar el entorno en el que opera el sistema.
La especificacin debe ser un modelo cognitivo.
La especificacin debe ser tolerable a la incompletitud y ampliable.
La especificacin debe ser localizada y dbilmente acoplada.
Problemas Comunes:

Muchos de los problemas que aparecen en los sistemas una vez en utilizacin se derivan
de problemas aparecidos, o no detectados, en la fase de anlisis y/o especificacin de los
requisitos.
Los requisitos no reflejan las necesidades reales del cliente del sistema.
Los requisitos son inconsistentes y/o incompletos.
Es difcil introducir cambios en los requisitos una vez que estos han sido consensuados
entre cliente y desarrollador.
Hay una falta de entendimiento entre clientes y aquellos que desarrollan el sistema.

Estructura de un Documento ERS

La estructura que establece el estndar IEEE/ANSI 830-1993 para el documento de
especificacin de requisitos es:
1.
2.
3.
4.
5.

Introduccin
Descripcin general
Requisitos especficos
Apndices
Glosario

Requisitos no funcionales

Corresponden a los atributos o caractersticas de calidad que debe tener el software.

Estndar ISO 9126
o Se compone de cuatro partes: modelo de calidad, mtricas externas, mtricas
internas y mtricas para la calidad en uso.
o En la primera parte, se describen detalladamente seis caractersticas y subcaractersticas de calidad para los productos de software.
o Se puede determinar el grado de calidad de estos productos segn la evaluacin
de estas caractersticas y sub-caractersticas.

Caractersticas:
1. Funcionalidad:
a. Adecuacin: lo que realmente debe hacer, se comprueban con la trazabilidad.
b. Correccin: Pruebas.
c. Interoperabilidad:
d. Seguridad: acceso a la informacin, perfiles.
e. Conformidad: otros estndares.
2. Fiabilidad:
a. Madurez: Teniendo mismas condiciones de entrada va a responder de igual
forma
b. Tolerancia a fallos: Niveles de desempeo, que no se caiga.
c. Recuperabilidad: Si falla se puede recrear el estado anterior.
d. Conformidad: otros estndares.
3. Usabilidad:
a. Comprensibilidad: Comprender el software.
b. Aprendibilidad: Aprender sin manual.
c. Operabilidad: Como operamos el software
d. Atractividad: Diseo
e. Conformidad: otros estndares
4. Eficiencia:
a. Comportamiento temporal: tiempo de respuesta
b. Uso de recursos: Cuanta memoria, RAM, HDD, etc.
c. Conformidad: Otros estndares, tiempo de respuesta mnimo
5. Mantenibilidad:
a. Analizabilidad.
b. Comabiabilidad: Facilidad de cambios, depende de la trazabilidad.
c. Estabilidad: Versiones estables.
d. Facilidad de pruebas.
e. Conformidad: Estndares en la especificacin de requisitos.
6. Portabilidad:
a. Adaptabilidad: Distintos dispositivos.
b. Instalabilidad: Facilidad de instalar el software.
c. Co existencia: Con otro software
d. Reemplazabilidad: Si existe en el mercado un software que realice lo mismo.

UML: Unified Modeling Language

El trabajo en UML comenz en Octubre de 1994 por Rumbaugh y Booch en Rational. SU objetivo
era el de crear un nuevo mtodo, el Mtodo Unificado, que unira el mtodos de Booch y el
mtodo OMT-2.
En 1997 es aprobado como lenguaje estndar por la OMG.
Actualmente se est usando UML 2.4.1 (2012) (ISO/IEC 19505-1 y 19505-2)
El objetivo de UML es describir cualquier tipo de sistema en trminos de diagramas orientados a
objetos (crear un modelo).
Diagramas UML: Grficos que muestran los elementos del modelo de acuerdo a una vista
especfica.
1. Casos de Uso
a. Vista grfica de algunos o todos los actores, casos de uso y sus interacciones,
identificados para un sistema.
b. Cada sistema tpicamente tiene un diagrama de caso de uso principal, el cual es la
imagen de las fronteras del sistema (actores) y la funcionalidad principal
proporcionada por el sistema (casos de uso).
c. Otros diagramas de caso de uso pueden ser usados cuando sea necesario.
2. De Clases
a. Vista esttica del sistema.
b. Tiene similitudes con un modelo de datos (entidad-relacin), las clases no solo
muestran la estructura de la informacin sino que describen tambin el
comportamiento.
c. Definen una base para otros diagramas.
3. De objetos
a. Variante del de clases, usa casi la misma notacin.
b. La diferencia es que muestra una serie de objetos (instancias de las clases) en vez
de una de las clases actuales.
c. Es un ejemplo de un diagrama de clases que muestra una posible imagen de la
ejecucin del sistema.
4. De Estados
a. Es un complemento de la descripcin de una clase.
b. Muestra todos los estados posibles que los objetos de una clase pueden tener y
que eventos causan un cambio de estado (o transicin).
c. No son especificados para todas las clases, solo para aquella que tienen una serie
de estados bien definidos y en donde el comportamiento de la clase es afectado y
cambiado por los estados diferentes.
5. De Secuencia
a. Muestra una colaboracin dinmica entre una serie de objetos.
b. Muestra una secuencia de mensajes enviados entre los objetos.
c. Tambin muestra las interacciones entre los objetos.

6. De colaboracin
a. Muestra una colaboracin dinmica, como el diagrama de secuencia.
b. Es a menudo una eleccin mostrar una colaboracin ya sea con un diagrama de
secuencia o uno de colaboracin.
c. Adems de intercambiar mensajes, muestra los objetos y sus relaciones (tambin
conocidos como el contexto).
7. De Actividades
a. Muestra el flujo secuencial de las actividades.
b. Usado tpicamente para describir las actividades realizadas en una operacin.
Tambin puede ser usado para describir otros diagramas como el de uso o
interaccin.
c. Consiste en estados de accin los que contienen una especificacin de la actividad
que va a ser realizada (accin). Un estado de accin termina cuando ha sido
realizada la accin.
8. De Componentes
a. Muestra la estructura fsica del cdigo en trminos de los componentes de cdigo
(cdigo fuente, componente binario u ejecutable)
b. Las dependencias entre los componentes son mostradas haciendo fcil de analizar
cmo son afectados por un cambio los otros componentes.
9. De Despliegue
a. Muestra la arquitectura fsica del hardware y software del sistema.
b. Se pueden mostrar las computadoras y los dispositivos (nodos), junto con las
conexiones que tienen unos con otros. Tambin se puede mostrar el tipo de
conexin.

Planificacin y Elaboracin
Funciones del sistema: son aquellas que el sistema se supone que tiene que hacer. Se clasifican en
categoras para poder priorizarlas:

Evidentes: Obligatorias, el usuario est consciente de haberla realizado.

Ocultas: Obligatorias, pero no son visibles a los usuarios.
Superfluas: Opcionales, su agregacin no afecta significativamente el costo u otras
funciones.

Atributos del sistema: Cualidades no funcionales del sistema. Los atributos tienen un posible
conjunto de detalles de atributos, los cuales tienden a ser valores discretos, confusos o simblicos,
por ejemplo:
Tiempo de respuesta
Tolerancia a fallos
Facilidad de Uso
Algunos atributos del sistema tambin pueden tener restricciones de frontera del atributo, que
son condiciones obligatorias de frontera, generalmente dentro de un rango numrico de los
valores de un atributo, por ejemplo:
Tiempo de respuesta = (5 segundos cmo mximo)

Los atributos se relacionan con las funciones que son afectadas por ellos. Adems se debe definir
si el atributo es obligatorio u opcional.

BPMN: Business Process Model and Notation

BPMN 2.0 fue nombrado estndar el 03/01/2011

Se utiliza para representar procesos de negocio en un formato de workflow.
Tiene un formato fcil de entender por los stakeholders.
Se espera que su adopcin ayude a unificar los conceptos bsicos y vayan masificando los
conceptos de modelado.
Se utiliza para especificar las operaciones de los procesos de negocio.
Los stakeholders pueden entender incluso todos los detalles de los procesos complejos.

Existen 5 tipos bsicos de elementos:

1. Objetos de flujo:
a. Eventos: Ocurren dentro de un proceso de negocio y afectan al flujo del proceso.
Normalmente son gatillados por un trigger o impactan el resultado del sistema.
Existen 3 tipos: inicial, intermedio y final.

b. Actividades: Puedes ser un proceso de negocio, un proceso secundario o una

tarea.
c. Entradas (gateways): Representan decisiones o bifurcaciones.
2. Objetos de Datos: Proveen informacin a un proceso o representan la informacin
generada por un proceso.
3. Objetos de Conexin
a. Flujo de secuencia: Se utiliza para mostrar el orden de los eventos.
b. Flujo de Mensajes: Se usa para mostrar el flujo de mensajes entre los distintos
eventos.
c. Flujo de Asociacin: Se utiliza para asociar artefactos con objetos de flujo
4. Swimlanes (carriles): Se usan para diferenciar los negocios y roles del sistema
a. Piscinas: Identifican los participantes dentro de un flujo de trabajo
b. Carriles: Indican quien realiza que dentro de una piscina.
5. Artefactos: Se usan para mostrar las entradas y salidas de las actividades en los procesos.
a. Grupo: Se usa para clarificar la documentacin o anlisis.
b. Anotaciones: Se utilizan para incluir informacin adicional.
Elementos Comunes:
a. Mensaje: Describen una comunicacin entre dos participantes de un proceso.
b. Bifurcacin: Se usa para dividir la salida de una actividad.

Ejemplos:

Casos de Uso:

Permiten describir los procesos del dominio.

Un caso de uso es un documento narrativo que describe la secuencia de eventos de un
actor (agente externo) que utiliza un sistema para completar un proceso.
Los casos de uso son historias o casos de utilizacin de un sistema, que normalmente
abarca varios pasos.

Actores:
Un actor es una entidad involucrada en el sistema, que de alguna manera participa en la
historia del caso de uso.
Estimula el sistema con eventos de entrada o recibe algo de l.
Los actores estn representados por el papel (rol) que desempean.
Se indica la relacin entre un Actor y Caso de Uso mediante una lnea.

Frontera:
Es el lmite fsico y/o lgico para el caso de uso.
Representa la frontera del sistema modelado.
Los actores pueden ser internos o externos a la frontera del caso de uso.
Una frontera puede encerrar a ms de un caso de uso.
Identificacin de Casos de Uso:
-> Un mtodo de identificacin se basa en actores:
1. Se identifican los actores relacionados con un sistema o empresa.
2. Para cada actor se identifican los procesos que inician o en los cuales participan.
->Otro mtodo de identificacin se basa en eventos:
1. Se identifican los eventos externos a los que un sistema ha de responder.
2. Se relacionan los eventos con los actores y con los casos de uso.

Clasificacin:
Los casos de uso deberan clasificarse en primarios, secundarios y opcionales para
asignarles la prioridad de desarrollo.
Los casos de uso primarios representan los procesos ms importantes, como Comprar
productos.
Los casos secundarios de uso representan procesos menores o raros; por ejemplo,
Solicitud de surtir un nuevo producto.
Los casos opcionales de uso representan procesos que pueden no abordarse.
Casos de uso y ciclos de iteracin:
Los ciclos iterativos de desarrollo se organizan a partir de los requisitos del caso de uso.
Dicho de otra manera, se asigna un ciclo de desarrollo para implementar uno o ms casos
de uso o bien sus versiones simplificadas (si el caso es muy complejo como para ser
abordado en un solo ciclo).
Los casos de uso deben clasificarse, y los que ocupen los niveles ms altos han de
abordarse en los ciclos iniciales de desarrollo. La estrategia general consiste en seleccionar
los casos que influyen profundamente en la arquitectura bsica o los que presentan mayor
riesgo.
Diagrama de Casos de Uso:
Un diagrama de casos de uso explica grficamente un conjunto de casos de uso de un
sistema, los actores y la relacin entre ellos.
Los casos de uso se muestran en valos, los actores son las figuras estilizadas, y las
relaciones son lneas.

Estereotipos de casos de Uso:

Estereotipo <<include>>: Se recomienda utilizar cuando se tiene un conjunto de
caractersticas que son similares en ms de un caso de uso y no se desea mantener
copiada la descripcin de la caracterstica en cada caso de uso.
o Para utilizar <<include>>: Lo ms adecuado es derivar un caso de uso separado
con las caractersticas similares, con el fin de evitar copiar y pegar, y hacer
referencia a l desde el caso de uso original.
Estereotipo <<extend>>: Se recomienda utilizar cuando un caso de uso es similar a otro
(caractersticas), pero hace algo ms. Es decir, cuando se describa una variacin en un
comportamiento normal.
o Para utilizar <<extend>>: Poner el comportamiento normal en un caso de uso y el
comportamiento inusual en otro caso de uso. Dibujartodas las variaciones como
extensiones.
Semejanzas y Diferencias entre extend e include:
o En ambos hay que sacar fuera el comportamiento comn de la mayora de los casos de
uso a un caso de uso simple que es usado, o extendido por otros muchos casos de uso.
o Sin embargo, el propsito es diferente.
o En el caso del extend, los actores tienen una relacin con el caso de uso que est
siendo extendido. Se asume que el actor podr trabajar con el caso de uso base y
con todas las extensiones. Con una relacin de include, a menudo no hay actores
asociados con el caso de uso comn.
Formatos de Casos de Uso:
1. Casos de uso de alto nivel: Describen un proceso de manera breve. Son tiles en niveles bajos
del anlisis para la definicin de procesos:
a. Formato:
i. Caso de uso: <Nombre>
ii. Actores: <actor1>, ...., <actor n>
iii. Tipo:<tipo del caso>, se asume es tipo esencial, slo se especifica Primario,
secundario u opcional.
iv. Descripcin: <una breve descripcin del proceso>
b. Ejemplo: comprar artculos en una tienda cuando se emplea una terminal en el punto de
venta.
i. Caso de uso: Comprar Productos
ii. Actores: Cliente, Cajero
c. Tipo: Primario
d. Descripcin: Un cliente llega a la caja registradora con los artculos que comprar. El
Cajero registra los artculos y cobra el importe. Al terminar la operacin, el Cliente se
marcha con los artculos comprados.

2. Casos de uso expandidos: Describen un proceso ms a fondo que el de alto nivel, su principal
diferencia es la seccin curso normal de los eventos, que describe los eventos del proceso
paso a paso:
a. Formato:
i. Caso de uso: <Nombre>
ii. Actores: <actor1>, ...., <actor n>
iii. Propsito: <propsito>
iv. Tipo:<tipo del caso>, se asume es tipo esencial, solo se especifica Primario,
secundario u opcional.
v. Resumen: <una breve descripcin del proceso>
vi. Referencias cruzadas:<casos o funciones del sistema relacionadas con el caso de
uso especificado>

b. Ejemplo:

Diagramas de Interaccin:
Muestran cmo se comunican los objetos en una interaccin.
Los objetos interactan para realizar colectivamente los servicios ofrecidos por las
aplicaciones.
Son modelos que describen la manera en que colaboran grupos de objetos para
representar cierto comportamiento.
Habitualmente, un diagrama de interaccin capta el comportamiento de un solo caso de
uso.

Hay dos tipos de diagramas de interaccin:

o Diagramas de secuencia:
Muestra la secuencia cronolgica de mensajes entre objetos durante un
escenario concreto.
Cada objeto tiene una lnea vertical denominada lnea de vida del objeto.
Esta lnea representa la vida del objeto durante la interaccin.
Cada mensaje se representa mediante una flecha entre las lneas de vida
de dos objetos.
El tiempo transcurre de arriba abajo.
Cuando existe demora entre el envo y la atencin se puede indicar
usando una lnea oblicua.
Ejemplo de Notacin:

Un objeto puede enviarse a s mismo un mensaje. Este mensaje

(autodelegacin) se indica con una flecha que vuelve al objeto.

Los diagramas pueden incluir un regreso, el cual indica el regreso de un

mensaje, no un nuevo mensaje. Normalmente, no es necesario indicar el
retorno del control.

En el mensaje se pueden representar iteraciones. Existe un marcador de

iteracin, que muestra que un mensaje se enva muchas veces a varios
objetos receptores. Ej: *[para cada lnea de pedido].
Tambin se puede representar las iteraciones en pseudocdigo.
En el mensaje se puede poner una condicin que indica cuando se enva el
mensaje. Ej: [hay existencia]

Diagramas de Colaboracin:
El contexto de una interaccin comprende los argumentos, las variables
locales creadas en ejecucin y los enlaces entre los objetos que participan
en la interaccin.
La colaboracin se realiza mediante el intercambio de mensajes. Un
mensaje desencadena una accin en el objeto destinatario.
Son tiles en la fase exploratoria para identificar objetos y mtodos.
Ejemplo:

Modelo Conceptual
El modelo conceptual no es una descripcin de componentes de software, es una representacin
de conceptos del dominio del problema en el mundo real.
El Modelo conceptual muestra:
Conceptos
Asociaciones entre conceptos
Atributos
Los artefactos de software, como una ventana o una base de datos, no forman parte del modelo
conceptual, salvo que el dominio a modelar se refiera a conceptos de software; por ejemplo, un
modelo de interfaces grficas.
Representa la vista esttica del dominio, por lo tanto no se define ninguna operacin.
En trminos informales el concepto es una idea, cosa u objeto.

Como identificar los conceptos:

1. Mediante Lista de categoras de conceptos
2. Mediante identificacin de conceptos entre frases.
a. Identificar sustantivos en las descripciones textuales de los casos de uso y
considerarlos como candidatos a conceptos o atributos.
b. Errores comunes al identificar conceptos:
i. El error ms comn al identificar conceptos es el de representar atributos
como conceptos. Una regla simple para evitar esto es: Si pensamos en un
concepto X como un nmero o un texto en el mundo real, X
probablemente sea un atributo.
Atributos:
Es un valor lgico de un dato de un objeto.
Debern ser incluidos en el modelo todos aquellos por los cuales los requerimientos
sugieren o implican la necesidad de recordar informacin.
Los atributos en un modelo conceptual deben ser preferentemente atributos simples o
valores de datos puros.

Asociaciones:
Es una relacin entre conceptos que indica alguna conexin de inters que deber ser
preservada.
Una asociacin se representa como una lnea entre los conceptos con el nombre de la
asociacin. sta es intrnsecamente bidireccional: es un nexo entre objetos de un tipo y del
otro.
Los extremos de una asociacin pueden contener una expresin de multiplicidad que
indique la relacin numrica entre las instancias o conceptos.

La flecha indicada en el nombre (opcional) indica la direccin en la que se debe leer el

nombre de la asociacin. No indica direccin de visibilidad o navegacin. De omitirse la
flecha la convencin de lectura es de izquierda a derecha o de arriba hacia abajo.
Es posible obtener mltiples asociaciones entre dos conceptos o relaciones entre el mismo
concepto, esto no es irregular ni poco comn.
Directrices para Crear Asociaciones:
o Concentrarse en las asociaciones en que el conocimiento de la relacin ha de
preservarse durante algn tiempo (asociaciones que es necesario conocer ).
o Es ms importante identificar los conceptos que las asociaciones.
o Muchas asociaciones tienden a confundir el modelo conceptual en vez de
aclararlo.
o A veces se requiere mucho tiempo para descubrirlas, y los beneficios son escasos.
o No incluir las asociaciones redundantes, ni las derivables.
Multiplicidad en las Asociaciones:
Dos conceptos pueden tener varias asociaciones entre ellos; esto sucede con frecuencia.
Por ejemplo, en el dominio de la lnea area encontramos varias relaciones entre Vuelo y
Aeropuerto.
Las asociaciones volar-hacia y volar-de son netamente diferentes que deben mostrarse
por separado.

Ejemplo Modelo Conceptual:

Modelo de Clases:
Diseo de un Diagrama de Clases:

Un diseo de diagrama de clases ilustra las especificaciones para las clases de software y
las interfaces en la aplicacin.
Tpicamente est compuesto por:
o Clases, asociaciones y atributos
o Interfaces, con sus operaciones constantes
o Mtodos
o Informacin de los tipos de atributos
o Navegabilidad
o Dependencia
Para definir las clases, debemos considerar:
Cmo se conectan los objetos a otros objetos?
Cules son los mtodos de la clase?

Se debe inspeccionar los diagramas de interaccin, los cuales sugieren las conexiones
necesarias entre objetos y los mtodos que cada clase de software debe definir.

Un diagrama de clases requiere de la creacin previa de los diagramas de interaccin,

donde el diseador identificar las clases de software que participan en la solucin
adems de los mtodos de stas y del Modelo Conceptual, el que aportar los detalles a
las definiciones de las clases.
Cmo hacer un Diseo de Diagrama de Clase?
1. Identifique todas las clases participantes en la solucin del software. (Obtngalas
analizando los diagramas de interaccin y el modelo conceptual).
2. Dibjelos en un diagrama de clases.
3. Duplique los atributos de los conceptos asociados en el Modelo Conceptual.
4. Agregue los nombres de los mtodos analizando los diagramas de interaccin.
5. Agregue informacin de tipos para atributos y mtodos.
6. Agregue las asociaciones necesarias para soportar los requerimientos de visibilidad de los
atributos.
7. Agregue las flechas de navegabilidad a las asociaciones para indicar la direccin de la
visibilidad de los atributos.
Asociaciones:
La asociacin expresa una conexin semntica bidireccional entre clases.
Una asociacin es una abstraccin de la relacin existente en los enlaces entre los objetos.

Agregaciones y Composiciones:
1. La agregacin es un tipo de asociacin utilizada para modelar relaciones de partes de un
todo. El todo es llamado Compuesto y las partes no poseen denominacin.

2. Generalizaciones:
a. Algunos conceptos son muy similares; conceptos tales como: pago en efectivo,
pago con cheque, Pago con tarjeta de crdito.
b. En estos casos es posible organizarlos en un tipo jerrquico llamado
generalizacin, en el cual un supertipo representa un concepto ms general y los
subtipos especificaciones de ste.
c. Todos los miembros de un subtipo son miembros de su supertipo.

Patrones de Software:

Modelo que sirve de muestra para sacar otra cosa igual (RAE).
Los patrones se pueden clasificar en:
o Patrones de Arquitectura.
o Patrones de Programacin.
o Patrones de Anlisis.
o Patrones Organizacionales.
o Patrones de Diseo
o Otros Patrones de Software.
Patrones de Diseo:
o Los patrones de diseo nombran, explican y evalan un diseo recurrente en un
sistema orientado a objetos.
o Proponen una forma para reutilizar la experiencia de los diseadores, clasificando
y describiendo formas de solucionar problemas que ocurren de manera frecuente
en el desarrollo de software.

Anti patrones de Software:

Los antipatrones muestran actitudes o formas de enfrentarse a los problemas con

consecuencias negativas conocidas para los proyectos.
La fuerza de los antipatrones se basa en que puede ser ms fcil de detectar a priori las
malas lneas en el desarrollo de software que elegir el camino correcto.
Descartar las alternativas incorrectas nos puede ayudar en la eleccin de la mejor
alternativa.
Los antipatrones se clasifican en:
o Antipatrones de desarrollo
o Antipatrones de arquitectura del software.
o Antipatrones de gestin de proyectos.

Diseo Arquitectnico:

Proceso en el cual se identifican los subsistemas y se establece un marco para el control y

comunicacin entre ellos
Se asume que los sistemas son grandes y formados por varios subsistemas.
Las arquitecturas ms comunes son:
Arquitectura Centralizada
Arquitectura Cliente Servidor
Arquitectura Orientada a Servicios (SOA)
Arquitectura en la Nube (Cloud Computing)
Arquitectura Dirigida por Modelos (MDA)

Arquitectura Centralizada:

Caractersticas funcionales:
o El servidor central contiene todos los datos y es el responsable de la consolidacin
de la informacin.
o Desde el servidor central se controla el acceso a mltiples terminales conectados a
travs de productos integrados en la arquitectura de red.
o Los terminales funcionan como "esclavos" del Servidor central.
o Cada usuario tiene un nmero asignado de derechos y prioridades de ejecucin en
la mquina de sus programas o peticiones.

Caractersticas fsicas:

nico servidor corporativo dimensionado para soportar todos los procesos de la

organizacin, todos los datos y las posibles comunicaciones con las delegaciones.

Una gran base de datos donde residen todos los datos de la organizacin.

Impresoras y terminales (o computadores personales con emulacin de terminal)

como puestos de trabajo conectados en grupos (clusters) al servidor central.

Ventajas:
o

Alto rendimiento transaccional.

Alta disponibilidad.

Entorno probado y experimentado.

Control total del servidor, al ser ste nico y residente en un nico Centro de
Proceso de Datos.

Concentracin de todo el personal de explotacin y administracin del sistema en

un nico Centro de Proceso de Datos.

Alto nivel de seguridad.

Desventajas.
o

Alto precio del servidor, al requerirse mucha potencia de tratamiento para dar
servicio a todos los usuarios que estn conectados y gran espacio en disco para
albergar todos los datos.

Alta dependencia de las comunicaciones si existen. En caso de cada de una lnea,

todos los puestos de trabajo dependientes de dicha lnea quedan inoperantes.

Interfaces de usuario de caracteres (no grficos) y, por lo tanto, poco amigables.

Arquitecturas propietarias.

Arquitectura Cliente-Servidor
Caractersticas:

El servidor presenta a todos sus clientes una interfaz nica y bien definida.
El cliente no necesita conocer la lgica del servidor, slo su interfaz externa.
El cliente no depende de la ubicacin fsica del servidor, ni del tipo de equipo fsico en el
que se encuentra, ni de su sistema operativo.
Los cambios en el servidor implican pocos o ningn cambio en el cliente.

Elementos:

Interfaz de usuario, lgica de presentacin.

Gestin del procesamiento, lgica del negocio.
Gestin de la base de datos, capa de datos.
Estos elementos se pueden combinar en varios niveles.

Niveles:
1. Primer nivel:
El cliente asume parte de las funciones de presentacin de la aplicacin.
En el servidor an hay programas que se dedican a ese tipo de tareas.
Esta tcnica no exige el cambio en las aplicaciones orientadas a terminales, pero
dificulta su mantenimiento.
Adems, el servidor ejecuta todos los procesos y almacena la totalidad de los datos.
En este caso se dice que hay una presentacin distribuida o embellecimiento.
2. Segundo Nivel:
La aplicacin est soportada directamente por el servidor, excepto la presentacin que
es totalmente remota y reside en el cliente.
Los terminales del cliente soportan la captura de datos, incluyendo una validacin
parcial de los mismos y una presentacin de las consultas.
En este caso se dice que hay una presentacin remota.
3. Tercer Nivel:
La lgica de los procesos se divide entre los distintos componentes del cliente y del
servidor.
El diseador de la aplicacin debe definir los servicios y las interfaces del sistema de
informacin de forma que los papeles de cliente y servidor sean intercambiables,
excepto en el control de los datos que es responsabilidad exclusiva del servidor.
En este tipo de situaciones se dice que hay funcin distribuida o cooperativa.
4. Cuarto Nivel:
El cliente realiza tanto las funciones de presentacin como los procesos.
El servidor almacena y gestiona los datos que permanecen en una base de datos
centralizada.
En esta situacin se dice que hay un manejo de datos remoto.

5. Quinto Nivel:
El reparto de tareas es como en el anterior y adems el gestor de base de datos divide
sus componentes entre el cliente y el servidor.
Las interfaces entre ambos estn dentro de las funciones del DBMS y por lo tanto, no
tienen impacto en el desarrollo de las aplicaciones.
En este nivel se da lo que se conoce como manejo de datos distribuido.

Dos Capas:
Problemas:

Clientes obesos (thick clients): La mayor parte de la lgica de la aplicacin (gestin del
procesamiento) reside junto a la lgica de la presentacin (interfaz de usuario) en el
cliente, con la porcin de acceso a datos en el servidor.
Clientes delgados (thin clients): solo la lgica de la presentacin reside en el cliente,
con el acceso a datos y la mayora de la lgica de la aplicacin en el servidor.

Tres Capas:

La arquitectura de 3 capas surgi para superar las limitaciones de la arquitectura de 2

capas.
La tercera capa o capa intermedia proporciona gestin del procesamiento.
La ubicacin de una funcin particular en una capa u otra debe basarse en los siguientes
criterios:
o Facilidad de desarrollo y comprobacin.
o Facilidad de administracin.
o Escalabilidad de los servidores.
Funcionamiento (incluyendo procesamiento y carga de la red)
Las diferentes capas se encuentran en mquinas diferentes que estn comunicadas
mediante una red.
Middleware es el encargado del acceso a los datos, aceptando las consultas y datos
recuperados directamente de la aplicacin y transmitindolo por la red.

Cuatro Capas:
Ventajas:

Aumento de la productividad:
o Los usuarios pueden utilizar herramientas que le son familiares.
o Mediante la integracin de las aplicaciones cliente/servidor con las aplicaciones
personales de uso habitual, los usuarios pueden construir soluciones que se
ajusten a sus necesidades.
o Una interfaz grfica de usuario consistente reduce el tiempo de aprendizaje de las
aplicaciones.
o Menores costos de operacin:
Permiten un mejor aprovechamiento de los sistemas existentes,
protegiendo la inversin.
Proporcionan un mejor acceso a los datos. La interfaz de usuario ofrece
una forma homognea de ver el sistema, independientemente de los
cambios o actualizaciones que se produzcan en l y de la ubicacin de la
informacin.
El movimiento de funciones desde un servidor central hacia servidores
clientes locales origina el desplazamiento de los costos de ese proceso
hacia mquinas ms pequeas y por tanto, ms baratas.

Mejora en el rendimiento de la red:

Las arquitecturas cliente/servidor eliminan la necesidad de mover grandes
bloques de informacin por la red hacia los computadores personales o
estaciones de trabajo para su proceso.
Los servidores controlan los datos, procesan peticiones y despus
transfieren slo los datos requeridos a la mquina cliente.
Entonces, la mquina cliente presenta los datos al usuario mediante
interfaces amigables.
o Todo esto reduce el trfico de la red, lo que facilita que pueda soportar un mayor
nmero de usuarios.
Tanto el cliente como el servidor pueden escalarse para ajustarse a las
necesidades de las aplicaciones.
La existencia de varias CPUs proporciona una red ms fiable: un fallo en
uno de los equipos no significa necesariamente que el sistema deje de
funcionar.
Desventajas:
o Hay una alta complejidad tecnolgica al tener que integrar una gran variedad de
productos.
o Es ms difcil asegurar un elevado grado de seguridad en una red de clientes y
servidores que en un sistema con un nico ordenador centralizado.
o Los problemas de congestin de la red pueden reducir el rendimiento del sistema
por debajo de lo que se obtendra con una nica mquina.
o La interfaz grfica de usuario puede ralentizar el funcionamiento de la aplicacin.

Arquitectura Orientada a Servicios:

Las aplicaciones de negocio se descomponen en servicios individuales que pueden ser

utilizados independientemente de las aplicaciones de las que forman parte y de las
plataformas informticas sobre las que se ejecutan.
Al poder disponer de los servicios individuales de las aplicaciones como piezas
independientes, las empresas tendrn la posibilidad de integrarlos y agruparlos de
maneras distintas para conseguir capacidades completamente nuevas.

Arquitectura en la Nube (Cloud Computing)

Permite manejar servidores en la Nube de manera transparente.

Soporta la virtualizacin de servidores y recursos.
Es altamente dependiente del ancho de banda.
IaaS: Infrastructure as a Service
PaaS: Platform as a Service
SaaS: Software as a Service

Diagramas de componentes y despliegue

1. Diagrama de Componentes:
a. Son utilizados para modelar la arquitectura de un sistema.
b. Un componente representa una parte modular del sistema, que encapsula el
estado y el comportamiento de un conjunto de clases.
c. Un componente se comunica con otros componentes mediante dependencias e
interfaces.
d. Un componente con dos interfaces entregadas y 3 interfaces requeridas.

Representacin interna de un componente

Dependencias entre componentes

2. Diagrama de despliegue:
Se utiliza para representar cmo sern distribuidos los componentes en la
arquitectura del software.
Se deben especificar los artefactos, que son piezas de informacin fsicas relacionadas
a los componentes de la arquitectura.
Adems, es necesario especificar los nodos fsicos que conformarn la arquitectura.
Notacin para artefacto:

Notacin para nodo:

Diagrama de transicin de estados:

Describe el ciclo de vida completo de un objeto, con los estados vlidos que puede
tener y las acciones que pueden ocurrir durante su vida.

Estado inicial

Estado Intermedio

Estado Final

Transicin

Verificacin y Validacin (V&V)

Es un proceso de anlisis y pruebas realizado para asegurar que el software satisface las
especificaciones realizadas y entrega las funcionalidades esperadas por el cliente.
Este proceso se realiza en cada etapa del desarrollo de software.
Validacin: Se est construyendo el producto correcto?
Verificacin: Se est construyendo el producto correctamente?
Verificacin:
o Se refiere a comprobar que el software cumple con las especificaciones realizadas.
o Esto incluye comprobar los requisitos (funcionales y no funcionales) y los modelos
a utilizar en cada fase de desarrollo de software, la sintaxis y semntica de los
modelos, la trazabilidad de los requisitos al sistema final, etc.
Validacin:
o Se refiere a comprobar que el software cumple con las expectativas del cliente.
o Es ms general que la verificacin.
o Debe asegurar que se cumplen los deseos y necesidades de usuarios y clientes.
Es posible analizar y probar todo?
o No. Es muy caro y, adems, siempre pueden surgir casos que nadie imagin.
o Recordar el nivel de confianza (95%, 99%, 99,9%).
o El nivel de confianza requerido depende del propsito del sistema (sistemas
crticos), las expectativas del usuario (algunos usuarios toleran los fallos) y el
entorno de mercado (sistemas competidores).
V&V
o Inspecciones del Software
Analizan las especificaciones del sistema (Documentos de requisitos,
anlisis, diseo y cdigo).
Se pueden realizar en cualquier fase del desarrollo de software.
Se pueden realizar de manera automtica.
Son conocidas como tcnicas estticas, ya que no es necesario ejecutar el
programa para realizarlas.
o Pruebas
Es necesario ejecutar el software con datos de prueba.
Se inspeccionan las salidas y su entorno operacional.
Son esenciales para comprobar rendimiento y fiabilidad.
Son conocidas como tcnicas dinmicas de V&V.
Depuracin:
o El objetivo del proceso de V&V es demostrar la existencia de defectos y fallos.
Defecto: -> se identifica en las especificaciones del software.
Fallo: -> se identifica en el sistema.
o El objetivo del proceso de depuracin es localizar estos defectos y fallos, y
corregirlos.
o Normalmente, es difcil detectar un defecto, pues puede estar muy distante del
fallo localizado.
o En este caso, es necesario disear otros casos de prueba para identificar el
defecto.
o Una vez identificado y corregido el defecto, es necesario ejecuta nuevamente
todas las pruebas.
o ES MUY COSTOSO.

Proceso V&V esttico:

o Se utiliza para buscar defectos en las especificaciones del software y el cdigo.
o Segn Conradi et al. [Conradi, Mohagheghi, Arif, Hegde, Bunde and Pedersen
2003], los defectos se clasifican en:
Omisin: tem faltante.
Informacin extraa: tems que no deberan estar en la especificacin.
Hecho incorrecto: tergiversacin de un hecho.
Ambigedad: concepto no claro.
Inconsistencia: desacuerdo en la representacin de un concepto.
o Las inspecciones de software normalmente son guiadas por heursticas o reglas
que se utilizan para analizar las especificaciones del software (Reading
Techniques).
o Estas heursticas o reglas pueden ser automatizadas para disminuir el costo
asociado a las inspecciones (inspeccin esttica automatizada).
o Los mtodos formales son utilizados para realizar verificaciones y validaciones
estticas. -> implica la especificacin formal del sistema.
o Ventajas inspecciones de software:
Durante las pruebas, los fallos pueden enmascarar otros fallos/defectos.
Pueden inspeccionarse versiones incompletas del software.
Adems de buscar defectos, las inspecciones pueden evaluar atributos de
calidad (ej. Conformidad con los estndares, mantenibilidad, etc.)
o Desventajas de las inspecciones del software:
Alto costo y tiempo.
Es necesario indicar al equipo qu buscar y cmo (segn la experiencia).
Planificacin de la V&V:
o La V&V es un proceso caro, que normalmente implica ms del 50% del costo del
software.
o Es necesario realizar una planificacin cuidadosa de V&V para sacar el mximo
provecho.
o Se debe definir un equilibrio entre las tcnicas estticas y dinmicas -> esto
depender tambin del tipo de sistema: ms crtico, ms V&V esttica.
o El plan de pruebas especifica el calendario, recursos de hardware, recursos de
software y los procedimientos para realizar la V&V.

Estructura del Plan de Pruebas:

El proceso de prueba (Fases del proceso).
Trazabilidad de requisitos.
Elementos Probados.
Calendario de pruebas.
Procedimiento de registro de pruebas.
Requisitos de hardware y software.
Restricciones.
IMPORTANTE: Los planes de prueba no son documentos estticos, sino que evolucionan
durante el proceso de desarrollo.
Objetivos de las pruebas
1) Se realizan para demostrar al desarrollador y al cliente que el sistema satisface los
requisitos:
a. Debe haber al menos una prueba por cada requisito.
b. En este caso, el xito de la prueba implica que se ha demostrado que el sistema
funciona correctamente.
2) Para descubrir fallos en el comportamiento del software, o comportamientos no
deseados.
a. Ejemplo: Cadas, corrupcin de datos, etc.
b. En este caso, el xito de la prueba implica que se demuestra que el sistema falla.
IMPORTANTE:
El objetivo final del proceso de pruebas es convencer a desarrolladores y clientes de que el
software es lo suficientemente bueno para su operacin.
Proceso de pruebas:
Modelo General:

Tener en cuenta que no es posible probar todos los casos, es necesario disear un
conjunto de casos que:
o Pruebe todas las funciones del sistema que se acceden por el men.
o Pruebe las combinaciones de funciones que se acceden a travs del men.
o Pruebe los puntos donde se ingresan datos por el usuario.
o El jefe de proyecto debe decidir quin realizar las pruebas.

 Proceso:
1. Inicialmente el programador prueba lo que ha construido (de manera intuitiva teniendo en
cuenta lo que el cdigo debe realizar).
2. Luego, el equipo de pruebas realiza las pruebas del sistema visto como un todo, es decir,
que integra todos los componentes construidos.
3. Posteriormente, el sistema se prueba en su entorno de implantacin.
4. Finalmente, se realizan pruebas durante la operacin del sistema.

Pruebas Unitarias:
o Tambin conocidas como pruebas de componentes.
o El objetivo es encontrar fallos en los componentes (funciones o mtodos de una
clase, clases con sus atributos y mtodos, o conjuntos de clases con interfaces
definidas para comunicarse)
o Ej: Cuando hay herencia, es necesario probar la superclase y las subclases, y todos
sus atributos y operaciones.
Pruebas del Sistema:
o Implica integrar dos o ms componentes para realizar las pruebas. Ejemplo:
Incremento en metodologa incremental.
o Existen dos tipos: pruebas de integracin y pruebas de entrega.
o Pruebas de Integracin:
Se tiene acceso al cdigo
Se conocen como pruebas de caja blanca
Al descubrir un fallo en el sistema, el equipo busca el origen del fallo en el
cdigo.
Pruebas de Entrega:
o No se tiene acceso al cdigo
o Se conocen como pruebas de caja negra.
o El equipo valida si el sistema satisface o no los requisitos y es fiable.
o Si encuentra algn fallo, lo registra. Posteriormente, el programador revisa el
cdigo para encontrar el origen del fallo.
o Si el cliente se implica en las pruebas de entrega, stas son conocidas como
pruebas de aceptacin.
o Normalmente, las pruebas de integracin se utilizan para verificar el sistema y las
de entrega para validarlo.
o Sin embargo, en ambos tipos se realiza parte de verificacin y validacin.
o Existe solape de las pruebas de integracin y las pruebas de entrega?
o S. Las pruebas de integracin se convierten en las pruebas de entrega cuando el
incremento ya tiene todas las funcionalidades requeridas.
Pruebas de Rendimiento:
o Se realizan cuando se han terminado las pruebas de integracin.
o Es necesario crear un perfil operacional para realizar estas pruebas.
o Normalmente se estresa el sistema para calcular su rendimiento -> pruebas de
estrs.

Pruebas de estrs:
o Se sobrecarga el sistema para ver hasta qu punto funciona correctamente.
o Se utilizan en sistemas distribuidos (-> la red se satura con datos de coordinacin +
datos del proceso)
Diseo de casos de prueba:
o El objetivo es crear un conjunto de casos de prueba que encuentren la mayora de
los defectos y fallos y que demuestren que el sistema satisface los requisitos.
o 1. Se selecciona una caracterstica a probar.
o 2. Se identifican y documentan las entradas (vlidas y no vlidas).
o 3. Se identifica el proceso (algoritmo) a realizar con las entradas.
o 4. Se identifican y documentan las salidas esperadas.
Pruebas Evolutivas:
o Su objetivo es encontrar un conjunto de casos de prueba que logran que el
sistema falle.

Pruebas de Cobertura:
o Indican la cantidad del cdigo que est siendo incluido en las pruebas.
o Una cobertura de 85%-90% es aceptable. Una cobertura menor indica que gran
parte del cdigo no est siendo revisado en las pruebas unitarias.
Pruebas de Regresin:
o Corresponden a un conjunto de casos de prueba que demuestra que el SUT
(sistema bajo prueba) funciona correctamente y que es aplicado luego de hacer un
cambio en el SUT (por ejemplo: una nueva versin).
Automatizacin de las pruebas:
o Las pruebas es un proceso caro y costoso. Existe una serie de herramientas que
permiten apoyar este proceso:
Gestor de pruebas: Ejecuta las pruebas (ej. JUnit).
Generador de datos de prueba
Orculo: genera predicciones de los resultados esperados.
Comparador de archivos: se utilizan para comparar los resultados de las
pruebas.
Generador de informes
Analizador dinmico: agrega cdigo al programa para contar el nmero de
veces que se ejecuta cada sentencia.
Simuladores: simulan el entorno operacional.

Con todas estas herramientas an no es posible disear casos de prueba

automticamente.

Gestin de Calidad:
Se divide en tres actividades principales:
1. Garanta de calidad: marco de trabajo y estndares que conducen a desarrollar SW de alta
calidad.
2. Planificacin de la Calidad: Seleccin de procedimientos adecuados para el marco de
trabajo y adaptacin de ellos a un proyecto especfico.
3. Control de calidad: Definicin y fomento de procesos que garanticen el seguimiento de los
procedimientos definidos.
Calidad del proceso y del Producto

La calidad del proceso tiene una influencia significativa en la calidad del producto de
software.
La gestin de la calidad del proceso debera minimizar los defectos del software.
La gestin de la calidad del proceso implica:
o Definir estndares.
o Supervisar el proceso para que se sigan los estndares.
o Hacer informes para el jefe del proyecto.
o Un problema de la calidad basada en estndares es que no tiene en cuenta el tipo
de software a desarrollar.
Estndares sobre el producto. Ejemplo: Estndares de documentacin, estndares de
codificacin.
Estndares sobre el proceso. Ejemplo: procesos de especificacin de requisitos, diseo,
verificacin, y validacin.
ISO 9000 - Calidad de productos:
No es especfico para el software. Puede ser aplicado para productos de manufactura como para el
desarrollo de software.
ISO 9001: describe el sistema de calidad utilizado para mantener el desarrollo de un
producto que implique diseo. Este se aplica para el desarrollo de software.
ISO 9000-3: interpreta el ISO 9001 para el desarrollo de software.
ISO 9004-2: este documento proporciona las directrices para el servicio de facilidades del
software como soporte de usuarios.
ISO 9126 Calidad del producto:
o El estndar ISO/IEC 9126 se compone de cuatro partes: el modelo de calidad,
mtricas externas, mtricas internas y mtricas para la calidad de uso.

CMMi
Es la evolucin del modelo CMM que permite evaluar la madurez de los procesos de
software. CMMi integra la evaluacin de los procesos de software.
Hay tres versiones de CMMi disponibles:
o CMMI-DEV: para procesos de desarrollo de productos y servicios.
o CMMI-ACQ: para gestionar la cadena de suministro, adquisicin y contratacin
externa en los procesos del gobierno y la industria.
o CMMI-SVC: para gestionar, establecer y entregar Servicios.

Inicial o Nivel 1: Este es el nivel en donde estn todas las empresas que no tiene procesos
bien definidos
o Caractersticas:
Los presupuestos se disparan.
No es posible entregar el proyecto en fechas.
Es necesario quedarse durante noches y fines de semana para terminar un
proyecto.
No hay control sobre el estado del proyecto.
El desarrollo del proyecto es completamente opaco, no sabes que es lo
que pasa en l
Si no sabes el tamao del proyecto y no sabes cunto llevas hecho, nunca
sabrs cuando vas a terminar.
Gestionado o Nivel 2: El xito de los resultados obtenidos se pueden repetir.
o La principal diferencia entre este nivel y el anterior es que el proyecto es
gestionado y controlado durante el desarrollo del mismo.
o El desarrollo no es opaco y se puede saber el estado del proyecto en todo
momento.
o Los procesos que hay que implantar para alcanzar este nivel son:
Gestin de requisitos
Planificacin de proyectos
Seguimiento y control de proyectos
Gestin de proveedores
Aseguramiento de la calidad
Gestin de la configuracin

Definido o Nivel 3: La forma de desarrollar proyectos (gestin e ingeniera) est definida,

por definida quiere decir que est establecida, documentada y que existen mtricas
(obtencin de datos objetivos) para la consecucin de objetivos concretos.
o Los procesos que hay que implantar para alcanzar este nivel son:
Desarrollo de requisitos
Solucin Tcnica
Integracin del producto
Verificacin
Validacin
Desarrollo y mejora de los procesos de la organizacin.
Definicin de los procesos de la organizacin
Planificacin de la formacin.
Gestin de riesgos.
Anlisis y resolucin de toma de decisiones.
La mayora de las empresas que llegan al nivel 3 paran aqu. ste es un nivel que proporciona
muchos beneficios y no ven la necesidad de ir ms all porque tienen cubiertas la mayora de sus
necesidades.

Cuantitativamente Gestionado o Nivel 4: Los proyectos usan objetivos medibles para

alcanzar las necesidades de los clientes y la organizacin. Se usan mtricas para gestionar
la organizacin.
o Los procesos que hay que implantar para alcanzar este nivel son:
Gestin cuantitativa de proyectos.
Mejora de los procesos de la organizacin.

Optimizando o Nivel 5: Los proyectos usan objetivos medibles para alcanzar las
necesidades de los clientes y la organizacin. Se usan mtricas para gestionar la
organizacin.
o Los procesos que hay que implantar para alcanzar este nivel son:
Innovacin organizacional.
Anlisis y resolucin de las causas.

*Normalmente las empresas que intentan alcanzar los niveles 4 y 5 lo realizan simultneamente
ya que estn muy relacionados.

Gestin de la configuracin
La gestin de la configuracin es necesaria para controlar los cambios y las versiones del
software.
El cambio es un hecho vital en el desarrollo del software:
Los clientes desean modificar los requerimientos.
El equipo de desarrollo desea modificar el enfoque tcnico.
Los gestores desean modificar el enfoque del proyecto.
Lnea de base: Una lnea base es un punto del ciclo de vida del software en el cual se aplica
el control de configuraciones a un elemento especfico de la configuracin.

Numeracin de documentos: Cada documento debe ser referenciado por un nmero

nico.
o Ejemplo:

MTRICA es una metodologa para la gestin de la configuracin que incluye los siguientes
elementos:
o Ejecutables.
o Cdigo fuente.
o Modelos de datos.
o Modelos de procesos.
o Especificaciones de requisitos.
o Pruebas.
o *Para cada elemento se almacena Nombre, Versin, Estado y Localizacin.