INGENIERA DE SOFTWARE

UNIDAD IV
Anlisis del Proyecto de
Software
Alumno: Daz Lozano Brenda Karina
N-C: 13250883
Prof. Jos Antonio Navarrete Prieto
Grupo T-42

4.1 Modelado, Anlisis y

Documentacin
4.1.1 MODELADO
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
El diseo del software es la primera de las tres actividades 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 secuenciales o
concurrentes
VERIFICACION
Verificacin de los requerimientos.
Verificacin del diseo.
ESTETICA
Simplicidad, Elegancia y Claridad

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

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 comportamiento, el rendimiento, las restricciones y
los criterios de validacin del software.

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 nunca han sido ejecutadas.

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 de su
complejidad.

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 FUNCIO

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 complejidad
del software.

4.4.2 METRICAS ORIENTAS A AL PUNTO DE FUNCIO

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 FUNCIO

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 utilizan para transmitir
informacin a otro sistema.

4.5 IMPLEMENTACION YMANTENIMIENTO DEL

SOFTWARE
La implementacin y mantenimiento de software es una pieza clave
para el buen funcionamiento de un negocio o de una empresa.
Implementacin: 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.5 IMPLEMENTACION 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)
2)
3)
4)

Mantenimiento Correctivo
Mantenimiento Adaptativo
Mantenimiento Perfectivo
Ingeniera Inversa o Reingeniera.