DESARROLLO DEL SOFTWARE II (unidad I) Analisis y especificacion de requerimientos

1. Análisis y Especificación de Requisitos Ingeniería de Software II por: Prof. Sara Blach

 2.  ¿QUÉ DEFINEN LOS REQUERIMIENTOS? Lo que el sistema debe hacer: Las funciones que debe ejecutar. Los datos que debe capturar y almacenar. La información que debe producir.

 3.  ¿QUE DEFINEN LOS REQUERIMIENTOS? Las interacciones usuarios-sistema y sistema-sistema: La interfaz gráfica usuario-sistema. La interfaz de la aplicación con otros sistemas.

 4.  ¿QUE DEFINEN LOS REQUERIMIENTOS? Las restricciones bajo las cuales el sistema debe operar: La plataforma de operación del sistema. La tecnología de información que debe utilizar el sistema.

 5.  ¿QUE DEFINEN LOS REQUERIMIENTOS? Los atributos de calidad que el sistema debe satisfacer: Estándar ISO 9126 Software Quality Model

 6.  ¿POR QUÉ DETERMINAR REQUERIMIENTOS? El software está integrado por muchos componentes. El costo de cambiar requerimientos crece a medida que avanza el proyecto. (Durante la fase de diseño, durante la fase del diseño detallado, durante la codificación, durante la prueba de unidades, durante la validación, después que el sistema ha sido implantado).

 7.  PROBLEMAS AL DETERMINARREQUERIMIENTOS: El usuario o cliente no siempre sabe lo que quiere del sistema: Al inicio del proyecto, no sabe que esperar del sistema. Los requerimientos suelen surgir a medida que el usuario se familiariza con el sistema.

 8.  PROBLEMAS AL DETERMINARREQUERIMIENTOS: El usuario no tiene tiempo para participar en el proyecto: Evita participar en el proyecto. No esta consiente de la importancia de su participación. No ve el sistema como algo que le pertenece.

 9.  PROBLEMAS AL DETERMINARREQUERIMIENTOS: Problemas de comunicación: El cliente o usuario no entiende el lenguaje informático de los analistas. Los analistas no entienden el lenguaje del dominio de la aplicación.

 10.  PROBLEMAS AL DETERMINARREQUERIMIENTOS: Los requerimientos pueden interpretarse de diferentes maneras: El analista entiende y específica de manera diferente los requerimientos del cliente. El diseñador interpreta de otra manera los requisitos especificados por el analista.

 11.  PROBLEMAS AL DETERMINARREQUERIMIENTOS: Requerimientos mal definidos: No reflejan las necesidades reales de los usuarios del sistema. Son inconsistentes. Son incompletos. No son factibles.

 12.  SOLUCIÓN A LOS PROBLEMAS DE LOSREQUERIMIENTOS: Entender la naturaleza del software: Promueve cambios frecuentes en los requerimientos. Entender el espacio del problema: Modelar el negocio antes de identificar y especificar requerimientos. Utilizar un proceso de desarrollo bien definido y probado.

 13. Utilizar prácticas conocidas (mejores prácticas): Incorporar al cliente en el desarrollo del sistema (activamente). Modelar los requerimientos usando notaciones graficas estandarizadas. Gestionar los requisitos.

Read More

Desarrollo del software II (unidad I) Análisis y requerimientos funcionales y no funcionales existentes

 
Requerimientos de procesos:
requerimientos de procesos son la especificación de los estándares de calidad que se deben utilizar en el proceso, una especificación que el diseño debe producir con una herramienta CASE particular y una descripción del proceso a seguir.
Requerimientos funcionales:
Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no debe hacer.
 Los requerimientos funcionales de un sistema describen lo que el sistema debe hacer. Estos requerimientos dependen del tipo de software que se desarrolle, de los posibles usuarios del software y del enfoque general tomado por la organización al redactar requerimientos. Cuando se expresan como requerimientos del usuario, habitualmente se describen de una forma bastante abstracta. Sin embargo. los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etcétera. Los requerimientos funcionales para un sistema software se pueden expresar de diferentes formas. A continuación se presentan algunos ejemplos de estos requerimientos funcionales para un sistema de biblioteca universitario, denominado LIBSYS, utilizado por estudiantes y personal docente que solicitan libros y documentos de otras bibliotecas.1. El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella. 
