INTRODUCCIN Para el xito en el desarrollo del software es fundamental la comprensin de los requisitos necesarios para la construccin del producto

software. Muchas veces es irrelevante lo bien diseado o codificado que pueda estar un programa si es que no cuenta con una etapa de anlisis previa. La tarea del anlisis de requisitos es un proceso de descubrimiento, refinamiento, modelado y especificacin. Se refina en detalle el mbito del software, inicialmente establecida por el ingeniero de sistemas y refinada durante la planificacin temporal del proyecto de software. Se crean modelos de los requisitos de datos, flujo de informacin y control, y del comportamiento operativo. Se analizan soluciones alternativas y se asignan a diferentes elementos del software. 2. ANLISIS DE REQUISITOS Es una tarea de la ingeniera del software que cubre el hueco entre la definicin del software a nivel sistema y el diseo del software. El anlisis de requisitos permite refinar la definicin del software y construir los modelos de los dominios de datos, funcional y de comportamiento a ser considerados en el producto software. El anlisis de requisitos proporciona al diseador del software los siguientes modelos: de datos, arquitectnico, de interfaz y procedimental. La especificacin de requisitos proporciona al diseador y al cliente los medios para valorar la calidad una vez que se ha construido el software. El anlisis de requisitos del software puede dividirse en las siguientes cinco actividades de esfuerzo: Reconocimiento del problema. Reconocer los elementos bsicos del problema, tal y como los percibe el usuario o el cliente. Evaluacin y sntesis. Definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la informacin y elaborar todas las funciones del software. Esta actividad continua hasta que el analista y el cliente se sienten seguros de que se puede especificar adecuadamente el software para las fases posteriores de desarrollo. Modelado. Durante la actividad de evaluacin y sntesis de la solucin, el analista crea modelos del sistema en un esfuerzo de entender mejor el flujo de datos y de control, el tratamiento funcional, el comportamiento operativo y el contenido de la informacin. Especificacin. El modelo sirve como fundamento para el diseo del software y como base para la creacin de una especificacin del software. Revisin. Consiste en llevar adelante la actividad de revisar las especificaciones del software para considerar las mas adecuadas. 3. TCNICAS DE COMUNICACIN El anlisis de requisitos del software siempre comienza con la comunicacin entre dos o mas partes. Normalmente un cliente tiene un problema que pretende sea resuelto con un resultado producido por un programa computacional. Un desarrollador responde a la solicitud de ayuda del cliente. En este paso la comunicacin comienza, pero es comn comprobar que el camino de la comunicacin al entendimiento est a menudo lleno de baches.

3.1 Inicio del proceso La tcnica de anlisis ms utilizada para empezar el proceso de comunicacin es llevar a cabo una reunin o entrevista preliminar. Gause y Weinberg sugieren que el analista comience preguntando cuestiones de contexto libre, enfocados sobre el cliente, los objetivos generales y los beneficios esperados. Por ejemplo se debera preguntar: a. Quin est detrs de la solicitud de este trabajo? b. Quin utilizar la solucin? c. Cul ser el beneficio econmico del xito de una solucin? d. Existe alguna otra alternativa necesaria para la solucin? El segundo conjunto de preguntas permite al analista obtener un entendimiento mejor del problema y al cliente comentar sus opiniones sobre la solucin, estas preguntas son: a. Cmo caracterizara un buen resultado generado por una buena solucin? b. A que tipo de problema o problemas est dirigida la solucin? c. Podra mostrarme el entorno en que se utilizar la solucin? d. Existen aspectos o restricciones especiales de rendimiento que afecten a la manera de enfocar la solucin? El ltimo conjunto de preguntas se concentra en la eficacia de la reunin, estas se denominan meta - preguntas y proponen la siguiente lista: a. Es usted la persona adecuada para responder a estas preguntas? Sus respuestas son oficiales? b. Son adecuadas mis preguntas para el problema que tiene? c. Estoy preguntando demasiado? d. Hay alguien ms que pueda proporcionar informacin adicional? e. Hay algo mas que debera preguntarle? 3.2 Tcnica para facilitar especificaciones de una aplicacin (TFEA) Este enfoque es partidario de la creacin de un equipo de clientes y desarrolladores que trabajan juntos para identificar el problema, proponer soluciones, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solucin.

