El proceso de aplicar distintas tcnicas y principios con el propsito de definir un producto con los suficientes detalles como para

permitir su realizacin fsica. Con el diseo se pretende construir un sistema que: Satisfaga determinada especificacin del sistema Se ajuste a las limitaciones impuestas por el medio de destino Respete requisitos sobre forma, rendimiento utilizacin de recursos, coste, etc. El diseo es la primera etapa tcnica del proceso de Ingeniera del Software, consiste en producir un modelo o representacin tcnica del software que se va a desarrollar El diseo es el proceso sobre el que se asienta la calidad del software El diseo de software es un proceso iterativo a travs del cual se traducen los requisitos en una representacin del software El diseo se representa a un alto nivel de abstraccin, un nivel que se puede seguir hasta requisitos especficos de datos, funcionales y de comportamiento.

ANALISIS DISO CONSTRUCCIN

PRUEBA
PUESTA EN MARCHA Y EXPLOTACIN

MANTENCIN

Diseo de datos: Modelo de informacin a estructuras de datos Diseo arquitectnico: Define las relaciones entre los elementos estructurales de nuestro programa Diseo procedimental: Se transforman los elementos estructurales de nuestro programa en una descripcin procedimental del software Diseo de interfaz: Describe cmo se comunica el software consigo mismo y con su entorno.

El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y debe acomodar todos los requisitos implcitos que desee el cliente El diseo debe ser una gua que puedan leer y entender los que construyan el cdigo y los que prueban y mantienen el software El diseo debera proporcionar una completa idea de lo que es el software, enfocando los dominios de datos, funcional y de comportamiento desde la perspectiva de la implementacin.

Como paradigma es una filosofa de la que surge una cultura nueva que incorpora tcnicas y metodologas diferentes En ella el universo computacional est poblado por objetos, cada uno responsable de si mismo, y comunicndose con los dems por medio de mensajes. Cada objeto representa una instancia de alguna clase, y estas clases son miembros de una jerarqua de clases unidas va 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 abstraccin, la esencia de un objeto.

Abstraccin Descripcin simplificada del sistema que resalta unos detalles y suprime otros Encapsulacin Ocultar detalles de un objeto que no contribuyen a sus caractersticas esenciales Modularidad Propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos coherentes e independientes Jerarqua o herencia Abstracciones organizadas por niveles.

Estructurada

Orientada a Objetos

Modular

Orientada a Aspectos

Orientada a Componentes

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 estimacin de estos costos ha preocupado a analistas de sistema, gerentes de proyecto e ingenieros de software durante dcadas. El primer obstculo es clarificar el alcance del proyecto. Qu debera 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 descripcin de los mismos. Esta informacin hace ms fcil alcanzar un acuerdo sobre el tamao del sistema al comienzo del proyecto. El mtodo de puntos en casos de uso, que esbozaremos a continuacin, es un mtodo de estimacin prometedor que se adapta bien al enfoque de caso de uso para la descripcin de los requisitos. En sus bases yace el concepto de transaccin de caso de uso, la unidad ms pequea de medicin. Lamentablemente, hay muchas suposiciones disidentes sobre el concepto. En este artculo examinaremos algunas de estas visiones y cmo funcionan en la prctica. Comenzaremos con un bosquejo del mtodo de puntos de caso de uso, seguido de una discusin sobre cul es la definicin de transaccin de caso de uso que mejor funciona. Tambin mostraremos cmo estn relacionadas con otros conceptos en torno a los casos de uso. Concluiremos con una discusin sobre cmo contar estas transacciones (y cmo no hacerlo).

Figura 1: Conceptos principales del mtodo de puntos en casos de uso. El peso de un caso de uso est dado por el nmero de transacciones de casos de uso diferentes en la interaccin entre el actor y el sistema que se ha de crear. Segn el mtodo 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 ms de 7 transacciones, peso = 15 Por consiguiente, las suposiciones sobre la naturaleza de una transaccin y la estrategia usada para contar las transacciones influyen notoriamente sobre la estimacin.