Ir 2011

Ingeniera de Software II
Ingeniera en Informtica FICH UNL

Unidad I: Ingeniera de Requerimientos
Docentes:
Morais, Mara Josefina Romero, Lucila Santucci, Viviana Andrea Schneider, Mara de los Milagros Bogado, Vernica
Ingeniera de Software
Establecer y usar principios de ingeniera orientados a obtener software de manera econmica, que sea fiable y funcione eficientemente
Bauer
Ingeniera de Software
Es la disciplina que comprende todos los aspectos de la produccin de software desde las etapas iniciales de la especificacin del sistema, hasta el mantenimiento de ste despus de que se utiliza.
Sommerville
SWEBOK
La IEEE Computer Society y la Association for Computing Machinery han trabajando en un proyecto conjunto para desarrollar una gua del Cuerpo de Conocimientos de la Ingeniera de Software (SWEBOK). SWEBOK busca aglutinar en un solo texto las competencias que debiese tener todo ingeniero de software para desempearse competentemente en el mercado. Es un proyecto para clasificar y definir todo lo que es Ingeniera de Software (IS). http://www.computer.org/portal/web/swebok
Ingeniera de Software II 4
Objetivos del SWEBOK

Identificar el contenido de la disciplina de la Ingeniera de Software. Proveer acceso al cuerpo de conocimientos de la Ingeniera de Software. Promover una visin uniforme y consistente de la Ingeniera de Software a nivel mundial. Aclarar el lugar de la Ingeniera de Software con respecto a otras disciplinas tales como, ciencias de la computacin, gestin de proyectos, matemticas, etc. Proveer una fundamentacin para el desarrollo del currculum (programas universitarios) y material de certificacin individual.
Pblico del SWEBOK

El proyecto est orientado hacia una variedad amplia de audiencias como ser: Organizaciones pblicas y privadas. Ingenieros de software practicantes. Elaboradores de polticas pblicas. Sociedades profesionales. Estudiantes de Ingeniera de Software y Educadores y formadores.
Organizacin del SWEBOK
reas de conocimiento del SWEBOK

Unidad I Unidad II Unidad III Unidad IV
Costo relativo de los errores

ETAPAS 20
.2-.1 0.5
Anlisis de Requerimientos Diseo Codificacin Prueba de Unidad Prueba de Aceptacin Mantenimiento 6 1 Anlisis Diseo Codificacin (J.Leite)
20
COSTO RELATIVO DE CORRECCIN
Grfico 1
Grfico 2
Algunas definiciones
Universo de Informacin (UdI): tambin llamado Universo de Discurso (UdeD). Es el contexto general
en el cual el software deber ser desarrollado y operado. El UdI incluye todas las fuentes de informacin y todas las personas relacionadas al software. Esas personas son tambin conocidas como los actores de ese universo. El UdI es la realidad influenciada por el conjunto de objetivos definidos por los que demandan el software.
Stakeholder: todos aquellos que tienen algn inters en el cambio que se est considerando, aquellos que ganan con l, y aquellos que pierden con l.
Definicin de Requerimiento
Requerimiento: Necesidad de un Stakeholder Requerimiento es... una especificacin de lo que debera ser implementado. Son una descripcin de cmo el sistema debera comportarse o de una propiedad o atributo del sistema, que puede ser una restriccin sobre el proceso de desarrollo del sistema.
97 Sommerville and Sawyer
Requerimiento - Requisito
Simplemente... cualquier cosa que un cliente necesite. Desde el punto de vista del diseador, cualquier cosa que necesite ser diseada.
12
Ingeniera de Requerimientos
La Ingeniera en Requisitos es una subtarea (est incluida dentro) de la Ingeniera de Software. Propone mtodos, tcnicas y herramientas que faciliten el trabajo de Definicin de lo que se quiere de un software La Ingeniera de Requerimientos es "la aplicacin disciplinada de principios cientficos y tcnicas para desarrollar, comunicar y administrar los requerimientos". La Ingeniera de Requerimientos es "el proceso sistemtico de desarrollar los requerimientos a travs de un proceso iterativo de analizar un problema, documentar las observaciones resultantes, y verificar la exactitud de la comprensin ganada"
13
Clasificacin de los Requerimientos

