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 universitaria,
denominada LIBSYS, utilizada 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.
Para un desarrollador de
sistema 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 deben establecer nuevos
requerimientos y hacer cambios en el sistema. Por supuesto. Esto retrasa la
entrega de éste e incrementa los costes.
Requerimientos
no funcionales
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. 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
Proyecto se refiere a todas las acciones que deben realizarse para cumplir con una necesidad definida dentro de los plazos. Así, ya que el proyecto es una acción temporaria que tiene principio y fin, que utiliza recursos identificados (humanos y materiales) durante su ejecución, y que tiene uncosto, deberá tener recursos presupuestados y una hoja de balance independiente a la de la compañía. "Productos finales" se refiere a los resultados esperados del proyecto.
La dificultad de la gestión de un proyecto radica en gran medida en la cantidad de personas involucradas. De hecho, en contrapartida con los proyectos personales o internos en pequeña escala para los cuales la necesidad y la respuesta para dicha necesidad puede ser provista por la misma persona o por un grupo limitado de personas, en un proyecto en el sentido profesional, la expresión de una necesidad y la satisfacción de esta necesidad generalmente es responsabilidad de diferentes personas.
Así, es necesario asegurarse (para toda la duración del proyecto) que el producto que se está creando cumpla claramente con las expectativas del "cliente". En contraposición con el modelo tradicional comercial ("vendedor"/"comprador") en el que un cliente compra un producto ya fabricado para que cumpla con su necesidad, el proyecto busca crear un producto original que cumpla con una necesidad específica que debe estar claramente expresada. Esta expresión de las necesidades es incluso más difícil ya que generalmente el proyecto no tiene precedentes dentro de la compañía, dado que es una novedad. En forma opuesta, generalmente es difícil resumir soluciones existentes y concentrarse solamente en las necesidades en términos funcionales.
Ejemplo: para realización de un proyecto se deben tener en cuenta muchas factores las cuales van a ayudar a que este proyecto conlleve mas n aya de lo común.
por ejemplo para la realización de un software de contabilidad, debemos tener en cuenta que es lo que nos están pidiendo y desde allí desglosar un mundo de parámetros para plantear una "hipótesis" o un pequeño plano de lo que se va eleborar para esto surgen las preguntas como, cuando , donde para que o con que fin , riesgos que podría tener.
ya después de plantear todo con la cual se podra elaborar el proyecto,se pasa a la getion de anctividades , recolección de papeleo, aleboracion de un sistema para la elaboracion de este,requiesitos, un listado con todo lo que nos esta pidiendo la persona a la cual le estamos realizando el trabajo, mirar minuciosamente que nos sirve y que no nos sierbe.
luego de tener todo esto planteado y organiado daremos paso a la elaboracion del proyecto,para que este proyecto no se cea afectado por un lacso de tiempo deberemos de tener un cronograma que nos facilitara para ver con que tiempo estamos elaborando el programa si si nos esta rindiendo el tiempo instipulado por el cliente o si nos estamos retrasando por alguna rezon, si seestra retrasando el trabajo analizar y mirar ell por que de la situacion y dar una solucion lo mas antes posible
3)MODULO
En programación un módulo es una porción de un programa de computadora. De las varias tareas que debe realizar un programa para cumplir con su función u objetivos, un módulo realizará, comúnmente, una de dichas tareas (o varias, en algún caso).
En general (no necesariamente relacionado con la programación), un módulo recibe como entrada la salida que haya proporcionado otro módulo o los datos de entrada al sistema (programa) si se trata del módulo principal de éste; y proporcionará una salida que, a su vez, podrá ser utilizada como entrada de otro un módulo o bien contribuirá directamente a la salida final del sistema (programa), si se retorna al módulo principal.
Particularmente, en el caso de la programación, los módulos suelen estar (no necesariamente) organizados jerárquicamente en niveles, de forma que hay un módulo principal que realiza las llamadas oportunas a los módulos de nivel inferior.
Cuando un módulo es convocado, recibe como entrada los datos proporcionados por otro del mismo o superior nivel, el que ha hecho la llamada; luego realiza su tarea. A su vez este módulo convocado puede llamar a otro u otros módulos de nivel inferior si fuera necesario; cuando ellos finalizan su tareas, devuelven la salida pertinente al módulo inmediato llamador, en secuencia reversa, finalmente se continúa con la ejecución del módulo principal.
CARACTERISTICAS DE UN MODULO
.Cada uno de los módulos de un programa idealmente debería cumplir las siguientes características:
- Tamaño relativamente pequeño.- Esto facilita aislar el impacto que pueda tener la realización de un cambio en el programa, bien para corregir un error, o bien por re diseño del algoritmo correspondiente.
- Independencia modular.- Cuanto más independientes son los módulos entre sí más fácil y flexible mente se trabajará con ellos, esto implica que para desarrollar un módulo no es necesario conocer detalles internos de otros módulos. Como consecuencia de la independencia modular un módulo cumplirá:
- Características de caja negra, es decir abstracción (ver abstracción en programación orientada a objetos).
- Aislamiento de los detalles mediante encapsula miento (ver encapsula miento en programación orientada a objetos).
- La independencia modular mejora el rendimiento humano, pudiendo realizarse programación en equipo y desarrollar módulos paralelamente. También contribuye a la re utilización de software.
