RESUMEN PARCIAL ING - SW

CAPITULO 2 - EL PROCESO
Definimos un proceso de software como un marco de trabajo de las tareas que se requieren para construir software
de alta calidad.
INGENIERA DEL SOFTWARE
Proceso, mtodos y herramientas
La ingeniera del software es una tecnologa multicapa. Los cimientos que son la base de la ingeniera del software
estn orientados hacia la calidad.
El fundamento de la ingeniera del software es la capa proceso. El proceso define un marco de trabajo para un
conjunto de reas clave de proceso (ACPs) que se debe establecer para la entrega efectiva de la tecnologa de la
ingeniera del software.
Los mtodos de la ingeniera del software indican como construir tcnicamente el software. Estos abarcan tareas
que incluyen anlisis de requisitos, diseo, construccin del programa, pruebas y mantenimiento.
Las herramientas de la ingeniera del software proporcionan un soporte automtico o semi-automtico para el
proceso y para los mtodos. Cuando se integran herramientas para que la informacin creada por una herramienta
la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado ingeniera del
software asistida por computadora (Computer-aided software engineering CASE).
Una visin general de la ingeniera del software
El trabajo que se asocia a la ingeniera del software se puede dividir en tres fases genricas:
La fase de definicin se centra sobre el qu. El que desarrolla el software intenta identificar que informacin ha
de ser procesada, qu funcin y rendimiento se desea, qu comportamiento del sistema, qu interfases van a
ser establecidas, qu restricciones de diseo existen, y que criterios de validacin se necesitan para definir un
sistema correcto.
La fase de desarrollo se centra en el cmo. Definir cmo han de disearse las estructuras de datos, cmo ha de
implementarse la funcin como una arquitectura del software, cmo han de caracterizarse las interfases, cmo
ha de traducirse el diseo de un lenguaje de programacin (o lenguaje no procedimental) y cmo ha de
realizarse la prueba.
La fase de mantenimiento se centra en el cambio que va asociado a la correccin de errores, a las adaptaciones
requeridas a medida que evoluciona el entorno del software, y a cambios debidos a las mejoras producidas por
los requisitos cambiantes del cliente. Durante esta fase se encuentran cuatro tipos de cambios:
Correccin. Mantenimiento correctivo para corregir los defectos.
Adaptacin. El mantenimiento adaptativo para acomodarlo a los cambios de su entorno externo.
Mejora. El mantenimiento perfectivo lleva al software ms all de sus requisitos funcionales originales.
Prevencin. Mantenimiento preventivo tambin llamado reingeniera del software, hace cambios en programas de
computadoras a fin de que se puedan corregir, adaptar y mejorar ms fcilmente.
Las fases y los pasos relacionados descriptos se complementan con un nmero de actividades protectoras en las cuales
se incluyen:
- Seguimiento y control del proyecto del software - Revisiones tcnicas formales
- Garanta de calidad del software - Gestin y configuracin del software
- Preparacin de produccin de documentos - Gestin de reutilizacin
- Mediciones - Gestin de riesgos
Las actividades se aplican a lo largo de todo el proyecto.
EL PROCESO DEL SOFTWARE
Se establece:
Un marco comn del proceso, definiendo un pequeo nmero de actividades del marco de trabajo.
Un conjunto de tareas que permiten que las actividades del marco de trabajo se adapten a las caractersticas del
proyecto del software y a los requisitos del equipo de proyecto.
Las actividades de proteccin, tales como garanta de calidad del software, gestin de configuracin del software
y medicin, abarcan el modelo de proceso. Estas son independientes de cualquier actividad del marco de
trabajo.

1
Para determinar el estado actual de madurez del proceso, el SEI (Software Engineering Institute) utiliza un
cuestionario de evaluacin y esquema de cinco grados:
Nivel 1: Inicial: Se definen pocos procesos, y el xito depende del esfuerzo individual.
Nivel 2: Repetible: Para repetir xitos anteriores en proyectos con aplicaciones similares se aplica la disciplina
necesaria para el proceso.
Nivel 3: Definido: En este nivel se incluyen todas las caractersticas definidas en el nivel 2.
Nivel 4: Gestionado: Mediante la utilizacin de medidas detalladas, se comprenden y se controlan cuantitativamente
tanto los productos como los procesos.
Nivel 5: Optimizacin: Mediante un resultado cuantitativo del proceso y de las ideas y tecnologas innovadoras se
posibilita una mejora del proceso.
El SEI ha asociado las ACP a cada uno de los niveles de madurez. Cada ACP se describe identificando las
caractersticas siguientes:
Objetivos
Compromisos (requisitos para lograr los objetivos)
Capacidades (elementos que deben encontrarse)
Actividades (tareas especificas)
Mtodos para supervisar la implementacin
Mtodos para verificar la implementacin
MODELOS DE PROCESO DEL SOFTWARE
Para resolver los problemas reales de una industria, un ingeniero del software o un equipo de ingenieros deben
incorporar una estrategia de desarrollo que acompae al proceso, mtodos, capas de herramientas y las fases
genricas. Esta estrategia se llama modelo de proceso o paradigma de ingeniera del software.
Todo el desarrollo del software se puede caracterizar como un bucle de resolucin de problemas en el que se
encuentran cuatro etapas distintas:
Status quo: estado actual del problema.
Definicin de problemas: identifica el problema especfico a resolver.
Desarrollo tcnico: resuelve el problema a travs de la aplicacin de alguna tecnologa.
Integracin de soluciones: ofrece resultados a los que solicitan la solucin en primer lugar.
EL MODELO LINEAL SECUENCIAL
Llamado algunas veces ciclo de vida bsico o modelo de cascada sugiere un enfoque sistemtico, secuencial del
desarrollo del software que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin, pruebas
y mantenimiento. El modelo lineal secuencial acompaa a las actividades siguientes:
Ingeniera y modelado de Sistemas/Informacin. Como el software siempre forma parte de un sistema ms grande, el
trabajo comienza estableciendo requisitos de todos los elementos del sistema y asignando al software algn
subgrupo de estos requisitos.
Anlisis de los requisitos del software. El proceso de reunin de requisitos se intensifica y se centra especialmente en
el software.
Diseo. Es un proceso de muchos pasos que se centra en cuatro atributos distintos de un programa:
Estructura de datos Arquitectura del software
Representaciones de interfaz Detalle procedimental (algoritmo)
Traduce requisitos en una representacin del software que se pueda evaluar por calidad antes de que comience la
generacin de cdigo. El diseo se documenta.
Generacin de cdigo. El diseo se debe traducir en una forma legible por la mquina.
Pruebas. Una vez que se ha generado un cdigo, comienzan las pruebas del programa. El proceso de pruebas se
centra en los procesos lgicos internos del software.
Mantenimiento. El software indudablemente sufrir cambios despus de ser entregado al cliente. El mantenimiento
vuelve a aplicar cada una de las fases precedentes a un programa ya existente y no a uno nuevo.
Problemas en el modelo lineal secuencial:
1. Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo.
2. A menudo es difcil que el cliente exponga explcitamente todos los requisitos.
3. El cliente debe tener paciencia. Una versin de trabajo del (los) programa (s) no estar disponible hasta que el
proyecto est muy avanzado.
4. Los responsables del desarrollo del software siempre se retrasan innecesariamente.

