Prueba Ingenieria Del Software

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 7

REQUISITOS 

DEL SOFTWARE Y REQUERIMIENTOS DEL SOFTWARE

Es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un
conjunto de casos de uso que describe todas las interacciones que tendrá los usuarios con el
software.

DIFICULTADES DE REQUISITOS

Los usuarios no tienen claro lo que desean.

Los usuarios no entienden el proceso desarrollo.

Requisitos

Es una de las tareas más importantes en el ciclo de vida del desarrollo de software, puesto que
en ella se determinan los “platos” de la nueva aplicación. En cualquier proyecto software los
requisitos son las necesidades del producto que se debe desarrollar.

Ayudar a los clientes a describir claramente lo que se desea obtener mediante un determinado
software: el cliente debe participar activamente en la especificación de requisitos ya que este
tiene una visión mucho más detallado de los procesos que se llevan a cabo.

Validación de los requisitos

Proceso de confirmación por parte de los usuarios o del cliente de que los requisitos
especificados son validos, consistentes, completos, etc.

Verificación de los requisitos

Proceso de comprobación de que los requisitos realmente cubren las necesidades del cliente.

REQUERIMIENTOS DEL SOFTWARE

Algo se le pide o solicita a alguien.

Características que desea que pase a un sistema o un software

Tareas relacionadas con los requerimientos de un software.

Los requerimientos o requisitos son la pieza fundamental en un proyecto de software, ya que


marcan el punto de partida para actividades de planeación.

LOS REQUISITOS

Son el punto de acuerdo entre el cliente y el ingeniero de software. Este entendimiento es


necesario para poder construir software que satisfaga las necesidades de  nuestros clientes.

CONTEXTO DE SISTEMA

Un sistema de software

Ejemplo: Sistemas operativos, compilador, interpretes, DBMS, entre otros.

Un sistema de hardware-software

Ejemplo: Celulares, controladores de procesos, relojes digitales, GPS, entre otros.

Software de desarrollo
- Ejemplo: Herramientas CASE, conductor de pruebas, entre otros.

Aplicación de software

Ejemplo: Aplicaciones WEB, SIG, SSD, videojuegos, entre otros.

Un sistema de negocios

Se refiere al dominio de aplicación donde un sistema de software o H/S opera

QUÉ DEFINEN LOS REQUERIMIENTOS?

1. Lo que el sistema debe hacer

Las funciones que debe ejecutar.

Los datos que debe capturar y almacenar

La información que debe producir

2. Las interacciones usuarios-sistema y sistema-sistema

3. Las restricciones bajo las cuales el sistema debe operar

La interfaz gráfica usuario-sistema (GUI)

La interfaz de la aplicación con otros sistemas.

La plataforma de operación del sistema.


 

La tecnología de información que debe utilizar el sistema.

4. Los atributos de calidad que el sistema debe satisfacer

Estándar ISO 9126

Importancia de la ingeniería de requisitos en la practica

Es el proceso de desarrollar una especificación de Software. Las especificaciones pretenden


comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. Trata de
los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y
mantener los requisitos para sistemas basados en computadora, de forma sistemática y
repetible.

 
Levantamiento y recolección de requerimientos:

Técnicas más usadas: Método JAD

Método JAD Joint Application Development (JAD), en español Desarrollo Conjunto de


Aplicaciones, es una técnica exploratoria popular que incluye a los usuarios como participantes
activos en el proceso de desarrollo.

La técnica más usada según nuestro criterio es la Técnica de Método JAD, por que permite que
los usuarios dominantes participen con eficacia en los requisitos que modelan el proceso,
cuando los usuarios participan en el proceso del desarrollo de los sistemas, es más probable
percibir un sentido de la propiedad en los resultados, y la ayuda para el nuevo sistema.

JAD:

