CAMBIO DE USO
Qué es un Actor?
rLa palabra actor se utiliza en el UML para representar a los agentes externos que interactúan con el sistema a rollar.
Qué es un rol?
Es una actividad que puede asumir una pe?rsona o un sistema.
Cuantos roles puede tener un usuario?
Varios.
Para quien está dirigido los diagramas de casos de uso?
Es la explicación del cliente de que se trata el sistema, propietario y usuario
Cuantos niveles de Diagramas de Casos de uso existen y menciónelos
-Diagrama de negocios son más sencillos de entender el cliente
-Sistema Esta más al nivel de los desarrolladores
Qué hacer cuando el diagrama de caso de uso es muy grande y no cabe en una sola hoja?
-Tratar de agrupar varios casos de uso en un que sea más general
-Tratar de organizar los casos de uso por módulos
Cuando se tiene un diagrama de casos de uso muy complejo qué recomendarías?
Que es una clase?
Una clase es una construcción que se utiliza como un modelo (o plantilla) para crear objetos de ese tipo. El modelo describe el estado y el comportamiento que todos los objetos de la clase comparten. Un objeto de una determinada clase se denomina una instancia de la clase.
Ejemplos de clases
Una clase es un contenedor de uno o más datos (variables o propiedades miembro) junto a las operaciones de manipulación de dichos datos (métodos). Las clases pueden definirse como estructuras (struct), uniones (union) o clases (class) pudiendo existir diferencias entre cada una de las definiciones según el lenguaje. Además las clases son agrupaciones de objetos que describen su comportamiento.
La sintaxis típica de una clase es:
class Nombre {
// Variables miembro (habitualmente privadas)
miembro_1; //lista de miembros
miembro_2;
miembro_3;
Que es un Objeto?
En el paradigma de programación orientada a objetos (POO, o bien OOP en inglés), un objeto se define como la unidad que en tiempo de ejecución realiza las tareas de un programa. También a un nivel más básico se define como la instancia de una clase.Estos objetos interactúan unos con otros, en contraposición a la visión tradicional en la cual un programa es una colección de subrutinas (funciones o procedimientos), o simplemente una lista de instrucciones para el computador. Cada objeto es capaz de recibir mensajes, procesar datos y enviar mensajes a otros objetos de manera similar a un servicio.
En el mundo de la programación orientada a objetos (POO), un objeto es el resultado de la instanciación de una clase. Una clase es el anteproyecto que ofrece la funcionalidad en ella definida, pero ésta queda implementada sólo al crear una instancia de la clase, en la forma de un objeto. Por ejemplo: dado un plano para construir sillas (una clase de nombre clase_silla), entonces una silla concreta, en la que podemos sentarnos, construida a partir de este plano, sería un objeto de clase_silla. Es posible crear (construir) múltiples objetos (sillas) utilizando la definición de la clase (plano) anterior. Los conceptos de clase y objetos son análogos a los de tipo de datos y variable, es decir, definida una clase podemos crear objetos de esa clase, igual que disponiendo de un determinado tipo de dato (por ejemplo el tipo entero), podemos definir variables de dicho tipo:
int a,b;Que es una Instancia?
es una copia de una versión ejecutable del programa que ha sido escrito en la memoria del computador.Una instancia de un programa es creada típicamente por el click de usuario en un icono de una interfaz Gráfica para usuarios GUI o por la entrada de un comando en una interfaz de línea de comandos CLI y presionando la tecla ENTER. Instancias de programas pueden ser creadas por otros programas.
Que es UML?
Lenguaje Unificado de Modelado es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG. Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Cómo es la estructura de un objeto y cómo se representa en UML?
ESTRUCTURA DE UN OBJETO
Un objeto puede considerarse como una especie de cápsula dividida en tres partes:
1 - RELACIONES
2 - PROPIEDADES
3 - METODOS
Cada uno de estos componentes desempeña un papel totalmente independiente:
Las relaciones permiten que el objeto se insterte en la organización y están formadas esencialmente por punteros a otros objetos.
Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organización y tiene valores que dependen de la propiedadde que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización.
Los métodos son las operacionesque pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia.
Que es encapsulación?
se denomina encapsulamiento al ocultamiento del estado, es decir, de los datos miembro, de un objeto de manera que sólo se puede cambiar mediante las operaciones definidas para ese objeto.Cada objeto está aislado del exterior, es un módulo natural, y la aplicación entera se reduce a un agregado o rompecabezas de objetos. El aislamiento protege a los datos asociados a un objeto contra su modificación por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios e interacciones.
De esta forma el usuario de la clase puede obviar la implementación de los métodos y propiedades para concentrarse sólo en cómo usarlos. Por otro lado se evita que el usuario pueda cambiar su estado de maneras imprevistas e incontroladas.
Que es Abstracción?
Consiste en aislar un elemento de su contexto o del resto de los elementos que lo acompañan.
La abstracción encarada desde el punto de vista de la programación orientada a objetos expresa las características esenciales de un objeto, las cuales distinguen al objeto de los demás. Además de distinguir entre los objetos provee límites conceptuales. Entonces se puede decir que la encapsulación separa las características esenciales de las no esenciales dentro de un objeto. Si un objeto tiene más características de las necesarias los mismos resultarán difíciles de usar, modificar, construir y comprender
Ejemplo
Pensar en términos de objetos es muy parecido a cómo lo haríamos en la vida real. Una analogía sería modelizar un coche en un esquema de POO. Diríamos que el coche es el elemento principal que tiene una serie de características, como podrían ser el color, el modelo o la marca. Además tiene una serie de funcionalidades asociadas, como pueden ser ponerse en marcha, parar o aparcar. En un esquema POO el coche sería el objeto, las propiedades serían las características como el color o el modelo y los métodos serían las funcionalidades asociadas como ponerse en marcha o parar.
Por poner otro ejemplo vamos a ver cómo modelizaríamos en un esquema POO una fracción, es decir, esa estructura matemática que tiene un numerador y un denominador que divide al numerador, por ejemplo 3/2. La fracción será el objeto y tendrá dos propiedades, el numerador y el denominador. Luego podría tener varios métodos como simplificarse, sumarse con otra fracción o número, restarse con otra fracción, etc.
Estos objetos son utilizables en los programas, por ejemplo en un programa de matemáticas se puede hacer uso de objetos fracción y en un programa que gestione un taller de coches, objetos coche. Los programas orientados a objetos utilizan muchos objetos para realizar las acciones que se desean realizar y ellos mismos también son objetos. Es decir, el taller de coches será un objeto que utilizará objetos coche, herramienta, mecánico, recambios, etc.
Que es una relación?
Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto relacionarse con aquellos que forman parte de la misma organización.
Las hay de dos tipos fundamentales:
-Relaciones jerárquicas. Son esenciales para la existencia misma de la aplicación porque la construyen. Son bidireccionales, es decir, un objeto es padre de otro cuando el primer objeto se encuentra situado inmediatamente encima del segundo en la organización en la que ambos forman parte; asimismo, si un objeto es padre de otro, el segundo es hijo del primero (en la fig. 2, B es padre de D,E y F, es decir, D,E y F son hijos de B; en la fig. 3, los objetos B y C son padres de F, que a su vez es hijo de ambos).
Una organización jerárquica simple puede definirse como aquella en la que un objeto puede tener un solo padre, mientras que en una organización jerárquica compleja un hijo puede tener varios padres).
-Relaciones semánticas.Se refieren a las relaciones que no tienen nada que ver con la organización de la que forman parte los objetos que las establecen. Sus propiedades y consecuencia solo dependen de los objetos en sí mismos (de su significado) y no de su posición en la organización.
Se puede ver mejor con un ejemplo: supongamos que vamos a construir un diccionarioinformatizado que permita al usuario obtener la definición de una palabra cualquiera. Supongamos que, en dicho diccionario , las palabras son objetos y que la organización jerárquica es la que proviene de forma natural de la estructura de nuestros conocimientos sobre el mundo.
etc.
Veamos un ejemplo: estableceremos la relación trabajo entre los objetos NEWTON y OPTICA y la interpretaremos diciendo que significa que Newton trabajó en óptica (véase la fig. 4). La relación es, evidentemente, semántica, pues no establece ninguna connotación jerárquica entre NEWTON y OPTICA y su interpretación depende exclusivamente del significado de ambos objetos
Que es herencia
En orientación a objetos la herencia es el mecanismo fundamental para implementar la reutilización y extensibilidad del software. A través de ella los diseñadores pueden construir nuevas clases partiendo de una jerarquía de clases ya existente (comprobadas y verificadas) evitando con ello el rediseño, la modificación y verificación de la parte ya implementada. La herencia facilita la creación de objetos a partir de otros ya existentes, obteniendo características (métodos y atributos) similares a los ya existentes.
Que es Modularidad?
se denomina Modularidad a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes.Estos módulos que se puedan compilar por separado, pero que tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la Modularidad de diversas formas.
Que es Polimorfismo?
comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.
Que es sobrecarga?
la sobrecarga se refiere a la posibilidad de tener dos o más funciones con el mismo nombre pero funcionalidad diferente. Es decir, dos o más funciones con el mismo nombre realizan acciones diferentes. El compilador usará una u otra dependiendo de los parámetros usados. A esto se llama también sobrecarga de funciones.
También existe la sobrecarga de operadores que al igual que con la sobrecarga de funciones se le da más de una implementación a un operador.
Sobrecarga es la capacidad de un lenguaje de programación, que permite nombrar con el mismo identificador diferentes variables u operaciones
El mismo método dentro de una clase permite hacer cosas distintas en función de los parámetrosJava no permite al programador implementar sus propios operadores sobrecargados, pero sí utilizar los predefinidos como el +. • C++, por el contrario si permite hacerlo
En otras palabras, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo
Pasos para la Definición de un Caso de Uso:
El coste de una buena recogida de requisitos y análisis del sistema a desarrollar es menor comparado con el coste resultante de tener requisitos pobres, es decir, el coste de reparar productos deficientes o de poca calidad, el coste de los proyectos cancelados y el coste de haber perdido la oportunidad de tener el producto correcto en el momento correcto.
El fundamento básico de cualquier software recae sobre su proceso de ingeniería de requisitos. El éxito o fallo del software depende casi siempre de cómo de bien se hayan capturado, entendido y usado los requisitos como base para el desarrollo. La ingeniería de requisitos es la fase de la ingeniería del software donde se definen las propiedades y la estructura del software. La ingeniería de requisitos comprende el desarrollo y gestión de requisitos.
-
El desarrollo de requisitos implica entender los requisitos de negocio, identificar los requisitos de usuario y trasladar los requisitos de usuario y de negocio a requisitos de sistema/software.
-
OBTENCIÓN DE REQUISITOS: BUSQUEDA DE REQUISITOS
DEFINICIÓN DE REQUISITOS: ESCRIBIR REQUISITOS
VERIFICAR REQUISITOSREVISIÓN: PUERTAS DE CALIDAD
DEFINICIÓN DE REQUISITOS
Conseguir que los requisitos estén claramente definidos puede ser difícil. Para ello es importante:
Definir los requisitos teniendo en cuenta la perspectiva del usuario
Reutilizar requisitos, revisando proyectos ya finalizados para ver si contienen material potencialmente reutilizable. La ventaja de esta reusabilidad es que, una vez que un requisito ha sido especificado satisfactoriamente para un producto y que el producto ha tenido éxito, el requisito no tendrá que volverse a inventar, podrá ser utilizado las veces que se desee.
Documentar los requisitos de la forma correcta. Aunque escribir los requisitos puede parecer una tarea tediosa, es la única manera de asegurar que la esencia de los requisitos ha sido capturada correctamente, y que esto pueda ser probado.
IMPACTO DE ERRORES EN LA ETAPA DE REQUERIMIENTOS
REQUERIMIENTOS FUNCIONALES
Requerimientos No Funcionales: Tipos Administración de Requerimientos
Que es Extensión?
Relación <<extend>> Un caso de uso extiende a otro cuando sin alterar a este, se incorpora su funcionalidad como parte integral del primero. Se denota con una relación que apunta del caso extendido al caso base y la conexión se hace o bien al principio del flujo de eventos principal del caso base o en alguno de los puntos de extensión que este haya definido.La notación gráfica es la siguiente:
Que es sobrecarga?
la sobrecarga se refiere a la posibilidad de tener dos o más funciones con el mismo nombre pero funcionalidad diferente. Es decir, dos o más funciones con el mismo nombre realizan acciones diferentes. El compilador usará una u otra dependiendo de los parámetros usados. A esto se llama también sobrecarga de funciones.
También existe la sobrecarga de operadores que al igual que con la sobrecarga de funciones se le da más de una implementación a un operador.
Sobrecarga es la capacidad de un lenguaje de programación, que permite nombrar con el mismo identificador diferentes variables u operaciones
El mismo método dentro de una clase permite hacer cosas distintas en función de los parámetrosJava no permite al programador implementar sus propios operadores sobrecargados, pero sí utilizar los predefinidos como el +. • C++, por el contrario si permite hacerlo
UML y Conceptos bàsicos de POO
MANADA SISTEM
Caso de uso
En ingeniería del software, un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. Normalmente, en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso.En otras palabras, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo
Un poco de Historia en la programación
En 1986, Ivar Jacobson, importante contribuyente al desarrollo de los modelos de UML y proceso unificado, creó el concepto de caso de uso. Se han realizado muchas mejoras al concepto que se estableció entonces, pero probablemente la más influyente y significativa, en términos de definición del término caso de uso, fue la de Alistair Cockburn en el libro Escribir casos de uso efectivos publicado en el año 2000.
Durante los años 1990 los casos de uso se convirtieron en una de las prácticas más comunes para la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la programación orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.
Definiciones básicas
Actores
Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a todos los sistemas externos, además de entidades abstractas, como el tiempo.
En el caso de los seres humanos se pueden ver a los actores como definiciones de rol, por lo que un mismo individuo puede corresponder a uno o más Actores. Suele suceder sin embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente encontrar que nuestros sistemas deben efectuar operaciones automáticas en determinados momentos; y siendo esto un requisito funcional obvio, resulta de interés desarrollar alguna forma de capturar dicho requisito en el modelo de caso de uso final.
Tipos de relaciones
- ``comunica (<<communicates>>): Relación (asociación) entre un actor y un caso de uso que denota la participación del actor en dicho caso de uso.
- ``usa ( <<uses>>) (o <<include>> en la nueva versión de UML): Relación de dependencia entre dos casos de uso que denota la inclusión del comportamiento de un escenario en otro.
- ``extiende (<< extends>>): Relación de dependencia entre dos casos de uso que denota que un caso de uso es una especialización de otro. Por ejemplo, podría tenerse un caso de uso que extienda la forma de pedir azúcar, para que permita escoger el tipo de azúcar (normal, dietético o moreno) y además la cantidad en las unidades adecuadas (cucharadas o bolsas). Un posible diagrama se muestra en la figura
Se utiliza una relación de tipo <<extends>> entre casos de uso cuando nos encontramos con un caso de uso similar a otro pero que hace algo más que éste (variante). Por contra, utilizaremos una relación tipo << uses>> cuando nos encontramos con una parte de comportamiento similar en dos casos de uso y no queremos repetir la descripción de dicho comportamiento común.
En una relación << extends>>, un actor que lleve a cabo el caso de uso base puede realizar o no sus extensiones. Mientras, en una relación <<include>> el actor que realiza el caso de uso base también realiza el caso de uso incluido.
En general utilizaremos <<extends>> cuando se presenta una variación del comportamiento normal, y <<include>> cuando se repite un comportamiento en dos casos de uso y queremos evitar dicha repetición.
Por último en un diagrama de casos de uso, además de las relaciones entre casos de uso y actor (asociaciones) y las dependencias entre casos de uso (<<include>> y <<extends>>), pueden existir relaciones de herencia ya sea entre casos de uso o entre actores.
Llamamos modelo de casos de uso a la combinación de casos de uso y sus correspondientes diagramas. Los modelos de casos de uso se suelen acompañar por un glosario que describe la terminología utilizada. El glosario y el modelo de casos de uso son importantes puntos de partida para el desarrollo de los diagramas de clases.
Por último se debe tener en cuenta, que aunque cada caso de uso puede llevar a diferentes realizaciones, es importante reflejar en cada representación el motivo que nos ha llevado a descartarla, si es el caso.
Pasos para la Definición de un Caso de Uso:
- ID
- NOMBRE
- REFERENCIAS CRUZADAS
- CREADO POR
- ULTIMA ACTUALIZACION POR
- FECHA DE CREACION
- FECHA DE ULTIMA ACTUALIZACION
- ACTORES
- DESCRIPCION
- TRIGGER
- PRE-CONDICION
- POST-CONDICION
- FLUJO NORMAL
- FLUJOS ALTERNATIVOS
- INCLUDES
- FRECUENCIA DE USO
- REGLAS DE NEGOCIO
- REQUERIMIENTOS ESPECIALES
- NOTAS Y ASUNTO
Normas de aplicación
Los casos de uso evitan típicamente la jerga técnica, prefiriendo la lengua del usuario final o del experto del campo del saber al que se va a aplicar. Los casos del uso son a menudo elaborados en colaboración por los analistas de requerimientos y los clientes.
Cada caso de uso se centra en describir cómo alcanzar una única meta o tarea de negocio. Desde una perspectiva tradicional de la ingeniería de software, un caso de uso describe una característica del sistema. Para la mayoría de proyectos de software, esto significa que quizás a veces es necesario especificar diez o centenares de casos de uso para definir completamente el nuevo sistema. El grado de la formalidad de un proyecto particular del software y de la etapa del proyecto influenciará el nivel del detalle requerido en cada caso de uso.
Los casos de uso pretenden ser herramientas simples para describir el comportamiento del software o de los sistemas. Un caso de uso contiene una descripción textual de todas las maneras que los actores previstos podrían trabajar con el software o el sistema. Los casos de uso no describen ninguna funcionalidad interna (oculta al exterior) del sistema, ni explican cómo se implementará. Simplemente muestran los pasos que el actor sigue para realizar una tarea.
Un caso de uso debe:
- describir una tarea del negocio que sirva a una meta de negocio
- tener un nivel apropiado del detalle
- ser bastante sencillo como que un desarrollador lo elabore en un único lanzamiento
Situaciones que pueden darse:
- Un actor se comunica con un caso de uso (si se trata de un actor primario la comunicación la iniciará el actor, en cambio si es secundario, el sistema será el que inicie la comunicación).
- Un caso de uso extiende otro caso de uso.
- Un caso de uso utiliza otro caso de uso.
Ventajas
La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el actor (su usuario) al hacer uso del sistema.
Como técnica de extracción de requerimiento permite que el analista se centre en las necesidades del usuario, qué espera éste lograr al utilizar el sistema, evitando que la gente especializada en informática dirija la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos.
A su vez, durante la extracción (elicitation en inglés), el analista se concentra en las tareas centrales del usuario describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego la priorización del requerimiento.
Limitaciones
Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero no establecen completamente los requisitos funcionales ni permiten determinar los requisitos no funcionales. Los casos de uso deben complementarse con información adicional como reglas de negocio, requisitos no funcionales, diccionario de datos que complementen los requerimientos del sistema. Sin embargo la ingeniería del funcionamiento especifica que cada caso crítico del uso debe tener un requisito no funcional centrado en el funcionamiento asociado.
SISTEMAS DE GESTION DE REQUISITOS
DEFINICION DE REQUISITOS
-CONDICION O CAPACIDAD QUE NECESITA EL USUARIO PARA RESOLVER UN PROBLEMA O ALCANZAR UN OBJETIVO.
- CONDICION O CAPACIDAD QUE DEBE SASTIFACER O POSEER UN SISTEMA O UN COMPONENTE DE UN SISTMA PARA SATISFACER UN CONTRATO,UN STANDART,UNA ESPECIFICACION U OTRO DOCUMENTO FORMAMENTE IMPUESTO.
-REPRESENATACION DOCUMENTADA DE UNA CONDICON O CAPACIDAD COMO LSA EXPRESADAS ANTERIORMENTE.
¿Por qué necesitamos requisitos?
El coste de una buena recogida de requisitos y análisis del sistema a desarrollar es menor comparado con el coste resultante de tener requisitos pobres, es decir, el coste de reparar productos deficientes o de poca calidad, el coste de los proyectos cancelados y el coste de haber perdido la oportunidad de tener el producto correcto en el momento correcto.
El fundamento básico de cualquier software recae sobre su proceso de ingeniería de requisitos. El éxito o fallo del software depende casi siempre de cómo de bien se hayan capturado, entendido y usado los requisitos como base para el desarrollo. La ingeniería de requisitos es la fase de la ingeniería del software donde se definen las propiedades y la estructura del software. La ingeniería de requisitos comprende el desarrollo y gestión de requisitos.
-
El desarrollo de requisitos implica entender los requisitos de negocio, identificar los requisitos de usuario y trasladar los requisitos de usuario y de negocio a requisitos de sistema/software.
-
La gestión de requisitos implica gestionar los cambios de requisitos y mantener la consistencia entre los requisitos y otros productos de trabajo del proyecto
.
¿Qué es un requisito?
Un requisito es algo que el producto debe hacer o una característica que debe tener. Un requisito existe por el tipo de demanda que tiene el producto o porque el cliente quiere que el requisito sea parte del producto entregado. La tarea de todo analista de requisitos es hablar con la gente, entenderla, escuchar lo que dicen y también lo que no dicen, para entender lo que necesitan.
Tipos de requisitos
Descripción:
- Requisitos de negocio Dan una descripción a alto nivel de lo que elsistema debe hacer. Representan: los objetivos, la base del negocio, estrategias, visión, alcance y el valor esperado del desarrollo del software
- Requisitos de usuarioSon una descripción de las tareas que el sistema ha de ejecutar cuando el usuario opera con él.Describen la funcionalidad necesaria para satisfacer tareas específicas, necesidades operacionales y grupos de usuarios.
- Requisitos del sistema/softwareDefinen las funcionalidades y características que debe tener el sistema para satisfacer tanto los requisitos de negocio como los de usuario.Van a servir como base para llevar a cabo la arquitectura, diseño y planes de pruebas del sistema
- RestriccionesSon condiciones que limitan las elecciones disponibles al diseñador o programador. Pueden ser restricciones del propio proyecto o del diseño del producto.
OBTENCIÓN DE REQUISITOS: BUSQUEDA DE REQUISITOS
DEFINICIÓN DE REQUISITOS: ESCRIBIR REQUISITOS
VERIFICAR REQUISITOSREVISIÓN: PUERTAS DE CALIDAD
REVISIÓN REQUISITOS:PRIORIZACION
DEFINICIÓN DE REQUISITOS
Conseguir que los requisitos estén claramente definidos puede ser difícil. Para ello es importante:
Definir los requisitos teniendo en cuenta la perspectiva del usuario
Reutilizar requisitos, revisando proyectos ya finalizados para ver si contienen material potencialmente reutilizable. La ventaja de esta reusabilidad es que, una vez que un requisito ha sido especificado satisfactoriamente para un producto y que el producto ha tenido éxito, el requisito no tendrá que volverse a inventar, podrá ser utilizado las veces que se desee.
Documentar los requisitos de la forma correcta. Aunque escribir los requisitos puede parecer una tarea tediosa, es la única manera de asegurar que la esencia de los requisitos ha sido capturada correctamente, y que esto pueda ser probado.
IMPACTO DE ERRORES EN LA ETAPA DE REQUERIMIENTOS
- EL SOFTWARE RESULTANTE PUEDE NO SATISFACER A LOS USUSARIOS
- PUEDEN CAUSAR DESACUERDOS ENTRE CLIENTE S Y DESARROLLADORES
REQUERIMIENTOS FUNCIONALES
- Relacionados con la descripción delcomportamiento fundamental de los componentes del software.
- Las funciones son especificadas en términos de entradas, procesos y salidas.
Requerimientos funcionales: Ejemplos
El sistema deberá permitir localizar un cliente para registrarle
el cobro, presionando un botón que le permita buscar por el
nombre del cliente y el identificador del cliente. (incluye
detalles de implementación).
el cobro, presionando un botón que le permita buscar por el
nombre del cliente y el identificador del cliente. (incluye
detalles de implementación).
Importancia
- Juegan un papel crucial en el diseño y desarrollo del sistema de información.
- Pueden ser a veces mas críticos que los funcionales. Una
falla en un requerimiento no funcional podría inutilizar el
sistema.
Requerimientos No Funcionales: Tipos Administración de Requerimientos
Dificultades Asociadas a los Requerimientos
No Funcionales
Administración de Requerimientos
- No hay reglas ni lineamientos para determinar cuando
- se obtuvo una solución óptima.
- Tiene buenas y malas soluciones, no soluciones correctas e incorrectas.
- Requerimientos del producto:especifican el comportamiento del producto, como por ejemplo la velocidad de ejecución o la tasa de fallas.
- Requerimientos organizacionales:se derivan de las políticas y procedimientos existentes en la organización del cliente.
- Requerimientos externos:derivan de los factores externos al sistema y de su proceso de desarrollo, como por ejemplo los requerimientos legales.
