[Php-avanzado] Adelanto del apunte

[Leonardo Rozas]

Buenas:

Leo queria saber si se puede clarificar un poco el item

 "...armar un modelo de datos válido..."


ya que no me queda claro a que se apunta, por ahi un minimo ejemplo me
ayudaria a visualizarlo, o sino algun link donde poder ahondar en la
informacion.


Desde ya muchas gracias


Leonardo


El 22 de abril de 2010 16:22, Leonardo Tadei - Pegasus Tech Supply <
leonardot en pegasusnet.com.ar> escribió:

> 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
>
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://www3.fi.mdp.edu.ar/cgi-bin/mailman/private/php-avanzado/attachments/20100423/3e34e084/attachment-0001.htm