Análisis del Proyecto de Software

Análisis del Proyecto
de Software
Unidad 4
1Ramirez Salazar Maricela T42

4.1 MODELADO, ANALISIS,
DISEÑO Y DOCUMENTACION
2

4.1.1 MODELADO
 El modelado es una actividad de definición formal de aspectos del mundo
físico y social que nos rodea con el propósito de entender y comunicar, para lo
cual es una actividad de modelado que permite combinar problemas:
 Empíricos: especificaciones ligadas al mundo real
 Formales: abstracción, estructura y representación del conocimiento del
problema.
 De ingeniería: métodos formales de construcción
3

Tipos de Modelado
 Se puede elegir entre una variedad de esquemas
1. Lenguaje natural. Muy expresivo y flexible, Pobre al intentar
captar la semántica del modelo, mejor para la toma de
requerimientos
2. Notación semi formal. Captura estructura y alguna semántica,
puede llevar a cabo algún razonamiento, chequeo de
consistencia y animación.
3. Notación formal. Semántica muy precisa y son muy complejos.
4

Técnicas de Modelado
a) Modelado de empresa
o Metas y objetivos
o Estructura organizacional
o Actividades, procesos y productos
o Roles y trabajos de agentes
a) Modelo de requerimientos funcionales
o Vistas estructurales (de datos)
o Vistas de comportamiento
o Requerimientos de tiempo
a) Modelo de requerimientos no funcionales
o De productos, de procesos y externos
5

4.1.2 ANALISIS
 Proveer un marco de trabajo para modelar de forma detallada el sistema
como parte de la obtención y análisis de requerimientos:
 Aproximación al modelo conceptual orientada en los datos
 El diagrama de flujo de datos (DFD) es el elemento mas representativo
 Se deben entender los requerimientos necesarios para continuar en la
evolución del sistema
DEBILIDADES
 No provee métodos efectivos para tratar con requerimientos no
funcionales
 No ayuda al usuario a decidir el mejor matoso para cada caso
 Produce demasiada documentación
6

 Conceptos centrales del análisis
1. TRANSFORMACIÓN DE DATOS
 Actividades que transforman los datos
2. FLUJO DE DATOS
 Indica el paso de datos de la entrada del mismo hacia la salida
 Representa grupos de datos o elementos de datos
3. ALMACENAMIENTO DE DATOS
 Lugar donde se deja información para su uso posterior
 Los almacenes de datos son pasivos, no transforman los datos
7

4.1.3 DISEÑO EN LA INGENIERIA DEL
SOFTWARE
 El diseño del software se sitúa en el núcleo técnico del proceso de
ingeniería del software y se aplica independientemente del paradigma
del desarrollo utilizado. El diseño del software es la primera de las
tres actividades técnicas: diseño, codificación y prueba: necesarias
para construir y verificar el software.
 La importancia del diseño del software se puede decir con una sola
palabra: calidad.
 El diseño externo de software requiere de concebir, planear y
especificar sus características de un producto de programación.
8

I. CONCEPTOS FUNDAMENTALES DEL
DISEÑO
 ABSTRACCIÓN:
Cuando consideramos una solución modular para cualquier problema, se puede
plantear muchos NIVELES DE ABSTRACCIÓN. Al NIVEL SUPERIOR DE ABSTRACCIÓN
se establece una solución en términos amplios usando el lenguaje del entorno
del problema. A NIVELES MAS BAJOS, se conjuga la terminología orientada al
problema con la terminología orientada a la implementación es un esfuerzo
para plantear una solución. A medida que nos movemos a través del proceso del
diseño, se reduce el nivel de abstracción. Finalmente, al NIVEL INFERIOR DE
ABSTRACCIÓN la solución se establece de manera que pueda implementarse
directamente, se construye el código.
9

 REFINAMIENTO.
El refinamiento paso a paso (Stepwise) es una estrategia de diseño
descendente. En cada paso (del refinamiento), se descomponen una o
varias instrucciones del programa en cuestión en instrucciones mas
detalladas. Esta descomposición sucesiva o refinamiento de
especificaciones termina cuando todas las instrucciones se expresan en
términos de cualquier lenguaje subyacente de programación.
 MODULARIDAD.
Es el atributo del software que permite a un programa se manejable
intelectualmente. Se divide el software en componentes identificables y
tratables por separado, denominados módulos, que están integrados para
satisfacer los requisitos del programa, con el fin de imponer un
ordenamiento jerárquico en el uso de las funciones. Puede ser utilizada
para aislar a las dependencias funcionales; para mejorar el desempeño
de un producto o para facilitar la depuración, las pruebas, la integración,
el ajuste y la modificación de un sistema.
10

 Concurrencia.