En cuanto a contenido Funcionales No Funcionales Inversos En cuanto a nivel de abstraccin Requisitos-c Requisitos-d
Clasificacin de los requerimientos

Requerimientos Funcionales: describen la funcionalidad o los servicios que se espera que el sistema proveer. Requerimientos No Funcionales: se refieren a las propiedades emergentes del sistema, como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. Requerimientos Inversos: definen cmo el Sistema de Software nunca se debe comportar.
15
Requerimientos Funcionales
Describen la funcionalidad o los servicios que se esperan del sistema de software. Dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software. Cuando se expresan cmo requerimientos del usuario, se describen de forma general; mientras que los requerimientos funcionales del sistema describen con detalle la funcin de ste, sus entradas y salidas, excepciones, etc.
16
RNF Atributos de calidad

Calidad: confiabilidad, disponibilidad, robustez,.. Factores humanos: facilidad de uso, simplicidad de las interfaces,... Caractersticas de rendimiento: tiempos de respuesta, performance,... Restricciones de hardware y software: compatibilidad con equipamiento y/o sistemas disponibles,... Cambios y/o adaptaciones nuevos requerimientos: adaptabilidad, reuso de componentes,... Restricciones de seguridad.
RNF: Clasificacin
Requerimientos no funcionales
Requerimientos del producto
Requerimientos organizacionales
Requerimientos externos
Requerimientos de eficiencia
Requerimientos de fiabilidad
Requerimientos de portabilidad
Requerimientos de interoperabilidad
Requerimientos ticos
Requerimientos de usabilidad
Requerimientos de entrega
Requerimientos de implementacin
Requerimientos de estndares
Requerimientos legislativos
Requerimientos de privacidad
Requerimientos de seguridad
18
Requerimientos No Funcionales
No se refieren directamente a las funciones especficas que brinda el sistema, sino a sus propiedades emergentes: fiabilidad, tiempo de respuesta, capacidad de almacenamiento , etc. Definen las restricciones del sistema: capacidad de los dispositivos de entrada/salida, representacin de datos que se utiliza en las interfaces, etc.
19
Funcionales vs No Funcionales
Los requerimientos no funcionales se refieren al sistema como un todo ms que a rasgos particulares del mismo; => a menudo son ms crticos que los requerimientos funcionales particulares.
Mientras que el incumplimiento de un requerimiento funcional degradar al sistema, una falla en un requerimiento no funcional del sistema lo inutiliza.
RNF: Requerimientos del producto

Especifican el comportamiento del producto. Ejemplos: Requerimientos de desempeo en la rapidez de ejecucin del sistema y cunta memoria se requiere; De fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; De portabilidad y de usabilidad.
21
RNF: Requerimientos organizacionales

Se derivan de las polticas y procedimientos existentes en la organizacin del cliente y en la del desarrollador. Ejemplos: Estndares en los procesos que deben utilizarse; Requerimientos de implementacin como los lenguajes de programacin o el mtodo de diseo a utilizar; Requerimientos de entrega que especifican cundo se entregar el producto y su documentacin.
RNF: Requerimientos externos

Este gran apartado cubre todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. Estos incluyen: Los requerimientos de interoperabilidad que definen la manera en que el sistema interacta con los otros sistemas de la organizacin; Los requerimientos legales que deben seguirse para asegurar que el sistema opere dentro de la ley; Los requerimientos ticos, que son impuestos al sistema para asegurar que ser aceptado por el usuario y por el pblico en general.
23
IR: el proceso
Concepto Anlisis del Problema
Factibilidad y eleccin de opciones Anlisis y Modelado
Cada etapa debe ser seguida de una validacin para chequear la veracidad de la informacin conseguida y el entendimiento ganado sobre el problema.
Documentacin de Requerimientos
IR: el proceso
25
Criterios de validacin de los requerimientos

