LOS PROYECTOS DE SOFTWARE

BEATRIZ POSADA CASTRO

INGENIERA DE SISTEMAS
MAESTRIA EN INFORMATICA


















SENA REGIONAL QUINDIO
CENTRO DE LA CONSTRUCCION Y LA INDUSTRIA
ARMENIA 2011
CAPITULO I

EL DOCUMENTO DE LA
DETERMINACION DE
REQUERIMIENTOS
OBJETIVO GENERAL

Desarrollar las actividades necesarias para llevar a cabo la etapa de
Identificacin de necesidades del cliente

OBJETIVOS ESPECIFICOS

Obtener una visin global del sistema.
Identificar problemas existentes en la actualidad, en funcin a las necesidades
presentes y futuras del sistema.
Identificar requisitos a satisfacer por el nuevo sistema.

RESULTADOS DE APRENDIZAJE

Evidencia de
conocimiento
Evidencia de desempeo Evidencia de producto
Definicin de:
mbito del sistema
Requisitos funcionales
Requisitos no funcionales
Reglas del negocio.

Comportamiento y
habilidad para comprender,
describir el sistema e
identificar necesidades, e
implementar mejoras al
sistema.
Informe de requerimientos
DETERMINACION DE REQUERIMIENTOS
The User Requirements Definition Phase


La actividad de la determinacin de requerimientos, es la base de todas las
fases siguientes en la construccin del software, puesto que dependiendo del
entendimiento del negocio se desarrollaran todas las etapas posteriores para
construir el sistema. Sin embargo a excepcin del estndar IEEE 830 no
existe una estructura definida para la elaboracin del informe de
requerimientos, por lo cual a travs de capitulo, se pretende brindar a los
analistas de sistemas de informacin una metodologa que sirva como base
para la elaboracin de este documento.

Para definir los requerimientos del sistema, es necesario antes que nada,
comprender el contexto del negocio: cual es su objetivo, cuales son sus
procesos, las actividades de los procesos, reglas del negocio, reas y usuarios
que intervienen en el sistema, entradas necesarias (datos) que se requieren,
informacin de salida suministrada, problemas como cuellos de botella y
necesidades no satisfechas por el sistema actual; dicha compresin del
sistema debe ser analizada bajo un enfoque sistmico, una visin holistica que
permita obtener resultados sinrgicos.

Por todo lo anterior se hace necesario, como primer paso en la identificacin
de necesidades del cliente la elaboracin del mbito del sistema que
describa textualmente los aspectos anteriores.

Una vez comprendido y elaborado el mbito del sistema, es importante contar
con una descripcin grafica de los procesos del sistema en estudio, por lo que,
, si muy necesario es la elaboracin de mapas de procesos a travs de
diagramas de flujo, que muestren el panorama desde otra perspectiva.

El siguiente paso es definir los requerimientos funcionales que los usuarios
tienen para un nuevo sistema y los que usted a travs de su anlisis; basado
en la experiencia y la lgica pueda aportar como valor agregado para el nuevo
sistema.

En esta etapa debe tambin definir los requerimientos no funcionales, tanto
para la etapa de desarrollo, como para la etapa de implantacin,;
requerimientos que definen restricciones del sistema.


DOCUMENTO DE REQUISITOS DE USUARIO
User Requirements Document

En el documento de requerimientos, todas las funciones deben ser definidas y
especificadas, no debe haber requerimientos que entren en conflictos con
otros. El documento debe describir lo que es requerido para que el sistema sea
desarrollado, debe describir lo que el sistema hace actualmente y lo que har.
No es un documento de diseo.
Tengan en cuenta que el documento de requerimientos debe ser entendible
tanto para el cliente como para los desarrolladores.


ESTRUCTURA

1. mbito del sistema

El propsito de esta tarea es comprender como funciona el (los) proceso(s);
cuales son sus actividades, comprender los flujos de informacin, reglas del
negocio y como interacta con otros subsistemas.
La anterior informacin la debe obtener, en entrevistas con los usuarios del
sistema y se podr apoyar en mapas de procesos, normas o leyes en las
cuales se enmarcan la realizacin de dichas actividades.

Como resultado de esta tarea elabore:

o Una descripcin textual del sistema.
Importante: identifique aqu donde empieza y donde terminan las
actividades del sistema.
o Para cada proceso defina cual (es) es su objetivo
o Defina que datos son necesarios para cada proceso
o Cuales son las limitaciones para cada proceso (Tiempo y cantidad)?
o Identifique la informacin que debe proporcionar cada proceso (salida)
o Reglas de dominio (negocio)

