SlideShare una empresa de Scribd logo
Análisis de
          Análisis de
        Requerimientos
        Requerimientos




    Situación de la Industria de
             Software
• Mas del 30% de todos los proyectos de
  software son cancelados antes de su
  finalización.
• Mas del 70% de los proyectos restantes
  fallan al entregar y evaluar las características
  esperadas.
• Un proyecto promedio ejecuta 189% sobre el
  presupuesto aprobado y extiende sus
  actividades sobre el 222%.
           »             Fuente : The Standish Group - 1996
Porqué los Proyectos de
        Software son exitosos ?
•   Involucra a Usuarios                               15.9%
•   Soporte Administración                             13.9%
•   Clara definición de Requerimientos                 13.0%
•   Apropiado Planeamiento                              9.6%
•   Expectativas Realistas                              8.2%
•   Hitos no Extensos                                   7.7%
•   Staff Competente de profesionales                   7.2%
•   Propietario                                         5.3%
               »     Fuente:   QualitySystems
                               Quality Systems & Software - 1997




         Porqué los Proyectos de
            Software fallan ?
•   Requerimientos Incompletos                         13.1%
•   Falta de Requerimientos                            12.4%
•   Falta de Recursos                                  10.6%
•   Expectativas no Realistas                           9.9%
•   Cambio Requerimientos/Especificaciones              8.7%
•   Falta de Planeamiento                               8.1%
•   No se especifico el tiempo adecuado                 7.5%

               »     Fuente : Quality Systems & Software - 1997
                              QualitySystems
Qué es un Requerimiento ?
• Un requerimiento es una condición o
  capacidad a la que el sistema (siendo
  construido) debe conformar [ Rational ].
• Un requerimiento de software puede ser
  definido como :
  – Una capacidad del software necesaria por el usuario
    para resolver un problema o alcanzar un objetivo.
  – Una capacidad del software que debe ser reunida o
    poseída por un sistema o componente del sistema
    para satisfacer un contrato, especificación, estándar,
    u otra documentación formal.




  Qué son Requerimientos ?
• Los requerimientos de usuario representan el
  conjunto completo de resultados a ser
  obtenidos utilizando el sistema.
• Los requerimientos de sistemas deben
  mostrar todo lo que el sistema debe hacer
  mas todas las restricciones sobre la
  funcionalidad.
• Los requerimientos forman un modelo
  completo, representando el sistema total a
  algún nivel de abstracción.
Rol de Requerimientos
• Si un producto no es lo que el cliente o los
  usuarios quieren, entonces la calidad de la
  construcción es irrelevante.
• El rol clave de los requerimientos es mostrar a
  los desarrolladores y usuarios que se necesita
  de un sistema. Proveer los requerimientos forma
  parte de un lenguaje que todos comprenden, ya
  que todos están involucrados, incluyendo los
  clientes.
• El primer y básico rol de los requerimientos es
  por lo tanto la comunicación.




       Cómo identificamos los
         Requerimientos ?
• Los Requerimientos toman vida desde que
  realizamos nuestro primer encuentro de
  interlocución con usuarios o clientes.
• Este puede desarrollarse utilizando cualquiera
  de una variedad de técnicas como entrevistas
  para intercambiar opiniones, brainstorming ,
                                   brainstorming,
  prototipeo,
  prototipeo , cuestionarios, etc.
• Cuando los requerimientos se logran redactar a
  un significativo nivel de detalle, tendremos listo
  el documento denominado “Especificación de
  Requerimientos”.
Buena Especificación de
          Requerimientos
• Un resultado primario de esta administración
  es la Especificación de Requerimientos, la
  cual define y documenta en forma completa
  el comportamiento externo del sistema a ser
  construido. Caracterizándose por :
  –   Definidos sin ambiguedad
  –   Son completos
  –   Tienen consistencia
  –   Especifica el origen
  –   Evita detalles de diseño
  –   Están enumerados




   Beneficios de una Buena
Administración de Requerimientos
• Mejor control de proyectos complejos.
• Mejora en la calidad del software y en la
  satisfacción del cliente.
• Reducción en los retrasos y en los costos del
  proyecto.
• Mejora en la comunicación del equipo.
• Facilita la conformidad con estándares y
  regulaciones.
Los Problemas de la Administración
        de Requerimientos
• No son siempre obvios y tienen muchas fuentes.
• No son siempre fáciles de expresar en palabras.
• Hay muchos tipos diferentes a distintos niveles
  de detalle.
• El número puede llegar a ser inmanejable.
• Están relacionados a otros en una variedad de
  formas.
• Hay muchos interesados y partes responsables.
• Cambian.
• Pueden ser sensibles al tiempo.




 El Alto Costo de Errores en los
         Requerimientos
• Hay fuertes evidencias que una efectiva
  administración de requerimientos conducen
  los ahorros del proyecto integral.
• Las tres razones primarias para esto son :
  – Costos de reparar errores en los requerimientos
    superan en mas de 10 veces a otros errores.
  – Errores de requerimientos comprenden encima del
    40% de todos los errores de un proyecto de software.
  – Pequeños reducciones en el número de errores de
    requerimientos rinden grandes dividendos al evitar
    costos de re -trabajo y días de retraso.
              re-
Procesos de
             Ingeniería Software
Requerimientos de       Procesos de            Sistema
   usuarios

Nuevo o cambiado    Ingeniería de Software Nuevo o cambiado



 “ Un Proceso es el conjunto total de actividades
   de ingeniería necesarias para transformar dentro
   de software los requerimientos de usuarios ”
                           “Managing the Process”, Humphrey, 1989




 Requerimientos del Dominio
• Se derivan del dominio del sistema más que de
  las necesidades específicas de los usuarios.
  Pueden ser requerimientos funcionales nuevos,
  restringir los existentes o establecer cómo se
  deben ejecutar cálculos particulares.
• Los requerimientos del dominio son importantes
  debido a que a menudo reflejan los
  fundamentos del dominio de aplicación.
• Si estos requerimientos no se satisfacen, es
  imposible hacer que el sistema trabaje de forma
  satisfactoria.
Ej. Definición de
    Requerimientos de Usuario

 1.El software debe proveer un medio para
   representar y acceder a archivos externos
   creados por otras herramientas.




      Ej. Especificación de
   Requerimientos del sistema
1.1 Al usuario se le proveerá con los recursos para definir el
    tipo de archivos externos.
1.2 Cada tipo de archivo externo tendrá una herramienta
    asociada que será aplicada al archivo.
1.3 Cada tipo de archivo externo se representará como un
    icono especifico sobre la pantalla del usuario.
1.4 Se proveerán recursos para que el usuario defina el icono
    que representa un tipo de archivo externo.
1.5 Cuando un usuario selecciona un icono que representa
    un archivo externo, el efecto de esa selección es aplicar
    la herramienta asociada con este tipo de archivo al
    archivo representado por el icono seleccionado.
Requerimientos Funcionales
• Describen la funcionalidad o los servicios que se
  espera proveerá el sistema.
