Optimizacion
Upcoming SlideShare
Loading in...5
×
 

Optimizacion

on

  • 192 views

 

Statistics

Views

Total Views
192
Views on SlideShare
192
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Optimizacion Optimizacion Document Transcript

  • Introducción a la Ingeniería de INGENIERÍA de Requerimientos REQUERIMIENTOS La Ingeniería de Requerimientos (IR) se Unidad I – Parte I relaciona con la búsqueda de la situación futura y el cambio asociado. Introducción – Ing. De Software – Ing. De Requerimientos – Ciclo de Vida del Software – Está relacionada con encontrar (capturar) Crisis del Software – Chaos Report información y considerar posibles opciones, y con la identificación de lo que debería ser diseñado en orden a satisfacer una necesidad futura percibida 1 2 Hito: “No Silver Bullets” Hito: “No Silver Bullets” (Brooks, 1987) (Brooks, 1987) • Problemas o dificultades esenciales:• Paper magistral de Brooks (Abril,1987) – Complejidad• Dos tipos de problemas: • no lineal con el tamaño, – Esenciales: inherentes a la naturaleza • dependiente de diversos factores, del software. • problemas de gestión, de comunicación, … – Accidentales: relacionadas a la – Conformidad (complejidad arbitraria, puntos de vista) producción de software, pero que no son inherentes a él. – Modificabilidad (presiones constantes al cambio) – Invisibilidad (no tangible, no visualizable) 3Brooks, Fred P. (1987). "No Silver Bullet - Essence and Accidents in Software Engineering". IEEE Brooks, Fred P. (1987). "No Silver Bullet - Essence and Accidents in Software Engineering". IEEE 4Computer, 20(4): 10-19. Computer, 20(4): 10-19. Hito: “No Silver Bullets” Hito: “No Silver Bullets” (Brooks, 1987) (Brooks, 1987) “La parte más difícil de construir un sistema de software es “La parte más difícil de construir un sistema de software es decidir precisamente qué construir. decidir precisamente qué construir. Ninguna otra parte del trabajo conceptual es tan dificultosa Ninguna otra parte del trabajo conceptual es tan como establecer los requerimientos técnicos detallados, dificultosa como establecer los requerimientos técnicos incluyendo todas las interfases hacia las personas, detallados, incluyendo todas las interfases hacia las máquinas y otros sistemas de software. personas, máquinas y otros sistemas de software. Ninguna otra parte del trabajo paraliza el sistema si es mal Ninguna otra parte del trabajo paraliza el sistema si es mal hecha. Ninguna otra parte es tan difícil de rectificar hecha. Ninguna otra parte es tan difícil de rectificar después” después”Brooks, Fred P. (1987). "No Silver Bullet - Essence and Accidents in Software Engineering". IEEE 5 Brooks, Fred P. (1987). "No Silver Bullet - Essence and Accidents in Software Engineering". IEEE 6Computer, 20(4): 10-19. Luciana C. Ballejos Computer, 20(4): 10-19. Luciana C. Ballejos CIDISI, Centro de I+D en Ingeniería en Sistemas de Información CIDISI, Centro de I+D en Ingeniería en Sistemas de Información 1
  • Hito: “No Silver Bullets” Costo relativo de corregir defectos (Brooks, 1987) 3 ideas fundamentales a considerar: • La parte más difícil del trabajo: al inicio. • El impacto perjudicial del error. • La dificultad de rectificar posteriormente. El costo de reparar un defecto de software varía de acuerdo al momento en que se esté dentro del ciclo de vida del software.Brooks, Fred P. (1987). "No Silver Bullet - Essence and Accidents in Software Engineering". IEEE 7 Wiegers, Karl E. (2003). Software Requirements, Second Edition. Microsoft Press 8Computer, 20(4): 10-19. Luciana C. Ballejos CIDISI, Centro de I+D en Ingeniería en Sistemas de Información Problemas del Diseño de Soft Problemas del Diseño de Soft Áreas problemáticas: Causas de problemas: • Obtención de información informal, • funcionalidades implícitas o no establecidas, • Simplificaciones en los procesos • suposiciones no fundamentadas o no • Prácticas usadas para obtener, documentar, comunicadas, acordar y alterar los requerimientos de los • requerimientos no adecuadamente documentados productos. • cambios casuales en los procesos de requerimientos. 9 10 Problemas del Diseño de Soft Orientación de la IR Entre el 40 y el 60 % de los defectos encontrados Trabajo presente Opciones pertenecen a la etapa de requerimientos. del usuario Tecnológicas IR: relacionada Esencialmente la diferencia es “entre lo que los a encontrar la Diseño del situación futura desarrolladores piensan que tienen que construir y Sistema y el cambio lo que los usuarios o clientes piensan que van a asociado obtener”. Sistema Futuro t 11 12 2
  • Los ciclos de vida y la IR Los ciclos de vida y la IR Requerimientos Diseño Codificación Requerimientos en el modelo de Ciclo de Vida Testeo en Cascada. Operación Requerimientos en el modelo en V. 13 14 Los ciclos de vida y la IR Los ciclos de vida y la IRModelo Incremental Modelo Espiral • Comenzar produciendo una pequeña parte del sistema (pero completamente funcional). • Una vez completada, se crea una segunda parte, acoplada a la primera, de manera de que en cada iteración, se obtiene una versión aumentada del sistema hasta terminar. • No hay conocimiento completo a priori de los requerimientos (incertidumbre) Cada secuencia produce un “incremento” de software. Cada iteración o “incremento” produce una versión operativa se entrega un producto operacional. 15 16 Luciana C. Ballejos CIDISI, Centro de I+D en Ingeniería en Sistemas de Información Los ciclos de vida y la IR Requerimientos en CMMiRequerimientos en el Rational Unified Process (RUP) Categorías: - Administración de Procesos - Administración de Proyectos - Ingeniería - Soporte REQM: Administración de Requerim. PI: Integración de Producto. RD: Desarrollo de Requerimientos. VER: Verificación 17 TS: Solución Técnica. VAL: Validación 18 3 View slide
  • La IR en la Ingeniería de Software Crisis del Software: Crónicas Del Proceso de Producción de Software se encarga la • Nuevo aeropuerto de Denver (’90s) • El sistema de manejo de equipaje Ingeniería de Software subterráneo: casi 34 km de cintas transportadoras y 4000 telecars ¿Cómo surge?: Debido a los problemas ocasionados por errores independientes para 20 aerolíneas. de software • Un sistema central de 100 PC en red, 5000 Función: Producción de Software más robusto, proveyendo sensores eléctricos, 400 receptores de radio procesos de producción más confiables. y 56 lectores de barra. 19 20 Crisis del Software: Crónicas Crisis del Software: Crónicas• Por nueve meses no estuvo en funcionamiento por • FAA de EEUU: Reemplazo del sistema de control de tráfico aéreo por el AAS (Advanced Automation System). errores en el sistema de control. • Cuando un sistema es muy complejo no hay un gerente• 193 millones de dólares, pospuso la apertura del enteramente responsable del mismo. aeropuerto por 8 meses. De octubre a mayo, el costo • Más de 1 millón de líneas, distribuidas en más de 100 1,1 millón por día. computadoras. De cada 6 sistemas que se ponen en operación, 2 son • Se eligió a IBM. cancelados. • Se esperaba pagar 500 U$S por línea de código El mayor presupuesto promedio estimado siempre es la • Se pagó 700 - 900 por línea mitad de lo que se paga. • Cada línea de código escrita se reescribió once veces! Alrededor de ¾ de los grandes sistemas no funcionan • La FAA: canceló dos de las 4 partes solicitadas y rediseñó (para atrás) otra. como se intentó o no son usados. • Costo total del proyecto 144 millones de U$S. 21 22 CHAOS Report (2009) Crónicas • Exitoso: El proyecto se completa en el tiempo y con el presupuesto planificado, con todas las funciones y características especificadas originalmente. • De cada 6 sistemas que se ponen en • Comprometido/Cuestionado (“Challenged”): El proyecto se operación, 2 son cancelados. completa y es operacional, pero con tiempos y presupuesto mayores a los estimados y/o con menor cantidad de • El mayor presupuesto promedio estimado características y funciones de las especificadas inicialmente. siempre es la mitad de lo que se paga. • Fallado o Cancelado: El proyecto se cancela antes de ser completado o nunca es implementado. • Alrededor del 70% de los grandes sistemas no funcionan como se intentó o no son usados. 23 24 The Standish Group. (2009). Chaos Report 2009. 4 View slide
  • CHAOS Report (2009) Chaos Report • Por qué fallan los proyectos? 1. Requerimientos Incompletos 13.1% 2. Pobre Inclusión de los Usuarios 12.4% 3. Planificación y Estrategia 10.6% 4. Expectativas no Realistas 9.9% 5. Falta de Soporte Gerencial 9.3% 6. Requerimientos y Espec. Cambiantes 8.7% 7. Recursos Insuficientes 8.1% 8. Reqs. dejan de ser Necesarios 7.5% 9. Pobre Manejo de IT 6.2% 25 10. Desconocimiento de la Tecnología 4.3% 26The Standish Group. (2009). Chaos Report 2009. Chaos Report Introducción: Abstracción vs. Formalismo Abstracto • Por qué los proyectos son exitosos? Muy alto 1. Usuarios involucrados 15.9% (IDEAL) nivel 2. Soporte Gerencial 13.9% No Alg. (CONVENCIONAL) + Algorit. 3. Requerimientos Claros 13.0% 4. Planeamiento Apropiado 9.6% Alto nivel 5. Expectativas Realistas 8.2% Bajo 6. Milestones Pequeños (hitos/objetivos) 7.7% + nivel 7. Recursos Apropiados 7.2% Meta Nivel de 8. Metodología y Estrategia 5.3% máquina 9. Visión y Objetivos Claros 2.9% Prosa Especificación Código Concreto 10. Trabajo Duro, Recursos en Foco 2.4% 27 Informal Nivel Lingüístico Formal 28 ¿En qué se relaciona la Ingeniería de Software con Introducción la Ingeniería en Requerimientos? Lo que abarca Ingeniería de Requerimientos? La Ingeniería de Software abarca todo lo concerniente al desarrollo del Software, ofreciendo métodos y técnicas para las UdI DEFINICIÓN ? distintas etapas del ciclo de vida, de manera de desarrollar y mantener software de calidad: ♣ Definición del Problema DISEÑO ♣ Estudio de Factibilidad ♣ Análisis CICLO DE IMPLEMEN- SOFTWARE ♣ Diseño del Sistema VIDA TACIÓN ♣ Diseño Detallado DEL SOFT ♣ Implementación ♣ Mantenimiento 29 30 5
  • Introducción Necesidad de RequerimientosLa Ingeniería en requerimientos entra como una subtarea de la ¿Porqué es necesaria una etapa de Requerimientos?Ingeniería de Software; propone métodos, técnicas y herramientas quefaciliten el trabajo de Definición de lo que se quiere de un software: Determina- Compra Instalación Introducción y Uso Uso ción de o entrenamiento limitado Total ♣ Definición del Problema Necesidades Desarrollo Ingeniería de requerimientos: ♣ Estudio de Factibilidad Rol fundamental ♣ Análisis t ♣ Diseño del Sistema Evaluación y Evaluación de ♣ Diseño Detallado decisión de limitaciones ♣ Implementación etapa siguiente del producto ♣ Mantenimiento Debido a esta relación se deriva que: Muy fuerte Desde el punto de vista del cliente una etapa de requerimientos interacción es necesaria porque le ayuda a entender y expresar las nuevas Ing. en requerimientos Demandantes del Soft necesidades y a identificar cómo puede satisfacerlas. 31 32 Requerimiento - requisito Requerimiento - requisito ¿Qué es un Requerimiento? ’94 Jones: “Los requerimientos son las sentencias de necesidades de un usuario que lanzan el desarrollo de un programa o sistema” • Simplemente... cualquier cosa que un cliente necesite. ’93 Alan Davis: “una necesidad de un usuario o una facilidad • Desde el punto de vista del diseñador, cualquier cosa necesaria, función o atributo de un sistema que puede ser sensado que necesite ser diseñada. desde una posición externa al sistema” En general, el énfasis está en: Lo que irá en el producto, sus características. No cómo el producto se diseñará o construirá. 33 34 Requerimiento - requisito Requerimiento - requisito La más notable de las definiciones es la de la IEEE: ’97 Sommerville and Sawyer: “Requerimientos son... una 1. Una condición o capacidad necesaria para un especificación de lo que debería ser implementado. Son una usuario para resolver un problema o alcanzar un descripción de cómo el sistema debería comportarse o de una propiedad o atributo del sistema. Puede ser una restricción sobre objetivo. el proceso de desarrollo del sistema” 2. Una condición o capacidad que debe ser alcanzada o poseída por un sistema o componente de un sistema Lo que realmente necesitamos es asegurarnos que todos los para satisfacer un contrato, estándar, especificación, u stakeholders del proyecto llegan a un entendimiento otro documento formalmente impuesto. compartido de los términos usados para describir los requerimientos. 3. Una representación documentada de una condición o capacidad dada en 1 o 2. 35 36 6
  • Requerimientos Requerimientos Clasificación de los requerimientos Clasificación de los requerimientos: En cuanto al nivel de abstracción En cuanto al contenido • requerimientos-c: contienen los requerimientos funcionales, requerimientos- • Funcionales: describen las entradas, salidas y funciones de no funcionales e inversos descriptos en un lenguaje Funcionales transformación del Sistema; comprensible al cliente/usuario, utilizando excesivamente el vocabulario de la aplicación; • No Funcionales: definen atributos como confiabilidad, Funcionales performance, entre otros; • requerimientos-d: contienen también los requerimientos requerimientos- funcionales, no funcionales e inversos, siendo, mientras • Inversos: definen cómo el Sistema de Software nunca se debe tanto, descriptos en un lenguaje orientado al comportar. analista/desarrollador, evitando al máximo la utilización del 37 vocabulario de la aplicación. 38 Requerimientos Reqs. del Requerimientos Otra clasificación Negocio Relación entre los componentes de En cuanto al origen Doc. Visión y Alcance requerimientos de software Reqs. del Atributos de•Del negocio: objetivos de alto nivel de la organización. Usuario CalidadDocumentados en la visión o alcance del proyecto. Otros RNFs Doc. Casos de Uso•Del usuario: tareas que los usuarios deben hacer con el producto.Documentados en los casos de uso o escenarios. Reqs. del Reqs. Restricciones•Funcionales: las funcionalidades del soft a construir. Sistema funcionales•No Funcionales: que responden a estándares, regulaciones,contratos, interfases, performance, restricciones y atributos de Especificación de Requerimientos de Softwarecalidad. (SRS) 39 40 Wiegers, Karl E. (2003). Software Requirements, Second Edition. Microsoft Press 7