UNIDAD IV

Anlisis del Proyecto de Software

Guzmn Prez Luis Eduardo 13250492
Ingeniera de Software
Prof. Jos Antonio Navarrete Prieto
Cruz Alcala Mario Hector 13250841
Grupo T-42

4.1 Modelado, Anlisis y

4.1.1 MODELADO
Documentacin
El modelado es una actividad que define los aspectos del mundo
fsico y social que nos rodea su propsito es entender y
comunicar, esto nos permite combinar problemas:

Empricos: especificaciones ligadas al mundo real

Formales: abstraccin, estructura y representacin
conocimiento del problema.
De ingeniera: mtodos formales de construccin

del

4.1.1 MODELADO
Tipos de modelado.
Se puede elegir entre una variedad de esquemas conceptuales:

Lenguaje natural. Muy expresivo y flexible, Pobre al intentar

captar la semntica del modelo, mejor para la toma de
requerimientos
Notacin semi-formal. Captura estructura y alguna
semntica, puede llevar a cabo algn razonamiento, chequeo
de consistencia y animacin.
Notacin formal. Semntica muy precisa y son muy
complejos.

4.1.1 MODELADO
Tcnicas de modelado:
Modelado de empresa
Metas y objetivos
Estructura organizacional
Actividades, procesos y productos
Roles y trabajos de agentes
Modelado de requerimientos funcionales
Vistas estructurales (de datos)
Vistas de comportamiento
Requerimientos de tiempo
Modelado de requerimientos no funcionales.
De productos, de procesos y externos

4.1.2 ANALISIS
Definicin. Proveer un marco de trabajo para modelar de forma
detallada el sistema como parte de la obtencin y anlisis de
requerimientos:
Aproximacin al modelo conceptual orientada en los datos
El diagrama de flujo de datos (DFD) es el elemento ms
representativo
Se deben entender los requerimientos necesarios para
continuar en la evolucin del sistema.

4.1.2 ANALISIS
Debilidades
No provee mtodos efectivos para tratar con requerimientos
no funcionales
No ayuda al usuario a decidir el mejor mtodo para cada
caso
Produce demasiada documentacin
Modelos muy detallados que son de difcil comprensin por
parte de los usuarios

4.1.2 ANALISIS
Conceptos centrales del Anlisis
Transformacin de datos
Actividades que transforman los datos
Flujo de datos
Indica el paso de datos de la entrada del mismo hacia la
salida
Representa grupos de datos o elementos de datos
Almacenamiento de datos
Lugar donde se deja informacin para su uso posterior
Los almacenes de datos son pasivos, no transforman los
datos

4.1.3 DISEO EN
LAINGENIERA DEL
SOFTWARE
del software es la primera de las tres actividades

El diseo
tcnicas: diseo, codificacin y prueba: necesarias para
construir y verificar el software. Cada actividad transforma la
informacin de manera que se obtenga finalmente un software
valido.
La importancia del diseo del software se puede decir con una
sola palabra: calidad.
El diseo externo de software requiere de concebir, planear y
especificar
sus
caractersticas
de
un
producto
de
programacin.

4.1.3 DISEO EN LAINGENIERA DEL SOFTWARE

A) CONCEPTOS FUNDAMENTALES DEL DISEO
Abstraccin. Cuando consideramos una solucin modular
para cualquier problema, se puede plantear muchos
NIVELES DE ABSTRACCIN.
Al NIVEL SUPERIOR DE ABSTRACCIN
NIVELES MAS BAJOS,
NIVEL INFERIOR DE ABSTRACCIN
Refinamiento El refinamiento ayuda al diseador a revelar
detalles de bajo nivel a medida que progresa el diseo.
Ambos conceptos ayudan al diseador a crear un modelo de
diseo completo a medida que evoluciona el diseo.

4.1.3 DISEO EN LAINGENIERA DEL SOFTWARE

MODULARIDAD
Caractersticas de los mdulos:
Tienen capacidad de descomponerse.
Contienen instrucciones, lgica de proceso y estructuras de datos.
Pueden ser compilados aparte y almacenados en una biblioteca.
Pueden quedar incluidos dentro de un programa.
CONCURRENCIA
Los sistemas de programacin pueden ser categorizados como
concurrentes
VERIFICACION
Verificacin de los requerimientos.
Verificacin del diseo.
ESTETICA
Simplicidad, Elegancia y Claridad

secuenciales o

4.1.3 DISEO EN LAINGENIERA DEL SOFTWARE