• Estos dependen del tipo de software y del
  sistema que se desarrolle y de los posibles
  usuarios del software.
• Cuando se expresan como requerimientos del
  usuario, habitualmente se describen de forma
  general mientras que los requerimientos
  funcionales del sistema describen con detalle la
  función de éste, sus entradas y salidas,
  excepciones, etc.




    Ej. Sistema de Biblioteca
1. El usuario deberá tener la posibilidad de
   buscar referencias bibliográficas en el conjunto
   inicial de la base de datos o seleccionar un sub
   conjunto de ella.
2. El sistema deberá proveer visores adecuados
   para que el usuario lea documentos en el
   almacén de documentos.
3. A cada pedido se le deberá asignar un
   identificador único que el usuario podrá copiar
   al área de almacenamiento permanente de la
   cuenta.
Análisis de la especificación de
         Requerimientos
• El sistema de biblioteca puede almacenar
  documentos en diferentes formatos y la
  intención de este requerimiento es que los
  visores para todos estos formatos estén
  disponibles.
• Sin embargo, el requerimiento es ambiguo
  puesto que no clarifica que los visores para
  cada formato deban ser provistos.
• Un desarrollador bajo la presión del tiempo
  sencillamente podría proporcionar un visor de
  texto y afirmar que se ha cumplido el
  requerimiento.




Requerimientos No Funcionales
• Son aquellos requerimientos que no se refieren
  directamente a las funciones específicas que entrega el
  sistema, sino a las propiedades emergentes de éste
  como la fiabilidad, la respuesta en el tiempo y la
  capacidad de almacenamiento.
• De forma alternativa, definen las restricciones del
  sistema, como la capacidad de los dispositivos de
  entrada/salida y la representación de datos que se utiliza
  en las interfaces del sistema.
• Sin embargo, estos requerimientos no siempre se
  refieren al sistema de software a desarrollar.
MÉTRICAS PARA ESPECIFICAR REQUERIMIENTOS NO FUNCIONALES


   PROPIEDAD                                            MEDIDA
                   • Transacciones procesadas por segundo
Rapidez            • Tiempo de respuesta al usuario y a eventos
                   • Tiempo de actualización de la pantalla
Tamaño             • KB’s
                   • Tamaño de RAM
Facilidad de uso   • Tiempo de capacitación
                   • Número de ventanas de ayuda
                   • Tiempo promedio entre fallas
Fiabilidad         • Probabilidad de no disponibilidad
                   • Tasa de ocurrencia de las fallas
                   • Disponibilidad
                   • Tiempo de reinicio después de fallas
Robustez           • Porcentaje de eventos que provocan las fallas
                   • Probabilidad de corrupción de los datos después de las fallas
Portabilidad       • Porcentaje de declaraciones dependientes del objetivo
                   • Número de sistemas objetivo
Identificación de Requerimientos
      y Reglas del Negocio
• Para identificar los requerimientos correctos del negocio
  primero debemos de comprender como funciona, es
  decir cuales son las reglas del negocio.
• Mientras más complejo es el sistema una mayor
  cantidad de vistas del mismo son necesarias para
  comprender su funcionamiento.
• Las distintas vistas del negocio pueden conseguirse a
  través de un mapeo de la situación actual (AS-IS)
  utilizando a un alto nivel:
   –   El Diagrama de descomposición funcional o mapeo de procesos.
   –   Las cadenas de responsabilidad para la atención de los requerimi entos
   –   Los Diagramas de Actividad
   –   Los Diagramas de Colaboración
   –   Los Diagramas de Interacción de Roles
   –   Casos de Uso del Negocio




                                                               Descomposición
                                                              Funcional – IDEF0
Cadena de Responsabilidades
• Es la cadena funcional que se
  establece para la atención de
                                                           Actor Negocio
  un requerimiento.                                    Alguien o alguna cosa
• Una cadena involucra las                             fuera del negocio que
                                                       interactúa con el.
  interacciones producto de los
  requerimientos de un actor
  externo al negocio (cliente o                         Trabajador Negocio

  proveedor) con las                                    Role o conjunto de
                                                        roles dentro del
  responsabilidades de un                               negocio. Interactúa con
                                                        otros trabajadores de
  trabajador de negocio.                                negocio y manipula las
                                                        entidades.




                   CADENA DE
               RESPONSABILIDADES
                                         Barra de
                                         bifurcación   Unidad de Negocio

             Trabajador
             de Negocio
                          Punto de
                          Decisión

                                     Barra de
  Actor de                           sincronización
  Negocio
                    Condición                                 Condición
                    final                                     final


• La cadena eslabona a las unidades organizacionales de los
  trabajadores de negocio, que intervienen como consecuencia de
  las responsabilidades de cada uno y a través de la interacción
  entre ellos (cumpliendo un rol) y de estos con el actor de negocio
  externo (cliente o proveedor).
Diagrama de Interacción de
               Roles
• Un diagrama que muestra las actividades de cada actor
  interno o externo como consecuencia de su interacción
  para la atención de un requerimiento.
• Los roles de usuario son definidos en los rectángulos de
  la parte superior de cada línea de rol vertical.
• Modela la interacción entre diferentes actores,
  incluyendo al cliente, dentro de un proceso de negocios.
• Este ilustra el flujo de trabajo (líneas verticales gruesas)
  hechas por diferentes roles (líneas verticales delgadas)
  vía los eventos que causan la interacción (flechas
  horizontales).
Diagrama de Interacción de
               Roles
• Los puntos de inicio y termino son
  círculos, y las actividades son las líneas
  gruesas asignadas a cada rol de usuario.
• Las flechas definen las condiciones para
  la transición entre estas entidades.




                   Actor              Trabajador           Trabajador
                  Negocio              Negocio              Negocio

      Evento                mensaje
      de inicio

                                             actividades




 reproceso                                    mensaje




                                             decisión




                               DIAGRAMA DE INTERACCIÓN
                                      DE ROLES
DIAGRAMA DE COLABORACIÓN
• Es un diagrama que permite representar la
  forma en la que colaboran los trabajadores de
  negocio para satisfacer un requerimiento de un
  actor de negocio, así como representar las
  entidades relacionadas.
• Documentan como interactúan los trabajadores
  de negocio y las entidades del negocio para
  ejecutar una función de negocio, mostrando los
  mensajes intercambiados entre ellos.
• Una entidad es alguna cosa manejada o
  utilizada por los trabajadores de negocio.
Diagrama de Colaboración




                                               En sultad ura
                                                                  RESULTADOS         CLAVES




                                                re lect
                                                 treg os
                                                   de
                                                                   LECTURA          RESPUESTA
                             Responsable




                                                     a
                               Lectura
  FICHAS




                                 Or lectur s
                                   de a d
  ÓPTICAS




                                    re rore
                                      na e
                        as




                                       er
                                                                    Entr
               ica ich
                                                                        e
                                                                   de re ga clav
            ópt trega f


                                                                        spu     e
                                                                           esta s
                  s
             En




                                                 Comisión
                             Entrega de          Admisión
                                       s
                             Resultado

                                                 Ordena                             Responsable
                                                              n
                                                 recalificació                      Procesamiento

     Presidente CA
                                                          RESULTADOS
                                                          CALIFICACIÓN




     Diagrama de Actividades