2
EL MODELO DE CONSTRUCCIN DE PROTOTIPOS
Un cliente a menudo define un conjunto de objetivos generales para el software, pero no identifica los requisitos
detallados de entrada, procesamiento, o salida. En estas y en otras muchas situaciones, un paradigma de
construccin de prototipos puede ofrecer el mejor enfoque.
El paradigma de construccin de prototipos comienza con la recoleccin de requisitos. El desarrollador y el cliente
encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos, y las reas del
esquema en donde es obligatoria ms definicin. Entonces aparece un diseo rpido. El diseo rpido lleva a la
construccin de un prototipo. El prototipo lo evala el cliente/usuario y lo utiliza para refinar los requisitos del
software a desarrollar. La interaccin ocurre cuando el prototipo satisface las necesidades del cliente, a la vez que
permite que el desarrollador comprenda mejor lo que necesita hacer.
Problemas del modelo de construccin de prototipos:
1. El cliente ve lo que parece ser una versin de trabajo del software, sin saber que con la prisa de hacer que
funcione no se ha tenido en cuenta la calidad del software global o la facilidad de mantenimiento a largo plazo.
2. El desarrollador a menudo hace compromisos de implementacin para hacer que el prototipo funcione
rpidamente.
EL MODELO DRA
El Desarrollo Rpido de Aplicaciones (DRA) es un modelo de proceso del desarrollo del software lineal secuencial que
enfatiza un ciclo de desarrollo extremadamente corto. Es una adaptacin a alta velocidad del modelo lineal
secuencial utilizando un enfoque de construccin basado en componentes. Comprende las siguientes fases:
Modelado de gestin: responde: qu informacin conduce el proceso, qu informacin se genera, quin la
genera, a dnde va y quin la procesa.
Modelado de datos: se definen las caractersticas de cada uno de los objetos y las relaciones entre los objetos
Modelado de proceso: las descripciones del proceso se crean para aadir, modificar, suprimir, o recuperar un
objeto de datos
Generacin de aplicaciones: trabaja para utilizar componentes ya existentes o a crear componentes reutilizables.
Pruebas y entrega: se deben probar todos los componentes nuevos y las interfaces.
Inconvenientes:
Para proyectos grandes, requiere recursos humanos suficientes para crear los equipos DRA.
Requiere clientes y desarrolladores comprometidos en las rpidas actividades necesarias.
MODELOS DE PROCESOS EVOLUTIVOS DE SOFTWARE
Modelo incremental
Combina elementos del modelo lineal secuencial con la filosofa interactiva de construccin de prototipos. Cada
secuencia lineal produce un incremento del software.
Cuando se utiliza un modelo incremental, el primer incremento es un producto esencial (ncleo). El plan afronta la
modificacin del producto central para cumplir las necesidades del cliente. Este proceso se repite hasta que se
elabore el producto completo. A diferencia de la construccin de prototipos, se centra en la entrega de un producto
operacional en cada incremento. Es til cuando no est disponible el personal para una implementacin completa en
la fecha lmite.
Modelo en espiral
Es un modelo de proceso evolutivo que acompaa la naturaleza interactiva de la construccin de prototipos con los
aspectos del modelo lineal secuencial.
El modelo en espiral se divide en actividades estructurales, tambin llamadas regiones de tareas:
Comunicacin con el cliente
Planificacin: definir recursos, tiempo y otras informaciones relacionadas con el proyecto.
Anlisis de riesgos: evaluar riesgos tcnicos y de gestin.
Ingeniera: construir una o ms representaciones de la aplicacin.
Construccin y adaptacin: construir, probar, instalar y proporcionar soporte al usuario.
Evaluacin del cliente: obtener la reaccin del cliente.
En todos los casos se aplican las actividades de proteccin.
Modelo de ensamblaje de componentes
El modelo de ensamblaje de componentes configura aplicaciones desde componentes preparados de software
(clases). Es un modelo evolutivo e interactivo.
Se identifican las clases candidatas. Esto se lleva a cabo examinando los datos que se van a manejar por parte de la
aplicacin y el algoritmo que se va a aplicar para conseguir el tratamiento. Las clases creadas se almacenan en una
3
biblioteca de clases. Una vez identificadas las clases candidatas se examina si ya existen y en ese caso se vuelven a
utilizar. Se compone as la primera interaccin de la aplicacin a construirse.
Este modelo lleva a la reutilizacin del software.
Modelo de desarrollo concurrente
Define una serie de acontecimientos que dispararn transiciones de estado a estado para cada una de las actividades
de la ingeniera del software. Todas las actividades existen concurrentemente, pero residen en estados diferentes.
MODELO DE MTODOS FORMALES
El modelo de mtodos formales acompaa a un conjunto de actividades que conducen a la especificacin
matemtica del software. La ambigedad, lo incompleto y la inconsistencia se descubren y corrigen mediante el
anlisis matemtico.
Inconvenientes:
Caro y lleva mucho tiempo.
Los desarrolladores poseen pocos antecedentes necesarios.
Difcil comunicacin con el cliente con pocos conocimientos tcnicos.
TCNICAS DE CUARTA GENERACIN
El paradigma de las tcnicas de cuarta generacin (T4G) se orienta hacia la posibilidad de especificar el software
usando formas de lenguaje especializado o notaciones grficas que describan el problema que hay que resolver en
trminos que los entienda el cliente.
Actualmente, incluye algunas de las siguientes herramientas: lenguajes no procedimentales de consulta de base de
datos, generacin de informes, manejo de datos, interaccin y definicin de pantallas, generacin de cdigos,
capacidades grficas de alto nivel y capacidades de hoja de clculo.
TECNOLOGA DE PROCESOS
Los modelos de procesos tratados se deben adaptar para utilizarse por el equipo de proyecto. Para conseguirlo, se
han desarrollado herramientas de tecnologa de procesos que permiten que una organizacin de software construya
un modelo automatizado de la estructura comn del proceso, conjuntos de tareas y actividades de proteccin.
PRODUCTO Y PROCESO
Las personas obtienen tanta satisfaccin del proceso creativo que del producto final. La dualidad de producto y
proceso es un elemento importante para mantener ocupada a la gente creativa hasta que se finalice la transicin de
la programacin a la ingeniera del software.

METODOLOGAS
Beneficios
Predecir y Reducir costos y tiempos de desarrollo Aumentar velocidad de desarrollo
Mejorar la calidad Mejorar las relaciones con usuarios y clientes
Apalancamiento de recursos Pro actividad con proveedores externos
Minimizar riesgos Enriquecer capital intelectual de la organizacin
Definir roles y perfiles
Ciclo de vida: enfoque por fases de las tareas de desarrollo (Requerimientos, Anlisis/Diseo, Construccin, Pruebas,
Produccin/Mantenimiento)
Fase: conjunto de actividades relacionadas con un objetivo en el desarrollo de un sistema.
Entregables: productos intermedios que generan las fases. Materiales o inmateriales.
Modelo de ciclo de vida: vista de las act del desarrollo, determina orden y criterios de transicin entre etapas.
Modelo en Cascada (Relevamiento, Anlisis, Diseo, Codificacin, Testing)
Asume requerimientos estables
Netamente secuencial
No hay superposicin de etapas ni vuelta atrs
En cada etapa se produce un artefacto diferente
Los problemas se acumulan hacia las ltimas etapas
Modelo Iterativo (Se entrega el sistema completo al comienzo y se van haciendo cambios y mejoras en cada release).
Ventajas:
Riesgos reducidos a una iteracin
Concentracin en el producto no en las tareas
Cambios de requerimientos no afectan la construccin
4
 Entrega rpida y peridica de funcionalidad
