 |
- ¿Cuánta documentación se requiere?
- ¿Qué recursos materiales, personales o de otro tipo se requieren para construir,
utilizar y mantener el sistema?
- ¿Cuál será el formato de los datos, tanto para la entrada como para la salida?
- ¿Debe controlarse el acceso al sistema o a la información?
Los requerimientos deben ser correctos con esto nos referimos a que tanto el cliente como el desarrollador deben revisarlos para asegurar que no tienen
errores. Otra característica de los requerimientos es que debe ser consistentes con esto nos referimos a que los requerimientos se deben cumplir simultáneamente o no se podrían desarrollar.
Las entrevistas pueden ser de dos tipos:
El estudio de viabilidad no debe requerir más de dos o tres semanas. El resultado de este
estudio es un informe que recomiende si vale o no la pena seguir con la ingeniería de
requerimientos y el proceso de desarrollo del sistema. En el informe se pueden proponer
cambios en el alcance, el presupuesto o sugerir requerimientos adicionales de alto nivel.
La siguiente etapa del proceso de ingeniería de requerimientos es la obtención y análisis de
requerimientos. En esta actividad, los ingenieros de software trabajan con los clientes y los
usuarios finales del sistema para determinar el dominio de la aplicación, qué servicios debe
proporcionar el sistema, el rendimiento requerido del sistema, las
Es un documento que define, de forma completa, precisa y verificable,
los requisitos, el diseño y el comportamiento u otras características, de un sistema o
componente de un sistema.
Para realizar bien el desarrollo de software es esencial tener una especificación completa
de los requerimientos. Independientemente de lo bien diseñado o codificado que esté, un
sistema pobremente especificado decepcionará al usuario y hará fracasar el desarrollo.
La validación de requerimientos sirve para demostrar que éstos realmente definen el
sistema que el cliente desea. Asegura que los requerimientos están completos, son exactos y consistentes. Debe garantizar que lo descrito es lo que el cliente pretende ver en el producto
final. Esta validación es importante porque la detección de errores durante el proceso de
análisis de requerimientos reduce mucho los costos. Si se detecta un cambio en los
requerimientos una vez que el sistema esta hecho, los costos son muy altos, ya que significa
volver a cambiar el diseño, modificar la implementación del sistema y probarlo
nuevamente.
El principal objetivo de lo que se conoce como Ingeniería del Software es producir
software de calidad. El ideal que siempre persigue un informático es que sus programas sean
rápidos fiables, fáciles de usar, legibles, modulares, estructurados, etc. Estas características
describen dos tipos diferentes de cualidades software.
Por un lado estamos considerando propiedades como facilidad de uso y rapidez, que son
detectadas por los usuarios del producto, entendiendo por usuarios no sólo las personas que
interactúan con el producto final, sino aquellas que trabajan en su desarrollo y evolución. Por otro
lado, existen características inherentes al producto que sólo son percibidas por profesionales de
la informática, como modularidad o legibilidad. Esta diferencia en la detección de la ausencia
o presencia de una propiedad en el software nos permite distinguir entre factores de calidad
externos e internos. En el primer grupo podríamos incluir básicamente factores como corrección,
robustez, extensibilidad, reutilización, compatibilidad, transportabilidad, eficiencia, facilidad de
verificación, integridad y facilidad de
Desarrollo de sistemas la unidad básica de
construcción es la función, es decir, modelan a un sistema en términos de conjuntos de
instrucciones que ejecutan una tarea. En otras palabras, las metodologías estructuradas se
enfocan principalmente en la descomposición funcional de un sistema. El objetivo es lograr
una definición completa del sistema en términos de funciones, estableciendo los datos de
entrada y salida correspondientes.
Existen tres herramientas gráficas de modelado, también llamadas artefactos, que sirven
para construir una especificación de los requerimientos del usuario usando una metodología
estructurada, éstas son: los Diagramas de Entidad-Relación (DER), los Diagramas de Flujo
de Datos (DFD) y los Diagramas de Transición de Estados (DET). Cada uno de ellos brinda
una visión diferente del sistema.
Las herramientas gráficas más importantes del análisis estructurado son los Diagramas de
Flujo de Datos (DFD). Un diagrama de flujo de datos (DFD), es una técnica gráfica que
describe el flujo de información y las transformaciones que se aplican a los datos, conforme
se mueven de la entrada a la salida, visualiza a un sistema como una red de procesos
conectados entre sí. Los Diagramas de Flujo de datos son una notación operacional semiformal que ha sido ampliamente adoptada para la especificación de sistemas de
información. Un DFD es independiente del tamaño y de la complejidad del sistema,
consiste en un diagrama en forma de red que representa el flujo de datos y las
transformaciones que se aplican sobre ellos al moverse desde la entrada hasta la salida del
sistema. El DFD se apoya en otras 2 técnicas: Diccionario de Datos, y Especificaciones de
procesos.
El Diccionario de Datos es una lista organizada de todos los datos pertinentes al sistema
con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un
entendimiento común de todas las entradas, salidas, componentes de almacenes y cálculos
intermedios.
Un análisis del dominio de la información puede ser incompleto si solo se considera el
flujo de datos. Cada flecha de un diagrama de flujo de datos representa uno o más elementos de información. Por tanto, el analista debe disponer de algún otro método para
representar el contenido de cada flecha de un DFD.
Sirven para modelar un almacenamiento de datos. En muchos casos, los datos manipulados
por el sistema determinan las acciones que se realizan. Puede ser útil definir los
requerimientos concentrándose en los datos en lugar de las funciones. La abstracción de
datos es una técnica para describir para qué son los datos, en lugar de cuál es su apariencia
o como se denominan.
Para describir los datos se utiliza el diccionario de tipo de datos. La idea central es
categorizar los datos y agrupar los elementos semejantes.
El Modelo Entidad /Relación fue desarrollado por Chen en 1976. Es un modelo muy
utilizado en el campo de diseños de bases de datos. Su principal ventaja es que es traducible
casi automáticamente a un esquema de bases de datos bajo modelo relacional.
El aspecto de datos es más estable que el funcional en la mayoría de los sistemas; también
es mucho más difícil pensar en modelo de datos. La mayor dificultad se presenta en poder
establecer la estructura de los objetos y las relaciones entre los mismos.