Se han propuesto muchos enfoques diferentes de TFEA. Cada uno utiliza un escenario ligeramente diferente, pero todos aplican alguna variacin en las siguientes directrices bsicas: a. La reunin se celebra en un lugar neutral y acuden tanto los clientes como los desarrolladores. b. Se establecen normas de preparacin y participacin. c. Se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes pero lo suficientemente informal como para animar el libre flujo de ideas. d. Se elige un coordinador que controle la reunin. e. Se utiliza un mecanismo de definicin (hojas de trabajo, grficos, carteles, pizarra, etc.) f. El objetivo es identificar el problema, proponer elementos de solucin, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solucin. 3.3 Despliegue de la funcin de calidad (DFC) Es una tcnica de gestin de calidad que traduce las necesidades del cliente en requisitos tcnicos del software. DFC se concentra en maximizar la satisfaccin del cliente, haciendo nfasis en entender lo que resulta valioso para el cliente y luego desplegar estos valores a lo largo del proceso de ingeniera. DFC identifica tres tipos de requisitos: a. Requisitos normales. Son requisitos bsicos asociados a objetivos y metas para un producto software, si estos estn presentes el cliente quedar satisfecho. b. Requisitos esperados. Son implcitos al producto y pueden ser tan fundamentales que el cliente no los declara explcitamente. Su ausencia puede ser motivo de una insatisfaccin significativa. c. Requisitos innovadores. Van ms all de las expectativas del cliente y suelen ser muy satisfactorias como valor agregado al producto. 4. PRINCIPIOS DEL ANLISIS Todos los mtodos de anlisis se relacionan a travs del siguiente conjunto de principios operativos: a. La representacin y el entendimiento del dominio de informacin de un problema. Requiere el examen del dominio de la informacin. Este dominio contiene tres visiones diferentes de los datos y del control: (1) contenido de la informacin y relaciones, (2) flujo de la informacin y (3) estructura de la informacin. El contenido es definido por los atributos necesarios para crearlo. El flujo representa como cambian los datos y el control a medida que se mueven dentro de un sistema. La estructura representa la organizacin interna de los elementos de datos o de control.

b. La definicin de funciones que debe realizar el software. Los modelos se crean para entender de mejor manera la entidad que se va construir como solucin aun problema. Para transformar la informacin el software debe realizar al menos tres funciones genricas: entrada, procesamiento y salida. c. La representacin del comportamiento del software. La caracterstica estimulo respuesta forma la base del modelo de comportamiento. Un programa de computadora siempre est en un estado, en un modo de comportamiento observable exteriormente (imprimiendo, calculando, etc.). d. La divisin de los modelos que representan informacin, funcin y comportamiento de manera que se puedan descubrir los detalles por capas, para que las partes puedan entenderse fcilmente y establecer luego las interacciones entre las mismas de manera que se pueda conseguir la funcin global. e. El proceso de anlisis debera ir desde la informacin esencial hasta el detalle de la implementacin. Una visin esencial de los requisitos del software presenta las funciones a conseguir y la informacin a procesar sin tener en cuenta los detalles de la implementacin. La visin de implementacin de los requisitos del software introduce la manifestacin en el mundo real de las funciones de procesamiento y las estructuras de la informacin. 5. CREACIN DE PROTOTIPOS El anlisis normalmente se realiza independientemente del paradigma de ingeniera del software que se aplique. Hay circunstancias que requieren la construccin de un prototipo al principio del anlisis, debido a que el modelo es el nico medio a travs del cual se pueden obtener eficazmente los requisitos. El modelo evoluciona despus hacia la produccin del software. El paradigma para la creacin de prototipos puede ser: a. Enfoque cerrado. Se denomina a menudo prototipo desechable. Sirve nicamente para una basta demostracin de los requisitos, despus se desecha y se hace la ingeniera del software con un paradigma diferente. b. Enfoque abierto. Denominado prototipo evolutivo. Emplea el prototipo como primera parte de una actividad de anlisis a la que seguir el diseo y la construccin 6. ESPECIFICACION El modo de especificacin tiene mucho que ver con la calidad de la solucin. La especificacin puede verse como un proceso de representacin. Los requisitos se representan de manera que como fin ultimo lleven al xito de la implementacin del software. Los siguientes principios de especificacin son adaptados del trabajo de Balzer y Goldman: 1. Separar la funcionalidad de la implementacin.