Rpido feedback del cliente
Modelo Incremental (se especifica el sistema y se particiona en subsistemas, se comienza por uno y se va agregando
funcionalidad en cada release, cascada en cada release)
Desventaja: errores en los requisitos se detectan tarde
Modelo Iterativo-Incremental (se van creando versiones cada vez ms completas segn feedback del cliente,
usualmente iteraciones de 30 das)
Ventajas:
Resolucin de problemas en tiempos tempranos del proyecto
Visin de avance desde el inicio
Feedback rpido
Aprendizaje rpido del equipo, mejorando productividad
Menor tasa de fallo del proyecto, menos defectos
Permite manejar complejidad, yendo por partes
Evolucin de Metodologas
Codificar y corregir, Estructurada, Cascada, CMM(CMMI, ISO, PMI), Orientacin a Objetos, RUP, Agiles.
Metodologa Estructurada: fines de los 70 con prog estructurada, luego aparecieron tcnicas para el diseo (diag de
estructura) y despus anlisis (diag de flujo de datos). Ideales para proyectos en lenguajes de 3ra y 4ta generacin.
Metodologas orientadas a objetos: (lenguajes SIMULA fines 60, Smalltalk-80 fines 70, C++ v. 1ra en 1981, Java o C#
actuales) Fines de los 80, consolidacin de algunos mtodos OO. 1995 Boock y Rumbaugh proponen Mtodo
Unificado posteriormente Unifed Modeling Languaje (UML). Ejemplos de metodologas que usan UML: RUP, OPEN,
METRICA
Metodologas orientadas al plan: Caractersticas: requiere: Procesos definidos, Planificacin predictiva, Definicin de
tareas e hitos, Documentacin como producto intermedio entre etapas. Esto tiende a controlar, medir y mejorar el
proceso. (Mitos: Implica modelo en cascada, alto nivel de madurez, burocrticos, tiempo dedicado al inicio
justificado, impide adaptarse a cambios)
Metodologas Agiles: Manifiesto gil: Hemos llegado a valorar:
A los individuos y su interaccin, por encima de los procesos y las herramientas.
El software que funciona, por encima de la documentacin exhaustiva.
La colaboracin con el cliente, por encima de la
negociacin contractual.
La respuesta al cambio, por encima del seguimiento de
un plan.
Aunque hay valor en los elementos de la derecha, valoramos
ms los de la izquierda.
Caractersticas: Satisfaccin del cliente (rpida y continua
entrega de funcionalidad), SW completamente funcional
liberado en semanas en vez de meses y es la principal
medida de progreso, Cooperacin cercana (diaria entre
gente de negocios y desarrolladores), mejor comunicacin
(cara a cara), proyectos construidos por gente motivada en la que se confa, Atencin en la excelencia tcnica y al
buen diseo, equipos auto-organizados, Adaptacin regular a circunstancias cambiantes, Simplicidad. (Mitos: No se
planifica, integrantes de gurpo excepcionales, costo de los cambios uniforme) Ejemplos: Scrum, XP, Lean
development, Crystal, DSDM, EVO, Feature-Driven Development, Adaptative SW Development
Metodologas giles Metodologas Tradicionales
Basadas en heursticas provenientes de prcticas de Basadas en normas provenientes de estndares seguidos por
produccin de cdigo el entorno de desarrollo.
Especialmente preparados para cambios durante el Cierta resistencia a los cambios
proyecto
Impuestas internamente (por el equipo) Impuestas externamente
Proceso menos controlado, con pocos principios Proceso mucho ms controlado, con numerosas
polticas/normas
No existe contrato tradicional o al menos es Existe un contrato prefijado

5
bastante flexible
El cliente es parte del equipo de desarrollo El cliente interacta con el equipo de Desarrollo mediante
reuniones
Grupos pequeos (<10 integrantes) y trabajando en Grupos grandes y posiblemente distribuidos
el mismo sitio
Pocos artefactos Ms artefactos
Pocos roles Ms roles
Menos nfasis en la arquitectura del software La arquitectura del software es esencial y se expresa
mediante modelos
Desarrollo en incrementos cortos con entregas Desarrollo sin entrega de producto durante largos perodos
frecuentes. de tiempo.
Se trabaja con inventario reducidos. Aumento de inventarios de informacin en cada fase de
desarrollo.
Adaptabilidad permanente a los cambios. Rigidez, control y prevencin de cambios en los requisitos.
Foco en la satisfaccin del Cliente. Foco en cumplir un proceso definido
Transferencia de informacin en momentos pre- Transferencia frecuente de informacin durante todo el
determinados del desarrollo. desarrollo
Anarqua gil
Cuando se planifica es de manera informal Se planifica regularmente.
Se usa todo el tiempo para codificar Se usa todo el tiempo realizando tareas que aporten valor al
producto que se va a construir.
Las personas se comunican solo cuando hay El equipo y el cliente se comunican continuamente
problemas.
Los involucrados tienen poca visibilidad Los involucrados tienen siempre tiene visibilidad sobre lo que
control del proyecto est pasando
Rara vez se documenta Se documenta lo necesario.
Rara vez se cumple con los plazos prometidos. Al final de cada iteracin se entrega lo comprometido.
Prcticas XP: El juego de la planificacin, Entregas pequeas, Metfora, Diseo simple, Pruebas, Refactorizacin
(Refactoring), Programacin en parejas, Propiedad colectiva del cdigo, Integracin continua, 40 horas por semana,
Cliente in-situ.
Seleccin de Metodologas

6
 PLANIFICACION DE PROYECTOS DE SOFTWARE

El proceso de gestin del proyecto de software comienza con un conjunto de actividades que, se denominan
planificacin del proyecto. L a primera de esas actividades es la estimacin.
OBSERVACIONES SOBRE LA ESTIMACION
La complejidad del proyecto tiene un gran defecto en la incertidumbre, que es inherente en la planificacin.
El tamao del proyecto puede afectar a la precisin de las estimaciones. A medida que el tamao aumenta, crece
rpidamente la interdependencia entre varios elementos del soft. El problema de la descomposicin, un enfoque
importante hacia la estimacin, se hace mas difcil porque los elementos descompuestos pueden ser todava
excesivamente grandes.
El grado de incertidumbre estructural tiene tambin efecto en el riesgo de la estimacin.
La disponibilidad de informacin histrica tambin determina el riesgo de la estimacin.
El riesgo se mide por el grado de incertidumbre de las estimaciones cuantitativas establecidas por recursos, coste y
planificacin temporal. Si no se entiende bien el mbito del proyecto o los requisitos del proyecto estn sujetos a
cambios, la incertidumbre y el riesgo son peligrosamente altos.
OBJETIVOS DE LA PLANIFICACION DEL PROYECTO
Es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos, coste y
planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un
proyecto de software, y deberan actualizarse regularmente a medida que progresa el proyecto. Adems las
estimaciones deberan definir los escenarios del mejor caso y peor caso de forma que los resultados del proyecto
pueden limitarse.
OBJETIVOS DE LA PLANIFICACION DEL PROYECTO
Determinar el mbito del software es la primera actividad de la planificacin del proyecto.
El mbito describe la funcin, el rendimiento, las restricciones, las interfaces y la fiabilidad.
- Funciones: descriptas en el enunciado del mbito y en algunos casos se refinan para dar ms detalles antes del
comienzo de la estimacin.
- Rendimiento: abarcan los requisitos de tiempo de respuesta y de procesamiento.
- Restricciones: identifican los lmites del software originados por el hardware externo, por la memoria disponible
y por otros sistemas existentes.
El planificador del proyecto examina la especificacin del mbito y extrae todas las funciones importantes del
software. Este proceso se denomina descomposicin.
La funcin, el rendimiento y las restricciones estn ntimamente relacionadas.
El software interacta con otros elementos del sistema informtico. El planificador considera la complejidad de la
interfaz para determinar cualquier efecto sobre los recursos, los costes y la planificacin temporal del desarrollo. El
concepto de interfaz abarca lo siguiente:
- Hardware que ejecuta el soft y los dispositivos que estn controlados indirectamente por el soft.
- Software ya existente que debe ser integrado con el nuevo soft
- Persona que hace uso del soft por medio de terminales u otros medios de entrada/salida
- Procedimientos que preceden o suceden al soft en una secuencia de operaciones.
Existen medidas de fiabilidad, pero raramente se usan en esta etapa del proyecto.
RECURSOS

