PROYECTO DE SOFTWARE&

ESTIMACION DE COSTO

Camilo López &

Cristian Ocampo

¿QUE ES EL DISEÑO?•El proceso de aplicar distintas técnicas y principios con el propósito de definir un producto con los suficientes detalles como para permitir su realización física.•Con el diseño se pretende construir un sistema que:–Satisfaga determinada especificación del sistema–Se ajuste a las limitaciones impuestas por el medio de destino–Respete requisitos sobre forma, rendimiento utilización de recursos, coste, etc.•El diseño es la primera etapa técnica del proceso de Ingeniería del Software, consiste en producir un modelo o representación técnica del software que se va a desarrollar•El diseño es el proceso sobre el que se asienta la calidad del software•El diseño de software es un proceso iterativo a través del cual se traducen los requisitos en una representación del software•El diseño se representa a un alto nivel de abstracción, un nivel que se puede seguir hasta requisitos específicos de datos, funcionales y de comportamiento.

ANALISIS

DISÉÑO

CONSTRUCCIÓN

PRUEBA

PUESTA EN MARCHA Y EXPLOTACIÓN

MANTENCIÓN

METODOLOGIAS DEL DISEÑO•Diseño de datos:–Modelo de información a estructuras de datos•Diseño arquitectónico:–Define las relaciones entre los elementos estructurales de nuestro programa•Diseño procedimental:–Se transforman los elementos estructurales de nuestro programa en una descripción procedimental del software•Diseño de interfaz:–Describe cómo se comunica el software consigo mismo y con su entorno.

DIRECTRICES PARA UN BUEN DISEÑO

•El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acomodar todos los requisitos implícitos que desee el cliente•El diseño debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el software•El diseño debería proporcionar una completa idea de lo que es el software, enfocando los dominios de datos, funcional y de comportamiento desde la perspectiva de la implementación.

PROGRAMACION ORIENTADA A OBJETOS

•Como paradigma es una filosofía de la que surge una cultura nueva que incorpora técnicas y metodologías diferentes•En ella el universo computacional está poblado por objetos, cada uno responsable de si mismo, y comunicándose con los demás por medio de mensajes. Cada objeto representa una instancia de alguna clase, y estas clases son miembros de una jerarquía de clases unidas vía relaciones de herencia•La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstracción, la esencia de un objeto.

PRINCIPIOS DEL MODELADO ORIENTADO A OBJETOS

•Abstracción–Descripción simplificada del sistema que resalta unos detalles y suprime otros•Encapsulación–Ocultar detalles de un objeto que no contribuyen a sus características esenciales•Modularidad–Propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes•Jerarquía o herencia–Abstracciones organizadas por niveles.

EVOLUCION HISTORICA DE LA PROGRAMACIÓN

Estructurada

Modular

Orientada a Component

es

Orientada a

Aspectos

Orientada a Objetos

ESTIMACIÓN DEL COSTO DEL SOFWARE

Una parte importante de la toma de decisiones al comenzar un nuevo proyecto de desarrollo de software está dada por el costo que éste tendrá. La estimación de estos costos ha preocupado a analistas de sistema, gerentes de proyecto e ingenieros de software durante décadas. El primer obstáculo es clarificar el alcance del proyecto. ¿Qué debería ser capaz de hacer el sistema? La captura de los requisitos funcionales en casos de uso ha ayudado considerablemente a comunicar los requisitos de una forma que sea comprensible a los usuarios y a otros expertos en el campo. Al comienzo del proyecto debe hacerse un modelo de caso de uso que contenga una lista de todos los actores (usuarios o sistemas externos) y casos de uso del sistema, así como sus nombres y una breve descripción de los mismos. Esta información hace más fácil alcanzar un acuerdo sobre el tamaño del sistema al comienzo del proyecto.El método de puntos en casos de uso, que esbozaremos a continuación, es un método de estimación prometedor que se adapta bien al enfoque de caso de uso para la descripción de los requisitos. En sus bases yace el concepto de transacción de caso de uso, la unidad más pequeña de medición. Lamentablemente, hay muchas suposiciones disidentes sobre el concepto.En este artículo examinaremos algunas de estas visiones y cómo funcionan en la práctica. Comenzaremos con un bosquejo del método de puntos de caso de uso, seguido de una discusión sobre cuál es la definición de transacción de caso de uso que mejor funciona. También mostraremos cómo están relacionadas con otros conceptos en torno a los casos de uso. Concluiremos con una discusión sobre cómo contar estas transacciones (y cómo no hacerlo).

Figura 1: Conceptos principales del método de puntos en casos de uso.El peso de un caso de uso está dado por el número de transacciones de casos de uso diferentes en la interacción entre el actor y el sistema que se ha de crear.Según el método de puntos en casos de uso, los criterios para asignar peso a un determinado caso son:Caso de uso simple – de 1 a 3 transacciones, peso = 5 Caso de uso medio – de 4 a 7 transacciones, peso = 10 Caso de uso complejo – más de 7 transacciones, peso = 15Por consiguiente, las suposiciones sobre la naturaleza de una transacción y la estrategia usada para contar las transacciones influyen notoriamente sobre la estimación.

MODELOS DEL DESARROLLO DE UN SOFTWARE

Modelo Cascada

Modelo en Espiral

Modelo General Evolutivo

Modelo Cascada Realimentado

Modelo Interactivo Incremental

Procesos Ingenieros (Requisitos)