[Php-avanzado] Adelanto del apunte

[Leonardo Tadei - Pegasus Tech Supply]

Buenas a todos,

	dada la inquietud de Bruno con sus sistema, les adelanto un par de
páginas del próximo apunte, en dónde se trata el tema de los Proyectos
de Software y sobre todo de la Especificación de Requerimientos de
Software (SRS).

	Estos son los lineamientos a usar para el armado de la tesis del curso,
de la cual les pediremos al menos una parte de la SRS: los
Requerimientos Funcionales.

	Para los que quieran irlo armando, o al menos para estar en el tema en
esta discusión con Bruno, les envío esta parte por adelantado:


                              Gestión de Proyectos de Software

Una de las principales incertidumbres a la hora de querer trabajar
construyendo aplicaciones web y software en general la produce el no
saber por dónde empezar. En esta sección vamos a tratar de
esclarecer aunque superficialmente cómo abordar un proyecto de software.
Para esto, vamos a comenzar con la definición de Proyecto: “Se puede
definir PROYECTO como un conjunto de actividades interdependientes
orientadas a un fin específico, con una duración predeterminada”.
Esto nos divide el problema en 3 partes que podremos abordar por
separado:
*determinar la finalidad del proyecto: parece obvio, pero la mayoría de
los proyectos fracasan porque no está claramente determinado cuál es el
resultado final al que se debe llegar. Esto convierte a la etapa de
especificación de requerimientos en un paso muy importante, ya que el
éxito o el fracaso de un proyecto se determina viendo si cumplió o no
con su objetivo, para lo cual necesitamos primero conocer nosotros y el
interesado en el software perfectamente ese objetivo. El requerimiento
debe volcarse por escrito, y hasta se suele firmar por las partes a modo
de contrato.
* determinar cuales serán las actividades independientes: estas
actividades pueden variar de proyecto en proyecto, pero las que siempre
estarán presentes serán a) saber qué hay que hacer (requerimiento), b)
armar un modelo de datos válido, c) diseñar los procesos que manipularán
los datos, d) diseñar las interfaces con que el usuario usará los
procesos y visualizará los datos (en esta etapa pueden surgir
nuevos procesos “de interfaz”), e) probar que el sistema cumpla con el
requerimiento determinado al principio.
* calcular la duración: una vez determinadas las actividades
independientes recién podrá estimarse la duración del proyecto. En este
cálculo los informáticos tendemos a ser muy optimistas y consideramos
menos tiempo del que realmente necesitamos, no por no saber calcular el
tiempo en hacer una actividad, sino por no considerar factores ajenos
que nos impiden dedicar todo nuestro tiempo al desarrollo. Es una
buena política sumar a los proyectos entre un 10 y un 25% del tiempo
calculado optimistamente hasta ser capaces de incluir estas demoras en
el propio cálculo. Naturalmente que el cálculo del tiempo es una parte
importante del cálculo de costos de un sistema, junto con su
complejidad, arquitectura, restricciones de
hardware, etc.

                     Especificación de Requerimientos de Software

Una especificación de requerimientos del software es una descripción
completa del comportamiento del sistema a desarrollar. Incluye un
conjunto de casos de uso que describen todas las interacciones que se
prevén que los usuarios tendrán con el software. También contiene
requerimientos no funcionales (o suplementarios). Los requerimientos no
funcionales son aquellos que imponen restricciones al diseño o
funcionamiento del sistema (tal como requerimientos de funcionamiento,
estándares de calidad, o requerimientos del diseño).
Las estrategias recomendadas para la especificación de los
requerimientos del software están descritas por IEEE 830-1998. Este
estándar describe la estructuras posibles, contenido deseable, y
calidades de una especificación de requerimientos del software.
Los requerimientos pueden ser de tres tipos:

* Requerimientos Funcionales: son los que el usuario necesita que
efectúe el software. Ej: el sistema debe emitir un comprobante al
registrar la entrega de mercadería.
* Requerimientos No funcionales: son los "recursos" para que trabaje el
sistema de información (redes, tecnología).Ej: el soporte de
almacenamiento a usar debe ser MySQL
* Requerimientos Empresariales u Organizacionales: son el marco
contextual en el cual se implantará el sistema para conseguir un
objetivo macro. Ej: abaratar costos de expedición.

