lunes, 30 de agosto de 2010

REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES


Requisito funcional

Un requisito funcional define el comportamiento interno del software: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que muestran cómo los casos de uso serán llevados a la práctica. Son complementados por los requisitos no funcionales, que se enfocan en cambio en el diseño o la implementación.
Como se define en la ingeniería de requisitos, los requisitos funcionales establecen los comportamientos del sistema.
Típicamente, un analista de requisitos genera requisitos funcionales luego de diagramar los casos de uso. Sin embargo, esto puede tener excepciones, ya que el desarrollo de software es un proceso iterativo y algunos requisitos son previos al diseño de los casos de uso. Ambos elementos (casos de uso y requisitos) se complementan en un proceso bidireccional.
Un requisito funcional típico contiene un nombre y un número de serie único y un resumen. Esta información se utiliza para ayudar al lector a entender por qué el requisito es necesario, y para seguir al mismo durante el desarrollo del producto.
El núcleo del requisito es la descripción del comportamiento requerido, que debe ser clara y concisa. Este comportamiento puede provenir de reglas organizacionales o del negocio, o ser descubiertas por interacción con usuarios, inversores y otros expertos en la organización.

Requisito no funcional

Un requisito no funcional es, en la ingeniería de sistemas y la ingeniería de software, un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que ni describen información a guardar, ni funciones a realizar.
Los requisitos no funcionales más habituales son la estabilidad, la portabilidad y el costo.

Ejemplo


Sistema de Información de Biblioteca podría ser el siguiente:
Otra forma de realizar la descomposición, es usando un esquema de análisis y diseño orientado a objetos. En este esquema, se busca descomponer el problema en objetos, y no en funciones. Por ejemplo, una descomposición orientada a objetos del Sistema de Información de Biblioteca podría ser la siguiente:
Algunas de las tareas a realizarse en la etapa de análisis son las siguientes:
1. Definir los requerimientos.
2. Definir los casos esenciales de uso.
3. Crear y perfeccionar los diagramas de casos de uso.
4. Crear y perfeccionar el modelo conceptual.
5. Crear y perfeccionar el glosario.
6. Definir los diagramas de secuencia de los sistemas.
7. Definir los contratos de operaciones.
Algunas de las tareas a realizarse en la etapa de diseño son las siguientes:
1. Definir los casos reales de uso.
2. Definir los reportes, la interfaz de usuario y la secuencia de las pantallas.
3. Perfeccionar la arquitectura del sistema.
4. Definir los diagramas de interacción.
5. Definir los diagramas de diseño de clases.
6. Definir el esquema de la base de datos.
Caso de estudio: el punto de venta
Supongamos como caso de estudio el sistema de una terminal de punto de venta. Esta terminal es un sistema automatizado con el que se registran las ventas y se realizan los pagos. Por lo general este tipo de sistemas comprenden hardware (un computador y un lector de código barras) y software (el sistema que se ejecuta en la terminal). Suponga que se nos ha contratado para crear este software.
Los requerimientos
Los requerimientos son una descripción de las necesidades o deseos de un producto. La meta principal en esta etapa es identificar y documentar lo que en realidad se necesita, en una forma en que pueda fácilmente ser transmitido al cliente y al equipo de desarrollo. Se recomienda aquí definir al menos los siguientes puntos:
• Panorama general
• Metas
• Funciones del sistema
• Atributos del sistema
a) Panorama general
Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se utilizará en las ventas al menudeo.
b) Metas
En términos generales, la meta es una mayor automatización del pago en las cajas registradoras, y dar soporte a servicios más rápidos, más baratos y mejores. Más concretamente, la meta incluye:
• Pago rápido de los clientes.
• Análisis rápido y exacto de las ventas.
• Control automático del inventario.
c) Funciones del sistema
Las funciones del sistema son lo que éste deberá de hacer. Hay que identificar estas funciones y listarlas en grupos lógicos. Para verificar que X es en verdad una función del sistema, la siguiente frase deberá tener sentido: “El sistema deberá hacer X”. Por ejemplo: “el sistema deberá autorizar pagos a crédito”.
Las funciones pueden clasificarse en tres categorías: evidentes, ocultas y superfluas. Las evidentes deben realizarse, y el usuario debe saber que se han realizado. Las ocultas también deben realizarse, y puede que no sean visibles para el usuario. Muchas de estas funciones se omiten (erróneamente) durante el proceso de obtención de requerimientos. Las superfluas son opcionales, y su inclusión no repercute significativamente en el costo ni en otras funciones.
Las siguientes son algunas de las funciones más representativas del sistema de punto de venta: Funciones básicas:
Referencia Función Categoría
R1.1 Registra la venta en proceso (actual): los productos comprados. evidente
R1.2 Calcula el total de la venta actual; se incluye el impuesto. evidente
R1.3 Captura la información sobre el objeto comprado usando su código de barras y un lector, o usando una captura manual de un código de producto. evidente
R1.4 Reduce las cantidades del inventario cuando se realiza una venta. oculta
R1.5 Se registran las ventas efectuadas. oculta
R1.6 El cajero debe introducir una identificación y una contraseña para poder utilizar el sistema. evidente
R1.7 Ofrece un mecanismo de almacenamiento persistente. oculta
R1.8 Ofrece mecanismos de comunicación entre los procesos y entre los sistemas. oculta
R1.9 Muestra la descripción y el precio del producto registrado. evidente
Funciones de pago:
Referencia Función Categoría
R2.1 Maneja los pagos en efectivo, capturando la cantidad ofrecida y calculando el saldo deudor. evidente
R2.2 Maneja los pagos a crédito, capturando la información crediticia a partir de una lectora de tarjetas, o mediante captura manual, y autorizando los pagos con el servicio de autorización (externa) de créditos de la tienda a través de una conexión por modem. evidente
R2.3 Maneja los pagos con cheque, capturando el número de RUT y teléfono mediante captura manual, y autorizando los pagos con el servicio de autorización (externo) de cheques de la tienda a través de consulta telefónica. evidente
R2.4 Registra los pagos en el sistema de cuentas por cobrar, pues el servicio de autorización de crédito debe a la tienda el monto del pago. oculta
d) Atributos del sistema
Los atributos del sistema son cualidades no funcionales que a menudo se confunden con las funciones. Por ejemplo: facilidad de uso, tolerancia a fallas, tiempo de respuesta, metáfora de interfaz, plataformas.
Los atributos tienen un posible conjunto de detalles de atributos, los cuales tienden a ser valores discretos, confusos o simbólicos. Por ejemplo:
tiempo de respuesta = (psicológicamente correcto) metáfora de interfaz = (gráfico, colorido, basado en formularios)
Algunos atributos del sistema también pueden tener restricciones de frontera del atributo, que son condiciones obligatorias de frontera, generalmente en un rango numérico de valores de un atributo. Por ejemplo:
tiempo de respuesta = (dos segundos como máximo)
Algunos atributos del sistema de punto de venta son:
Atributo Detalles y restricciones de frontera
tiempo de respuesta (restricción de frontera) Cuando se registre un producto vendido, la descripción y el precio aparecerán en un segundo.
metáfora de interfaz (detalle) Ventanas orientadas a la metáfora de un formulario y cuadros de diálogo.
(detalle) Maximiza una navegación fácil con teclado y no con mouse.
tolerancia a fallas (restricción de frontera) Debe registrar los pagos a crédito autorizados que se hagan a las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de energía o del equipo.
plataformas del sistema operativo (detalle) Microsoft Windows 95, 98, 2000 y NT.
Finalmente, es conveniente describir todos los atributos del sistema que se relacionen claramente con las funciones especificadas. Además, los detalles de los atributos y las restricciones de frontera pueden catalogarse como obligatorios u opcionales. Por ejemplo:
Ref. Función Categoría Atributo Detalles y restricciones Categoría
R1.9 Mostrar la descripción y el precio del producto registrado. evidente tiempo de respuesta 1 segundo como máximo obligatorio
   metáfora de interfaz Pantallas basadas en formularios. Con colores. obligatorio