Completo El requerimiento debe describir toda la informacin necesaria para implementarlo en forma explcita. Necesario El requerimiento debe poder asociarse con un uso concreto y relevante. Verificable El requerimiento debe poder ser verificado una vez implementado. Consistente El requerimiento debe actuar en forma armnica con el resto de los requerimientos funcionales y no-funcionales. Alcanzable El requerimiento debe permitir su implementacin.
Tcnicas de Elicitacin de Requisitos

Lectura de Documentos: Contacto con el vocabulario de la aplicacin y del UdI. Observacin: El analista tiene una posicin pasiva en el UdI observando el ambiente donde el software ir a actuar. Entrevistas: Son el medio ms usual con el cual el analista recoge los hechos. Existen diferentes tipos de entrevista: Estructuradas, Informales y Tutoras. Cuestionarios: Los cuestionarios son utilizados cuando se tiene un buen conocimiento sobre el problema (aplicacin) y se quiere abarcar un nmero grande de clientes. Anlisis de Protocolos: Esta estrategia consiste en analizar el trabajo de determinada persona a travs de sus relatos, normalmente durante su trabajo.
Tcnicas de Elicitacin de Requisitos (cont.)

Participacin activa de los actores del UdI: intenta incorporar al grupo de analistas los actores que demandan el SW. Los actores deben aprender el lenguaje de modelado. Enfoque antropolgico: se usa una tcnica inversa de la descripta anteriormente, ya que los analistas deben procurar integrarse al UdI de forma de alcanzar un conocimiento lo ms amplio posible del problema. Reuniones: son una extensin de las entrevistas. Reutilizacin: como su nombre lo indica, esta tcnica consiste en reutilizar hechos ya elicitados. Recuperacin del diseo de software: estudio de SW disponible en la organizacin. Trabajos de reingeniera han sido propuestos como una forma de, no solo recuperar lo que exactamente hacen los sistemas existentes, sino tambin como para optimizar la tarea de mantenerlos.
Rastreabilidad de requerimientos
La rastreabilidad de requerimientos (traceability) significa que los requerimientos relacionados deben estar relacionados de alguna manera y que a su vez deben estar relacionados a sus fuentes. La rastreabilidad es una propiedad de una buena especificacin de los requerimientos que se ve reflejada por la facilidad para encontrar requerimientos relacionados. Algunas herramientas CASE proveen soporte para la rastreabilidad. Por ejemplo, pueden encontrar todos los requerimientos que usen los mismo trminos.
Tcnicas de rastreabilidad
Asignar un numero nico a todos los requerimientos. Hacer un referencia cruzada (cross-reference) de los requerimientos relacionados utilizando este numero nico. Producir una matriz de referencias cruzadas para cada documento de requerimientos mostrando los requerimientos relacionados. Varias matrices pueden ser necesarias para diferentes tipos de relaciones.
30
Documento de Requerimientos
Tambin conocido como Especificacin de
Requerimientos de Software (ERS o SRS, en ingls)
Un DR es una especificacin de lo que se

requiere que haga un sistema (informtico) y no de cmo hacerlo.
Un DR puede ser evaluado por su efectividad

como un medio de comunicacin, por su contenido como una medida de chequeo (checklist), y por la calidad de su contenido.
Documento de Requerimientos
(cont.)
No existe un nivel de especificacin universalmente correcto. Los clientes con gran experiencia prefieren especificaciones de alto nivel, y aquellos con escasa experiencia pretenden mayor detalle. Recomendaciones: Cada clusula debe contener solamente un requerimiento. Evitar tener requerimientos que hace(n) referencia a otro(s) Agrupar los requerimientos semejantes.
ERS IEEE: Gua de especificacin de Requerimientos de SW