Una correcta Especificación de Requerimientos de Software produce
requerimientos organizados, medibles, comprobables, sin ambigüedades o
contradicciones, ranqueables, homogeneos, etc.
La especificación de requerimientos es un "documento vivo" que se usa
durante todo el ciclo de desarrollo del sistema y muchas veces cambia y
se actualiza, por tanto para su mejor uso, debe tener una portada
con el nombre del proyecto, los autores y la versión de la
especificación.

Definición de requerimientos funcionales:
La definición de requerimientos funcionales consiste en la
caracterización de lo que el sistema (artefacto) debe hacer. Debe
hacerse referencia exclusivamente a lo que el sistema debe hacer, y
nunca a lo que el usuario hará con el sistema: estamos caracterizando al
sistema, no a quienes lo usarán.
Cada requerimiento debe estar numerado, de forma tal que pueda hacerse
referencia a él desde otro requerimiento, y ordenado de forma tal que
cuando un requerimiento mencione a otro, este otro ya haya sido
definido.
Cada requerimiento debe definir una funcionalidad y solo una
funcionalidad del sistema, ya que de otra manera se pierde la
homogeneidad de la SRS. En caso de que un requerimiento sea demasiado
extenso, lo que significa que su definición puede ser demasiado general,
se subdivide en items, en los cuales se redactarán los subrequerimientos
que lo componen.
Dado que lo que debemos hacer es definir que hace el sistema, y no por
ejemplo qué es lo que los usuarios harán con el sistema, cada
requerimiento funcional comienza con "El sistema debe..." y luego lo que
hará el sistema. Ej: El sistema debe mostrar el saldo de los clientes.
Es por esto que, y aunque parezca extraño a primera vista, en la
Especificación de Requerimientos Funcionales, el usuario jamás es
nombrado, ya que la lista de funcionalidades que el sistema debe cumplir
no depende del usuario que la usa (si bien podrá darse el caso de que un
usuario no pueda acceder a ella, de todos formas el sistema sí debe
implementarla).
Por una cuestión de simplicidad, convenimos en usar la palabra "gestión"
como un sinónimo de Altas, Bajas y Modificaciones de los datos. Por Ej:
"El sistema debe gestionar clientes" es una abreviatura de tres
requerimientos funcionales, a saber "El sistema debe dar de alta
clientes", "El sistema debe dar de baja clientes" y "El sistema debe
modificar clientes". 
La Especificación de Requerimientos Funcionales tiene generalmente dos
apéndices. Uno es el Diccionario, en dónde se definen los términos
ambiguos o desconocidos usados en la redacción de los requerimientos y
se los acota al contexto del sistema. Por ejemplo un "vendedor" no es lo
mismo para un sistema de ventas en un comercio, que para uno de una
compañía de seguros, que para una empresa que envía vendedores a
recorrer ciudades y tomar pedidos. En el Diccionario es el lugar ideal
para, al definir el término, enumerar los atributos que los
caracterizan, como por ejemplo:

Vendedor: persona que recorre en un auto propio pueblos y ciudades y
toma pedidos a los Clientes de la Empresa, a la vez que intenta sumar
nuevos. 

Atributos:
Nombre
Apellido
Tipo y Nro de Documento.
Teléfono
Sueldo base
Comisión por venta (%)
Cuota de ventas ($)
Premio por cuota cumplida ($)

El otro apéndice usado es el que tiene un modelo de los listados a
emitir por el sistema, detallando el título, las columnas del listado y
los totalizadores. Por cada Requerimiento Funcional que implique emitir
un listado, debería haber un modelo de la salida impresa a generar. Es
habitual hacerlos en hojas de cálculo, para documentar también las
fórmulas que se usan para los totalizadores.
Una Especificación de Requerimientos Funcionales detallada, puede ser
usada como un contrato informal entre el cliente que pide el desarrollo
del sistema y los que lo construyen, ya que ahí estás enumeradas
cada una de las funcionalidad a cumplir, con lo que conseguimos
determinar claramente se un pedido del cliente es una omisión nuestra,
de la cuál deberemos hacernos cargo, o un olvido del cliente, en cuyo
caso deberemos cotizar la ampliación del sistema para que sea aceptada.
Dado que el producto de nuestro trabajo es intangible, ser muy claros
siempre es una cuestión importante.

-- 

Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key