• Es un diagrama que presenta una vista
  alternativa a las actividades que realiza cada
  actor externo o interno para la atención de un
  requerimiento, y que puede utilizarse como
  complemento a la vista mostrada a través de
  una cadena de responsabilidades.
• En el diagrama se muestran un nodo de inicio,
  actividades, decisiones, barras de bifurcación
  y/o de sincronización, y un nodo final.
Responsable Lectura            Comisión                           Responsable
                                                 Admisión                          Procesamiento
Generar Archivo                  Inicio

de Ingresantes
                         Lee las Hojas
                         de Identificación


                                               Verifican Resultados
                                                   de la Lectura


                                          No
                                                             Son correctos ?


                                                 Si

                          Lee hojas de
                           respuesta



                        Genera archivo
                          de lectura




                                                                               Registra Claves
                                                                                 y vacantes




                                                                                   Procesa
                                                                                  resultados



                                                       Evaluan
                                                      resultados



                                                             Cubren
                                                             Vacantes ?
                                                                                    No

                                                                   Si
                                                                                                   Diagrama de
                                                                                Genera Archivo
                                                                                 de Ingresantes    Actividades
                                                                                          Fin

                                      Ing. Luis Zuloaga Rotta FIIS-UNI




       Casos de Uso de Negocio
 • Un caso de uso es la cadena de interacciones
   entre un actor de negocio (cliente, proveedor o
   trabajador) y el sistema (la empresa, una unidad
   organizacional o un proceso del negocio) con la
   finalidad de satisfacer un requerimiento o
   alcanzar un objetivo.
 • Una secuencia de acciones que produce un
   resultado de valor para un particular actor de
   negocio.
Negocio vs. Sistema
                                                       • Cada trabajador de negocio
                                                         identificado en el modelo del
 Actor Negocio                                           negocio es un potencial
                                                         actor del sistema.
                                       Actor           • Cada actor del negocio
                                                         también es un potencial
                                                         actor del sistema, si este
                                                         actor de negocio interactúa
           Trabajador Negocio                            directamente con el sistema
                                                         bajo desarrollo.
                                                       • Cada caso de uso de
                                                         negocio es un candidato a
                                                         caso de uso del sistema.
Caso Uso de Negocio             Caso Uso del Sistema




        Ejemplo de un Diagrama de Casos de Uso de Negocio




            CLIENTE             Proceso de Cotización             VENTAS



                                   <<include >>




                                                               FABRICACIÓN
                                Proceso de Pedido




             FACTURACIÓN
                                                                INSTALACIÓN
                                            DESPACHO

Más contenido relacionado

La actualidad más candente

Unidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De UsoUnidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De Uso
Sergio Sanchez
 
Caso De Uso
Caso De UsoCaso De Uso
Caso De Uso
Arcangel Gale
 
Ingenieria de requerimientos 1
Ingenieria de requerimientos 1Ingenieria de requerimientos 1
Ingenieria de requerimientos 1
jmpov441
 
Qué es un documento de requerimientos
Qué es un documento de requerimientosQué es un documento de requerimientos
Qué es un documento de requerimientos
Carlos Alonso
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
Cesar Prado
 
Diagrama de casos de usos
Diagrama de casos de usosDiagrama de casos de usos
Diagrama de casos de usos
Juan Carlos Tapias
 
IEEE 1471-2000: Documento de arquitectura de software
IEEE 1471-2000: Documento de arquitectura de softwareIEEE 1471-2000: Documento de arquitectura de software
IEEE 1471-2000: Documento de arquitectura de software
Jesús Navarro
 
7.modelado de los requerimientos escenarios y clases
7.modelado de los requerimientos  escenarios y clases7.modelado de los requerimientos  escenarios y clases
7.modelado de los requerimientos escenarios y clases
Ramiro Estigarribia Canese
 
Principios diseño del software
Principios diseño del software Principios diseño del software
Principios diseño del software
Jose Patricio Bovet Derpich
 
Rol del Analista de Sistemas
Rol del Analista de SistemasRol del Analista de Sistemas
Rol del Analista de Sistemas
Núcleo UNEFA. Ext. San Casimiro
 
Proyecto Final - Calidad de Software
Proyecto Final - Calidad de SoftwareProyecto Final - Calidad de Software
Proyecto Final - Calidad de Software
Yessenia I. Martínez M.
 
Plantilla de toma de requisitos softwarev 1.0
Plantilla de toma de requisitos softwarev 1.0Plantilla de toma de requisitos softwarev 1.0
Plantilla de toma de requisitos softwarev 1.0
Javier Hermoso Blanco
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
Zuleima
 
Casos De Uso
Casos De UsoCasos De Uso
Casos De Uso
guest2accd2
 
Estimación Software por Puntos de Función
Estimación Software por Puntos de FunciónEstimación Software por Puntos de Función
Estimación Software por Puntos de Función
Fundación Universitaria Konrad Lorenz
 
Requerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónRequerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicación
Yare LoZada
 
Diagrama de dominio armando
Diagrama de dominio armandoDiagrama de dominio armando
Diagrama de dominio armando
Negrita Ruiz Bruno
 
tecnicas de revisión del software
tecnicas de revisión del softwaretecnicas de revisión del software
tecnicas de revisión del software
MARCO POLO SILVA SEGOVIA
 
Requerimientos no funcionales
Requerimientos no funcionalesRequerimientos no funcionales
Requerimientos no funcionales
Angel Minga
 
Roles desarrollo del software
Roles desarrollo del softwareRoles desarrollo del software
Roles desarrollo del software
Joan Sebastián Ramírez Pérez
 

La actualidad más candente (20)

Unidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De UsoUnidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De Uso
 
Caso De Uso
Caso De UsoCaso De Uso
Caso De Uso
 
Ingenieria de requerimientos 1
Ingenieria de requerimientos 1Ingenieria de requerimientos 1
Ingenieria de requerimientos 1
 
Qué es un documento de requerimientos
Qué es un documento de requerimientosQué es un documento de requerimientos
Qué es un documento de requerimientos
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
 
Diagrama de casos de usos
Diagrama de casos de usosDiagrama de casos de usos
Diagrama de casos de usos
 
IEEE 1471-2000: Documento de arquitectura de software
IEEE 1471-2000: Documento de arquitectura de softwareIEEE 1471-2000: Documento de arquitectura de software
IEEE 1471-2000: Documento de arquitectura de software
 
7.modelado de los requerimientos escenarios y clases
7.modelado de los requerimientos  escenarios y clases7.modelado de los requerimientos  escenarios y clases
7.modelado de los requerimientos escenarios y clases
 
Principios diseño del software
Principios diseño del software Principios diseño del software
Principios diseño del software
 
Rol del Analista de Sistemas
Rol del Analista de SistemasRol del Analista de Sistemas
Rol del Analista de Sistemas
 
