análisis del proyecto de software
TRANSCRIPT
Ramirez Salazar Maricela T42
Análisis del Proyecto de
Software
Unidad 4
1
2
4.1 MODELADO, ANALISIS, DISEÑO Y DOCUMENTACION
3
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
4
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.
5
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
6
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
7
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
8
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.
9
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.
10
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.
11
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.
12
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
13
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.
14
4.2 CONSTRUCCION, CODIFICACION, PRUEBAS Y EVALUACION, MANUAL DEL
USUARIO Y MANUAL TECNICO
15
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
16
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.
17
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.
18
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.
19
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
20
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.
21
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.
22
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
23
4.3 MEDIDA, METRICAS E INDICADORES
24
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.
25
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.
26
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.
27
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.
28
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.
29
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.
30
4.4 TIPOS DE METRICAS. METRICAS DE PROCESO, METRICAS DE PROYECTO, METRICAS ORIENTAS A AL
PUNTO DE FUNCION.
31
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ódigoDe Estructura de Diseño
V. Acoplamiento / Cohesión / Flujo de Información Modular
32
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.
33
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.
34
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.
35
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.
36
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.
37
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.
38
4.5 IMPLEMENTACION Y MANTENIMIENTO DEL
SOFTWARE
39
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.
40
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.