Esta forma de trabajar es una variante del modelo "en cascada", uno de
los primeros que se intentaron aplicar formalmente.
Desde el punto de vista del desarrollo/implementación, puedo decirte
que es un modelo al que se le atribuyen todo tipo de males. Por
ejemplo, es normal que en la última fase descubres que hay que cambiar
algo o que el proyecto nunca empiece por hacer un "bucle infinito" en
las primeras fases (ya que deben ser perfectas).
Con la experiencia que tenemos hoy en día para el desarrollo de
software, mi recomendación es que hagas ciclos pequeños de desarrollo.
Plantea el desarrollo en fases cortas (no más de 1 mes) de forma que
tengas una parte más grande de tu proyecto completa (y usable) tras
cada fase y que la perspectiva de cómo se va materializando tu idea te
permita introducir ajustes en las siguientes fases. Esto también te
permitirá explorar la funcionalidad que ya tienes y someterla a pruebas.
Siendo además un proyecto de red social, probablemente te interese
tener una "beta" con funcionalidad parcial funcionando cuanto antes
para poder hacer experimentos con usuarios reales. Quizá la forma de
uso que le dan a la red te sorprenda y afecte a los siguientes ciclos
de desarrollo.
Si no vas a participar en la implementación del sistema, lo mejor es
que te dejes aconsejar en cuanto a la tecnología. Si la empresa que
contratas está cómoda con ella, el resultado será mejor que si fuerzas
una en concreto.
Además, asegúrate de tener contacto frecuente con la empresa que
desarrolle la idea para evitar problemas de comunicación, que es el
principal motivo para que un proyecto salga mal.
Salvo por la elección de la tecnología, en cada fase puedes seguir los
10 pasos que comenta Álvaro, excepto que dónde dice "completamente" yo
pondría "de forma detallada para esta fase".
Es decir, si durante un ciclo vas a implementar el alta y login de
usuarios, en el 1er paso define "de forma detallada para esta fase"
cómo quieres que sea esa funcionalidad (qué datos hay que capturar en
el alta, cómo se puede recuperar un password perdido, si llevará
captcha, cuanto tiempo se recuerda a un usuario, etc...).
Retrasar los detalles hasta que sean necesarios te permite mantener
una visión de conjunto muy clara de tu proyecto. Si te centras en los
detalles demasiado pronto, puedes llegar a olvidar el porqué esos
detalles eran necesario en primer lugar.
Un saludo,
El 12/09/2009, a las 13:15, Alvaro J escribió:
Existes multitud de metodologías de trabajo, cada una de ellas te
dirá una serie de documentos a realizar, llamándolo de una manera
distinta. Nosotros lo resumimos en 10 pasos de la siguiente manera:
1º Saber qué vas a hacer (definir completamente la funcionalidad).
2º Saber cómo lo vas a hacer (definir completamente la tecnología).
3º Saber como lo vas a colocar (definir completamente la
arquitectura de la información).
4º Repasar fases anteriores
5º Si algo no cuadra, retocarlo.
6º Saber cómo se va a interacturar con ello. (Definir completamente
el modelo de interacción de usuario).
7º Repasar fases anteriores.
8º Si algo no cuadra retocarlo.
9º Definir el diseño gráfico.
10ª Implementarlo.
Si en la fase 10 te das cuenta de que debes repasar las fases
anteriores.... HAS MUERTO !!!!!!
Así de "fácil".
Mucho ánimo.
Que tengas un buen dia.
-------------------------------------------------------------------
El equipo de DS Multimedia
www.dsmultimedia.es
[email protected]
+34 927 626 735
+34 650 923 735
_______________________________________________
altas, bajas y modificaciones:
http://www.cadius.org/lista/opciones.html
--
Abel Muiño - http://ramblingabout.wordpress.com/
_______________________________________________
altas, bajas y modificaciones:
http://www.cadius.org/lista/opciones.html