Proyecto Final - Calidad de Software
Proyecto Final - Calidad de SoftwareProyecto Final - Calidad de Software
Proyecto Final - Calidad de Software
 
Plantilla de toma de requisitos softwarev 1.0
Plantilla de toma de requisitos softwarev 1.0Plantilla de toma de requisitos softwarev 1.0
Plantilla de toma de requisitos softwarev 1.0
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
Casos De Uso
Casos De UsoCasos De Uso
Casos De Uso
 
Estimación Software por Puntos de Función
Estimación Software por Puntos de FunciónEstimación Software por Puntos de Función
Estimación Software por Puntos de Función
 
Requerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónRequerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicación
 
Diagrama de dominio armando
Diagrama de dominio armandoDiagrama de dominio armando
Diagrama de dominio armando
 
tecnicas de revisión del software
tecnicas de revisión del softwaretecnicas de revisión del software
tecnicas de revisión del software
 
Requerimientos no funcionales
Requerimientos no funcionalesRequerimientos no funcionales
Requerimientos no funcionales
 
Roles desarrollo del software
Roles desarrollo del softwareRoles desarrollo del software
Roles desarrollo del software
 

Destacado

Modelo de casos de uso 2ª versión
Modelo de casos de uso 2ª versiónModelo de casos de uso 2ª versión
Modelo de casos de uso 2ª versión
Jose Torres Gonzales
 
Modelo de casos de uso 2ª versión(2)
Modelo de casos de uso 2ª versión(2)Modelo de casos de uso 2ª versión(2)
Modelo de casos de uso 2ª versión(2)
Jose Torres Gonzales
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientos
Marvin Romero
 
1.1 REQUERIMIENTOS DE PROCESO
1.1 REQUERIMIENTOS DE PROCESO1.1 REQUERIMIENTOS DE PROCESO
1.1 REQUERIMIENTOS DE PROCESO
mataditoxd
 
Casos de uso
Casos de usoCasos de uso
Casos de uso
Ejército Mexicano
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De Requerimientos
Sergio Sanchez
 

Destacado (6)

Modelo de casos de uso 2ª versión
Modelo de casos de uso 2ª versiónModelo de casos de uso 2ª versión
Modelo de casos de uso 2ª versión
 
Modelo de casos de uso 2ª versión(2)
Modelo de casos de uso 2ª versión(2)Modelo de casos de uso 2ª versión(2)
Modelo de casos de uso 2ª versión(2)
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientos
 
1.1 REQUERIMIENTOS DE PROCESO
1.1 REQUERIMIENTOS DE PROCESO1.1 REQUERIMIENTOS DE PROCESO
1.1 REQUERIMIENTOS DE PROCESO
 
Casos de uso
Casos de usoCasos de uso
Casos de uso
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De Requerimientos
 

Similar a Analisis de requerimientos, Ingenieria de Software

Analisis requer
Analisis requerAnalisis requer
Analisis requer
rasek13
 
Presentación de ingeniería de requerimientos.pptx
Presentación de ingeniería de requerimientos.pptxPresentación de ingeniería de requerimientos.pptx
Presentación de ingeniería de requerimientos.pptx
BoliviaBolivia2
 
Analisis De Requerimientos Erick Rojas Figueroa
Analisis De Requerimientos   Erick Rojas FigueroaAnalisis De Requerimientos   Erick Rojas Figueroa
Analisis De Requerimientos Erick Rojas Figueroa
edays
 
02 captura de requisitos
02 captura de requisitos02 captura de requisitos
02 captura de requisitos
Mariana Fajardo Estudillo
 
Investigación sobre técnicas que se implementan en las tareas de la Ingenierí...
Investigación sobre técnicas que se implementan en las tareas de la Ingenierí...Investigación sobre técnicas que se implementan en las tareas de la Ingenierí...
Investigación sobre técnicas que se implementan en las tareas de la Ingenierí...
Karim Krystalgami
 
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdfTema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
NinoskaChuraLlojlla1
 
conceptos 1.pdf
conceptos 1.pdfconceptos 1.pdf
conceptos 1.pdf
CESARAS4
 
Unidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientosUnidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientos
mezcalote
 
metodologias de desarrollo.ppt
metodologias de desarrollo.pptmetodologias de desarrollo.ppt
metodologias de desarrollo.ppt
CristianFlasher1
 
Taller en clases requisitos inge jerez, evan, catalina,lesly esleider
Taller en clases requisitos inge jerez,  evan, catalina,lesly esleiderTaller en clases requisitos inge jerez,  evan, catalina,lesly esleider
Taller en clases requisitos inge jerez, evan, catalina,lesly esleider
Sergio Ramos
 
Taller requisitos
Taller  requisitos Taller  requisitos
Taller requisitos
leslyvallejo2
 
Taller requisitos
Taller requisitosTaller requisitos
Taller requisitos
DoesVargas1
 
Ingenieria de Requisitos
Ingenieria de RequisitosIngenieria de Requisitos
Ingenieria de Requisitos
Erick Javier Diaz H.
 
Requisitos
RequisitosRequisitos
Requisitos
guest90198711
 
REQUI
REQUIREQUI
Taller en clases (1)
Taller en clases (1)Taller en clases (1)
Taller en clases (1)
jocabedmariamartinez
 
Taller en clases
Taller en clasesTaller en clases
Taller en clases
3045433345
 
Análisis de requerimientos
Análisis de requerimientosAnálisis de requerimientos
Análisis de requerimientos
Gustavo Araque
 
REQUISITOS
REQUISITOSREQUISITOS
IngenieriaDeRequisitos2.pptx
IngenieriaDeRequisitos2.pptxIngenieriaDeRequisitos2.pptx
IngenieriaDeRequisitos2.pptx
ssuser8c00ad
 

Similar a Analisis de requerimientos, Ingenieria de Software (20)

Analisis requer
Analisis requerAnalisis requer
Analisis requer
 
Presentación de ingeniería de requerimientos.pptx
Presentación de ingeniería de requerimientos.pptxPresentación de ingeniería de requerimientos.pptx
Presentación de ingeniería de requerimientos.pptx
 
Analisis De Requerimientos Erick Rojas Figueroa
Analisis De Requerimientos   Erick Rojas FigueroaAnalisis De Requerimientos   Erick Rojas Figueroa
Analisis De Requerimientos Erick Rojas Figueroa
 
02 captura de requisitos
02 captura de requisitos02 captura de requisitos
02 captura de requisitos
 
Investigación sobre técnicas que se implementan en las tareas de la Ingenierí...
Investigación sobre técnicas que se implementan en las tareas de la Ingenierí...Investigación sobre técnicas que se implementan en las tareas de la Ingenierí...
Investigación sobre técnicas que se implementan en las tareas de la Ingenierí...
 
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdfTema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
 
conceptos 1.pdf
conceptos 1.pdfconceptos 1.pdf
conceptos 1.pdf
 
Unidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientosUnidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientos
 