7
La segunda tarea de la planificacin del desarrollo es la estimacin de los recursos requeridos. Recursos de Desarrollo
en forma de pirmide:
- Base: entorno de desarrollo soft y hard
- Nivel ms alto: componentes reutilizables-
- Nivel siguiente ms alto: recurso primario las personas.
Cada recurso queda especificado mediante cuatro caractersticas: descripcin del recurso informe de
disponibilidad fecha cronolgica en la que se requiere el recurso tiempo durante el que ser aplicado el recurso-
Recursos humanos:
El encargado de la planificacin comienza elevando el mbito y seleccionando las habilidades tcnicas, hay que
especificar la posicin dentro de la organizacin y la especialidad. Para proyectos relativamente pequeos una sola
persona puede llevar a cabo todos los pasos de ingeniera del soft. El nmero de personas requerido para un
proyecto solo puede ser determinado despus de hacer una estimacin del esfuerzo de desarrollo. Ej. personas-mes
o personas-ao.
Recursos de soft reutilizables:
La reutilizacin es la creacin y la reutilizacin de bloques de construccin de soft. Tales bloques deben establecerse
en catlogos para una consulta ms fcil, estandarizarse para una fcil aplicacin y validarse para la integracin.
4 categoras de recursos reutilizables a tener en cuenta:
- Componentes ya desarrollados: listos para utilizarse
- Componentes ya experimentados: las modificaciones requeridas tendrn un riego relativamente bajo.
- Componentes con experiencia parcial: las modificaciones requeridas tendrn bastante grado de riesgo.
- Componentes nuevos: componentes que se deben construir especficamente para satisfacer las necesidades del
proyecto actual.
Recursos del entorno:
El entorno es donde se apoya el proyecto de soft (entorno de ingeniera del soft (EIS)), incorpora hard y soft. El hard
proporciona una plataforma con las herramientas (soft) requeridas para producir los productos que son el resultado
de una buena practica de la ing del soft.
ESTIMACION DEL PROYECTO DE SOTFWARE
Para realizar estimaciones seguras de costes y esfuerzos tenemos varias opciones posibles:
1. Dejar la estimacin para ms adelante. no prctica-
2. Basar las estimaciones en proyectos similares ya terminados si el proyecto actual es similar -
3. Utilizar tcnicas de descomposicin relativamente sencillas para generar las estimaciones de coste y de esfuerzo
del proyecto.
4. Desarrollar un modelo emprico para el clculo de costes y esfuerzos del software.
3) y 4) mtodos viables.
TECNICAS DE DESCOMPOSICION
Si el problema es demasiado complejo para considerarlo como un todo, se descompone definindolo como un
conjunto de pequeos problemas.
Descomposicin desde dos puntos de vista diferentes:
- Descomposicin del problema
- Descomposicin del proceso
Antes de hacer una estimacin, el planificador del proyecto debe comprender el mbito del soft a construir y
generar una estimacin de su tamao.
Tamao del software: representa el primer reto importante del planificador de proyectos. Enfoque directo: se
puede medir en LDC lneas de cdigo -
Enfoque indirecto: el tamao se representa como PF puntos de funcin
Estimaciones basadas en el problema: los datos del LDC y PF se utilizan de dos formas durante la estimacin del
proyecto de software:
1. Como variable de estimacin que se utiliza para dimensionar cada elemento del software
2. Como mtricas de lnea base recopiladas de proyectos anteriores y utilizadas junto con variables de
estimacin para desarrollar proyecciones de coste y de esfuerzo.
Cuando ms grande sea el particionamiento, ms probable ser que pueda desarrollar estimaciones ms exactas.

8
Estimaciones basadas en el proceso: la tcnica ms comn para estimar un proyecto es basar la estimacin en el
proceso que se va a utilizar. El proceso se descompone en un conjunto relativamente pequeo de actividades o
tareas, y en el esfuerzo requerido para llevar a cabo la estimacin de cada tarea.
Si ambas estimacin coinciden las estimaciones son fiables, sino hay que buscar ms informacin.
MODELOS EMPIRICOS DE ESTIMACION
Un modelo de estimacin para el soft de computadora utiliza formulas derivadas empricamente para predecir el
esfuerzo como una funcin de LDC y PF. Los valores resultantes para LDC y PF se unen al modelo de estimacin. Los
datos empricos que soportan la mayora de los modelos de estimacin se obtienen de una muestra limitada de
proyectos.
El modelo COCOMO modelo constructivo de coste - jerarqua de modelos de estimacin de soft.
- Modelo 1: COCOMO BASICO: calcula el esfuerzo del desarrollo de soft en funcin del tamao del programa,
expresado en las lneas estimadas de cdigo. (LDC)
- Modelo 2: COCOMO INTERMEDIO: calcula el esfuerzo del desarrollo de software en funcin del tamao del
programa y de un conjunto de conductores de coste que incluyan la evaluacin subjetiva del producto, del
hardware, del personal y de los atributos del proyecto.
- Modelo 3: COCOMO AVANZADO: incorpora todas las caractersticas de la versin intermedia y lleva a cabo una
evaluacin del impacto de los conductores de coste en cada fase (anlisis, diseo, etc) del proyecto de ingeniera
del software.
Los modelos COCOMO estn definidos para tres tipos de proyectos de software:
- Modo orgnico- proyectos relativamente pequeos y sencillos - pequeos equipos con buena experiencia en la
aplicacin -
- Modo semiacoplado - proyectos medianos- equipos con distintos niveles de experiencia
- Modo empotrado proyectos que deben ser desarrollados en un conj. de hard, soft y restricciones operativas
muy restringido.

La ecuacin del software:

Es un modelo multivariable que asume una distribucin especfica del esfuerzo a lo largo de la vida de un proyecto
de desarrollo de software.
La ecuacin del software tiene dos parmetros dependientes:
1. Una estimacin del tamao
2. Una indicacin de la duracin del proyecto en meses o aos.
LA DECISION DESARROLLAR-COMPRAR
Los gestores de ingeniera se enfrentan con una decisin desarrollar o comprar . opciones de adquisicin:
1. El software se puede comprar ya desarrollado (con licencia);
2. Se pueden adquirir componentes de soft totalmente experimentado o parcialmente experimentado y
entonces modificarse e integrarse para cumplir las necesidades especficas.
3. El soft puede ser construido de forma personalizada por una empresa externa para cumplir las especificaciones
del comprador.
La organizacin de la ingeniera del software puede:
1. Construir el sistema desde el principio
2. Reutilizar los componentes existentes
3. Comprar un producto de software disponible y modificarlos para cumplir las necesidades locales.
4. Contratar el desarrollo del software a un vendedor externo. (outsourcing- Subcontratacin)
Subcontratacin: Las actividades de ingeniera del soft se contratan a un tercero quien hace el trabajo a bajo coste,
asegurando una alta calidad. El trabajo de soft dentro de la compaa se reduce a una actividad de gestin de
contratos.
HERRAMIENTAS AUTOMATICAS DE ESTIMACION
Permiten al planificador estimar costes y esfuerzos, as como llevar a cabo anlisis del tipo que pasa si con
importantes variables del proyecto, tales como la fecha de entrega o la seleccin de personas.
Aunque existen muchas herramientas automticas de estimacin, todas exhiben las mismas caractersticas
generales y todas requieren una o ms clases de datos como los mostrados a continuacin:
1. Una estimacin cuantitativa del tamao del proyecto
2. Caractersticas cualitativas del proyecto (complejidad/fiabilidad etc)
3. Alguna descripcin del personal de desarrollo y/ o entorno de desarrollo.
9
 EL PROCESO DE SOFTWARE Y METRICAS DEL PROYECTO