1. Introduccin 1.1. Propsito 1.2. Alcance 1.3. Definiciones, Acrnimos, y Abreviaciones 1.4. Referencias 1.5. Resumen Descripcin General 2.1. Perspectiva de Producto 2.2. Funciones 2.3. Caractersticas de Usuario 2.4. Restricciones generales 2.5. Suposiciones y dependencias Requerimientos Especficos 3.1. Requerimientos Funcionales 3.1.1. Requerimiento Funcional 1 3.1.1.1. Introduccin 3.1.1.2. Entradas (Inputs) 3.1.1.4. Salidas (Outputs)
33
2.
3.
3.2.
3.3. 3.4.
3.5.
3.6.
3.1.2. Requerimiento Funcional 2 Requerimientos de Interfase externos 3.2.1. Interfase de usuarios 3.2.2. Interfase de Hardware 3.2.3. Interfase de Software 3.2.4. Interfase de Comunicacin Requerimientos de Performace Restricciones de Diseo 3.4.1. Cumplimiento de Estndares 3.4.2. Limitaciones de Hardware Atributos 3.5.1. Seguridad 3.5.2. Mantenibilidad Otros Requerimientos 3.6.1. Bases de Datos 3.6.2. Operaciones 3.6.3. Adaptacin al sitio
Apndices ndice
El Documento de Requerimientos
De acuerdo a la IEEE (1984), un buen DR debera contener sentencias (oraciones, afirmaciones): No ambiguas Completas Verificables Consistentes Modificable Trazable (seguible) Usable
Tipos de lenguajes
Informales: (grficos, arbitrarios, lenguaje natural, etc.)
natural para stakeholders fcil de validar no automatizacin
Semi-formales: (diagramas-ER, SADT, etc.) Formales: (Z, VDM, etc.)

Se consideran formales aquellos lenguajes que son ejecutados sin ambigedad por una mquina.
Un usuario necesita de un lenguaje informal para exponer sus necesidades y entender lo que el analista capt del problema. El analista, a su vez, precisa de lenguajes semi-formales y formales para entender mejor el problema, verificar inconsistencias y ambigedades.
Ingeniera de Software II 36 36
Lxico Extendido del Lenguaje

El Lxico Extendido del Lenguaje (LEL) es una tcnica utilizada para describir los smbolos de un lenguaje. La idea central del LEL es la existencia de lenguajes de aplicacin. Esta idea parte del principio de que en el UdI existen una o ms culturas y que cada cultura (grupos sociales) tiene su lenguaje propio. Por lo tanto, el principal objetivo a ser alcanzado por los analistas en la tarea de elicitacin del LEL es la identificacin de palabras o frases peculiares al medio social de la aplicacin en estudio.
LEL - Fases
Identificacin de smbolos del lenguaje.
A travs de una tcnica de colecta de hechos (por ejemplo: entrevistas informales, observacin, lectura de documentos), el analista anota las frases o palabras que parecen tener un significado especial para la aplicacin. El resultado de esta fase es una lista de palabras o frases.
Identificacin de la semntica de cada smbolo.

En base a la lista de smbolos el analista procede a una entrevista estructurada con actores de la aplicacin procurando entender lo que significa cada smbolo.
LEL Formato de la ficha

La representacin requiere que para cada smbolo sean descriptos:
Nociones: lo que significa el smbolo. Impactos: describe los efectos del uso/ocurrencia del smbolo en la aplicacin o del efecto de algo en la aplicacin sobre el smbolo.
La descripcin de impactos y nociones est orientada por los principios de vocabulario mnimo y circularidad
LEL - Principios
Vocabulario mnimo: prescribe que al describir una mnimo: nocin o un impacto, esta descripcin debe minimizar el uso de smbolos externos al lenguaje, y que cuando esos smbolos externos son usados deben intentar tener una representacin matemtica clara, ej. Conjunto, unin, funcin. Circularidad define que las nociones e impactos deben ser descriptos usando smbolos del propio lenguaje.
40
LEL - Categoras
Sujeto Objeto Accin, Verbo o Frase verbal Situacin o Estado: no es tan clara la delimitacin entre esta
categora y la anterior. Pueden estar unidas.
Estas categoras se pueden abrir en subcategoras dependiendo de la conveniencia dentro del dominio en el que se est trabajando.
41
LEL - Ejemplo
LEL Solicitud de Adhesin / Solicitud / Formulario Nociones : Formulario que completa el solicitante para requerir la adhesin a un Plan de Ahorro. Contiene: Datos de Aceptacin Datos del Bien Datos del monto incial Datos Personales del solicitante Contiene las condiciones generales que debe cumplir el adherente al formar parte de un plan. Impactos : Necesaria para considerar el ingreso de una persona a un plan. La aceptacin de la solicitud implica la adhesin a un plan de ahorro. La solicitud puede ser rechazada.
42
LEL - Heursticos
Cada smbolo puede tener 1 o + impactos Cada smbolo tiene 0 o ms sinnimos (\) (alias) Cada smbolo tiene 1 o + nociones Escribir frases simples, una sola idea Las nociones e impactos de un smbolo pueden indicar puntos de vista diferentes o complementarios Respetar la circularidad y el vocabulario mnimo
43
LEL Heursticos (cont.)