Es un proceso usado en el área del ciclo de vida de prototipado del Método de Desarrollo de
Sistemas Dinámicos (DSDM) para reunir requerimientos en el desarrollo de nuevos sistemas de
información para una compañía. El proceso JAD también incluye aproches para la mejora en la
participación de los usuarios, agilizar el desarrollo, y mejorar la calidad de las especificaciones.
Consiste en un taller donde los trabajadores del conocimiento y los especialistas en
Tecnologías de Información se reúnen, algunas veces durante varios días, para definir y revisar
los requerimientos de negocio para el sistema. Los asistentes incluyen oficiales de
administración de alto nivel, quienes se aseguran de que el producto provea los reportes y la
información requerida al final. Esto actúa como “un proceso de administración” que permite
que los departamentos de Servicios de Información Corporativa trabajen más eficientemente
con los usuarios en un marco de tiempo más reducido

F.P.A:

(ANÁLISIS DE PUNTOS DE FUNCIÓN)Es un método utilizado en ingeniería del software para


medir el tamaño del software. Fue definida por Allan Albrecht, de IBM, en 1979 y pretende
medir la funcionalidad entregada al usuario independientemente de la tecnología utilizada
para la construcción y explotación del software, y también es útil en cualquiera de las fases de
vida del software, desde el diseño inicial hasta la explotación y mantenimiento.

¿Qué son Requerimientos? 

(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un


objetivo

Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no


funcionales.
Los requerimientos funcionales definen las funciones que el sistema será capaz de
realizar. Describen las transformaciones que el sistema realiza sobre las entradas para
producir salidas. 

Los requerimientos no funcionales tienen que ver con características que de una u otra
forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y
espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de
equipo), mantenimiento, seguridad, portabilidad, estándares, etc. 
Características de los requerimientos 

Las características de un requerimiento son sus propiedades principales. A continuación


se presentan las más importantes.
 
Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el
sistema a construir, y además su capacidad, características físicas o factor de calidad no
pueden ser reemplazados por otras capacidades del producto o del proceso. 
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe
ser simple y clara para aquellos que vayan a consultarlo en un futuro. 
Completo: Un requerimiento está completo si no necesita ampliar detalles en su
redacción, es decir, si se proporciona la información suficiente para su comprensión. 
Consistente: Un requerimiento es consistente si no es contradictorio con otro
requerimiento. 
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. 
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera
que permita hacer uso de los siguientes métodos de verificación: inspección, análisis,
demostración o pruebas. 

Dificultades para definir los requerimientos

• Los requerimientos no son obvios y vienen de muchas fuentes. 


• Son difíciles de expresar en palabras (el lenguaje es ambiguo). 
• Existen muchos tipos de requerimientos y diferentes niveles de detalle. 
• La cantidad de requerimientos en un proyecto puede ser difícil de manejar. 
• Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más
estables que otros. 
• Los requerimientos están relacionados unos con otros, y a su vez se relacionan con
otras partes del proceso. 
• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas. 
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. 
• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para
cada proyecto. 

Ingeniería de Requerimientos vs. Administración de Requerimientos  

El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema
es llamado Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos
(IR) es entregar una especificación de requisitos de software correcta y completa. 
Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de software,
es ellos se basan muchos participantes del proyecto para: 
Planear el proyecto y los recursos que se usarán en él. Los líderes de proyecto usan los
requerimientos como una base para la estimación del esfuerzo necesario en un
proyecto. 
Especificar el tipo de verificaciones que se habrán de realizar al sistema. Por ejemplo:
cuando se esta tratando de alinearse a cierta norma oficial o estándar. 
Planear la estrategia de prueba a la que habrá de ser sometido el sistema. Los
requerimientos son la base sobre la cual se decide si un caso de prueba fue ejecutado
exitosamente por el sistema o no. 
características deben de poseer los requerimientos adecuadamente formulados. 

Los requerimientos deben ser: 