metodologias de desarrollo.ppt
metodologias de desarrollo.pptmetodologias de desarrollo.ppt
metodologias de desarrollo.ppt
 
Taller en clases requisitos inge jerez, evan, catalina,lesly esleider
Taller en clases requisitos inge jerez,  evan, catalina,lesly esleiderTaller en clases requisitos inge jerez,  evan, catalina,lesly esleider
Taller en clases requisitos inge jerez, evan, catalina,lesly esleider
 
Taller requisitos
Taller  requisitos Taller  requisitos
Taller requisitos
 
Taller requisitos
Taller requisitosTaller requisitos
Taller requisitos
 
Ingenieria de Requisitos
Ingenieria de RequisitosIngenieria de Requisitos
Ingenieria de Requisitos
 
Requisitos
RequisitosRequisitos
Requisitos
 
REQUI
REQUIREQUI
REQUI
 
Taller en clases (1)
Taller en clases (1)Taller en clases (1)
Taller en clases (1)
 
Taller en clases
Taller en clasesTaller en clases
Taller en clases
 
Análisis de requerimientos
Análisis de requerimientosAnálisis de requerimientos
Análisis de requerimientos
 
REQUISITOS
REQUISITOSREQUISITOS
REQUISITOS
 
IngenieriaDeRequisitos2.pptx
IngenieriaDeRequisitos2.pptxIngenieriaDeRequisitos2.pptx
IngenieriaDeRequisitos2.pptx
 

Más de Marvin Romero

Procesos e Hilos, Sistemas Operativos
Procesos e Hilos, Sistemas OperativosProcesos e Hilos, Sistemas Operativos
Procesos e Hilos, Sistemas Operativos
Marvin Romero
 
Gestion Procesos, Sistemas Operativos
Gestion Procesos, Sistemas OperativosGestion Procesos, Sistemas Operativos
Gestion Procesos, Sistemas Operativos
Marvin Romero
 
Guía de Ejercicios de Fundamentos de Programación
Guía de Ejercicios de Fundamentos de ProgramaciónGuía de Ejercicios de Fundamentos de Programación
Guía de Ejercicios de Fundamentos de Programación
Marvin Romero
 
Guia de Ejercicios Fundamentos de Programacion
Guia de Ejercicios Fundamentos de ProgramacionGuia de Ejercicios Fundamentos de Programacion
Guia de Ejercicios Fundamentos de Programacion
Marvin Romero
 
Todo sobre Sistemas Operativos
Todo sobre Sistemas OperativosTodo sobre Sistemas Operativos
Todo sobre Sistemas Operativos
Marvin Romero
 
Estructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativoEstructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativo
Marvin Romero
 
Clasificación de los Sistemas Operativos
Clasificación de los Sistemas OperativosClasificación de los Sistemas Operativos
Clasificación de los Sistemas Operativos
Marvin Romero
 
Introducción a los Sistemas Operativos
Introducción a los Sistemas OperativosIntroducción a los Sistemas Operativos
Introducción a los Sistemas Operativos
Marvin Romero
 
Importancia de los Sistemas Operativos
Importancia de los Sistemas OperativosImportancia de los Sistemas Operativos
Importancia de los Sistemas Operativos
Marvin Romero
 
Máquina de von neumann
Máquina de von neumannMáquina de von neumann
Máquina de von neumann
Marvin Romero
 
Estructuras de Control en Lenguaje C
Estructuras de Control en Lenguaje CEstructuras de Control en Lenguaje C
Estructuras de Control en Lenguaje C
Marvin Romero
 
Variables, Constantes y Tipos de datos en C
Variables, Constantes y Tipos de datos en CVariables, Constantes y Tipos de datos en C
Variables, Constantes y Tipos de datos en C
Marvin Romero
 
Importancia de la programación estructurada opt
Importancia de la programación estructurada optImportancia de la programación estructurada opt
Importancia de la programación estructurada opt
Marvin Romero
 
Historia y caracteristicas del lenguaje c opt
Historia y caracteristicas del lenguaje c optHistoria y caracteristicas del lenguaje c opt
Historia y caracteristicas del lenguaje c opt
Marvin Romero
 
Jornalizacion Sistemas Operativos I-2012
Jornalizacion Sistemas Operativos I-2012Jornalizacion Sistemas Operativos I-2012
Jornalizacion Sistemas Operativos I-2012
Marvin Romero
 
Jornalizacion Fundamentos de Programación I-2012
Jornalizacion Fundamentos de Programación I-2012Jornalizacion Fundamentos de Programación I-2012
Jornalizacion Fundamentos de Programación I-2012
Marvin Romero
 
Metodologías y Técnicas de Diseño de Software
Metodologías y Técnicas de Diseño de SoftwareMetodologías y Técnicas de Diseño de Software
Metodologías y Técnicas de Diseño de Software
Marvin Romero
 
Especificación de requerimientos, Ingenieria de Software
Especificación de requerimientos, Ingenieria de SoftwareEspecificación de requerimientos, Ingenieria de Software
Especificación de requerimientos, Ingenieria de Software
Marvin Romero
 
Cocomo ejemplo
Cocomo ejemploCocomo ejemplo
Cocomo ejemplo
Marvin Romero
 
Planificacion y gestion de proyectos primera parte
Planificacion y gestion de proyectos primera partePlanificacion y gestion de proyectos primera parte
Planificacion y gestion de proyectos primera parte
Marvin Romero
 

Más de Marvin Romero (20)

Procesos e Hilos, Sistemas Operativos
Procesos e Hilos, Sistemas OperativosProcesos e Hilos, Sistemas Operativos
Procesos e Hilos, Sistemas Operativos
 
Gestion Procesos, Sistemas Operativos
Gestion Procesos, Sistemas OperativosGestion Procesos, Sistemas Operativos
Gestion Procesos, Sistemas Operativos
 
Guía de Ejercicios de Fundamentos de Programación
Guía de Ejercicios de Fundamentos de ProgramaciónGuía de Ejercicios de Fundamentos de Programación
Guía de Ejercicios de Fundamentos de Programación
 
Guia de Ejercicios Fundamentos de Programacion
Guia de Ejercicios Fundamentos de ProgramacionGuia de Ejercicios Fundamentos de Programacion
Guia de Ejercicios Fundamentos de Programacion
 
Todo sobre Sistemas Operativos
Todo sobre Sistemas OperativosTodo sobre Sistemas Operativos
Todo sobre Sistemas Operativos
 
Estructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativoEstructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativo
 
Clasificación de los Sistemas Operativos
Clasificación de los Sistemas OperativosClasificación de los Sistemas Operativos
Clasificación de los Sistemas Operativos
 
Introducción a los Sistemas Operativos
Introducción a los Sistemas OperativosIntroducción a los Sistemas Operativos
Introducción a los Sistemas Operativos
 
Importancia de los Sistemas Operativos
Importancia de los Sistemas OperativosImportancia de los Sistemas Operativos
Importancia de los Sistemas Operativos
 
Máquina de von neumann
Máquina de von neumannMáquina de von neumann
Máquina de von neumann
 