1.1. Reglas del dominio (negocio)

Son las polticas y restricciones de negocio de una organizacin, las cuales
pueden ser de origen interno o estar regidas por alguna ley gubernamental.

No son requisitos (funcionales) de aplicacin, pero los requisitos se pueden
ver afectados por las reglas de dominio.

Es importante identificar las reglas del negocio que afectan los requisitos, ya
que pueden aclarar el contenido de un caso de uso.

Ejemplo para el caso del Sistema de Contratacin.

Regla para invitar proveedores
Para seleccionar proveedores solo se tendrn en cuenta quienes estn
inscritos en la base de datos y que estn al da con el pago de impuestos,
aportes parafiscales y quienes hayan actualizado su informacin en un
periodo mnimo de 6 meses.

Regla para calificar proveedores
Para evaluar los proveedores en una escala de 100 puntos, se tendrn en
cuenta los siguientes parmetros:

o precio de la oferta 30 ptos,
o tiempo de garanta del servicio y/o producto 30 ptos,
o tiempo en el mercado:
Menos de 2 aos 5 ptos
Entre 2 y 5 aos 10 ptos
Mas de 5 aos 20 ptos
o Evaluacin de venta de servicio y/o productos anteriores 20 ptos.


Nota: Reglas del dominio en un concepto mas amplio que reglas del negocio,
ya que abarca restricciones de leyes fsicas, necesarias por ejemplo en un
sistema de manejo de clima.




2. Mapa de proceso o diagrama de actividad(UML) del sistema

Es una descripcin grafica del mbito del sistema.


3. Especificacin de Requisitos del Software (ERS)

Es una descripcin completa del comportamiento del sistema que se va
ha de desarrollar. Incluye los requisitos funcionales y no funcionales.
La manera para registrar dichos requisitos va desde un listado con una
estructura jerrquica, hasta la utilizacin de casos de uso (UML)

Una especificacin puede ser un documento escrito, un conjunto de
modelos grficos, un modelo matemtico formal, una coleccin de
escenarios de uso, un prototipo o cualquier combinacin de estos [Roger
Presman]


3.1. Definicin de los requerimientos funcionales.

Son declaraciones de los servicios que debe proporcionar el sistema.
Especifica la manera en que debe comportarse ante determinadas
entradas.

Cmo hacerlo?. Siempre que vaya a definir este tipo de requerimientos,
piense en funcin de las siguientes frases: El sistema deber, El
sistema debe permitir. Piense en torno a las responsabilidades del
sistema. Agrupe los requerimientos jerrquicamente. En el desarrollo de
esta actividad es interesante y necesario realizar una descripcin breve
(casos de uso) de los requerimientos mas importantes.

Para estructurar los requerimientos, puede hacer uso de un diagrama
jerrquico, en donde cada requerimiento empiece por un verbo en infinitivo
y tenga un identificador nico. Ejemplo.

Una vez haya definido los requerimientos, deber validarlo, para lo cual
puede utilizar como herramienta una matriz de objetivos vs. funciones, que
le permitir identificar cuales de las necesidades podran no requerirse o por
el contrario si no se ha detectado algn requerimiento que satisfaga un
objetivo del sistema.


3.2. Definicin de los requerimientos no funcionales.

Los requisitos no funcionales son restricciones en el diseo o la
implementacin. Estos pueden ser de:

Rendimiento
Seguridad
Hardware
Software
Usabilidad
Entrega

Ejemplos requerimientos no funcionales
4. Usuarios

Relacione la identificacin de los usuarios que participaron directa o
indirectamente en la elaboracin del documento.


ROL PROCESO/ACTIVIDADES AREA NOMBRE-USUARIO



5. Referencias

Identifique las fuentes documentales como normas y/o leyes en los que se
basa la definicin de requerimientos.


6. Apndices o anexos

o Formatos impresos, formatos de pantallas, informes.

o Plataforma tecnolgica: si el sistema debe ser implementado sobre
un hardware especial, ese hardware y sus interfaces deben ser
descritas. Si hardware existente ser usado la configuracin mnima
y ptima para el sistema debe ser definida

7. Glosario: defina aqu los trminos tcnicos usados en el
documento.

Tabla de contenido



Nota: Haga firmar las hojas de los requerimientos por los usuarios que
participaron en la identificacin de los mismos.