Mtricas del software: Son medidas para el software de computadora. La medicin se puede aplicar:
- Al proceso (para mejorarlo)
- En el proyecto (para ayudar en la estimacin, control de calidad etc).
- El ingeniero del software (para evaluar calidad de productos/ para ayudar en la toma de decisiones)
MEDIDAS, METRICAS E INDICADORES
Medida: indicacin cuantitativa de extensin cantidad, dimensiones, capacidad y tamao de algunos atributos de un
proceso o producto.
Medicin: es el acto de determinar una medida.
Mtrica: medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado.
Indicador: se obtiene de la recopilacin de medidas y desarrollo de mtricas. Proporciona: visin profunda del
proceso de soft, del proyecto de soft y del producto del soft
Las mtricas permiten al gestor del proyecto y/o ing. soft la toma de decisiones ms fundamentadas.
METRICAS EN EL PROCESO Y DOMINIOS DEL PROYECTO
Indicadores del proceso: Permite:
- Visin de la eficiencia de un proceso ya existente.
- Evaluar lo que funciona y lo que no.
- Las mtricas de recopilan de todos los proyectos un largo tiempo.
Indicadores del proyecto: Permite:
- Evaluar el estado del proyecto
- Seguir la pista de los riegos potenciales
- Detectar reas de problemas antes de que se conviertan en criticas
- Ajustar flujo y tareas del trabajo
- Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos.
METRICAS DEL PROCESO
La eficiencia de un proceso de soft se mide indirectamente. Se extrae un juego de mtricas segn los resultados que
provienen del proceso. Entre los resultados se incluyen:
- Errores detectados antes de la entrega del soft.
- Defectos detectados e informados por los usuarios finales.
- Productos de trabajo entregado
- Esfuerzo humano y tiempo consumido
- Ajuste con la planificacin
- Caractersticas de tareas especficas de la ing del software.
Para diferentes tipos de datos de proceso existen mtricas de:
Uso privado: entre los ejemplos de mtricas que son privadas del individuo se incluyen:
- ndices de defectos
- ndices de defectos por mdulos
- Errores encontrados durante el desarrollo
Uso pblico: algunas mtricas del proceso son privadas para el equipo del proyecto, pero son pblicas para todos los
miembros del equipo. Entre los ejemplos se incluyen:
- Defectos informados de funciones importantes del software
- Errores encontrados durante revisiones tcnicas formales y lneas de cdigo o puntos de funcin por mdulo y
funcin
A medida que una organizacin est ms a gusto con la recopilacin y utiliza mtricas de proceso, la derivacin de
indicadores simples abre el camino hacia un enfoque ms riguroso, llamado mejora estadstica del proceso del
software MEPS. MEPS utiliza: anlisis de fallos del software para recopilar informacin de errores y defectos
encontrados al desarrollar y utilizar una aplicacin de sistema o producto.
El anlisis de fallos funciona de la siguiente manera:
1. Todos los errores y defectos se categorizan por origen
2. Se registra tanto el coste de corregir cada error como el defecto.
10
3. El nmero de errores y de defectos de cada categora se cuentan y se ordenen en orden descendente.
4. Se computa el coste global de errores y defectos de cada categora.
5. Los datos resultantes se analizan para detectar las categoras que producen el costo ms alto para la
organizacin.
6. Se desarrollan planes para modificar el proceso con el intento de eliminar la clase de errores y defectos que sean
ms costosos.
La coleccin de mtricas del proceso es el conductor para la creacin del diagrama en espina completo desde el cual
se puede analizar para extraer los indicadores que permitan a una organizacin modificar su proceso para reducir la
frecuencia de errores y defectos.
METRICAS DEL PROYECTO
- Se deben recopilar mtricas de proyectos anteriores que se utilizan como base para estimaciones (medidas de
esfuerzo y tiempo).
- Se miden ndices de produccin.
- Se miden horas de revisin
- Los puntos de funcin
- Lneas fuentes entregadas.
- Se sigue la pista de los errores detectados
- Se recopilan las mtricas tcnicas para evaluar la calidad del diseo.
El uso de mtricas para el proyecto tiene dos aspectos fundamentales:
- Minimizar la planificacin de desarrollo
- Evaluar la calidad de los productos en el momento actual
Otro modelo de mtricas sugiere que todos los proyectos deberan medir:
- Entradas: la dimensin de los recursos (personas, entorno) que se requieren para realizar el trabajo
- Salidas: medidas de las entregas o productos creados durante el proceso de ingeniera del soft.
- Resultados: medidas que indican la efectividad de las entregas.
Este modelo se puede aplicar tanto al proceso como al proyecto. Las salidas de una actividad se convierten en las
entradas de las siguientes.
MEDICIONES DEL SOFTWARE
Medidas directas:
- Del proceso de la ingeniera del software: se incluyen el coste y el esfuerzo aplicados.
- Del producto: se incluyen las lneas de cdigo producidas, velocidad de ejecucin, tamao de memoria y los
defectos.
Medidas indirectas:
- Se incluyen la funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento.
Las mtricas del software se dividen en mtricas de:
- Proceso
- Proyecto
- producto

METRICAS ORIENTADAS AL TAMAO

- Provienen de la normalizacin de las medidas de calidad y/o tamao productividad considerando el tamao
del soft. que se haya producido.

- Si una organizacin de soft mantiene registros sencillos, se puede crear una tabla de datos orientados al tamao.
La tabla lista cada proyecto de desarrollo de soft de ltimos aos y las medidas correspondientes de cada
proyecto.

- Se seleccionan lneas de cdigo como valor de normalizacin (LDC)

Mtricas simples orientadas al tamao:

- Errores por KLDC (miles de lneas de cdigo, KiloLDC)
- defectos por KLDC
- $ por LDC
- Pginas de documentacin por KLDC
- Errores/persona-mes
11
- LDC por persona-mes
- $/pgina de documentacin.
METRICAS ORIENTADAS A LA FUNCIN
Utilizan una medida de la funcionalidad entregada por la aplicacin como valor de normalizacin. Ya que la
funcionalidad no se puede medir directamente, se debe derivar indirectamente mediante otras medidas directas.
Punto de funcin: se derivan con una relacin emprica segn las medidas contables (directas) del dominio de
informacin del soft y las evaluaciones de la complejidad del soft. Para aplicaciones de sist de inf de gestin. Se
determinan cinco (5) caractersticas de dominios de informacin. Los valores de dominios se definen de la forma
siguiente:
- Nmero de entradas de usuario
- Nmero de salidas de usuario
- Nmero de peticiones de usuario
- Nmeros de archivos
- Nmero de interfaces externas.
Una vez que se han recopilado los datos, a la cuenta se asocia un valor de complejidad. Las organizaciones que
utilizan mtodos de punto de funcin desarrollan criterios para determinar si una entrada en particular es simple,
media o compleja.
Para calcular puntos de funcin (PF) se utilizan la siguiente relacin:

PF= cuenta total * (0.65 + 0.01 * Fi)

