Conceptos básicos de Análisis y Diseño de

Software

Ing. Ariel Adolfo Rodríguez

ariel.rodriguez@uptc.edu.co 3144163790

@aadolforh

arielrodriguezh.blogspot.com

facebook.com/aadolforh

1. Conceptos de Análisis de Sistemas

1.1.Sistema1.2. Requisito1.3. Tipos requisitos1.4. Características de un requisito1.5. Análisis de software1.6. Análisis de requisitos1.7. Modelado del analisis

SistemaEs el conjunto de partes o elementos organizados y relacionados que interactúan entre sí para lograr un objetivo. Los sistemas reciben datos, energía o materia del ambiente (denominada entrada) y proveen información, energía o materia (denominada salida).

Cada sistema existe dentro de otro más grande por lo tanto un sistema puede estar formado por subsistemas, y a la vez puede ser parte de un supersistema.

Los sistemas tienen límites y fronteras, que los diferencian del ambiente, este límite puede ser físico o conceptual. Si hay algún intercambio entre el sistema y el ambiente, el sistema es abierto, de lo contrario, es cerrado.

El ambiente es el medio en externo que envuelve al sistema. El sistema tiene interacción con el ambiente, del cual recibe entradas y al cual se le devuelven salidas. El ambiente también puede ser una amenaza para el sistema.

Requisito

Un requisito es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniería de sistemas, ingeniería de software e ingeniería de requisitos. En la ingeniería clásica, los requisitos se utilizan como datos de entrada en la etapa de diseño.

Concepto de Requisito: Condición o capacidad que un usuario necesita para poder resolver un

problema o lograr un objetivo (IEEE). Condición o capacidad que debe exhibir o poseer un sistema para

satisfacer un contrato, estándar, especificación, u otra documentación formalmente impuesta (IEEE).

Una condición o capacidad que debe ser conformada por el sistema (RUP).

Algo que el sistema debe hacer o una cualidad que el sistema debe poseer (Robertson - Robertson).

Tipos de requisitos.

Un requisito funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requisito especifica algo que el sistema entregado debe ser capaz de realizar.

Un requisito no funcional: de rendimiento, de calidad, etc; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.

Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto.

Una colección de requisitos describe las características o atributos del sistema deseado

Características de Requisito

Los requisitos bien formulados deben satisfacer varias características. Si no lo hacen, deben ser reformulados hasta hacerlo.

Necesario: Lo que pida un requisito debe ser necesario para el producto. No ambiguo: El texto debe ser claro, preciso y tener una única interpretación

posible. Conciso: Debe redactarse en un lenguaje comprensible para usuario en lugar de

uno de tipo técnico y especializado. Consistente: Ningún requisito debe entrar en conflicto con otro requisito

diferente, ni con parte de otro. Y el lenguaje empleado entre los distintos requisitos debe ser consistente también.

Completo: Los requisitos deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen.

Alcanzable: Un requisito debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles.

Verificable: Se debe poder verificar con absoluta certeza, si el requisito fue satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis, demostración o testeo.

Como las características suelen ser subjetivas, oxea no pueden ser calculadas de forma automática por ningún sistema. Se tiende a utilizar métricas o indicadores que sí que pueden ser calculados de forma automática y que, de algún modo, pueden contribuir a ponderar las anteriores características.

Análisis de software

Conocido como la ingeniería de requisitos es el uso sistemático de procedimientos, técnicas, lenguajes y herramientas para obtener con un costo reducido el análisis, documentación, evolución continua de las necesidades del usuario y la especificación del comportamiento externo de un sistema que satisfaga las necesidades del usuario.

Análisis de requisitos

El análisis de requisitos es una tarea de ingeniería de software que cubre el hueco entre las definiciones del software a nivel sistema y el diseño del software.

El análisis de requisitos permite especificar las características operacionales del software (función, datos y rendimientos), indica la interface del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

Análisis de requisitos

Las 5 áreas de esfuerzo del AR:

Reconocimiento del problema. Evaluación y síntesis. Modelado. Especificación.  Revisión.

Principios Operativos del Análisis de requisitos

1.Debe representarse y entenderse el dominio de información 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 información, función y comportamiento de manera que se descubran los detalles por capas.

5. El proceso de análisis deriva ir desde la información esencial hasta el detalle de la implementación.