Los sistemas de programación pueden ser categorizados como secuenciales o
concurrentes. En un sistema secuencial solo una porción del sistema se
encuentra activa en un momento dado; los sistemas concurrentes tienen
procesos independientes que pueden ser actividades en forma simultanea, si
existen procesadores múltiples.
 Verificación.
Un diseño es verificable si puede demostrarse que el diseño general del producto
que satisface los requerimientos del cliente.
 Estética.
Tanto en las artes como en las ingenierías las condiciones estéticas son
fundamentales para el diseño; así como la simplicidad, elegancia y claridad de
un propósito distingue de un producto de alta calidad de los mediocres. Se
refiere aquellas propiedades que van mas allá de la satisfacción de los
requerimientos. 11

II. PROCESO DEL DISEÑO
 Es un proceso mediante el que se traducen los requisitos en una
representación del software. Desde el punto de vista de gestión del proyecto,
el diseño del software se realiza en tres pasos:
 DISEÑO PRELIMINAR:
Se centra en la transformación de los requisitos en los datos y la arquitectura del
software
 DISEÑO DETALLADO:
Se ocupa del refinamiento de la representación arquitectónica que lleva a una
estructura de datos detallada y las representaciones algorítmicas del software
 DISEÑO DE LA INTERFAZ:
Establece la disposición y los mecanismos para la interacción hombre-maquina
12

III. DOCUMENTACION DEL DISEÑO
 Es el esquema de documentación presenta una descripción completa del diseño del
software y esta formada por varias secciones:
a) Ámbito.
b) Documentos de referencia.
c) Descripción del diseño.
d) Módulos, para cada módulo.
e) Estructura de archivos y datos globales.
f) Referencias cruzadas para los requisitos.
g) Provisiones de prueba.
h) Empaquetamiento.
i) Notas especiales.
j) Apéndices. 13

4.2 CONSTRUCCION,
CODIFICACION, PRUEBAS Y
EVALUACION, MANUAL DEL
USUARIO Y MANUAL TECNICO
14

 El desarrollo de una visión conceptual de un sistema de
programación incluye la determinación 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. En cada una de estas aplicaciones
existen diversos puntos de vista, así como terminologías,
herramientas y notaciones adecuadas para esa clase de
aplicaciones; resulta esencial que el grupo
15

4.2.1 CONSTRUCCION DEL SOFTWARE POR PASOS
 La construcción del software por pasos es una técnica para descomposición
del software mediante sus especificaciones de alto nivel hasta sus niveles
más elementales; esta técnica también se denomina “desarrollo a pasos
de un programa” y “refinamiento sucesivo”. Esta técnica requiere las
siguientes actividades
1) Descomposición en niveles elementales.
2) Aislamiento de los aspectos de diseño que no sean totalmente
interdependientes.
3) Proposición al máximo de las decisiones que conciernen a los detalles de
representación.
4) Demostración cuidadosa de que en cada paso sucesivo, el refinamiento es
solo una expresión fiel de los pasos anteriores.
16

4.2.2 CODIFICACION MEDIANTE LOS
NIVELES DE ABSTRACCIÓN
 Auxilia de la ingeniería de software asistida por computadora.
a. Herramientas (CASE). Son un conjunto de métodos, utilidades y
técnicas que facilitan la automatización del ciclo de vida del
desarrollo de sistemas de información.
 La principal ventaja de la utilización de una herramienta CASE, es la
mejora de la calidad de los desarrollos realizados y, en segundo
término, el aumento de la productividad. Para conseguir estos dos
objetivos es conveniente contar con una organización y una
metodología de trabajo además de la propia herramienta.
17

Tipos de CASE
 No existe una única clasificación de herramientas CASE y, en
ocasiones, es difícil incluirlas en una clase determinada. Podrían
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.
18

4.2.3 PRUEBA DEL SOFTWARE
 Un programa no solamente debe estar libre de errores, sino que
es igualmente importante que el rendimiento del programa final
no sea mayor o menor a lo proyectado originalmente. Escribir un
programa que se ejecute como se planeó no es una tarea simple.
 Este proceso tiene tres etapas bien definidas:
1) Pruebas de desarrollo e ingeniería
2) Pruebas de aseguramiento de calidad internas
3) Pruebas con usuarios
19

4.2.4 EVALUACION DEL PROYECTO DE
SOFTWARE
A. Prueba de Caja Negra. Los datos de prueba se escogerán
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.
20