R2.4 Registrar los pagos a crédito en el sistema de cuentas por cobrar, pues el servicio de autorización de crédito debe a la tienda el importe del pago. oculto tolerancia a fallas Debe registrar en las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de energía o del equipo. obligatorio tiempo de respuesta 10 segundos como máximo obligatorio

martes, 10 de agosto de 2010

¿Como instalar JOOMLA?

Hola, los pasos para instalar Joomla son:

1. Instalamos appserv en la consola.

2.Creamos una base de datos en  localhost

3.Descargamos Joomla en la pagina de internet http://www.joomla.com/

4.entramos a MP donde encontraremos una carpeta appserv, enter, www y pegamos la carpeta de joomla ya descomprimida.

5. Nos dirigimos a internet: http://localhost/joomla, y realizamos la instalacion.

gracias.

sábado, 7 de agosto de 2010

MODELO INCREMENTAL

Desventajas
  • El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.

  • En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.
Caracteristicas

El proceso de desarrollo y empleo de prototipos tiene las siguientes características: 
  • El prototipo es una aplicación que funciona
  • Los prototipos se crean con rapidez
  • Los prototipos evolucionan a través de un proceso iterativo
  • Los prototipos tienen un costo bajo de desarrollo

martes, 3 de agosto de 2010

DESVENTAJAS DEL MODELO EN CASCADA


  • En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso.
  • El proceso de creación del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no esté completo no se opera. Esto es la base para que funcione bien.
  •  El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.
  • Requiere de mucha planeacion, tanto administrativa como técnica.
  • Requiere de metas claras para conocer el estado del proyecto.