B) EL PROCESO DEL DISEO
El diseo del software es un proceso mediante el que se traducen los
requisitos en una representacin del software. Desde el punto de vista de
gestin del proyecto, el diseo del software se realiza en tres pasos:

EL DISEO PRELIMINAR: se centra en la transformacin de los

requisitos en los datos y la arquitectura del software.
EL DISEO DETALLADO: se ocupa del refinamiento de la
representacin arquitectnica que lleva a una estructura de datos
detallada y las representaciones algortmicas del software.

DISEO DE LA INTERFAZ: establece la disposicin y los

mecanismos para la interaccin hombre-mquina.

4.1.3 DISEO EN LAINGENIERA DEL SOFTWARE

C) DOCUMENTACIN DEL DISEO.
El esquema de documentacin presenta una descripcin completa del diseo
del software y esta formada por varias secciones:
mbito.

Documentos de referencia.

Descripcin del diseo.

Mdulos, para cada mdulo.

Estructura de archivos y datos globales.

Referencias cruzadas para los requisitos.

Provisiones de prueba.

Empaquetamiento.

Notas especiales.

Apndices.

4.2 CONSTRUCCION, CODIFICACION,

PRUEBAS Y EVALUACION, MANUAL
DEL USUARIO Y MANUAL TECNICO
El desarrollo de una visin conceptual de un
sistema
de
programacin
incluye
la
determinacin del tipo de sistema a
desarrollar. Este puede ser un sistema de
base de datos, un sistema de graficas, un
sistema de telecomunicaciones, un sistema
de control de proceso o bien un sistema de
procesamiento de datos; igualmente, el
sistema puede combinar aspectos de

4.2.1 CONSTRUCCION DEL

SOFTWARE POR PASOS
La construccin del software por pasos es una tcnica para descomposicin
del software mediante sus especificaciones de alto nivel hasta sus niveles ms
elementales; esta tcnica tambin se denomina desarrollo a pasos de un
programa y refinamiento sucesivo. Inicialmente propuesta por Wirth, esta
tcnica requiere de las siguientes actividades:
a) Descomposicin en niveles elementales.
b) Aislamiento de los aspectos de diseo que no sean totalmente
interdependientes.
c) Proposicin al mximo de las decisiones que conciernen a los detalles
de representacin.
d) Demostracin cuidadosa de que en cada paso sucesivo, el refinamiento
es solo una expresin fiel de los pasos anteriores.

4.2.2 CODIFICACION MEDIANTE LOS NIVELES DE

ABSTRACCIN
Dijkstra describi por primera vez los niveles de abstraccin como una tcnica
de diseo hacia arriba, en la cual un sistema operativo se diseo como una
divisin de niveles jerrquicos, comenzando en el nivel 0.
Herramientas (CASE). Son un conjunto de mtodos, utilidades y tcnicas que
facilitan la automatizacin del ciclo de vida del desarrollo de sistemas de
informacin, completamente o en alguna de sus fases.
Tipos de Case. No existe una nica clasificacin de herramientas CASE y, en
ocasiones, es difcil incluirlas en una clase determinada. Podran clasificarse
atendiendo a:

Las plataformas que soportan.

Las fases del ciclo de vida del desarrollo de sistemas que cubren.
La arquitectura de las aplicaciones que producen.
Su funcionalidad.

4.2.3 PRUEBA DEL SOFTWARE

El proceso de software incluye verificacin y validacin. Este proceso tiene
tres etapas bien definidas:
1) Pruebas de desarrollo e ingeniera
2) Pruebas de aseguramiento de calidad internas
3) Pruebas con usuarios
Organizacin para la prueba de software. En cualquier proyecto de
software existe un conflicto de intereses inherente que aparece cuando
comienza la prueba. Se pide a la gente que ha construido el software que lo
pruebe.
Estrategia de prueba del software. El proceso de la ingeniera del
software se puede ver como una espiral. Inicialmente la ingeniera del
sistema define el papel del software y conduce al anlisis de los requisitos del
software donde se establece el campo de informacin la funcin el

4.2.4 EVALUACION DEL PROYECTO DE SOFTWARE

Prueba de Caja Negra. Los datos de prueba se escogern

atendiendo a las especificaciones del problema, sin importar
los detalles internos del programa, a fin de verificar que el
programa corra bien. Con este tipo de pruebas se intenta
encontrar:
Funciones incorrectas o ausentes.
Errores de interfaz.
Errores en estructuras de datos o en accesos a la bases
de datos externas
Errores de rendimiento.

Prueba de la Caja de Cristal. Principia con la observacin