Directrices para la Ingeniería de Requisitos:

Entender el problema antes de empezar a crear el modelo del análisis.

Desarrollar prototipos que permitan al usuario entender cómo será la interacción hombre-máquina.

Registrar el origen y la razón de cada requisito.

Usar múltiples planteamientos de requisitos.

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

Dar prioridad a los requisitos. Cronogramas.

Trabajar para eliminar la ambigüedad.

MODELADO DEL ANÁLISIS

Es la primera representación técnica de un sistema.

Elementos del modelado del análisis

Debe lograr tres objetivos:

1. Describir lo que requiere el cliente.

2. Establecer una base para la creación de un diseño de software.

3. Definir un conjunto de requisitos que se pueda validar una vez que se construye el software.

Modelado de datos

El diagrama de Entidad-relación se centra solo en los datos. El modelado de datos estudia los datos independientemente del procesamiento que los transforma.

El modelado de datos se compone de tres piezas de información:

Objetos de datos. Atributos: Propiedades de objeto. Relaciones.

Modelado de procesosLos diagramas UML es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema o modelo, incluye aspectos conceptuales tales:

Procesos de negocio Funciones del sistema Aspectos concretos como expresiones de lenguajes de programación, esquemas de bases

de datos y compuestos reciclados.

Compuesto por un conjunto de diagramas a saber:

De Estructura◦ Diagrama de clases◦ Diagrama de objetos◦ Diagrama de componentes◦ Diagrama de estructura compuesta◦ Diagrama de paquetes◦ Diagrama de despliegue

De Comportamiento◦ Diagrama de casos de uso◦ Diagrama de actividades◦ Diagrama de estado

De InteracciónDiagrama de secuenciaDiagrama de colaboración UML 1.X Diagrama de comunicación UML 2.0

Próxima clase

Conceptos de Diseño de Sistemas

Bibliografía

Jacobson, I., Booch, G. & Rumbaugh, G. (2000). El Proceso Unificado de Desarrollo de Software. Madrid. Pearson Educación S.A.

Pressman R. (2010). Ingeniería del software. Un enfoque práctico. Editorial Mc Graw Hill. Séptima edición. 

Rational Software Corporation. (2006). Rational Unified Process, Versión 2002.05.00. http://www.ts.mah.se/RUP/RationalUnifiedProcess. Página web vigente al 8/05/2012.Software Engineering Standards Committee of the IEEE Computer Society. (1990). IEEE Std 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology. (Revision and redesignation of IEEE Std 792-1983). IEEE-SA Standards Board. The Institute of Electrical and Electronics Engineers. 

Software Engineering Standards Committee of the IEEE Computer Society. (1998). IEEE Std 830. IEEE Recommended Practice for Software Requirements Specifications. IEEE-SA Standards Board. The Institute of Electrical and Electronics Engineers, Inc. ISBN 0-7381-0332-2. http://www.mug.org.ar/Descargas/Jornadas/default.aspx. Página web vigente al 09/10/2009. 

Software Engineering Standards Committee of the IEEE Computer Society. (1998). IEEE Std 1233. 1998. IEEE Guía para el desarrollo de Especificaciones de Requerimientos de Sistemas. (incluye IEEE Std 1233–1996. e IEEE Std 1233a-1998). IEEE-SA Standards Board. The Institute of Electrical and Electronics Engineers. 

Software Engineering Institute, Carnegie Mellon University. (2010). CMMI® for Development, Version 1.3. CMMI-DEV, V1.3. Improving processes for developing better products and services. TECHNICAL REPORT CMU/SEI-2010-TR-033. ESC-TR-2010-033. Software Engineering Process Management Program. http://www.sei.cmu.edu/reports/10tr033.pdf . Página web vigente al 21/04/2012.  

Sommerville, I. (2005). Ingeniería de software. 7 Edición. México: Addison – Wesley. 

Sommerville, I. (2011). Ingeniería de software. 9 Edición. México. Pearson Educación.

Whitten. J, & Bentley. L. (2008). Análisis de sistemas: diseño y métodos. Séptima edición. Mc Graw Hill. México.

Yourdon, E. (2000). Análisis Estructurado Moderno. México: Pearson. ISBN 968-880-330-0.

Preguntas?

Descargar presentación desde:

arielrodriguezh.blogspot.com