APENDICE DEL CAPITULO II


Ejemplos determinacin requerimientos funcionales para un sistema de
intermediacin laboral.
























Regresar.



Ejemplo de requerimientos no funcionales

o De Rendimiento: los requerimientos de rendimiento describen el rendimiento
de ejecucin del sistema y normalmente estn relacionados con el tiempo.
Ejemplos:

o La generacin de las facturas mensuales no debe tardar ms de 3
minutos.
o Se van a procesar 18 mil transacciones en un periodo de tiempo de tres
minutos.

o El sistema requerir no ms de 3 segundos para mostrar una pgina
esttica al cliente.

o De Seguridad: establece niveles de acceso al sistema.
Ejemplo: "El sistema asegurar que toda la informacin confidencial
suministrada por los usuarios a travs de Internet estarn encriptadas".

R1.1 Registrar datos bsicos
R1.2 Registrar datos de estudio
R1.3 Registrar experiencia laboral
R1. Inscribir oferta
R2. Registrar empresa a travs de la Web
R3. Registrar vacantes
o De Software y Hardware: estos requerimientos se refieren al mnimo
hardware necesario para implementar el sistema. Es importante recordar que
no se refieren nicamente al hardware de servidor, tambin al de los clientes.
Ejemplos:

o "El sistema debe ser capaz de ejecutarse en la configuracin estndar
de los equipos de cliente de la compaa: Pentium II 800Mhz, 256MB
RAM, SVGA 800 x 600 x 16"

o El modulo disponible para servicio al cliente deber operar con una
pantalla tctil.

o Cabeza lectora de cdigo de barras y software que permita leer las
entradas escaneadas como si fueran del teclado.

o La implementacin (construccin), deber utilizarse utilizando la
tecnologa Java.

o La implemetnacion de la base de datos deber hacerse utilizando SQL
de Oracle.

o De usabilidad: Son los aspectos generales de la interfaz entre el usuario y el
sistema. Normalmente se refieren a estndares de interfaz de usuario. Para
aplicaciones Web, los requerimientos de usabilidad deben incluir las funciones
mnimas del navegador utilizado por los usuarios o los elementos HTML a usar.
Por ejemplo:

o El sistema debe ser accesible por cualquier navegador que soporte
formularios".
o Se debe ver el texto fcilmente a una distancia de 1 metro
Regresar.
APNDICE DEL CAPITULO II


Casos de Uso

Los casos de uso son requisitos funcionales que indican lo que har el sistema. En el
UP y mtodos modernos son el principal mecanismo que se usa para la identificacin
y definicin de requisitos funcionales.

Los casos de uso van desde texto hasta diagramas; el primer caso es el que debe
utilizarse en la etapa de Definicin de Requerimientos (Identificacin de
necesidades del cliente), etapa en la cual se pueden escribir en diferentes niveles
dependiendo de la necesidad, y van desde una breve descripcin hasta un completo
y detallado comportamiento de la forma en que se comportar el sistema y la manera
en como interactuar con el usuario (actor), pasando por una descripcin informal
(menos completa); el segundo caso (diagramas) es utilizado en la etapa de anlisis.

Como identificar casos de uso?. Los caso de uso no se tratan de una sencilla
actividad como eliminar un registro de pedido o imprimir el documento; el escenario
principal de xito debe estar formado por varias actividades (mnimo cinco),tampoco
debe cubrir actividades que conlleven mltiples das o sesiones: por ejemplo contratar
bienes y servicios; proceso que podra llevar varios das.

Sin embargo, y como excepcin de la norma anterior, en algunos casos encontramos
actividades que se repiten una y otra vez en diferentes casos de uso, para lo cual es
necesario crear un caso de uso a nivel de objetivo de subfuncion (dan soporte sun
objetivo de usuario) , el cual ser conectado o invocado en otros caso de uso base.

Cmo escribirlos?. La escritura del escenario principal, en la fase de requisitos debe
ser lo mas esencial posible, y centrarse en las intenciones y responsabilidades del
sistema (usuario-software) y no en detalles acerca de la interfaz del usuario; este tipo
de descripcin concreta para ayudar en el diseo de la GUI en etapas posteriores.


Los casos de uso deben aadir valor observable y cuantificable al negocio

Nota: Los casos de uso como tcnica para describir requisitos funcionales fue
introducida en 1986 por Ivar Jacobson, uno de los creadores de UML y UP.

Regresar.