Your SlideShare is downloading. ×
0
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Conceptos basicos de analisis y diseño

602

Published on

Presentación Conceptos basicos de Analisis y Diseño

Presentación Conceptos basicos de Analisis y Diseño

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
602
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
32
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×