“La parte más dura en la construcción de un sistema software es decidir cómo construirlo…Ninguna parte del trabajo mutila el resultado del sistema si está hecho mal. Ninguna parte es más dificultosa para rectificarlo después”
La ingeniería de requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando necesidades, confirmando su viabilidad, negociando una solución razonable, especificando la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transformen en un sistema operacional.
Los requerimientos para un sistema de software determinan lo que hará el sistema y definen las restricciones de su operación e implementación.
El proceso de ingeniería de requisitos puede ser descrito en 5 pasos distintos: identificación de requisitos, Análisis de requisitos y negociación, Especificación de requisitos, Modelizado del
IDENTIFICACION DE REQUISITOS
Christel y Kang identifican una serie de problemas que nos ayudan a comprender por qué la obtención de requisitos es costosa.
• Problemas de alcance. El límite del sistema está mal definido o los detalles técnicos innecesarios, que han sido aportados por los clientes/usuarios, pueden confundir más que clarificar los objetivos del sistema.
• Problemas de comprensión. Los clientes no están completamente seguros de lo que necesitan, tienen una pobre comprensión de las capacidades y limitaciones de su entorno de computación, no existe un total entendimiento del problema, etc.
• Problemas de volatilidad. Los requisitos cambian con el tiempo.
Para ayudar a solucionar estos problemas, los ingenieros de sistemas deben aproximarse de una manera organizada a través de reuniones para definir requisitos. El resultado alcanzado como consecuencia de la identificación de requisitos variará dependiendo del tamaño del sistema o producto a construir.
ANÁLISIS Y NEGOCIACIÓN DE REQUISITOS
Una vez recopilados los requisitos, el producto obtenido configura la base del análisis de requisitos. Los requisitos se agrupan por categorías y se organizan en subconjuntos, se estudia cada requisito en relación con el resto, se examinan los requisitos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades de los clientes/usuarios.
Es corriente en clientes y usuarios solicitar más de lo que puede realizarse, consumiendo recursos de negocios limitados. También es relativamente común en clientes y usuarios el proponer requisitos contradictorios, argumentando que se versión es “esencial por necesidades especiales”.
El ingeniero del sistema debe resolver estos conflictos a través de un proceso de negociación. Los clientes, usuarios y el resto de intervinientes deberán clasificar sus requisitos y discutir los posibles conflictos según su prioridad. Los riesgos asociados con cada requisito serán identificados y analizados. Se efectúan estimaciones del esfuerzo de desarrollo que se utilizan para valorar el impacto de cada requisito en el costo del proyecto y en el plazo de entrega. Utilizando un procedimiento iterativo, se irán eliminando requisitos, se irán combinando y/o modificando para conseguir satisfacer los objetivos planteados.
ESPECIFICACION DE REQUERIMIENTOS
El termino requerimiento no se utiliza de forma consistente en la industria del software. En algunos casos, un requerimiento se visualiza como una declaración abstracta de alto nivel de un servicio que debe proveer el sistema o como una restricción de éste. Por otro lado, es una definición matemática detallada y formal de una función del sistema
REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES
A menudo los requerimientos de sistemas de software se clasifican en funcionales y no funcionales, o como requerimientos del dominio.
Requerimientos funcionales
Son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.
Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera que éste provea. 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.
Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de éste e incrementando el costo.
En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. La compleción significa que todos los servicios solicitados por el usuario están definidos. La consistencia significa que los requerimientos no tienen definiciones contradictorias. En la práctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de consistencia y compleción. La razón de esto se debe parcialmente a la complejidad inherente del sistema y parcialmente a que los diferentes puntos de vista tienen necesidades inconsistentes. Estas inconsistencias son obvias cuando los requerimientos se especifican por primera vez. Los problemas emergen después de un análisis profundo. Una vez que éstos se hayan descubierto en las diferentes revisiones o en las fases posteriores del ciclo de vida, se deben corregir en el documento de requerimientos.
Requerimientos no funcionales
Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc.
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 la interface del sistema.
Muchos requerimientos no funcionales se refieren al sistema como un todo más que a rasgos particulares del mismo. Esto significa que a menudo con más críticos que los requerimientos funcionales particulares. Mientras que el incumplimiento de este último degradará el sistema, una falla en un requerimiento no funcional del sistema lo inutiliza.
Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con otros sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las políticas de privacidad, etcétera.
Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.
• Requerimientos del producto. Especifican el comportamiento del producto; como los requerimientos de desempeño en la rapidez de ejecución del sistema y cuánta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad.
• Requerimientos organizacionales. Se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador: estándares en los procesos que deben utilizarse; requerimientos de implementación como los lenguajes de programación o el método de diseño a utilizar, y los requerimientos de entrega que especifican cuándo se entregará el producto y su documentación.
• Requerimientos externos. Se derivan de los factores externos al sistema y de su proceso de desarrollo. Incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema interactúa con los otros sistemas de la organización; los requerimientos legales que deben seguirse para asegurar que el sistema opere dentro de la ley, y los requerimientos éticos. Estos últimos son impuestos al sistema para asegurar que será aceptado por el usuario y por el público en general.
Un problema común con los requerimientos no funcionales es que algunas veces son difíciles de verificar. Se redactan para reflejar las metas generales del usuario, como la facilidad de uso, la capacidad del sistema para recuperarse de las fallas o la respuesta rápida al usuario. Estos requerimientos causan problemas a los desarrolladores del sistema puesto que dejan abierta la posibilidad a la interpretación, lo que provoca discusiones subsecuentes una vez que el sistema se entregue.
De forma ideal, los requerimientos no funcionales no se deben expresar de manera cuantitativa utilizando métricas que se puedan probar de forma objetiva.
En la práctica, la especificación cuantitativa de requerimientos es difícil. A los clientes no les es posible traducir sus metas en requerimientos cuantitativos; para algunas de éstas, como las de mantenimiento, no existen métricas que se puedan utilizar; el costo de verificar de forma objetiva los requerimientos no funcionales cuantitativos es muy alto.
En principio, los requerimientos funcionales y no funcionales se diferencian en el documento de requerimientos. En la práctica, esto es difícil. Si un requerimiento no funcional se declara de forma separada a los funcionales, algunas veces es difícil ver la relación entre ellos. Si se declaran con los requerimientos funcionales, es difícil separar las condiciones funcionales y no funcionales e identificar los requerimientos que se refieren al sistema como un todo. Se debe hallar un balance apropiado que dependa del tipo de sistema a especificar. Sin embargo, los requerimientos que claramente se refieren a las propiedades emergentes del sistema se deben resaltar. Esto se hace colocándolos en una sección aparte o diferenciándolos, de alguna forma, de los otros requerimientos del sistema.
Requerimientos del dominio
Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características de ese dominio. Éstos pueden ser funcionales o no funcionales.
Se derivan del dominio del sistema más que de las necesidades especificas 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.
REQUERIMIENTOS DEL USUARIO Y DEL SISTEMA
Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos son resultado de no hacer una clara separación entre los diferentes niveles de descripción. Esto se hace utilizando requerimientos del usuario para determinar los requisitos abstractos de alto nivel, y requisitos del sistema, para designar la descripción detallada de lo que el sistema debe hacer. De igual forma que en estos dos niveles de detalle, se puede producir una descripción más detallada para establecer un puente entre la ingeniería de requerimientos y las actividades de diseño. Los requerimientos del usuario, los del sistema y la especificación del diseño de software se definen de la siguiente manera:
Requerimientos del usuario
Son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema provea y de las restricciones bajo las cuales debe operar.
Describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento técnico detallado. Únicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las características de diseño del sistema. Por consiguiente, los requerimientos del usuario no se deben definir utilizando un modelo de implementación. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos.
Sin embargo, pueden surgir diversos problemas cuando se redactan en lenguaje natural: falta de claridad, confusión de requerimientos y conjunción de requerimientos.
Los requerimientos del sistema
Establecen con detalle los servicios y restricciones del sistema. El documento de requerimientos del sistema, algunas veces denominado especificación funcional, debe ser preciso. Éste sirve como un contrato entre el comprador del sistema y el desarrollador del software.
Son descripciones más detalladas de los requerimientos del usuario. Sirven como base para definir el contrato de la especificación del sistema y, por lo tanto, debe ser una especificación completa y consistente del sistema. Son utilizados por los ingenieros de software como el punto de partida para el diseño del sistema.
La especificación de requerimientos del sistema incluye diferentes modelos del sistema como el de objetos o el de flujo de datos.
En principio, los requerimientos del sistema deberán establecer lo que éste hará y no la manera en que se implementará. Sin embargo, en el nivel de detalle requerido para especificar el sistema completamente, es casi imposible excluir toda la información de diseño.
Una especificación del diseño del software
Es una descripción abstracta del diseño del software, que es una base para un diseño e implementación detallados; agrega detalle a la especificación de requerimientos del sistema.
EL DOCUMENTO DE REQUERIMIENTOS DEL SOFTWARE
Éste es la declaración oficial de qué es lo que requieren los desarrolladores del sistema. Incluye tanto los requerimientos del usuario para el sistema como una especificación detallada de los requerimientos del sistema. En algunos casos, los dos tipos de requerimientos se integran en una única descripción. En otros, los del usuario se definen en una introducción de la especificación de los del sistema. Si existe un gran numero de requerimientos, los detalles de los requerimientos del sistema se pueden presentar como documentos separados.
El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los administradores principales de la organización, quienes pagan por el sistema, hasta los ingenieros responsables del software.
Una gran variedad de organizaciones han definido estándares para los documentos de requerimientos.
El IEEE sugiere la siguiente estructura para los documentos de requerimientos.
1. Introducción
• propósito del documento de requerimientos
• Alcance del producto
• Definiciones, acrónimos y abreviaturas
• Referencias • Resumen del resto del documento
2. Descripción general
• Perspectiva del producto
• Funciones del producto
• características del usuario
• Restricciones generales
• Suposiciones y dependencias
3. Requerimientos específicos. Cubren los requerimientos funcionales, no funcionales y de interfaz. Obviamente, ésta es la parte más sustancial del documento, pero debido a la amplia variabilidad en la práctica organizacional, no es apropiado definir una estructura estándar para esta sección. Los requerimientos pueden documentar las interfaces externas, describir la funcionalidad y el desempeño del sistema, especificar los requerimientos lógicos de la base de datos, las restricciones de diseño, las propiedades emergentes del sistema y las características de calidad.
4. Apéndices
5. Índice
Aunque el estándar IEEE no es ideal, contiene una buena ayuda de cómo tratar los requerimientos y evitar problemas. Es muy general para que pueda ser estándar de una organización. Sin embargo, se puede transformar y adaptar para definir un estándar que se ajuste a las necesidades de una organización en particular.
Por supuesto, la información que se incluya en un documento de requerimientos debe depender del tipo de software a desarrollar y del enfoque de desarrollo que se utilice.
MODELADO DEL SISTEMA
Es importante evaluar los componentes del sistema y sus relaciones entre sí, determinar cómo están reflejados los requisitos, y valorar como se ha concebido la “estética” en el sistema.
VALIDACIÓN DE REQUISITOS
El resultado del trabajo realizado es una consecuencia de la ingeniería de requisitos (especificación del sistema e información relacionada) y es evaluada su calidad en la fase de validación. La validación de requisitos examina las especificaciones para asegurar que todos los requisitos del sistema han sido establecidos sin ambigüedad, sin inconsistencias, sin omisiones, que los errores detectados hayan sido corregidos, y que el resultado del trabajo se ajusta a los estándares establecidos para el proceso, el proyecto y el producto.
GESTIÓN DE REQUISITOS
Es un conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento.
FACTORES EN LA CALIDAD DEL SOFTWARE
La construcción de software de calidad requiere el cumplimiento de numerosas características:
Eficiencia
La eficiencia del software es su capacidad para hacer un buen uso de los recursos que manipula.
Transportabilidad (portabilidad)
La transportabilidad es la facilidad con la que un software puede ser transportado sobre diferentes sistemas físicos o lógicos.
Verificabilidad
La verificabilidad es facilidad de verificación de un software; es su capacidad para soportar los procedimientos de validación y de aceptar juegos de test o ensayo de programas. Integridad
La integridad es la capacidad de un software para proteger sus propios componentes contra los procesos que no tengan derecho de acceso.
Fácil de utilizar
Un software es fácil de utilizar si se puede comunicar con él de manera cómoda.
Corrección
Capacidad de los productos software de realizar exactamente las tareas definidas por su especificación.
Robustez
Capacidad de los productos software de funcionar incluso en situaciones anormales.
Extensibilidad
Facilidad que tienen los productos de adaptarse a cambios en su especificación. Existen dos principios fundamentales para conseguir esto: diseño simple y descentralización.
Reutilización
Capacidad de los productos para ser reutilizados, en su totalidad o en parte, en nuevas aplicaciones.
Compatibilidad
Facilidad de los productos para ser combinados con otros.
Competencias Digitales (Tic’s Basicas) a practicar con este TEMA:
- Usar (click en )www.Google.com para buscar y localizar UN material academico apropiado y que se pueda recomendar para el tema, ver VIDEO BUSQUEDAS abajo en esta pagina.
- En el post ( o tema ) apropiado en el Libro de Blogger, pegar el material localizado y que se recomienda para este tema, ver VIDEO BLOGGER abajo en esta pagina.
pd: Recordar incluir la fuente del tema usando el formato de citacion apropiado, ver VIDEO WIKIPEDIA abajo en esta pagina.
- En el editor de Blogger usar colores para destacar los parrafos mas importantes y usar subrayados para las citas mas relevantes.
- En el post ( o tema ) apropiado en el libro en Blogger, para incluir ecuaciones o notacion matematica se debera usar el icono del editor de Blogger IMAGE y construir esta notacion matematica con imagenes Latex, ver VIDEO LATEX ABAJO.
- Construir al final y despues de la fuente del material, un breve resumen ( no mas de 2–3 parrafos) explicando palabras propias el contenido del tema.
pd: Se pueden usar alguna de las citas que encontradas dentro del tema, solo recordar encerrarla entre comillas.
pd: Se pueden usar tambien cambios en fonts para darle mas visibilidad, consistencia y relevancia al resumen del tema.
- PUNTOS EXTRAS Si se usa una segunda fuente valiosa de informacion y recordar encadenar los dos materiales mediante uno o dos parrafos apropiados.
- Enviar a el maestro o compañeros un correo electronico que incluya la liga a el tema en blogger para revision, recomendacion, sugerencias y evaluacion, ver VIDEO LIGAS GMAIL abajo.
- Sacar una cuenta (click en)http://docs.google.com, usando el correo de Gmail y tratar de conseguir el mismo usuario que se construyo en Gmail y Blogger ver VIDEO GOOGLE DOCS abajo en esta pagina.
pd: Si ya se tiene una cuenta ignorar esta competencia digital.
pd: Google Docs es el equivalente a OFFICE pero con la caracteristica que todos sus componentes ( procesador de palabras, presentacion electronica y hoja de calculo) estan completamente en internet, es decir todos los archivos o material estaran en linea, seguros y siempre disponibles, ademas de que se pueden trabajarlos desde cualquier pc, ya sea la personal, la del laboratorio de la escuela o la de un lugar publico como la biblioteca o un cafe internet.
- Construir una Presentacion Electronica ( usando muy pocos slides) del tema en GOOGLE DOCS e incrustrarla en el tema de bloger ver VIDEO GOOGLE DOCS en esta pagina abajo.
pd: Recordar que una presentacion electronica, es solamente un resumen muy condensado del tema ( o mapa o guia mental ), que ayuda a recordar los elementos y conceptos mas basicos del tema, cuando se estan exponiendo frente a un grupo.
pd: No olvidar incluir un primer slide con el titulo de la presentacion electronica, un segundo slide con un indice de la presentacion electronica y un ultimo slide con dos o tres parrafos de conclusiones y bibliografia.
- Buscar en Google Imagenes o www.Flickr.com o www.PhotoBucket.com una galeria de fotos o de imagenes apropiadas al tema actual,
- Para los casos de Photobucket y Flicker, ambos sitios proporcionan ligas a sus imagenes y tambien objetos (los recuerdan??), que se pueden incluir en el tema del libro apropiado en Blogger.
pd: para estos sitios deberan obtener una cuenta usando el correo de gmail y de preferencia obtener el mismo usario que se ha venido manejando a lo largo del curso.
pd: Tratar de usar resoluciones y tamaños de imagenes chicos o medianos, recordar que todo este material termina en el post del tema en Blogger y esa pagina no tiene mucho espacio para desplegar fotos o imagenes.
pd: El formato apropiado para fotos o imagenes es JPG, tratar de no usar otros formatos.
pd: Se puede construir y conseguir esta coleccion o galeria de imagenes con:
1) Usando Google Imagenes, recordar conseguir solo imagenes que tengan permiso de publicacion abierto, no usar imagenes o fotos que tengan derechos reservados.
pd: Estas fotos almacenarlas en un folder en el desktop o escritorio de su computadora y subirlas a el post en blogger usando el icono IMAGE del editor de Blogger.
2) Flickr y Photo Bucket tambien tienen una gran cantidad de imagenes que se pueden usar o mejor dicho enlazar a el tema o post en Blogger.
3) Tambien se puede usar la camaras digitales o las camaras de sus telefonos celulares.
4) Tambien se puede usar el programa o aplicacion llamado Srip32.exe( solo buscar srip32 en google) bajarlo e instalarlo, este programa permite capturar una pantalla de la pc, es decir si se encuentra un sitio con imagenes o incluso texto apropiado o relevante al tema, capturar la pantalla con srip32 y ya se tendra la imagen, ver VIDEO Srip32 abajo.
- Incluir al menos una imagen de cada uno de los dos sitios (flickr y Photobucket) en el tema o post que se esta construyendo en Blogger.
- PUNTOS EXTRAS Si se incluyen una galeria completa de imagenes apropiadas desde cualquiera de estos sitios de FLICKR o Photobucket.
- Sacar una cuenta (click en)www.DivShare.com, usando el correo de Gmail y tratar de conseguir el mismo usuario que se consiguio en Gmail y Blogger y Flickr ver VIDEO DIVSHARE abajo en esta pagina.
pd: Si ya se tiene una cuenta ignorar esta competencia digital.
pd: Usar Divshare para almacenar material en audio (MP3) apropiado a el tema ( no usarlo para almacenar material comercial o les suspenden la cuenta)
pd: El material en Audio, con formato MP3 se debera producir usando un microfono en la pc y programas de aplicacion apropiados, llamados editores de audio, un ejemplo de ellos es el SOUND RECORDER que ya viene en Windows, pero se recomienda usar mejor AUDACITY ( solo buscar en google AUDACITY) bajarlo e instalarlo, ver VIDEO AUDACITY abajo.
- Crear al menos dos archivos de audio mp3:
1) El primero de ellos sera la lectura completa de este tema en voz apropiada. ( o aprender a editar con audacity la voz)
2) El segundo de ellos sera un resumen del tema. ( buena voz o editarla con audacity)
3) Ambos archivos subirlos a Div Share (recordor que tienen que ser MP3) y el reproductor que proporciona gratis Div Share, ver VIDEO DIVSHARE abajo e insertarlo en el lugar apropiado del tema que se esta construyendo en Blogger.
4) Ejemplo del reproductor incrustado en una pagina:
- Sacar una cuenta (click en)www.YouTube.com, usando el correo de Gmail y tratar de conseguir el mismo usuario que se consiguio en Gmail y Blogger y Flickr.
pd: Si ya se tiene una cuenta ignorar esta competencia digital.
- Para producir video se pueden usar tres fuentes:
1) Localizar Videos apropiados en Youtube.
2) Usar nuestras camaras digitales o nuestros telefonos celulares para producir video.
3) Producir un video de la propia pantalla de la computadora ( muy similar a lo que se hizo con Srip32) pero usando un programa especializado en video, tal como CAMSTUDIO (click en www.CamStudio.org) bajar e instalar ( no olvidar bajar e instalar el CODEC que esta abajo en el mismo sitio.
3.1) para Usar Camstudio solo recordar que es muy similar a Srip32 Solo que el resultado final es un archivo de video AVI.
- Producir un video de resumen del tema (usar camstudio con el fondo de la pagina con el tema e irlo comentando en voz apropiada)
- Producir un video en vivo con la exposicion del tema ( pueden usar la presentacion electronica de fondo o cualquier otro material, pizarron, filminas, rotafolios, etc.)
- Subir los videos a su cuenta en Youtube e incluirlos o ligarlos en la pagina en Blogger, tambien los pueden subir directamente a BLOGGER ver VIDEO BLOGGER VIDEO abajo.
Saludos y suerte prof Lauro Soto, Ensenada, BC, Mexico.