Para un smbolo que es sujeto:
las nociones deben aclarar quien es el sujeto, y el impacto debe decir cuales son las acciones que ejecuta
Si es verbo:
las nociones deben aclarar quien ejecuta la accin, cundo y cules son los procedimientos incluidos, los impactos deben identificar las situaciones que impiden la accin, efectos de la accin en el ambiente y resultado.
LEL Heursticos (cont.)

Si es objeto:
las nociones deben definir el objeto e identificar otros objetos con los que se relaciona, los impactos deben aclarar las acciones que pueden ser aplicadas al objeto.
Si expresan una situacin:

las nociones deben decir que significan y cules son las acciones que llevan a esa situacin, los impactos otras acciones o situaciones derivadas de esta.
Revisin constante
LEL Proceso de construccin

1. Entrevistar usuario 2. Generar lista de smbolos 3. Clasificar lista 4. Describir smbolos 5. Validar el LEL 6. Controlar el LEL
46
LEL Proceso de construccin (cont.)

Dudas Entrevistar Usuario
Palabras y frases repetidas o enfatizadas Descripciones validadas
Validar LEL
Entradas candidatas
Generar lista
Descripciones Smbolos Clasificados Smbolos que no se ubican en la Clasificacin
Lista Candidata
Lista
Errores en las descripciones
Controlar LEL
Clasificar lista
Describir Descripcin de todos los smbolos smbolos validados
Clasificacin
LEL
47
LEL Otros ejemplos

LEL Solicitante Nociones : Toda persona de existencia fsica o jurdica que presenta una Solicitud de Adhesin a un Plan de Ahorro. Impactos : Presenta un formulario de Solicitud de Adhesin. Se convierte en adherente con la aceptacin de la solicitud. Debe cumplir con todos los requisitos para ser solicitante.
LEL Aceptacin/Aceptado/Aceptar Solicitud Nociones : Acto por el cual una solicitud de adhesin es aceptada e incorporada a un grupo. Impactos : El solicitante se transforma en adherente de un plan determinado. Un nuevo miembro se incorpora a un grupo. Se evala si un grupo es conformado.

Ir 2011

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ir 2011

Загружено:

Авторское право:

Доступные форматы

Ingeniera de Software II

Ingeniera en Informtica FICH UNL

Objetivos del SWEBOK

Pblico del SWEBOK

Organizacin del SWEBOK

reas de conocimiento del SWEBOK

Costo relativo de los errores

COSTO RELATIVO DE CORRECCIN

Clasificacin de los Requerimientos

Clasificacin de los requerimientos

RNF Atributos de calidad

Requerimientos del producto

RNF: Requerimientos del producto

RNF: Requerimientos organizacionales

RNF: Requerimientos externos

Factibilidad y eleccin de opciones Anlisis y Modelado

Criterios de validacin de los requerimientos

Tcnicas de Elicitacin de Requisitos

Tcnicas de Elicitacin de Requisitos (cont.)

Un DR es una especificacin de lo que se

Un DR puede ser evaluado por su efectividad

ERS IEEE: Gua de especificacin de Requerimientos de SW

Semi-formales: (diagramas-ER, SADT, etc.) Formales: (Z, VDM, etc.)

Lxico Extendido del Lenguaje

Identificacin de la semntica de cada smbolo.

LEL Formato de la ficha

LEL Heursticos (cont.)

LEL Heursticos (cont.)

Si expresan una situacin:

LEL Proceso de construccin

LEL Proceso de construccin (cont.)

Errores en las descripciones

Describir Descripcin de todos los smbolos smbolos validados

LEL Otros ejemplos

Вам также может понравиться