METRICAS AMPLIADA DE PUNTO DE FUNCION
Para remediar la medida del punto de funcin que era inadecuada para muchos sistemas de ingeniera y sistemas
empotrados (que enfatizan funcin y control) se proponen un numero de extensiones bsicas a la mtrica del punto
de funcin bsica:
- Punto de caracterstica: se acomoda a aplicaciones dnde la complejidad del algortmo es alta (soft de tiempo
real, control de procesos etc).
Algoritmo: problema de clculo limitado que se incluye dentro de un programa de computadora especfico.
- Punto de funcin 3d: adecuada para aplicaciones que enfatizan capacidades de funcin y control: sistemas en
tiempo real y productos de ingeniera.
Dimensin de datos: las cuentas de datos internos y los datos externos se utilizan a lo largo de las medidas de
complejidad para derivar una cuenta de dimensin de datos.
Dimensin funcional: Se mide considerando el nmero de operaciones internas requeridas para transformar datos
de entrada en datos de salida.
Dimensin de control: se mide contando el nmero de transiciones entre estados. Un estado presenta algn modo
de comportamiento externamente observable y una transicin ocurre como resultado de algn suceso que cambia el
modo de comportamiento del sistema o del soft.
RECONCILIACION DE LOS DIFERENTES ENFOQUES DE METRICAS
La relacin entre las lneas de cdigo y los puntos de funcin depende del lenguaje de programacin que se utilice
para implementar el software y la calidad del diseo.
LDC y PF: se utilizan para extraer mtricas de productividad.
Cinco factores que inciden en la productividad:
- Factores humanos: El tamao y la experiencia de la organizacin en desarrollo.
- Factores del problema: la complejidad del problema que se debe resolver y el nmero de cambios en las
restricciones o los requisitos del diseo.
- Factores del proceso: tcnicas de anlisis y diseo que se utilizan, lenguajes y herramientas CASE.
- Factores del producto: fiabilidad y diseo del sistema basado en computadora.
- Factores del recurso: disponibilidad de herramientas CASE, y recursos de hardware y software.
METRICAS PARA LA CALIDAD DEL SOFTWARE
El objetivo primordial de la ingeniera del software es producir un sistema, aplicacin o producto de alta calidad
VISION GENERAL DE LOS FACTORES QUE AFECTAN A LA CALIDAD.
Los factores de calidad evalan al software desde tres puntos de vista distintos:
1. Operacin del producto (utilizndolo)
2. Revisin del producto (cambindolo)
3. Transicin del producto (modificndolo para que funcione en un entorno diferente)
12
La relacin entre estos factores es llamada marco de trabajo.
MEDIDA DE CALIDAD
Proporcionan indicadores tiles:
- Correccin: es el grado en el que el soft lleva a cabo su funcin requerida. La medida mas comn de correccin
son los defectos de KLCD, en donde se define como una falta verificada de conformidad con los requisitos.
- Facilidad de mantenimiento: es la facilidad con la que se puede corregir un programa si se encuentra un error. Se
puede adaptar si su entorno cambia, o mejorar, si el cliente desea un cambio de requisitos.
- Facilidad de uso: es un intento de cuantificar lo amigable que puede ser con el usuario y se puede medir en
funcin de 4 caractersticas:
1. Habilidad intelectual y/o fsica requerida para aprender el sistema.
2. El tiempo requerido para llegar a ser moderadamente eficiente en el uso del sistema.
3. Aumento neto en productividad medida cuando alguien usa el sistema moderadamente y eficientemente.
4. Valoracin subjetiva de la disposicin de los usuarios hacia el sistema.
- Integridad: ste atributo mida la habilidad de un sistema para resistir ataques contra su seguridad. Para medir la
integridad, se tienen que definir 2 atributos adicionales: amenaza es la probabilidad de que un ataque de un tipo
determinado ocurra en un tiempo determinado. La seguridad es la probabilidad de que se pueda repeler el
ataque de un tipo determinado.
EFICACIA DE LA ELIMINACION DE DEFECTOS
Una mtrica de la calidad que proporciona beneficios tanto a nivel del proyecto como del proceso, es la eficacia de la
eliminacin de defectos (EDD). En esencia EED es una medida de la habilidad de filtrar las actividades de la garanta
de calidad y de control al aplicarse a todas las actividades del marco de trabajo del proceso. Cuando se toma en
consideracin globalmente para un proyecto, EED se define de la siguiente forma:

EED = E/ (E+D)
E= nmero de errores encontrados antes de la entrega del soft al usuario final.
D= nmero de defectos encontrados despus de la entrega.
El valor ideal de EED es 1, esto es, no se han encontrado defectos en el soft.
EED tambin se puede usar dentro del proyecto para evaluar la habilidad de un equipo en encontrar errores antes
de que pasen a la siguiente actividad estructural o tarea de ingeniera del soft.

CALIDAD
Razones (Competitividad, Supervivencia, Beneficios, Clientela, Distintivo)
Evolucin del concepto: Inspeccin, Control estadstico de la calidad, Aseguramiento de la calidad, Gestin
estratgica de la calidad)
Mitos (la calidad no puede medirse porque es intangible; es cara; significa lujo, peso y brillo; no es un problema de la
gerencia y la administracin; es responsabilidad del Dpto de calidad)
Cambio de paradigmas:
Detectar errores -> prevenirlos
Cumplir estndares -> satisfacer al cliente
Cumplir presupuesto -> agrega valor al producto
Invertir en calidad -> disminuir controles y aumentar la prevencin
Calidad requiere tiempo -> aprovecha el tiempo
Responsabilidad de pocos -> responsabilidad de todos (mejora continua)
Realizada: la que es capaz de obtener la persona que realiza el trabajo.
Programada: La que se ha pretendido obtener.
Necesaria: La que el cliente exige con mayor o menor grado de concrecin
Los costos asociados a la conformidad (entrenamiento, evaluacin y pruebas, planificacin) reducen (y producen
ahorro) los asociados a la no conformidad (desperdicio, retrabajo, correcciones)
Software: los programas de ordenador, los procedimientos y, posiblemente, la documentacin asociada y los datos
relativos a la operacin del sistema informtico (se desarrolla no se fabrica, no tiene existencia fsica es lgico, no se
degrada con el uso, se entrega con defectos, se hace a medida, extraordinariamente flexible.
La medida del SW:

13
- En numerosos casos se limita a la obtencin de datos estadsticos sobre la satisfaccin del cliente sin entrar en
conceptos ms propios del sw y sus atributos tales como la fiabilidad, madurez, estabilidad, etc.
- Se encuentra lejos de ser una verdadera cuantificacin de los atributos de procesos o productos, limitndose a
la acumulacin de cantidades, resultado de medidas realizadas sobre atributos poco definidos con el fin de
obtener una base de datos histrica sobre la que aplicar diferentes herramientas matemticas de naturaleza
estadstica (Ej.: Puntos funcionales)
La calidad de productos y servicios depende de la calidad de los profesionales.
Calidad de SW: Grado con el que un sistema, componente o proceso cumple:
Los requisitos especificados.
Las necesidades o expectativas del cliente o usuario.
Factores que determinan la Calidad del Software:
Correccin. Hace lo que quiero?
Fiabilidad. Lo hace de forma fiable todo el tiempo?
Eficiencia. Se ejecutar en mi hardware lo mejor que pueda?
Seguridad (Integridad). Es seguro?
Facilidad de uso. Est diseado para ser usado?
Por qu es importante? Si se pone nfasis en las tareas de calidad se reducen los tiempos de re-elaboracin lo
cual reduce los costos y el tiempo de llegada del producto al cliente.
Atributos de Calidad del SW: Funcionalidad, Confiabilidad, Usabilidad, Mantenibilidad, Portabilidad, Eficiencia.
Qu se entiende por rework? Se considera rework al trabajo que se hace a causa de no haber realizado el
trabajo correctamente la primera vez, tambin se considera rework los cambios continuos que se hacen y el
trabajo duplicado entre personas.
Consecuencias de Baja Calidad: Baja
satisfaccin del usuario, Fricciones con el
usuario, Baja productividad y/o mayores
plazos, Altos costos de mantenimiento, Baja
moral del personal y/o alta rotacin,
Cancelacin de proyectos.
Beneficios: Ahorros del orden del 75% en
mantenimiento, satisfaccin del usuario,
productos con menos de 2 errores por PF.
(Imagen)
Dificultades de Implementacin
Implicar dedicarle bastante tiempo y
trabajo. Se producir el fenmeno tpico de
resistencia al cambio. El riesgo de la
desilusin inherente a un fracaso.
Falta de recursos, que normalmente se debe
a la ausencia de apoyo de la direccin.
Falta de formacin y educacin del personal,
incluso falta de motivacin de los
trabajadores.
Recomendaciones para la implementacin
Asegurar el compromiso de la alta direccin.
Involucrar a los mandos intermedios en su funcionamiento.
Proporcionar formacin e informacin adecuada: ms profunda a sus responsables y de tipo operativo a sus
componentes.
Utilizar casos reales en su puesta en marcha.
Definir y efectuar los mecanismos de seguimiento continuo de sus resultados.
Pactar con expertos y tcnicos a la hora de establecer metodologas, requisitos, niveles y criterios de
aceptacin.
Escribir procedimientos factibles.
Implementar indicadores de calidad que permitan saber qu tal van las cosas.

14
Modelo de Capacidad y Madurez Integrado - CMMI
Es un modelo de referencia de prcticas maduras usadas para evaluar y mejorar la capacidad de los procesos. Es una
ruta evolutiva de implementacin de las mejores prcticas en los
procesos organizacionales
Las prcticas centrales definen los siguientes pasos:
Definir los requisitos del cliente, entregables y objetivos del
proyecto a travs de mtodos de comunicacin con el cliente bien
definidos
Medir el proceso existente y su salida para determinar la
conformidad de calidad actual recopilar mtricas de defectos)
Analizar las mtricas de defectos y determinar sus causas vitales
Mejorar el proceso eliminando las causas principales de los
defectos
Controlar el proceso para asegurarse de que en el futuro no se vuelvan a introducir estos defectos