Especificados por escrito. Como todo contrato o acuerdo entre dos partes 
Posibles de probar o verificar. Si un requerimiento no se puede comprobar, entonces
¿cómo sabemos si cumplimos con él o no? 
Descritos como una característica del sistema a entregar. Esto es: que es lo que el
sistema debe de hacer (y no como debe de hacerlo) 
Lo más abstracto y conciso posible. Para evitar malas interpretaciones. 

Fundamentos del Análisis de Requerimientos

Definición: Es el conjunto de técnicas y procedimientos que nos permiten conocer los


elementos necesarios para definir un proyecto de software. 
Es la etapa más crucial del desarrollo de un proyecto de software. 
La IEEE los divide en funcionales y no funcionales: 

Funcionales: Condición o capacidad de un sistema requerida por el usuario para


resolver un problema o alcanzar un objetivo. 

No Funcionales: Condición o capacidad que debe poseer un sistema para satisfacer un


contrato, un estándar, una especificación u otro documento formalmente impuesto. 
Para realizar bien el desarrollo de software es esencial realizar una especificación
completa de los requerimientos de los mismos. Independientemente de lo bien diseñado
o codificado que esté, un programa pobremente especificado decepcionará al usuario y
hará fracasar el desarrollo. 

La tarea de análisis de los requerimientos


El análisis de requerimientos puede dividirse en cuatro áreas: 
1.- Reconocimiento del problema 
2.- Evaluación y síntesis 
3.- Especificación 
4.- Revisión. 

Es un proceso de descubrimiento y refinamiento el análisis de requerimientos facilita al


ingeniero de sistemas especificar la función y comportamiento de los programas, indicar
la interfaz con otros elementos del sistema y establecer las ligaduras de diseño que debe
cumplir el programa. El análisis de requerimientos permite al ingeniero refinar la
asignación de software y representar el dominio de la información que será tratada por
el programa. El análisis de requerimientos de al diseñador la representación de la
información y las funciones que pueden ser traducidas en datos, arquitectura y diseño
procedimental. Finalmente, la especificación de requerimientos suministra al técnico y
al cliente, los medios para valorar la calidad de los programas, una vez que se haya
construido. 

La siguiente es una recomendación de cómo pueden ser clasificados los requerimientos


aunque cada proyecto de software pueda usar sus propias clasificaciones. 
• Requerimientos del "entorno" 
El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar el entorno,
existen cierto tipo de requerimientos que se clasifican en esta categoría por que: 
El sistema usa el entorno y lo necesita como una fuente de los servicios necesarios para
que funcione. Ejemplos del entorno podemos mencionar: sistemas operativos, sistema
de archivos, bases de datos. 
El sistema debe de ser robusto y tolerar los errores que puedan ocurrir en el entorno,
tales como congestión en los dispositivos y errores de entrada de datos, por lo tanto el
entorno se debe de considerar dentro de los requerimientos. 
• Requerimientos "ergonómicos" 
Él mas conocido de los requerimientos ergonómicos es la interfase con el usuario o GUI
(Graphic User Interface). En otras palabras, los requerimientos ergonómicos son la
forma en que el ser humano interactúa con el ser sistema. 
• Requerimientos de Interfase 
La interfase es como interactúa el sistema con el ser humano o con otros sistemas (el
enfoque es prácticamente el opuesto a los requerimientos ergonómicos), La interfase es
la especificación formal de los datos que el sistema recibe o manda al exterior.
Usualmente se especifica el protocolo, el tipo de información, el medio para
comunicarse y el formato de los datos que se van a comunicar. 

* Actividades de la Ingeniería de Requerimientos * 

En el proceso de IR son esenciales diversas actividades. En este documento serán