de que un programa difcilmente puede considerarse como
probado por completo si su cdigo contiene partes que

4.2.4 EVALUACION DEL PROYECTO DE SOFTWARE

Prueba de la Caja de Pandora. Consiste en abstenerse
de realizar pruebas de depurar bastante bien un proyecto;
se deja al cliente que lo ensaye y acepte. El resultado es
una bomba de tiempo.
Otros tipos de pruebas.- Hay cuatro tipos de pruebas que un
producto de programacin debe satisfacer:

Pruebas
Pruebas
Pruebas
Pruebas

funcionales.
de desempeo
de tensin
estructurales

4.3 MEDIDA, METRICAS E INDICADORES

MEDIDA:
Una
medida
proporciona
una
indicacin
cuantitativa de la extensin, cantidad, dimensiones, capacidad
o tamao de algunos atributos de un proceso o producto.
Hay cuatro razones para medir:
Caracterizar.
Evaluar.
Predecir.
Mejorar.

MTRICA: Una mtrica es una medida cuantitativa del

grado en que un sistema, componente o proceso posee un
atributo dado. Las mtricas son el fundamento de los
indicadores.

4.3 MEDIDA, METRICAS E INDICADORES

INDICADORES: Un indicador es una mtrica o combinacin

de mtricas que proporcionan una visin profunda el proceso
del software, del proyecto de software o del producto en si.
Los indicadores del proceso permiten, Al gestor, evaluar lo que
funciona y lo que no.
Nuestros objetivos son establecer:
Mtricas del proyecto = indicadores del proyecto.
Mtricas del proceso = indicadores del proceso.
Los indicadores del proyecto permiten al gestor:
Evaluar el estado del proyecto en curso.
Seguir la pista de riesgos potenciales.

4.3 MEDIDA, METRICAS E INDICADORES

Medidas relacionadas con el tamao del cdigo (
LOC - Lines of code). Esta forma de medir el tamao
de un software era utilizado cuando los lenguajes de
programacin, patrones de desarrollo y entornos de
desarrollo (IDE), no estaban ampliamente
desarrollados.
Medidas relacionadas con la funcin (UFC
Puntos de Funcin). El total de puntos de funcin no
es una caracterstica simple sino que es una
combinacin de caractersticas del software a las
cuales se les asigna un valor que cambia dependiendo

4.3 MEDIDA, METRICAS E INDICADORES

Los Puntos de Objeto (PO). Los PO se utilizan en el modelo
de estimacin Cocomo II con el nombre de Puntos de
Aplicacin. Estos son una alternativa a los UFC, y son usados
en los lenguajes orientados a objetos y de scripts. Dan valor a
cada pantalla dependiendo de su complejidad: simples = 1,
medianamente complejas = 2, muy complejas = 3. Los
reportes van de 2 a 8 dependiendo del nivel de complejidad, y
los mdulos en lenguaje imperativo como Java o C++ se
contabilizan como 10. Esto puede ser relacionado
directamente a las historias de usuario de algunas
metodologas agiles con lo cual facilita la estimacin de la
iteracin.

4.3 MEDIDA, METRICAS E INDICADORES

Modelo Constructivo de Costo: COCOMO II
Uno de los modelos de estimacin ms usados es COCOMO (Modelo
Constructivista de Costos) creado por el Dr. Barry Boehm. Cocomo II provee
niveles que nos permiten hacer estimaciones en diferentes momentos del
desarrollo ya que la estimacin de costos debe de ser un proceso dinmico a
lo largo del desarrollo, actualizando constantemente las variables, la
evolucin del equipo de desarrollo, las herramientas y lenguajes
involucrados. Los distintos niveles son:
1)
2)
3)
4)

Construccin de prototipos.
Diseo inicial.
Reutilizacin
Post-Arquitectura

4.4 TIPOS DE METRICAS. METRICAS DE PROCESO,

METRICAS DE PROYECTO, METRICAS ORIENTAS A AL
PUNTO DE FUNCION.
1) Medidas de Tamao
2) Long. del Cdigo / Tokens / Long. de especificacin y
diseo.
3) Medidas de Funcionalidad
4) Medidas de Estructura Lgica:
de Estructura de Cdigo
de Estructura de Diseo
5) Acoplamiento / Cohesin / Flujo de Informacin Modular

4.4.1 METRICAS EN EL
PROCESO Y METRICAS DEL
PROYECTO
Qu es? El proceso
del software y las mtricas del producto
son una medida cuantitativa que permite a la gente del
software tener una visin profunda de la eficacia del proceso
del software y de los proyectos que dirigen utilizando el
proceso como un marco de trabajo.