Estructuras de Control en Lenguaje C
Estructuras de Control en Lenguaje CEstructuras de Control en Lenguaje C
Estructuras de Control en Lenguaje C
 
Variables, Constantes y Tipos de datos en C
Variables, Constantes y Tipos de datos en CVariables, Constantes y Tipos de datos en C
Variables, Constantes y Tipos de datos en C
 
Importancia de la programación estructurada opt
Importancia de la programación estructurada optImportancia de la programación estructurada opt
Importancia de la programación estructurada opt
 
Historia y caracteristicas del lenguaje c opt
Historia y caracteristicas del lenguaje c optHistoria y caracteristicas del lenguaje c opt
Historia y caracteristicas del lenguaje c opt
 
Jornalizacion Sistemas Operativos I-2012
Jornalizacion Sistemas Operativos I-2012Jornalizacion Sistemas Operativos I-2012
Jornalizacion Sistemas Operativos I-2012
 
Jornalizacion Fundamentos de Programación I-2012
Jornalizacion Fundamentos de Programación I-2012Jornalizacion Fundamentos de Programación I-2012
Jornalizacion Fundamentos de Programación I-2012
 
Metodologías y Técnicas de Diseño de Software
Metodologías y Técnicas de Diseño de SoftwareMetodologías y Técnicas de Diseño de Software
Metodologías y Técnicas de Diseño de Software
 
Especificación de requerimientos, Ingenieria de Software
Especificación de requerimientos, Ingenieria de SoftwareEspecificación de requerimientos, Ingenieria de Software
Especificación de requerimientos, Ingenieria de Software
 
Cocomo ejemplo
Cocomo ejemploCocomo ejemplo
Cocomo ejemplo
 
Planificacion y gestion de proyectos primera parte
Planificacion y gestion de proyectos primera partePlanificacion y gestion de proyectos primera parte
Planificacion y gestion de proyectos primera parte
 

Último

Evolución, características, aplicación, ventajas y desventajas de las TIC
Evolución, características, aplicación, ventajas y desventajas de las TICEvolución, características, aplicación, ventajas y desventajas de las TIC
Evolución, características, aplicación, ventajas y desventajas de las TIC
Henry W. Zavala
 
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
MenaOlortinYherlyEli
 
BIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdf
BIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdfBIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdf
BIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdf
sunwndniel
 
Informe de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdf
Informe de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdfInforme de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdf
Informe de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdf
KEVINYOICIAQUINOSORI
 
Catalogo-Voxtech- accesorios radios RF.pdf
Catalogo-Voxtech- accesorios radios RF.pdfCatalogo-Voxtech- accesorios radios RF.pdf
Catalogo-Voxtech- accesorios radios RF.pdf
walter729637
 
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
bellomiguelangel68
 
DN Consultores | Una mirada al mercado de fibra en Perú
DN Consultores | Una mirada al mercado de fibra en PerúDN Consultores | Una mirada al mercado de fibra en Perú
DN Consultores | Una mirada al mercado de fibra en Perú
estudios22
 
_Manejo de Riesgos en el Laboratorio.pdf
_Manejo de Riesgos en el Laboratorio.pdf_Manejo de Riesgos en el Laboratorio.pdf
_Manejo de Riesgos en el Laboratorio.pdf
correodetareas
 
Presentación Redes Sociales Moderno Morado.pdf
Presentación Redes Sociales Moderno Morado.pdfPresentación Redes Sociales Moderno Morado.pdf
Presentación Redes Sociales Moderno Morado.pdf
anniehuanhuayo80
 
MATERIAL BASE D A T O S .docx
MATERIAL BASE    D A T O S              .docxMATERIAL BASE    D A T O S              .docx
MATERIAL BASE D A T O S .docx
CarlosAndresLoaizaRe
 
aplicaciones de sistema de informacion geografico
aplicaciones de sistema de informacion geograficoaplicaciones de sistema de informacion geografico
aplicaciones de sistema de informacion geografico
cyberquiximies
 
Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...
Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...
Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...
sunwndniel
 
CAPCUT PASO A PASO - herramientas tecnológicas de edición de videos
CAPCUT PASO A PASO - herramientas tecnológicas de edición de videosCAPCUT PASO A PASO - herramientas tecnológicas de edición de videos
CAPCUT PASO A PASO - herramientas tecnológicas de edición de videos
Iris505525
 
Generaciones de Computadoras .
Generaciones de Computadoras                 .Generaciones de Computadoras                 .
Generaciones de Computadoras .
gregory760891
 
DESARROLLO_DE_APLICACIONES_MULTIMEDIA.pptx
DESARROLLO_DE_APLICACIONES_MULTIMEDIA.pptxDESARROLLO_DE_APLICACIONES_MULTIMEDIA.pptx
DESARROLLO_DE_APLICACIONES_MULTIMEDIA.pptx
fortinodominguez78
 
El uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptxEl uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptx
Katia Reyes
 

Último (16)

Evolución, características, aplicación, ventajas y desventajas de las TIC
Evolución, características, aplicación, ventajas y desventajas de las TICEvolución, características, aplicación, ventajas y desventajas de las TIC
Evolución, características, aplicación, ventajas y desventajas de las TIC
 
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
 
BIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdf
BIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdfBIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdf
BIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdf
 
Informe de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdf
Informe de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdfInforme de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdf
Informe de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdf
 
Catalogo-Voxtech- accesorios radios RF.pdf
Catalogo-Voxtech- accesorios radios RF.pdfCatalogo-Voxtech- accesorios radios RF.pdf
Catalogo-Voxtech- accesorios radios RF.pdf
 
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
 
DN Consultores | Una mirada al mercado de fibra en Perú
DN Consultores | Una mirada al mercado de fibra en PerúDN Consultores | Una mirada al mercado de fibra en Perú
DN Consultores | Una mirada al mercado de fibra en Perú
 
_Manejo de Riesgos en el Laboratorio.pdf
_Manejo de Riesgos en el Laboratorio.pdf_Manejo de Riesgos en el Laboratorio.pdf
_Manejo de Riesgos en el Laboratorio.pdf
 
Presentación Redes Sociales Moderno Morado.pdf
Presentación Redes Sociales Moderno Morado.pdfPresentación Redes Sociales Moderno Morado.pdf
Presentación Redes Sociales Moderno Morado.pdf
 
MATERIAL BASE D A T O S .docx
MATERIAL BASE    D A T O S              .docxMATERIAL BASE    D A T O S              .docx
MATERIAL BASE D A T O S .docx
 
aplicaciones de sistema de informacion geografico
aplicaciones de sistema de informacion geograficoaplicaciones de sistema de informacion geografico
aplicaciones de sistema de informacion geografico
 
Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...
Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...
Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...
 
CAPCUT PASO A PASO - herramientas tecnológicas de edición de videos
CAPCUT PASO A PASO - herramientas tecnológicas de edición de videosCAPCUT PASO A PASO - herramientas tecnológicas de edición de videos
CAPCUT PASO A PASO - herramientas tecnológicas de edición de videos
 