SCM (SW CONFIGURATION MANAGEMENT)

Gestin de la configuracin conjunto de procesos destinados a asegurar la validez de todo producto obtenido
durante cualquiera de las etapas del ciclo de vida del software, a travs del estricto control de los cambios realizados
sobre los mismos y de la disponibilidad constante de una versin estable de cada elemento para toda persona
involucrada en el citado desarrollo.
Objetivo Maximizar la productividad reduciendo el riesgo de cometer errores, control de cambios, informado y
registrando inf.
Actividades
1. Identificar los cambios
2. Controlar los cambios
3. Asegurar que los cambios han sido implementados correctamente
4. Notificar a los interesados acerca de los cambios realizados
Elementos de la configuracin
Clasificacin de entregables:
1. Programas de software
2. Documentacin
3. Datos
En su conjunto lo llamamos configuracin del software.
Elementos a controlar:
- Documentos relacionados con SCM - Planes de proyecto
- Especificaciones (de todo tipo) - Piezas de software
- Cualquier documentacin que d soporte al mantenimiento futuro del SW. - Casos de prueba
Nomenclatura e identificacin de elementos:
- El tipo de elemento - El proyecto al que pertenece
- El nmero de versin o revisin al que corresponde
Lneas de base (baseline) es una especificacin o producto que ha sido revisado formalmente y posteriormente
aceptado que luego servir como base para futuras construcciones y que solo podr ser modificada a travs de
procedimientos formales de control de cambios.
Planificacin deber contener:
Elementos de la configuracin que se gestionarn y su esquema de identificacin
Responsables de los procedimientos
Polticas a utilizar en la gestin de la configuracin, cambios y versiones
Herramientas a utilizar (junto con la metodologa de uso de las mismas)
Definicin de la base de datos de configuracin a utilizar
Proceso de gestin de la configuracin serie de tareas con 4 objetivos principales:
1. Identificar todos los elementos que colectivamente definen la configuracin del software

15
 2. Gestionar los cambios a uno o ms de los elementos