2. Desarrollar un modelo del comportamiento deseado de un sistema que comprenda datos y las respuestas funcionales de un sistema a varios estmulos del entorno. 3. Establecer el contexto en que opera el software especificando la manera en que otros componentes del sistema interactan con l. 4. Definir el entorno en que operara el sistema. 5. Crear un modelo intuitivo en lugar de un diseo o modelo de implementacin. 6. Reconocer que la especificacin debe ser tolerante a un posible crecimiento. 7. Establecer el contenido y la estructura de una especificacin de manera que acepte cambios. Para representar una especificacin de requisitos debe seguirse el siguiente grupo de directrices. a. El formato de representacin y el contenido deben estar relacionados con el problema. b. La informacin contenida dentro de la especificacin debe estar escalonada. c. La numeracin de prrafos y diagramas debe indicar el nivel de detalle que se muestra. d. Los diagramas y otras formas de notacin deben restringirse en numero y ser consistentes en su empleo. e. La representacin debe permitir revisiones. Finalmente un esquema para la especificacin de los requisitos del software, sealado por Pressman es la siguiente:

CONCEPTOS Y PRINCIPIOS DE ANLISIS La ingeniera de requisitos es el uso sistemtico de procedimientos, tcnicas, lenguajes y herramientas para obtener con un coste reducido el anlisis, documentacin, evolucin continua de las necesidades del usuario y la especificacin del comportamiento externo de un sistema que satisfaga las necesidades del usuario. Tenga en cuenta que todas las disciplinas de la ingeniera son semejantes, la ingeniera de requisitos no se gua por conductas espordicas aleatorias o por modas pasajeras, sino que se debe basar en el uso sistemtico de aproximaciones contrastadas.

ANLISIS DE REQUISITOS

El anlisis de requisitos es una tarea de ingeniera de software que cubre el hueco entre las definiciones del software a nivel sistema y el diseo del software. El anlisis de requisitos permite al ingeniero der sistemas especificar las caractersticas operacionales del software (funcin, datos y rendimientos), indica la interface del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

Puede dividirse en 5 reas de esfuerzo:

Reconocimiento del problema. Evaluacin y sntesis. Modelado. Especificacin. Revisin.

La evaluacin del problema y la sntesis de la solucin es la siguiente rea principal de esfuerzo en el anlisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la informacin, definir y elaborar todas las funciones del software, entender el comportamiento del software en el contexto de acontecimientos que afectan al sistema, establecer las caractersticas de la interfaz del sistema y descubrir restricciones adicionales del diseo.

Cada una de estas tareas sirve para describir el problema de manera que se pueda sintetizar un enfoque o solucin global.

PRINCIPIOS DEL ANLISIS

Todos los mtodos de anlisis se relacionan por un conjunto de principios operativos:

1. Debe representarse y entenderse el dominio de informacin de un problema.

2. Debe definirse las funciones que debe realizar el software.

3. Debe representarse el comportamiento del software.

4. Debe dividirse los modelos que representan informacin, funcin y comportamiento de manera que se descubran los detalles por capas.

5. El proceso de anlisis deriva ir desde la informacin esencial hasta el detalle de la implementacin.

Davis sugiere un conjunto de principios directrices para la Ingeniera de Requisitos:

Entender el problema antes de empezar a crear el modelo del anlisis.

Desarrollar prototipos que permitan al usuario entender cmo ser la interaccin hombre-mquina.

Registrar el origen y la razn de cada requisito.

Usar mltiples planteamientos de requisitos.

o Reduce probabilidad de que se olvide algo. o Aumenta probabilidad de reconocer inconsistencias.

Dar prioridad a los requisitos. Cronogramas.

Trabajar para eliminar la ambigedad.

CREACIN DE PROTOTIPOS DE SOFTWARE

Se construyen un modelo del software a fabricar denominado prototipo para que lo valore el cliente y el desarrollador.

Seleccin del enfoque de creacin de prototipo.

o rea de aplicacin. o Complejidad. o Caractersticas del cliente y del proyecto.

Mtodos y herramientas. Desarrollo del prototipo.

o Tcnicas de cuarta generacin. o Componentes de software reutilizable

Conceptos y principios de diseo Presentation Transcript