Generaciones de Computadoras .
Generaciones de Computadoras                 .Generaciones de Computadoras                 .
Generaciones de Computadoras .
 
DESARROLLO_DE_APLICACIONES_MULTIMEDIA.pptx
DESARROLLO_DE_APLICACIONES_MULTIMEDIA.pptxDESARROLLO_DE_APLICACIONES_MULTIMEDIA.pptx
DESARROLLO_DE_APLICACIONES_MULTIMEDIA.pptx
 
El uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptxEl uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptx
 

Analisis de requerimientos, Ingenieria de Software

  • 1. Análisis de Análisis de Requerimientos Requerimientos Situación de la Industria de Software • Mas del 30% de todos los proyectos de software son cancelados antes de su finalización. • Mas del 70% de los proyectos restantes fallan al entregar y evaluar las características esperadas. • Un proyecto promedio ejecuta 189% sobre el presupuesto aprobado y extiende sus actividades sobre el 222%. » Fuente : The Standish Group - 1996
  • 2. Porqué los Proyectos de Software son exitosos ? • Involucra a Usuarios 15.9% • Soporte Administración 13.9% • Clara definición de Requerimientos 13.0% • Apropiado Planeamiento 9.6% • Expectativas Realistas 8.2% • Hitos no Extensos 7.7% • Staff Competente de profesionales 7.2% • Propietario 5.3% » Fuente: QualitySystems Quality Systems & Software - 1997 Porqué los Proyectos de Software fallan ? • Requerimientos Incompletos 13.1% • Falta de Requerimientos 12.4% • Falta de Recursos 10.6% • Expectativas no Realistas 9.9% • Cambio Requerimientos/Especificaciones 8.7% • Falta de Planeamiento 8.1% • No se especifico el tiempo adecuado 7.5% » Fuente : Quality Systems & Software - 1997 QualitySystems
  • 3. Qué es un Requerimiento ? • Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. • Un requerimiento de software puede ser definido como : – Una capacidad del software necesaria por el usuario para resolver un problema o alcanzar un objetivo. – Una capacidad del software que debe ser reunida o poseída por un sistema o componente del sistema para satisfacer un contrato, especificación, estándar, u otra documentación formal. Qué son Requerimientos ? • Los requerimientos de usuario representan el conjunto completo de resultados a ser obtenidos utilizando el sistema. • Los requerimientos de sistemas deben mostrar todo lo que el sistema debe hacer mas todas las restricciones sobre la funcionalidad. • Los requerimientos forman un modelo completo, representando el sistema total a algún nivel de abstracción.
  • 4. Rol de Requerimientos • Si un producto no es lo que el cliente o los usuarios quieren, entonces la calidad de la construcción es irrelevante. • El rol clave de los requerimientos es mostrar a los desarrolladores y usuarios que se necesita de un sistema. Proveer los requerimientos forma parte de un lenguaje que todos comprenden, ya que todos están involucrados, incluyendo los clientes. • El primer y básico rol de los requerimientos es por lo tanto la comunicación. Cómo identificamos los Requerimientos ? • Los Requerimientos toman vida desde que realizamos nuestro primer encuentro de interlocución con usuarios o clientes. • Este puede desarrollarse utilizando cualquiera de una variedad de técnicas como entrevistas para intercambiar opiniones, brainstorming , brainstorming, prototipeo, prototipeo , cuestionarios, etc. • Cuando los requerimientos se logran redactar a un significativo nivel de detalle, tendremos listo el documento denominado “Especificación de Requerimientos”.
  • 5. Buena Especificación de Requerimientos • Un resultado primario de esta administración es la Especificación de Requerimientos, la cual define y documenta en forma completa el comportamiento externo del sistema a ser construido. Caracterizándose por : – Definidos sin ambiguedad – Son completos – Tienen consistencia – Especifica el origen – Evita detalles de diseño – Están enumerados Beneficios de una Buena Administración de Requerimientos • Mejor control de proyectos complejos. • Mejora en la calidad del software y en la satisfacción del cliente. • Reducción en los retrasos y en los costos del proyecto. • Mejora en la comunicación del equipo. • Facilita la conformidad con estándares y regulaciones.
  • 6. Los Problemas de la Administración de Requerimientos • No son siempre obvios y tienen muchas fuentes. • No son siempre fáciles de expresar en palabras. • Hay muchos tipos diferentes a distintos niveles de detalle. • El número puede llegar a ser inmanejable. • Están relacionados a otros en una variedad de formas. • Hay muchos interesados y partes responsables. • Cambian. • Pueden ser sensibles al tiempo. El Alto Costo de Errores en los Requerimientos • Hay fuertes evidencias que una efectiva administración de requerimientos conducen los ahorros del proyecto integral. • Las tres razones primarias para esto son : – Costos de reparar errores en los requerimientos superan en mas de 10 veces a otros errores. – Errores de requerimientos comprenden encima del 40% de todos los errores de un proyecto de software. – Pequeños reducciones en el número de errores de requerimientos rinden grandes dividendos al evitar costos de re -trabajo y días de retraso. re-
  • 7. Procesos de Ingeniería Software Requerimientos de Procesos de Sistema usuarios Nuevo o cambiado Ingeniería de Software Nuevo o cambiado “ Un Proceso es el conjunto total de actividades de ingeniería necesarias para transformar dentro de software los requerimientos de usuarios ” “Managing the Process”, Humphrey, 1989 Requerimientos del Dominio • Se derivan del dominio del sistema más que de las necesidades específicas de los usuarios. Pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer cómo se deben ejecutar cálculos particulares. • Los requerimientos del dominio son importantes debido a que a menudo reflejan los fundamentos del dominio de aplicación. • Si estos requerimientos no se satisfacen, es imposible hacer que el sistema trabaje de forma satisfactoria.
  • 8. Ej. Definición de Requerimientos de Usuario 1.El software debe proveer un medio para representar y acceder a archivos externos creados por otras herramientas. Ej. Especificación de Requerimientos del sistema 1.1 Al usuario se le proveerá con los recursos para definir el tipo de archivos externos. 1.2 Cada tipo de archivo externo tendrá una herramienta asociada que será aplicada al archivo. 1.3 Cada tipo de archivo externo se representará como un icono especifico sobre la pantalla del usuario. 1.4 Se proveerán recursos para que el usuario defina el icono que representa un tipo de archivo externo. 1.5 Cuando un usuario selecciona un icono que representa un archivo externo, el efecto de esa selección es aplicar la herramienta asociada con este tipo de archivo al archivo representado por el icono seleccionado.
  • 9. Requerimientos Funcionales • Describen la funcionalidad o los servicios que se espera proveerá el sistema. • Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software. • Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma general mientras que los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc. Ej. Sistema de Biblioteca 1. El usuario deberá tener la posibilidad de buscar referencias bibliográficas en el conjunto inicial de la base de datos o seleccionar un sub conjunto de ella. 2. El sistema deberá proveer visores adecuados para que el usuario lea documentos en el almacén de documentos. 3. A cada pedido se le deberá asignar un identificador único que el usuario podrá copiar al área de almacenamiento permanente de la cuenta.
  • 10. Análisis de la especificación de Requerimientos • El sistema de biblioteca puede almacenar documentos en diferentes formatos y la intención de este requerimiento es que los visores para todos estos formatos estén disponibles. • Sin embargo, el requerimiento es ambiguo puesto que no clarifica que los visores para cada formato deban ser provistos. • Un desarrollador bajo la presión del tiempo sencillamente podría proporcionar un visor de texto y afirmar que se ha cumplido el requerimiento. Requerimientos No Funcionales • Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. • De forma alternativa, definen las restricciones del sistema, como la capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en las interfaces del sistema. • Sin embargo, estos requerimientos no siempre se refieren al sistema de software a desarrollar.
  • 11. MÉTRICAS PARA ESPECIFICAR REQUERIMIENTOS NO FUNCIONALES PROPIEDAD MEDIDA • Transacciones procesadas por segundo Rapidez • Tiempo de respuesta al usuario y a eventos • Tiempo de actualización de la pantalla Tamaño • KB’s • Tamaño de RAM Facilidad de uso • Tiempo de capacitación • Número de ventanas de ayuda • Tiempo promedio entre fallas Fiabilidad • Probabilidad de no disponibilidad • Tasa de ocurrencia de las fallas • Disponibilidad • Tiempo de reinicio después de fallas Robustez • Porcentaje de eventos que provocan las fallas • Probabilidad de corrupción de los datos después de las fallas Portabilidad • Porcentaje de declaraciones dependientes del objetivo • Número de sistemas objetivo
  • 12. Identificación de Requerimientos y Reglas del Negocio • Para identificar los requerimientos correctos del negocio primero debemos de comprender como funciona, es decir cuales son las reglas del negocio. • Mientras más complejo es el sistema una mayor cantidad de vistas del mismo son necesarias para comprender su funcionamiento. • Las distintas vistas del negocio pueden conseguirse a través de un mapeo de la situación actual (AS-IS) utilizando a un alto nivel: – El Diagrama de descomposición funcional o mapeo de procesos. – Las cadenas de responsabilidad para la atención de los requerimi entos – Los Diagramas de Actividad – Los Diagramas de Colaboración – Los Diagramas de Interacción de Roles – Casos de Uso del Negocio Descomposición Funcional – IDEF0
  • 13. Cadena de Responsabilidades • Es la cadena funcional que se establece para la atención de Actor Negocio un requerimiento. Alguien o alguna cosa • Una cadena involucra las fuera del negocio que interactúa con el. interacciones producto de los requerimientos de un actor externo al negocio (cliente o Trabajador Negocio proveedor) con las Role o conjunto de roles dentro del responsabilidades de un negocio. Interactúa con otros trabajadores de trabajador de negocio. negocio y manipula las entidades. CADENA DE RESPONSABILIDADES Barra de bifurcación Unidad de Negocio Trabajador de Negocio Punto de Decisión Barra de Actor de sincronización Negocio Condición Condición final final • La cadena eslabona a las unidades organizacionales de los trabajadores de negocio, que intervienen como consecuencia de las responsabilidades de cada uno y a través de la interacción entre ellos (cumpliendo un rol) y de estos con el actor de negocio externo (cliente o proveedor).
  • 14. Diagrama de Interacción de Roles • Un diagrama que muestra las actividades de cada actor interno o externo como consecuencia de su interacción para la atención de un requerimiento. • Los roles de usuario son definidos en los rectángulos de la parte superior de cada línea de rol vertical. • Modela la interacción entre diferentes actores, incluyendo al cliente, dentro de un proceso de negocios. • Este ilustra el flujo de trabajo (líneas verticales gruesas) hechas por diferentes roles (líneas verticales delgadas) vía los eventos que causan la interacción (flechas horizontales).
  • 15. Diagrama de Interacción de Roles • Los puntos de inicio y termino son círculos, y las actividades son las líneas gruesas asignadas a cada rol de usuario. • Las flechas definen las condiciones para la transición entre estas entidades. Actor Trabajador Trabajador Negocio Negocio Negocio Evento mensaje de inicio actividades reproceso mensaje decisión DIAGRAMA DE INTERACCIÓN DE ROLES
  • 16. DIAGRAMA DE COLABORACIÓN • Es un diagrama que permite representar la forma en la que colaboran los trabajadores de negocio para satisfacer un requerimiento de un actor de negocio, así como representar las entidades relacionadas. • Documentan como interactúan los trabajadores de negocio y las entidades del negocio para ejecutar una función de negocio, mostrando los mensajes intercambiados entre ellos. • Una entidad es alguna cosa manejada o utilizada por los trabajadores de negocio.
  • 17. Diagrama de Colaboración En sultad ura RESULTADOS CLAVES re lect treg os de LECTURA RESPUESTA Responsable a Lectura FICHAS Or lectur s de a d ÓPTICAS re rore na e as er Entr ica ich e de re ga clav ópt trega f spu e esta s s En Comisión Entrega de Admisión s Resultado Ordena Responsable n recalificació Procesamiento Presidente CA RESULTADOS CALIFICACIÓN Diagrama de Actividades • Es un diagrama que presenta una vista alternativa a las actividades que realiza cada actor externo o interno para la atención de un requerimiento, y que puede utilizarse como complemento a la vista mostrada a través de una cadena de responsabilidades. • En el diagrama se muestran un nodo de inicio, actividades, decisiones, barras de bifurcación y/o de sincronización, y un nodo final.
  • 18. Responsable Lectura Comisión Responsable Admisión Procesamiento Generar Archivo Inicio de Ingresantes Lee las Hojas de Identificación Verifican Resultados de la Lectura No Son correctos ? Si Lee hojas de respuesta Genera archivo de lectura Registra Claves y vacantes Procesa resultados Evaluan resultados Cubren Vacantes ? No Si Diagrama de Genera Archivo de Ingresantes Actividades Fin Ing. Luis Zuloaga Rotta FIIS-UNI Casos de Uso de Negocio • Un caso de uso es la cadena de interacciones entre un actor de negocio (cliente, proveedor o trabajador) y el sistema (la empresa, una unidad organizacional o un proceso del negocio) con la finalidad de satisfacer un requerimiento o alcanzar un objetivo. • Una secuencia de acciones que produce un resultado de valor para un particular actor de negocio.
  • 19. Negocio vs. Sistema • Cada trabajador de negocio identificado en el modelo del Actor Negocio negocio es un potencial actor del sistema. Actor • Cada actor del negocio también es un potencial actor del sistema, si este actor de negocio interactúa Trabajador Negocio directamente con el sistema bajo desarrollo. • Cada caso de uso de negocio es un candidato a caso de uso del sistema. Caso Uso de Negocio Caso Uso del Sistema Ejemplo de un Diagrama de Casos de Uso de Negocio CLIENTE Proceso de Cotización VENTAS <<include >> FABRICACIÓN Proceso de Pedido FACTURACIÓN INSTALACIÓN DESPACHO