Quin lo hace? Las mtricas del software son analizadas y

evaluadas por los administradores del software. A menudo las
medidas son reunidas por los ingenieros del software.

4.4.1 METRICAS EN EL PROCESO Y

METRICAS DEL PROYECTO

Por qu es importante? Si no mides, slo podrs juzgar basndote en

una evaluacin subjetiva. Mediante la medicin, se pueden sealar las
tendencias (buenas o malas), realizar mejores estimaciones, llevar a cabo
una verdadera mejora sobre el tiempo.

Cules son los pasos? Comenzar definiendo un conjunto limitado de

medidas de procesos, proyectos y productos que sean fciles de recoger.

Cul es el producto obtenido? Es un conjunto de mtricas del software

que proporcionan una visin profunda del proceso y de la comprensin del
proyecto.

Cmo puedo estar seguro de que lo he hecho correctamente?

Aplicando un plan de medicin sencillo pero consistente.

4.4.2 METRICAS ORIENTAS A AL PUNTO DE FUNCION

La medida de punto de funcin se dise originalmente para
aplicarse a aplicaciones de sistemas de informacin de gestin.
Para acomodar estas aplicaciones, se enfatiz la dimensin de
datos (los valores de dominios de informacin) para la exclusin
de dimensiones (control) funcionales y de comportamiento.
Las mtricas orientadas a la funcin fueron propuestas por
primera vez por Allan Albretch.
Una extensin del punto de funcin es la llamada puntos de
caractersticas; es una ampliacin de la medida del punto de
funcin que se puede aplicar a sistemas y aplicaciones de
ingeniera del software.

4.4.2 METRICAS ORIENTAS A AL PUNTO DE FUNCION

La medida de punto de caracterstica acomoda a
aplicaciones en donde la complejidad del
algoritmo es alta. Las aplicaciones de software de
tiempo real, de control de procesos, y
empotradas tienden a tener alta complejidad de
algoritmos y por lo tanto son adecuadas para el
punto de caracterstica. Los puntos de funcin se
derivan con una relacin emprica segn las
medidas contables (directas) del dominio de
informacin del software y las evaluaciones de la

4.4.2 METRICAS ORIENTAS A AL PUNTO DE FUNCION

Se determinan cinco caractersticas de dominios de
informacin y se proporcionan las cuentas en la posicin
apropiada de la tabla. Los valores de los dominios de
informacin se definen de la forma siguiente
Nmero de entradas de usuario. Se cuenta cada
entrada de usuario que proporciona diferentes datos
orientados a la aplicacin.

Nmero de salidas de usuario. Se cuenta cada

salida que proporciona al usuario informacin
orientada a la aplicacin.

4.4.2 METRICAS ORIENTAS A AL PUNTO DE FUNCION

Nmero de peticiones de usuario. Una peticin
se define como una entrada interactiva que produce
la generacin de alguna respuesta del software
inmediata en forma de salida interactiva. Se cuenta
cada peticin por separado.
Nmero de archivos. Se cuenta cada archivo
maestro lgico (esto es, un grupo lgico de datos
que puede ser una parte de una gran base de datos
o un archivo independiente).

Nmero de interfaces externas. Se cuentan

todas las interfaces legibles por la mquina (por
ejemplo: archivos de datos de cinta o disco) que se

4.5IMPLEMENTACION
YMANTENIMIENTO DEL SOFTWARE
La implementacin y mantenimiento de software es una pieza clave
para el buen funcionamiento de un negocio o de una empresa.
Implementacion: Es un paso importante en el desarrollo del
Software porque es la parte donde el sistema se integra a su
empresa, mejorando la eficacia de los procesos, reduciendo el
margen de riesgo de error e incrementando la capacidad del
negocio.
Mantenimiento: Es un aspecto necesario para toda
maquinaria que requiere de un cuidado y revisin peridica
no slo para su correcto funcionamiento sino para ir
adaptando al sistema, los cambios y requerimientos que se
puedan ir presentando durante la marcha.

4.5IMPLEMENTACION YMANTENIMIENTO DEL SOFTWARE

Dos caractersticas principales del mantenimiento de Software:
a)

El mantenimiento del software puede llevar hasta el 70%

de todo el esfuerzo gastado por una organizacin de
desarrollo.
b) El mantenimiento es mas que una Correccin de errores
Las 4 actividades que se llevan a cabo para describir el
mantenimiento de software:
1) Mantenimiento Correctivo
2) Mantenimiento Adaptativo
3) Mantenimiento Perfectivo