1. CONCEPTOS Y PRINCIPIOS DEL DISEOUNIVERSIDAD TCNICA DE MANABINGENIERIA EN SISTEMAS OCTAVO SEMESTRE 2. AUTORAS:NATALY ZAMBRANO MUOZVIRGINIA ZAMBRANO VERACINTHIA CEDEO SOSAEL CARMENMANABIECUADOR 4. El modelo de Anlisis Diagrama EntidadRelacinDiagrama de flujo de DatosDiccionario de DatosDiagrama de transicin de Estado El modelo de Diseo 5. El diseo del software es un proceso iterativo a travs del cual se traducen los requisitos en una representacin del softwareEL PROCESO DE DISEO ES UN CONJUNTO DE PASOS REPETITIVOS QUE

PERMITEN AL DISEADOR DESCRIBIR TODOS LOS ASPECTOS DEL SOFTWARE A CONSTRUIR El Proceso de Diseo

7. PRINCIPIOS DEL DISEO 9. Divide el software en componentes identificables y tratables por separado, denominados mdulosMODULARIDAD 11. Tambin llamada estructura del programa, representa la organizacin de componentes del programa e implica una jerarqua de controlJERARQUA DE CONTROLMABCDEFGHIJKL

CONCEPTOS Y PRINCIPIOS DEL DISEO El diseo es el proceso de aplicar distintas tcnicas y principos con el propsito de definir un dispositivo, un proceso o un sistema con suficientes detalle como para permitir su realizacin fsica.E l o b j e t i v o d e l d i s e a d o r e s p r o d u c i r u n modelo o representacin de una entidad que se va a c o n s t r u i r posteriormente.E l d i s e o d e l s o f t c a m b i a c o n t i n u a m e n t e a medida que evolucionan nuevos mtodos, mejores anlisis y perspectivas ms amplias. 13.1 DISEO E INGENIERIA DEL SOFTWARE El 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 seobtenga finalmente un software vlido.Cada uno de los elementos del modelo de anlisis proporciona informacin necesaria para crear un modelo dediseo. Los requisitos del soft, manifestados por los datos y los modelos funcional y de comportamiento, componen la fase de diseo. Mediante el empleo de uno de los mtodos de diseo, la fase de diseo produceun diseo de datos, un diseo arquitectnico, un diseo de interfaz y un diseo procedimental. Diseo de datos: Transforma el modelo de dominio de la informacin, creado durante el anlisis, en lase s t r u c t u r a s d e d a t o s n e c e s a r i a s p a r a i m p l e m e n t a r e l s o f t w a r e . L o s o b j e t o s d e d a t o s y l a s r e l a c i o n e s definidas en el diagrama entidad relacin (DER) y el contenido detallado de datos del diccionario de datos proporciona la base para la actividad de diseo de datos. Diseo arquitectnico: Define la relacin entre los principales elementos estructurales del programa.Esta representacin del diseo se puede obtener del modelo de anlisis y de la interaccin de subsistemas,definidos dentro del modelo de anlisis. Diagrama de flujo de datos.

Diseo de interfaz: describe cmo se comunica el software consigo mismo, con los sistemas que operancon l y con los operadores que lo emplean. Una interfaz implica un flujo de informacin, entonces losdiagramas de flujo de datos y control proporcionan informacin necesaria para el diseo de la interfaz. Diseo procedimental: transforma elementos estructurales de la arquitectura del program a e n u n a descripcin procedimental de los componentes de software. La informacin se obtiene de EP, EC y DTEsirve de base para el diseo procedimental.El diseo es el lugar donde se fomenta la calidad en el desarrollo del software. Sirve como fundamento paratodas las fases posteriores de ingeniera y mantenimiento del software. 13.2 EL PROCESO DE DISEO A lo largo de este proceso de diseo, se evala la calidad del diseo con una serie de revisiones tcnicas formales. Tres caractersticas que sirven de directrices para la evaluacin de un buen diseo:Debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y debe acomodar todoslos requisitos implcitos que desea el cliente.Debe ser una gua que puedan leer y entender los que construyan el cdigo y los que prueban y mantienen elsoftware.Debera proporcionar una completa idea de lo que es el software, enfocando los dominios de datos, funcionaly de comportamiento desde la perspectiva de la implementacin.Criterios tcnicos para un buen diseo. Consejos: un diseo debera