Unidad 4 - LEGP - T42 - 13250492

UNIDAD IVAnlisis del Proyecto de Software

Guzmn Prez Luis Eduardo 13250492

Ingeniera de SoftwareProf. Jos Antonio Navarrete Prieto

Cruz Alcala Mario Hector 13250841

Grupo T-42

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 realFormales: abstraccin, estructura y representacin del conocimiento del problema.De ingeniera: mtodos formales de construccin

4.1 Modelado, Anlisis y DocumentacinTipos 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 requerimientosNotacin 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 empresaMetas y objetivosEstructura organizacionalActividades, procesos y productosRoles y trabajos de agentes

Modelado de requerimientos funcionalesVistas estructurales (de datos)Vistas de comportamientoRequerimientos de tiempo

Modelado de requerimientos no funcionales. De productos, de procesos y externos4.1.1 MODELADODefinicin. 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 datosEl diagrama de flujo de datos (DFD) es el elemento ms representativoSe deben entender los requerimientos necesarios para continuar en la evolucin del sistema.

4.1.2 ANALISISDebilidades

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 usuarios4.1.2 ANALISISConceptos centrales del Anlisis

Transformacin de datosActividades que transforman los datos

Flujo de datosIndica el paso de datos de la entrada del mismo hacia la salidaRepresenta grupos de datos o elementos de datos

Almacenamiento de datosLugar donde se deja informacin para su uso posterior Los almacenes de datos son pasivos, no transforman los datos

4.1.2 ANALISISEl 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 SOFTWARECONCEPTOS FUNDAMENTALES DEL DISEOAbstraccin. 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 SOFTWAREMODULARIDADCaractersticas 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.

CONCURRENCIALos sistemas de programacin pueden ser categorizados como secuenciales o concurrentes

VERIFICACIONVerificacin de los requerimientos.Verificacin del diseo.

ESTETICASimplicidad, Elegancia y Claridad4.1.3 DISEO EN LAINGENIERA DEL SOFTWAREB) 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 SOFTWAREC) 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.1.3 DISEO EN LAINGENIERA DEL SOFTWAREEl 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 CONSTRUCCION, CODIFICACION, PRUEBAS Y EVALUACION, MANUAL DEL USUARIO Y MANUAL TECNICOLa 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:

Descomposicin en niveles elementales.Aislamiento de los aspectos de diseo que no sean totalmente interdependientes.Proposicin al mximo de las decisiones que conciernen a los detalles de representacin.Demostracin cuidadosa de que en cada paso sucesivo, el refinamiento es solo una expresin fiel de los pasos anteriores.

4.2.1 CONSTRUCCION DEL SOFTWARE POR PASOSDijkstra 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.2 CODIFICACION MEDIANTE LOS NIVELES DE ABSTRACCINEl proceso de software incluye verificacin y validacin. Este proceso tiene tres etapas bien definidas:

Pruebas de desarrollo e ingeniera Pruebas de aseguramiento de calidad internas 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.3 PRUEBA DEL 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 SOFTWAREPrueba 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 funcionales.Pruebas de desempeoPruebas de tensinPruebas estructurales

4.2.4 EVALUACION DEL PROYECTO DE SOFTWAREMEDIDA: 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 INDICADORESMedidas 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 INDICADORESLos 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 INDICADORESModelo 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:

Construccin de prototipos. Diseo inicial.ReutilizacinPost-Arquitectura

4.3 MEDIDA, METRICAS E INDICADORES Medidas de Tamao

Long. del Cdigo / Tokens / Long. de especificacin y diseo.

Medidas de Funcionalidad

Medidas de Estructura Lgica:de Estructura de Cdigo de Estructura de Diseo

Acoplamiento / Cohesin / Flujo de Informacin Modular

4.4 TIPOS DE METRICAS. METRICAS DE PROCESO, METRICAS DE PROYECTO, METRICAS ORIENTAS A AL PUNTO DE FUNCION. 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.1 METRICAS EN EL PROCESO Y METRICAS DEL PROYECTOLa 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 FUNCIONLa 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 FUNCIONSe 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 FUNCIONNmero 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.4.2 METRICAS ORIENTAS A AL PUNTO DE FUNCIONLa 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:

El mantenimiento del software puede llevar hasta el 70% de todo el esfuerzo gastado por una organizacin de desarrollo. El mantenimiento es mas que una Correccin de errores

Las 4 actividades que se llevan a cabo para describir el mantenimiento de software:

Mantenimiento CorrectivoMantenimiento AdaptativoMantenimiento PerfectivoIngeniera Inversa o Reingeniera.4.5IMPLEMENTACION YMANTENIMIENTO DEL SOFTWARE