2. El sistema deberá proporcionar visores adecuados para que el usuario lea documentos en el almacén de documentos. 

 3. A cada pedido se le deberá asignar un identificador único(ID_PEDIDO), que el usuario podrá copiar al área de almacenamiento permanente de la cuenta. Estos requerimientos funcionales del usuario definen los recursos específicos que el sistema debe proporcionar. Dichos requerimientos se toman del documento de requerimientos del usuario, e ilustran los diferentes niveles de detalle en que se pueden redactar los requerimientos funcionales (contraste los requerimientos l y 3). El sistema LIBSYS es una interfaz única para diferentes bases de datos de artículos. Esto permite a los usuarios descargar copias de artículos publicados en revistas. periódicos y publicaciones científicas. Una descripción más detallada de los requerimientos para el sistema en el cual se basa LIBSYS se puede ver en mi libro con Gerald Kotonya sobre ingeniería de requerimientos (Kontonya y Sommerville, 1998). La impresión en la especificación de requerimientos es la causa de muchos de los problemas de la ingeniería del software. 
Requerimientos no funcionales Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican a características o servicios individuales del sistema.

Los requerimientos no funcionales, como su nombre sugiere, son aquellos requerimientos que no se refieren directamente a las funciones específicas que proporciona el sistema, sino a las propiedades emergentes de éste como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las interfaces del sistema.

Los requerimientos no funcionales rara vez se asocian con características particulares del sistema. Más bien, estos requerimientos especifican o restringen las propiedades emergentes del sistema. como se explicó en el Capítulo 2. Por lo tanto, pueden especificar el rendimiento del sistema, la protección, la disponibilidad, y otras propiedades emergentes. Esto significa que a menudo son más críticos que los requerimientos funcionales particulares. Los usuarios del sistema normalmente pueden encontrar formas de trabajar alrededor de una función del sistema que realmente no cumple sus necesidades. Sin embargo. el incumplimiento de un requerimiento no funcional puede significar que el sistema entero sea inutilizable.
Por ejemplo, si un sistema de vuelo no cumple sus requerimientos de fiabilidad, no se certificará como seguro para el funcionamiento; si un sistema de control de tiempo real no cumple sus requerimientos de rendimiento, las funciones de control no funcionarán correctamente. Los requerimientos no funcionales no sólo se refieren al sistema software a desarrollar. Algunos de estos requerimientos pueden restringir el proceso que se debe utilizar para desarrollar el sistema. Ejemplos de requerimientos de procesos son la especificación de los estándares de calidad que se deben utilizar en el proceso, una especificación que el diseño debe producir con una herramienta CASE particular y una descripción del proceso a seguir.

Los requerimientos no funcionales surgen de las necesidades 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 software o hardware, o a factores externos como regulaciones de seguridad.

1. Requerimientos del producto. Estos requerimientos especifican el comportamiento del producto. Algunos ejemplos son los requerimientos de rendimiento en la rapidez de ejecución del sistema y cuánta memoria se requiere; los requerimientos de fiabilidad que fijan la tasa de fallos para que el sistema sea aceptable; los requerimientos de portabilidad, y los requerimientos de usabilidad.

2. Requerimientos organizacionales. Estos requerimientos se derivan de políticas y procedimientos existentes en la organización del cliente y en la del desarrollador. Algunos ejemplos son los estándares en los procesos que deben utilizarse; los 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.

3. Requerimientos externos. Este gran apartado incluye todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. Éstos pueden incluir los requerimientos de interoperabilidad que definen la manera en que el sistema interactúa con sistemas de otras organizaciones; los requerimientos legislativos que deben seguirse para asegurar que el sistema funcione dentro de la ley. y los requerimientos éticos. Estos últimos son puestos en un sistema para asegurar que será aceptado por sus usuarios y por el público en general.

Estudios de viabilidad: Para todos los sistemas nuevos, el proceso de ingeniería de requerimientos debería empezar con un estudio de viabilidad. La entrada de éste es un conjunto de requerimientos de negocio preliminares, una descripción resumida del sistema y de cómo éste pretende contribuir a los procesos del negocio. Los resultados del estudio de viabilidad deberían ser un informe que recomiende si merece o no la pena seguir con la ingeniería de requerimientos y el proceso de desarrollo del sistema.
 1. Un estudio de viabilidad es un estudio corto y orientado a resolver varias cuestiones:

2. ¿Contribuye el sistema a los objetivos generales de la organización?

3. ¿Se puede implementar el sistema utilizando la tecnología actual y dentro de las restricciones de coste y tiempo?

4. ¿Puede integrarse el sistema con otros sistemas existentes en la organización?
  La cuestión de si el sistema contribuye a los objetivos del negocio es crítica. Si no contribuye a estos objetivos, entonces no tiene un valor real en el negocio. Aunque esto pueda parecer obvio, muchas organizaciones desarrollan sistemas que no contribuyen a sus objetivos porque no tienen una clara declaración de estos objetivos, porque no consiguen definir los requerimientos del negocio para el sistema o porque otros factores políticos u organizacionales influyen en la creación del sistema. Aunque no se trata explícitamente, un estudio de viabilidad debería ser parte de la fase de Inicio del Proceso Unificado de Racionalización.

