Ingeniería de Software
Diseño del Sistema
Proceso de Software
Acumulación Errores
El Por Que?

Descripción del Problema
    • Descubrir los procesos de Negocio para realizar análisis del dominio
      del problema



Analisís del Problema

    • Entender mejor el problema mas que inicar el diseño de la solución
      para describrir los requerimientos del sistema.
Formalización del Problema

Modelado del Problema
   Expresar mediante diagramas de datos, de procesos, de estados, de
   interacción, de objetos, etc.

   El tipo de modelo elegido depende de:
   • La naturaleza del problema
   • La experiencia del modelador
   • La disponibilidad de herramientas
   • Por decreto. El cliente impone una notación
Ingeniería de Requerimientos

Como escribir Requisitos
   • La “mejor forma” de escribir requisitos no existe

   • Lo más utilizado es el lenguaje natural

   • Cada requisito expresado en una frases cortas
     (“el sistema hará X ...”, “se facilitará Y ...”, etc.)

   • Lenguaje natural complementado con diagramas y/o notaciones
     formales

   • La notación utilizada depende de quien lee o quien escribe los
     requisitos
Ingeniería de Requerimientos
Documento Estandar IEEE 830

Introducción
• Propósito
• Alcance
• Definiciones
• Referencias
• Visión General
                         http://es.scribd.com/doc/54229526/FORMATO-IEEE-830
Descripción General
• Perspectiva del producto
• Funciones del producto
• Características del usuario
• Restricciones
• Suposiciones

Requisitos específicos
Apéndices
En conclusión

Independiente del formato utilizado, un documento de requisitos contiene:



              Información acerca del problema


       Propiedades y comportamiento del sistema


  Restricciones de diseño y fabricación del producto
El Qué frente al Cómo
El Qué frente al Cómo

Relación Requisitos-Arquitectura
    • La elección de una determinada arquitectura software debe tener
      en cuenta los requisitos funcionales pero, sobre todo, los requisitos
      no funcionales (atributos de calidad del software)

    • No hay una regla definitiva para establecer, dados los requisitos, el
      tipo de arquitectura

    • Tan sólo hay una serie de heurísticas para, dados unos requisitos,
      elegir la arquitectura
El Cómo?

Diseño del Sistema
Clasificación de Requisitos

Criterios de agrupación
    • En funcionales vs. No funcionales (Capacidades vs. Restricciones)

    • Por prioridades

    • Por coste implementación

    • Por niveles (alto nivel, bajo nivel)

    • Según su volatilidad/estabilidad

    • Si son requisitos sobre el proceso o sobre el producto
Ejemplo Diagrama de Bloques

Iswii

  • 1.
  • 2.
  • 3.
  • 4.
    El Por Que? Descripcióndel Problema • Descubrir los procesos de Negocio para realizar análisis del dominio del problema Analisís del Problema • Entender mejor el problema mas que inicar el diseño de la solución para describrir los requerimientos del sistema.
  • 5.
    Formalización del Problema Modeladodel Problema Expresar mediante diagramas de datos, de procesos, de estados, de interacción, de objetos, etc. El tipo de modelo elegido depende de: • La naturaleza del problema • La experiencia del modelador • La disponibilidad de herramientas • Por decreto. El cliente impone una notación
  • 6.
    Ingeniería de Requerimientos Comoescribir Requisitos • La “mejor forma” de escribir requisitos no existe • Lo más utilizado es el lenguaje natural • Cada requisito expresado en una frases cortas (“el sistema hará X ...”, “se facilitará Y ...”, etc.) • Lenguaje natural complementado con diagramas y/o notaciones formales • La notación utilizada depende de quien lee o quien escribe los requisitos
  • 7.
  • 8.
    Documento Estandar IEEE830 Introducción • Propósito • Alcance • Definiciones • Referencias • Visión General http://es.scribd.com/doc/54229526/FORMATO-IEEE-830 Descripción General • Perspectiva del producto • Funciones del producto • Características del usuario • Restricciones • Suposiciones Requisitos específicos Apéndices
  • 9.
    En conclusión Independiente delformato utilizado, un documento de requisitos contiene: Información acerca del problema Propiedades y comportamiento del sistema Restricciones de diseño y fabricación del producto
  • 10.
  • 11.
    El Qué frenteal Cómo Relación Requisitos-Arquitectura • La elección de una determinada arquitectura software debe tener en cuenta los requisitos funcionales pero, sobre todo, los requisitos no funcionales (atributos de calidad del software) • No hay una regla definitiva para establecer, dados los requisitos, el tipo de arquitectura • Tan sólo hay una serie de heurísticas para, dados unos requisitos, elegir la arquitectura
  • 12.
  • 13.
    Clasificación de Requisitos Criteriosde agrupación • En funcionales vs. No funcionales (Capacidades vs. Restricciones) • Por prioridades • Por coste implementación • Por niveles (alto nivel, bajo nivel) • Según su volatilidad/estabilidad • Si son requisitos sobre el proceso o sobre el producto
  • 14.