3. Facilitar la construccin de diferentes versiones de una aplicacin
4. Garantizar que la calidad se preserva conforme la configuracin evoluciona a lo largo del tiempo
Actividades
Identificacin de objetos en la configuracin del SW (nomenclatura)
Control de versin (almacenar todas las versiones de cada objeto)
Control de cambio (su objetivo es controlar que versin de un conjunto de componentes pertenece a una versin
determinada de la aplicacin)
Auditoria de la configuracin (permite garantizar que las actividades previas han sido llevadas a cabo, preservando la
calidad, 2 actividades: Revisiones tcnicas formales y Auditora de la configuracin del SW)
Informe de estado (objetivo comunicar los cambios: qu ocurri?, quin lo hizo?, cundo ocurri?, qu cosa se
ha visto afectada?
Herramientas CASE para la gestin de configuraciones se utilizan para almacenar las versiones de los componentes
para identificar y controlar las diferentes versiones y para comunicar sobre los cambios en la configuracin, a los
principales interesados.

TESTING V&V
Ayuda a garantizar la calidad, revisin final de las especificaciones, del diseo y de la codificacin.
Fundamentos de las pruebas de SW
Objetivos de las pruebas: (Igual que principios bsicos) (que sistemticamente pongan a la luz diferentes clases de
errores, logrando el objetivo con la menor cantidad de tiempo y de esfuerzo)
La prueba es el proceso de ejecucin de un programa con la intencin de descubrir un error.
Un buen caso de prueba es aquel que tiene una alta probabilidad de detectar un error no descubierto hasta
entonces.
Una prueba tiene xito si descubre un error no detectado hasta entonces.
Facilidad de Prueba: SW fcil de probar, caractersticas:
- Operatividad (Cuanto mejor funciones, ms eficientemente se pude probar)
- Observabilidad (lo que ves es lo que pruebas)
- Controlabilidad (Cuanto mejor podamos controlar el SW, ms se puede automatizar y optimizar)
- Capacidad de descomposicin (Controlando el mbito de las pruebas, podemos aislar ms rpido los problemas
y llevar a cabo mejores pruebas de regresin)
- Simplicidad (Cuanto menos haya que probar, ms rpida ser la prueba)
- Estabilidad (Cuanto menos cambios, menos interrupciones a las pruebas)
- Facilidad de comprensin (Cuanta ms informacin tengan, ms inteligentes sern las pruebas)
Caractersticas de una buena prueba:
Alta probabilidad de encontrar un error, desarrollar una imagen mental.
No debe ser redundante.
Debera ser la mejor cosecha.
No debera ser ni demasiado sencilla ni demasiado compleja.
Validacin: Estamos construyendo el producto correcto? El software debe hacer lo que el usuario realmente solicit
Verificacin: Estamos construyendo correctamente el
producto? El software debe presentar conformidad
respecto de su especificacin-
LaV&V debe ser aplicada en todas las etapas del
proceso de desarrollo. Tiene dos objetivos principales:
Descubrir defectos en un sistema
Evaluar si el sistema es o no es usable y til en una
en operacin
V&V debe proporcionar confianza sobre si el software
es adecuado para el cumplimiento de sus propsitos
Pruebas (test): actividad en la cual un sist o uno de sus componentes se ejecuta en circunstancias previamente
especificadas, los resultados se observan y registran y se realiza una evaluacin de algn aspecto.
Tipos de Pruebas
16
Pruebas de defectos
- Pruebas diseadas para descubrir defectos en el sistema
- Una prueba exitosa es aquella que revela la presencia de defectos en el sistema
Pruebas de validacin
- Muestran que el software satisface los requerimientos
- Una prueba exitosa es aquella que muestra que un requerimiento ha sido implementado de manera correcta
Planificacin de la V & V
Se requiere una planificacin cuidadosa para obtener el mejor resultado del proceso de pruebas e inspeccin. Debe
comenzar en forma temprana en el proceso de desarrollo y considerar el balance entre la verificacin esttica y las
pruebas.
El plan debe contener:
- Descripcin del proceso de pruebas
- La trazabilidad de requerimientos
- Especificacin de los productos a ser testeados
- La calendarizacin de tiempos
- Los procedimientos de registro
- Requerimientos de HW y SW
- Restricciones
Inspecciones de software
Involucran personas para examinar las representaciones de origen (diseos, cdigo fuente, etc) con el propsito de
descubrir anomalas y defectos. Las inspecciones no requieren la ejecucin de un sistema, por lo que pueden ser
utilizadas antes de su implementacin
Han demostrado ser una tcnica efectiva para el descubrimiento de los errores (una de las ms efectivas). Se utilizan
explcitamente para deteccin de defectos (no para su correccin).
Las inspecciones y las pruebas son tcnicas de verificacin complementarias y no opuestas
Ambas deberan ser utilizadas durante el proceso de V&V.
Las inspecciones no permiten chequear requerimientos no funcionales, como performance, etc.
Software de sala limpia
El nombre proviene de Sala Limpia en la produccin de semi-conductores. El concepto es la prevencin de errores
en lugar de remocin de los mismos. Este proceso se basa en
- Desarrollo incremental
- Especificacin formal
- Verificacin esttica
- Pruebas estadsticas para determinar la confiabilidad del programa
El resultado de la utilizacin del proceso de sala limpia es interesante, contando con baja tasa de errores
descubiertos en sistemas entregados
El proceso es ms costoso que otros
El proceso no es utilizado ampliamente.
No resulta claro cmo emplearlo en un entorno con personal menos preparado o menos motivado
PUNTOS CLAVE
La verificacin y validacin no son lo mismo.
- La verificacin muestra la conformidad con la especificacin;
- La validacin muestra que el programa satisface los requerimientos de los clientes
Los planes de prueba deben ser diseados para guiar el proceso de pruebas
Las tcnicas de verificacin esttica involucran la evaluacin y anlisis del programa en bsqueda de errores.
Las inspecciones son muy efectivas en descubrir errores
El cdigo en las inspecciones es chequeado sistemticamente por un equipo reducido buscando errores en el
software escrito
Las herramientas de anlisis esttico pueden descubrir anomalas que pueden estar indicando errores en el
cdigo
Caso de Prueba (test case): Es una especificacin precisa de una ejecucin de una pieza de software, constituida por:
Un conjunto de valores entradas.
Condiciones de ejecucin.
17
 Resultados esperados desarrollados para un objetivo particular.
Defecto (defect, fault, <<bug>>) ejemplo una definicin de datos incorrecta.
Fallo (failure) La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas
dentro de los requisitos de rendimiento especificados.
Error (error): La diferencia entre un valor calculado, observado o medio y el valor verdadero, especificado o
tericamente correcto.
Depuracin Es el proceso mediante el cual se localizan los errores. Es proceso de localizar, analizar y corregir los
defectos.
Complejidad ciclomtica medicin cuantitativa de la complejidad lgica de un programa.
No se puede probar la calidad, si no est ah antes de comenzar las pruebas, no lo estar cuando termine
Tcnicas de pruebas de software
Diseo de casos de prueba
Cualquier SW puede probarse de una de estas dos formas:
Conociendo la funcin especfica para la que fue diseado el producto (Pruebas de caja negra)
Conociendo el funcionamiento del producto (Pruebas de caja blanca)
Aspectos del diseo de casos de pruebas
Cada caso de prueba debe definir el resultado de salida esperado
El programador debe evitar probar sus propios programas
Se debe inspeccionar a conciencia el resultado de cada prueba
Se deben incluir tanto datos de entrada vlidos y esperados como no vlidos e inesperados.
Las pruebas deben centrarse en dos objetivos:
o Probar si el software no hace lo que debe hacer.
o Probar si el software hace lo que no debe hacer
La probabilidad de descubrir nuevos defectos en una parte del
software es proporcional al nmero de defectos ya descubierto.
Las pruebas son una tarea tanto o ms creativa que el desarrollo de
software.
Estrategia de pruebas
Modelo general para el proceso de pruebas
Aspectos estratgicos
Especificar los requisitos del producto de
manera cuantificable mucho antes de que
comiencen las pruebas.
Establecer los objetivos de la prueba de
manera explcita.
Comprender qu usuarios van a manejar el software y desarrollar un perfil para cada categora de usuario.
Usar revisiones tcnicas formales efectivas como filtro antes de la prueba.
Criterios de finalizacin de las pruebas
- Detenerse cuando la calendarizacin y el tiempo disponible consumido as lo determinen.
- Detenerse cuando se ejecutaron todos los casos de prueba y ninguno ha sido exitoso.
Clasificacin de pruebas
Pruebas unitarias (pruebas de mdulo) (centra el proceso en la menor unidad de diseo, componente o mdulo)
Pruebas de integracin (para detectar errores asociados con la interaccin.
Pruebas de funcionamiento (desde el punto de vista del usuario, caja negra)
Pruebas de Sistema (Tienden a validar que el sistema cumple con el objetivo para el que ha sido diseado y
construido en su totalidad)
Pruebas especiales:
Pruebas de volumen (manejo de grandes volmenes de datos)
Pruebas de stress (situaciones de trabajo extremas)
Pruebas de usabilidad (debe revelar errores en el factor humano)
Pruebas de performance (relacionados con el consumo de recursos de SO y comunicaciones)
Pruebas de confiabilidad
Pruebas de interfaces grficas de usuario GUI
18
 Pruebas de arquitectura cliente servidor
Pruebas de la documentacin y facilidades de ayuda (1ra fase, claridad editorial, 2da fase, utiliza la
documentacin junto al uso del prog, caja negra)
Pruebas de sistemas de tiempo-real
Contenido de un plan de pruebas
- Objetivos - Criterio de completitud - Calendarizacin
- Responsables - Estndares y bibliotecas - Herramientas
- Tiempo de computadora y recursos - Configuracin de HW
Mtodos formales
Cualquier tcnica que trate la construccin y/o el anlisis de modelos matemticos que contribuyen a la
automatizacin del desarrollo de sistemas informticos.
En los ltimos aos, la idea de que la formalizacin matemtica del SW es el enfoque ms apropiado para conseguir
mejorar su calidad va adquiriendo cada vez ms fuerza. Son polmicos. Ventajas:
Se comprende mejor el sistema.
La comunicacin con el cliente mejora ya que se dispone de una descripcin clara y no ambigua de los requisitos
del usuario.
El sistema se describe de manera ms precisa.
El sistema se asegura matemticamente que es correcto segn las especificaciones.
Mayor calidad software respecto al cumplimiento de las especificaciones.
Mayor productividad
Problemtica actual de los mtodos formales
- El desarrollo de herramientas que apoyen la aplicacin de mtodos formales es complicado y los programas
resultantes son incmodos para los usuarios.
- Los investigadores por lo general no conocen la realidad industrial.
- Es escasa la colaboracin entre la industria y el mundo acadmico, que en ocasiones se muestra demasiado
dogmtico.
- Se considera que la aplicacin de mtodos formales encarece los productos y ralentiza su desarrollo.
Clasificacin de los mtodos formales
Especificaciones basadas en lgica de primer orden y teora de conjuntos
Especificaciones algebraicas
Especificacin de comportamiento:
Mtodos basados en lgebra de procesos (interaccin entre procesos concurrentes)
Mtodos basados en Redes de Petri (basado en autmatas)
Mtodos basados en lgica temporal (sistemas concurrentes)
Utilizacin de mtodos formales en el proceso de V&V:
Puede desarrollarse una especificacin formal del sistema y analizarse matemticamente para buscar
inconsistencias. Es un proceso no muy rentable.
Principios generales de las pruebas
Una parte fundamental de un caso de prueba es la definicin de los resultados esperados.
Los programadores deben evitar probar su propio cdigo.
Una organizacin no deben realizar las pruebas de sus propios productos.
Verificar exhaustivamente los resultados de cada prueba.
Los casos de prueba debern considerar tanto condiciones de entrada validas como invalidas.
Examinar un sistema para verificar que no hace lo que se supone que haga es la mitad de la pelcula, la otra
mitad es ver si el programa hace lo que no debe hacer.
Evite modelar casos de prueba antes de que el sistema se encuentre realmente modelado.
No planifique las pruebas como si no fuera a detectar errores.
La probabilidad de existencia de ms errores en una funcionalidad es directamente proporcional al nmero de
errores ya encontrados en esa misma parte del sistema.
Testear es una actividad extremadamente creativa, desafiante e intelectual.

19