B. Prueba de la Caja de Cristal. Principia con la observación de que
un programa difícilmente puede considerarse como probado por
completo si su código contiene partes que nunca han sido
ejecutadas. Este método analiza la estructura lógica del
programa y, para cada alternativa que puede presentarse, los
datos de prueba ideados conducirán a ella. Se procura escoger los
que verifiquen cada posibilidad en las proposiciones case, las
cláusulas de cada proposición if y la condición de terminación de
cada ciclo.
 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.
21

 Otros tipos de pruebas. Hay cuatro tipos de pruebas que un
producto de programación debe satisfacer:
A. Pruebas funcionales.
B. Pruebas de desempeño
C. Pruebas de tensión
D. Pruebas estructurales
22

4.3 MEDIDA, METRICAS E
INDICADORES
23

A) MEDIDA
 Una medida proporciona una indicación cuantitativa de la extensión, cantidad,
dimensiones, capacidad o tamaño de algunos atributos de un proceso o
producto.
 Hay cuatro razones para medir:
 Caracterizar.
 Evaluar.
 Predecir.
 Mejorar.
24

B) METRICA
 Una métrica es una medida cuantitativa del grado en que un
sistema, componente o proceso posee un atributo dado. Las
métricas son el fundamento de los indicadores.
25

C) INDICADORES
 Un indicador es una métrica o combinación de métricas que proporcionan una
visión 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. Los principales objetivos en un indicador permiten
establecer:
a) Métricas del proyecto = indicadores del proyecto.
b) Métricas del proceso = indicadores del proceso.
 Los indicadores del proyecto permiten al gestor:
a) Evaluar el estado del proyecto en curso.
b) Seguir la pista de riesgos potenciales.
26

 Para facilitar el proceso de estimación se han establecido a lo largo del
tiempo, métricas que ayudan a dar una idea aproximada del tamaño del
software:
 Medidas relacionadas con el tamaño del código ( LOC - Lines of code).
Esta forma de medir el tamaño de un software era utilizado cuando los
lenguajes de programación, patrones de desarrollo y entornos de desarrollo
(IDE), no estaban ampliamente desarrollados.
 Medidas relacionadas con la función (UFC – Puntos de Función). El total
de puntos de función no es una característica simple sino que es una
combinación de características del software a las cuales se les asigna un
valor que cambia dependiendo de su complejidad.
 Los Puntos de Objeto (PO). Los PO se utilizan en el modelo de estimación
COCOMO II con el nombre de Puntos de Aplicación. Estos son una alternativa
a los UFC, y son usados en los lenguajes orientados a objetos y de scripts.
27

 Modelo Constructivo de Costo: COCOMO II.
Cocomo II provee niveles que nos permiten hacer estimaciones en diferentes
momentos del desarrollo ya que la estimación de costos debe de ser un
proceso dinámico a lo largo del desarrollo, actualizando constantemente las
variables, la evolución del equipo de desarrollo, las herramientas y lenguajes
involucrados. Los distintos niveles son:
 Construcción de prototipos. Las estimaciones de tamaño están basadas en
puntos de aplicación con base en componentes reutilizables, prototipos y la
fórmula para estimar el esfuerzo requerido es muy simple: tamaño /
productividad.
 Diseño inicial. Está basado en los requerimientos originales del sistema a un
alto nivel (pantallas, reportes, procesos, transacciones) lo que son traducidos
a puntos de aplicación, esto nos sirve para hacer una predicción temprana
del costo.
28

 Reutilización. Este nivel se utiliza para calcular el esfuerzo requerido
para integrar el código generado por los IDE’s o herramientas de
generación de código reutilizable como Spring Roo o Genexus por ejemplo,
tomando en cuenta componentes reutilizables que facilitan el desarrollo
como Apache Commons.
 Post-arquitectura. Ya diseñado el sistema se pueden hacer estimaciones
más precisas del tamaño del software, aquí es importante señalar que el
software tiene una tasa de crecimiento de los requerimientos del sistema
entre el 2 y el 5 por ciento mensual, por lo cual no es posible hacer una
estimación exacta pero las predicciones de costo se pueden acercar
mucho a la realidad gracias a la aplicación de métricas que nos permiten
tener una variación muy pequeña con respecto al producto final.
29

4.4 TIPOS DE METRICAS. METRICAS DE
PROCESO, METRICAS DE PROYECTO,
METRICAS ORIENTAS A AL PUNTO DE
FUNCION.
30

I. Medidas de Tamaño
II. Long. del Código / Tokens / Long. de especificación y diseño
III. Medidas de Funcionalidad
IV. Medidas de Estructura Lógica:
 De Estructura de Código
 De Estructura de Diseño
V. Acoplamiento / Cohesión / Flujo de Información Modular
31