presentadas, sin embargo, en un proceso de ingeniería de requerimientos efectivo, estas
actividades son aplicadas de manera continua y en orden variado. 
Dependiendo del tamaño del proyecto y del modelo de proceso de software utilizado
para el ciclo de desarrollo, las actividades de la IR varían tanto en número como en
nombres. La tabla #1 muestra algunos ejemplos de las actividades identificadas para
cada proceso. 
A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto
de actividades mostradas en la tabla anterior, podemos identificar y extraer cinco
actividades principales que son: 
• Análisis del Problema 
• Evaluación y Negociación 
• Especificación 
• Validación 
• Evolución 
* Principios de Especificación * 

* Manejo de requerimientos * 

De acuerdo con el "Capability Maturity Model" (CMM), el manejo de requerimientos


involucra: 
"Establecer y mantener un acuerdo con el cliente sobre los requerimientos del proyecto
de software. Este acuerdo son los requerimientos del sistema alojados al software.
Este acuerdo cubre requerimientos técnicos y no técnicos (como fechas de entrega).
"Para lograr el control de los requerimientos, el grupo de requerimientos revisa los
requerimientos antes de que estos sean incorporados al proyecto de software y cada vez
que los requerimientos cambian los planes, productos, y actividades son ajustadas para
quedar en línea con los nuevos requerimientos de software". 
En otras palabras, para obtener el nivel que requiere el CMM en manejo de
requerimientos débenos de tomar en cuenta dos cosas. 
• Que los requerimientos deben de ser revisados (y aprobados) por el grupo de
requerimientos, y no son impuestos por en su totalidad por presiones externas ajenas al
proyecto. 
El requerimiento técnico podrá ser impuesto por el mercado o presiones de la
competencia, pero entonces los requerimientos no técnicos (Calidad, Costo y Tiempo de
entrega) deberán estar especificados de común acuerdo con el grupo de requerimientos
del proyecto de software. 
• Los requerimientos técnicos y no técnicos forman un conjunto entre sí, si cambia uno
forzosamente deberán cambiar los demás. Esto es: más contenido técnico implica o más
costo, o menos calidad o más tiempo estimado de entrega. De modo que los cambios
técnicos deberán ser aprobados por el grupo de requerimientos y este grupo estimará los
impactos en tiempo, costo, calidad. El resultado de la estimación es la entrada a los
líderes del proyecto para decidir si el cambio se acepta o no. 
* REQUERIMIENTOS DEL SISTEMA * 

Los Sistemas de Información por computadora normalmente están integrados por


muchos componentes. En la mayor parte de los casos, es difícil para los analistas
entender todos estos componentes aún mismo tiempo; por lo tanto los investigadores
tienen que comenzar con preguntas de tipo general con relación al propósito del sistema
sus entradas y salidas de los procesos incluidos. 
En los grandes proyectos de sistema varios analistas llevan a cabo una investigación en
forma seccionada que la distribuye entre ellos mismos, de manera que cada uno pueda
trabajar en forma independiente. 
Existen dos estrategias ampliamente utilizadas para determinar los requerimientos de
información. Se clasifican en dos tipos: 
1.- Flujo de Datos. 
2.- Estrategias de Análisis de Decisión para el Conocimiento para los Sistema de
Información. 

* DOCUMENTOS DE REQUERIMIENTOS DEL SOFTWARE* 

Fue la aparición del diseño y la programación estructurada alrededor de los años 60´s la
que dieron cabida al surgimiento del análisis estructurado, ya que existía la necesidad de
utilizar una notación gráfica para representar los datos y los procesos que los
transforman". Es por ello que surgen una serie de temas afines tales como: herramientas
automatizadas (CASE), prototipos, diagramas de entidad-relación etc. 
Índice de Términos relacionados: CASE (Ingeniería de Software auxiliada por
computadora), elaboración de prototipos, símbolos gráficos, diccionarios de datos,
descripciones de procesos y procedimientos, reglas, diagramas de estados, diagramas de
entidad-relación, diagramas de transición de eventos, división de eventos, modelos
esenciales y modelos de implantación. 

También podría gustarte