Llevar a cabo un estudio de viabilidad comprende la evaluación y recopilación de la información, y la redacción de informes. La fase de evaluación de la información identifica la información requerida para contestarlas tres preguntas anteriores. Una vez que dicha información se ha identificado, se debería hablar con las fuentes de información para descubrir las respuestas a estas preguntas. Algunos ejemplos de preguntas posibles son:
 1. ¿Cómo se las arreglaría la organización si no se implementara este sistema?

2. ¿Cuáles son los problemas con los procesos actuales y cómo ayudaría un sistema nuevo

3. a aliviarlos?

4. ¿Cuál es la contribución directa que hará el sistema a los objetivos y requerimientos del negocio?

5. ¿La información se puede obtener y transferir a otros sistemas dela organización?

6. ¿Requiere el sistema tecnología que no se ha utilizado previamente en la organización?
7. ¿A qué debe ayudar el sistema y a qué no necesita ayudar"
  En un estudio de viabilidad, se pueden consultar las fuentes de información, como los jefes de los departamentos donde se utilizará el sistema, los ingenieros de software que están familiarizados con el tipo de sistema propuesto, los expertos en tecnología y los usuarios finales del sistema. Normalmente se debería intentar completar un estudio de viabilidad en dos o tres semanas. Una vez que se tiene la información, se redacta el informe del estudio de viabilidad. Debería hacerse una recomendación sobre si debe continuar o no el desarrollo del sistema.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Read More

Desarollo del software II (unidad I) Reconocimiento del problema

Reconocimiento del Problema:

pasos a seguir para la evaluación de un problema:

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.

La evaluación del problema y la síntesis de la solución es la siguiente área principal de trabajo del análisis. El analista debe evaluar el flujo y estructura de la información, refinar en detalle todas las funciones del programa, establecer las características de la interface del sistema y descubrir las ligaduras del diseño, Cada una de las tareas sirven para descubrir el problema de forma que pueda sintetizarse un enfoque o solución global.

Métodos de Análisis de Requerimientos: Las metodologías de análisis de requerimientos combinan procedimientos sistemáticos con una notación única para analizar los dominios de información y funcional de un problema de software; suministra un conjunto de heurísticas para subdividir el problema y define una forma de representación para las visiones lógicas y físicas.

Las metodologías de análisis de requerimientos facilitan al analista la aplicación de los principios fundamentales del análisis de una manera sistemática. Aunque cada método introduce nueva notación y heurística de análisis, todos los métodos pueden ser evaluados en el contexto de las siguientes características comunes:

1. Mecanismos para el análisis del dominio de la información
2. Método de representación funcional
3. Definición de interfaces
4. Mecanismos para subdividir el problema
5. Soporte de la abstracción
6. Representación de visiones físicas y lógicas

Read More

Inteligencia artificial

La inteligencia artificial (en adelante I.A.) es una de las ciencias más modernas que existen, nace después de la segunda guerra mundial, por el año 1956. El campo de la I.A. está enfocado a no sólo tratar de comprender la estructura del pensamiento humano, del cómo pensamos y decidimos, sino también a construir entidades inteligentes. Esto es un poco complicado porque a día de hoy no se tiene un entendimiento completo de cómo funciona la mente humano y los procesos que dentro se llevan. Debido a esto la I.A. es una ciencia aún no explorada ni en un 20%, es nueva y tiene un gran camino por delante.

Debido al campo de estudio de la I.A., ésta abarca una gran variedad de subcampos y aplicaciones que van desde probar teoremas matemáticos, construir sistemas expertos, resolvedor de problemas de propósito general, implementación de algoritmos de búsqueda y toma de decisiones; en sí cualquier tarea que involucre una parte intelectual, lo que hace a la IA una ciencia universal en todos los sentidos, toma y aporta conocimientos de todas las ciencias.

Los científicos no tienen un conocimiento exacto de cómo trabaja la mente humana, sólo se suponen ciertos aspectos y patrones lo que complica si mencionamos que la IA se esfuerza en construir agentes inteligentes, tema principal y unificador. Podemos definirla entonces como el estudio de agentes inteligentes, los cuáles son entes que reciben percepciones del exterior y en base a éstas producen acciones. Los agentes implementan funciones que estructuran las percepciones y producen resultados.

Read More