4.4.1 METRICAS EN EL PROCESO Y
METRICAS DEL PROYECTO
1) ¿Qué es? El proceso del software y las métricas del producto son una
medida cuantitativa que permite a la gente del software tener una visión
profunda de la eficacia del proceso del software y de los proyectos que
dirigen utilizando el proceso como un marco de trabajo.
2) ¿Quién lo hace? Las métricas del software son analizadas y evaluadas por
los administradores del software. A menudo las medidas son reunidas por
los ingenieros del software.
3) ¿Por qué es importante? Si no mides, sólo podrás juzgar basándote en una
evaluación subjetiva. Mediante la medición, se pueden señalar las
tendencias (buenas o malas), realizar mejores estimaciones, llevar a cabo
una verdadera mejora sobre el tiempo.
32

4) ¿Cuáles son los pasos? Comenzar definiendo un conjunto
limitado de medidas de procesos, proyectos y productos que
sean fáciles de recoger.
5) ¿Cuál es el producto obtenido? Es un conjunto de métricas del
software que proporcionan una visión profunda del proceso y de
la comprensión del proyecto.
6) ¿Cómo puedo estar seguro de que lo he hecho correctamente?
Aplicando un plan de medición sencillo pero consistente.
33

4.4.2 METRICAS ORIENTAS A AL PUNTO
DE FUNCION
 La medida de punto de función se diseñó originalmente
para aplicarse a aplicaciones de sistemas de información
de gestión. Para acomodar estas aplicaciones, se enfatizó
la dimensión de datos (los valores de dominios de
información) para la exclusión de dimensiones (control)
funcionales y de comportamiento.
34

 Los valores de los dominios de información se definen de la forma
siguiente:
a) Número de entradas de usuario. Se cuenta cada entrada de usuario
que proporciona diferentes datos orientados a la aplicación. Las
entradas se deberían diferenciar de las peticiones, las cuales se cuentan
de forma separada.
b) Número de salidas de usuario. Se cuenta cada salida que proporciona
al usuario información orientada a la aplicación. En este contexto la
salida se refiere a informes, pantallas, mensajes de error, etc. Los
elementos de datos particulares dentro de un informe no se cuentan de
forma separada.
35

a) Número de peticiones de usuario. Una petición se define como
una entrada interactiva que produce la generación de alguna
respuesta del software inmediata en forma de salida interactiva.
Se cuenta cada petición por separado.
b) Número de archivos. Se cuenta cada archivo maestro lógico
(esto es, un grupo lógico de datos que puede ser una parte de
una gran base de datos o un archivo independiente).
c) Número de interfaces externas. Se cuentan todas las interfaces
legibles por la máquina (por ejemplo: archivos de datos de cinta
o disco) que se utilizan para transmitir información a otro
sistema.
36

 Las métricas orientadas a Puntos de Función se caracterizan por:
A. Tener un componente empírico, basado en la experiencia de
muchos proyectos.
B. Tener en cuenta la complejidad, aunque es muy difícil de
determinar en un proyecto
C. Ser independientes del entorno tecnológico y de las
metodologías aplicadas.
D. Utilizar medidas indirectas, que se caracterizan por ser
subjetivas y difíciles de calcular, sin embargo el resultado
obtenido es fácilmente comparable.
37

4.5 IMPLEMENTACION Y
MANTENIMIENTO DEL SOFTWARE
38

 Diversos productos como software a la medida, sistema bolsa de
trabajo, registro de usuarios, sistema de reservaciones, de gestión,
motor bienes raíces, outsourcing programadores, mapas geográficos,
servidores, aplicación server provider, Visual Studio, on line, AJAX,
SQL server, renta tiendas en línea, administrador de contenidos,
carrito de compras, cotizador, inventarios en línea, optimización y
posicionamiento web de sitios, portales o páginas en la red.
 La importancia de la implementación y mantenimiento de software
radica en brindarle la capacitación necesaria para el correcto manejo
del sistema y por otro lado permite que se cumpla la finalidad de
todo programa de software: dejar que el sistema haga todo el
trabajo pesado, brindándole el tiempo para trabajar sobre otras
áreas de su negocio.
39

 Dos características principales del mantenimiento de Software:
1. El mantenimiento del software puede llevar hasta el 70% de todo el
esfuerzo gastado por una organización de desarrollo.
2. El mantenimiento es mas que una “Corrección 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
4. Ingeniería Inversa o Reingeniería.
40

Análisis del Proyecto de Software

Más contenido relacionado

La actualidad más candente (20)

Similar a Análisis del Proyecto de Software (20)

Último (8)

Análisis del Proyecto de Software