Presentación Conceptos basicos de Analisis y Diseño

1. 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

2. 1. Conceptos de
Análisis de Sistemas
1.1.Sistema
1.2. Requisito
1.3. Tipos requisitos
1.4. Características de un requisito
1.5. Análisis de software
1.6. Análisis de requisitos
1.7. Modelado del analisis

3. Sistema
Es 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.

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

5. 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

6. 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.

7. 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.

8. 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.

9. Análisis de requisitos
Las 5 áreas de esfuerzo del AR:





Reconocimiento del problema.
Evaluación y síntesis.
Modelado.
Especificación.
Revisión.

10. 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.

11. 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
◦ Reduce probabilidad de que se olvide algo.
◦ Aumenta
probabilidad
de
reconocer

Dar
prioridad
a
los
requisitos.

Trabajar para eliminar la ambigüedad.
requisitos.
inconsistencias.
Cronogramas.

12. 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.

13. 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.

14. Modelado de procesos
Los 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
Diagrama
Diagrama
Diagrama
Diagrama
Diagrama
de
de
de
de
de
de
clases
objetos
componentes
estructura compuesta
paquetes
despliegue
De Comportamiento
◦ Diagrama de casos de uso
◦ Diagrama de actividades
◦ Diagrama de estado
De Interacción
Diagrama de secuencia
Diagrama de colaboración UML 1.X
Diagrama de comunicación UML 2.0

15. Próxima clase
Conceptos de Diseño de Sistemas

16. 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.

17. Preguntas?
Descargar presentación desde:
arielrodriguezh.blogspot.com