gof - design patterns singleton
¿Cuánto diseño debería seguir antes de que se realice cualquier codificación? (27)
Actualmente estoy en la escuela y para mi proyecto sénior tenemos que gastar 1/3 términos simplemente haciendo diagramas UML y otra documentación tediosa para nuestro proyecto.
Esto implica una gran cantidad de diseño y planificación para problemas futuros que aún tienen que ocurrir.
Por alguna razón, esto parece fomentar el diseño excesivo. Pasé la última hora escribiendo cosas como esta.
"Conéctese al servidor: conectándose a un servidor. Precondición: no existe conexión al servidor. Condición posterior: la conexión ya existe".
Prefiero estar codificando que haciendo estas tonterías. Me doy cuenta de que este trabajo de diseño tiene su lugar, pero ¿cuánto? Sé que esto no es una evidencia a prueba de balas para no diseñar mucho en una herramienta como Enterprise Arch, pero aquí voy.
Mi profesor que enseña estas materias ha diseñado el diablo de su proyecto. Todo lo que podría suceder en la aplicación ha sido documentado. En lugar de codificarlo él mismo, usó esta "inmaculada documentación" para cultivar el trabajo en el exterior y para los estudiantes durante el verano.
La aplicación que ha resultado de todo este diseño ha sido TERRIBLE. Es una de las peores aplicaciones que he visto y cualquiera podría decir que ha sido sobrediseñada.
¿Qué tiene que decir la comunidad de codificadores experimentados SO sobre este tema? ¿El diseño de una gran oferta antes del proyecto tiende a hacer malos programas al forzar las decisiones tomadas desde el principio simplemente porque el "diseño lo dice así"?
Gracias por cualquier idea que puedan aportar. Si supiera que esto fue por una buena razón, me sentiría mejor "perdiendo" mi tiempo haciéndolo. Estoy más que dispuesto a hacer algún trabajo de diseño de antemano, pero siento que mi profesor espera que se tomen muchas decisiones de ingeniería antes de escribir cualquier código.
EDITAR: Interesante artículo de slashdot sobre este tema. http://books.slashdot.org/story/09/11/16/1448204/Becoming-Agile
Los planes no son nada; la planificación es todo.
Trabajar en diagramas UML y otros tedio puede forzarlo a enfrentar todo el problema que está tratando de resolver y dividirlo en fragmentos manejables.
¿Deberías seguir el diseño de tu clase al pie de la letra? Casi seguro que no; Nunca he trabajado en un proyecto donde los requisitos no cambiaron a mitad de camino debido a alguna circunstancia imprevista. Pero al menos vas a entrar en eso con una idea de lo que hay que hacer. Me parece que seguiste tus documentos demasiado rígidamente, lo que puede causar problemas.
Sí, esa es una de las metodologías "tradicionales"
En estos días, los procesos de desarrollo iterativo Agile tienen mucho más ruido y están "reemplazando" al " modelo cascada " más antiguo.
El contraste, se nos dice, es entre el anterior, el plan primero, los requisitos de escritura, las especificaciones de escritura, el documento, finalmente, al final ... código, modelo, con uno "más nuevo": ágil. En Agile, un sistema se desarrolla incrementalmente en consulta con los usuarios. Uno intenta tener siempre un sistema en ejecución y pruebas unitarias. La dirección puede cambiarse antes de que los requisitos se malinterpreten seriamente y el esfuerzo desperdiciado se haga en la dirección incorrecta.
No estoy de acuerdo con esta explicación.
No estoy en desacuerdo con Agile, solo con la idea de que es nuevo. Por el contrario, diría que Agile es nuevamente popular
Creo que muchos o la mayoría de los buenos, que funcionan, los sistemas heredados fueron desarrollados con técnicas incrementales y evolutivas, simplemente no tenían una palabra de moda prestigiosa en aquel entonces. Ciertamente, un equipo podría haber hecho toda esa planificación y especificación, y luego procedió de manera ágil, construyendo un pequeño núcleo "funcional" y evolucionando hacia la versión final. (Qué pérdida de tiempo, sin embargo ...) Y muchos proyectos se desarrollaron fuera de los marcos burocráticos.
En algún momento, el prototipado incremental se convirtió en una metadología de diseño reconocida, y esta fue la encarnación temprana de Agile. Supongo que con suficiente dinero y tiempo, podrías construir algo completamente al techo hacia atrás, pero tengo que pensar que los desarrolladores exitosos usaron patrones similares a Agile desde el primer día .
El modelo de cascada, además de no ser nada divertido, tiene una tendencia en mi humilde opinión a funcionar peor cuanto más completamente lo apliques. Muchos proyectos que siguen ese modelo han pasado a un fracaso espectacular. Un problema específico es que permite a una organización gastar una gran cantidad de dinero sin ninguna indicación de éxito futuro. La idea de ejecutar su primera prueba después de que todo esté terminado es ROTFL-time hoy, pero piense en cuánto podría costar un gran proyecto de cascada antes de ejecutar siquiera la primera prueba real.
Habiendo dicho todo eso, no le hará daño intentarlo, y algunas de esas técnicas de documentación tienen valor fuera del modelo de cascada.
Creo que todos le darán una respuesta diferente, en parte por su opinión personal, y en parte porque tienen experiencia ... Mi experiencia es esta ...
Muchas veces, los proyectos planificados en "T" a menudo están bastante alejados de las especificaciones originales ... porque a veces se alcanzan limitaciones técnicas, o porque ocurren condiciones imprevistas en las que los diseños originales simplemente no funcionan.
He trabajado en proyectos para diferentes compañías que van desde el diseño a, a una especie de "aquí tenemos una idea general de lo que queremos" ... y creo que lo que funciona mejor es algún tipo de medio feliz entre los dos.
Trabajando para un cliente o construyendo una interfaz que otra persona va a consumir directamente, obviamente un diseño completo será la clave.
En cuanto a los diagramas UML, y una planificación real en profundidad como esa?
He trabajado para empresas que van desde grandes proveedores de servicios inalámbricos hasta grandes empresas inmobiliarias residenciales y comerciales, a una empresa de facturación de un tamaño bastante aceptable ... y puedo decir honestamente que no he visto personas REALMENTE usar diagramas UML con éxito. .
Creo que es bueno identificar sus puntos de contacto y su trabajo fluye, pero no es algo que una hoja de papel y un lápiz no puedan hacer por usted.
En cuanto al terrible código subcontratado que pudo haber recibido ... obtienes lo que pagas. No pretendo hacer ningún tipo de generalizaciones, etc., pero creo que incluso aquí en Estados Unidos, probablemente tengas una proporción de 10: 1 para desarrolladores incompetentes frente a competentes ... y creo que las proporciones aumentan a partir de aquí. No asumiría que el motivo de los problemas de código fue la planificación
Dependiendo del proyecto, tengo dos opciones que me gustan.
Para proyectos más pequeños que deseo terminar rápidamente, me gusta seguir las reglas de http://www.extremeprogramming.org/ (programación ágil) donde "realzas" tus ideas en lugar de resolverlas por completo.
Para proyectos más serios, me gusta dibujar un modelo básico (UML / base de datos / secuencia) antes de comenzar. Este modelo se basa en los requisitos establecidos anteriormente. El modelo es principalmente para darme una idea sobre qué clases deben construirse y cómo deben trabajar más. Sin embargo, nunca resolví los métodos, eso es para el tiempo de implementación.
Aprendí que tener un modelo base sólido acelera el proyecto de varias maneras. Por un lado, creará un código menos útil que debe ser revisado después. En segundo lugar, cuando se trabaja en grupos es más fácil explicar las ideas y asegurarse de que todos estén pensando en la misma dirección e implementando en la misma dirección. En tercer lugar, cuando te tomas un tiempo libre o el proyecto es más grande, es bueno tener una visión general de qué clase hizo qué: p.
En el enfoque de arriba hacia abajo, popularmente llamado el "modelo de cascada", las cosas no son interesantes con una larga fase de diseño esencial.
Si tienes un prototipo que funciona, entonces no importa, la cantidad de tiempo que lleva, el diseño es mejor. Así que controle su curiosidad y complete el diseño.
En general, estoy de acuerdo con las opiniones que promueven el enfoque ágil para el desarrollo de software. No me importaría diseñar la solución más compleja con todos los casos que puedas imaginar desde el principio. Hay un dicho muy conocido de Donald Knuth "La optimización prematura es la raíz de todo mal", así que tómalo en serio :) Una cosa que es más importante para el desarrollador de software cuando se comienza a trabajar en algo es definir exactamente lo que es para ser construido. Entonces, antes de todo diseño, el clima comienza de manera simple o se vuelve complejo, lo más probable es que llegues a donde no querías si no sabes lo que quieres construir al principio. Es particularmente importante definir las restricciones de la solución.
Su pregunta es un poco filosófica y plantea muchas otras preguntas en los jefes de los desarrolladores. Algunos otros ya lo señalaron a usted para ver el enfoque ágil del desarrollo, que en su forma específica aborda estas cuestiones. Por lo tanto, sugiero lecturas sobre los temas Agile también.
Aclamaciones,
Ivan
En mi experiencia, esta no es una buena idea. Es mucho mejor hacer un poco de planificación, pero luego escribir un código e iterar.
Es tan del siglo pasado, tan académico.
Lo que generalmente sucede, al menos en mi experiencia es que no importa cuánto trabajes en diseño, te perderás algo de alguna limitación técnica, algún vínculo entre las diferentes partes del sistema. También es el punto de partida del diseño: los requisitos están siempre lejos de ser inamovibles.
Más que eso para validar tu diseño, en realidad necesitas hacer algo de codificación: prototipos y demás. Los enfoques más nuevos para el proceso de desarrollo: ágil para uno, llevarlo a decir que solo necesita el diseño necesario para comenzar a codificar.
Esto no quiere decir que pueda apresurarse a codificar sin una comprensión clara de hacia dónde se dirige, pero exagerar es realmente malo.
Esto es muy subjetivo, pero en mi humilde opinión, solo lo suficiente como para adivinar razonablemente cómo debería ser la arquitectura global apropiada del sistema, pero el diseño no debería detenerse (o incluso desacelerarse apreciablemente) en ese punto, debería continuar durante el desarrollo y la refactorización de desarrollo debe fomentarse e iniciarse a menudo, ya que el diseño continuo ilumina las incoherencias entre el análisis del modelo de dominio, el diseño y el modelo de desarrollo. Los conceptos (y las herramientas) que su profesor le está enseñando serán de gran valor en el proceso de diseño, ya sea que haga todo su diseño antes del desarrollo, o a medida que avance el desarrollo.
Lo que hace su profesor suena como un caso clásico del proceso del ciclo de vida del diseño de software de Waterfall (SDLC). Su error principal no es que la fase de construcción (codificación) se retrase, sino que el diseño se detiene más o menos cuando comienza la codificación (debido a los impedimentos al cambio que crea la metodología Waterfall).
Algunas tomas de humor sobre esto se pueden encontrar here .
Gday,
Depende mucho de la naturaleza del proyecto.
He trabajado en proyectos en los que el nuevo sistema reemplazó a un sistema existente y la gran mayoría del tiempo se gastó recopilando el comportamiento del sistema existente para establecer los requisitos.
Esta fase, y luego la fase de diseño, tomó casi dieciocho meses. La codificación tomó aproximadamente cuatro meses en términos de calendario. En términos de esfuerzo, fue mucho más, pero el resultado neto fue un sistema estable que el cliente adoraba.
Oh, dicho sea de paso, esto fue un reemplazo para un sistema de control de tráfico aéreo existente, un sistema de control de tráfico aéreo alemán , por lo que ponerlo en funcionamiento después de solo un mes del período de evaluación programado de tres meses fue todo un logro que yo '' estoy increíblemente orgulloso de.
Creo que la gran fase de evaluación y diseño para este proyecto fue el mejor enfoque.
Editar: El sistema estaba en Karlsruhe en el centro de control de tráfico aéreo en ruta operado por el DFS, la versión alemana de la FAA. El sistema de procesamiento de radar existente iba a ser reemplazado por Raytheon, sin embargo, la entrega del sistema principal se retrasó. Entonces, el DFS decidió actualizar las posiciones del controlador a las del nuevo sistema, pero las conectó temporalmente al sistema de procesamiento ATC existente. De ahí el nombre del proyecto Karlsruhe AdvancedDisplay System o KADS. Se construyó un ala completamente nueva en la parte posterior del centro ATC existente a medida que se reemplazaba toda la sala de control.
Hubo una fase de recopilación obligatoria de requisitos en la que el equipo estaba trabajando en el sitio junto con los ingenieros de software que habían construido el sistema existente.
Ellos documentaron:
- todos los mensajes entre el sistema de procesamiento de radar existente y las posiciones del controlador
- todos los comportamientos de las posiciones existentes del controlador, paneles táctiles, teclados, características de visualización, etc.
Estos requisitos fueron luego firmados por el DFS y la fase de diseño comenzó. Esto duró aproximadamente un mes, mientras que varias partes se crearon como prototipos y se identificaron las mejores soluciones. Paralelamente a la implementación, se realizó una fase de diseño de prueba donde todos los requisitos se rastrearon hasta el código y se realizó una prueba asociada.
Luego comenzó la codificación y la prueba con varias entregas, aprox. diez, hecho, cada uno con una prueba asociada y fase de aceptación. Un enfoque de Scrum antes de que tuviera un nombre, ya que seleccionamos los trozos de trabajo que entrarían en cada fase de "lanzamiento" al comienzo de la fase. La entrega final llegó a tiempo y dentro del presupuesto.
El DFS pretendía ejecutar el nuevo sistema en paralelo con el sistema existente durante tres meses para que pudieran evaluar el rendimiento y la estabilidad del nuevo sistema. La transferencia completa al nuevo sistema fue una propuesta de "todo o nada". Tuvieron que sacar físicamente las viejas líneas de radar para quitar el viejo interruptor del teléfono y no hubo vuelta atrás después de eso.
¡Para que el servicio alemán de ATC esté tan contento con el sistema que harían eso, fue una gran palmada en la espalda para nosotros!
Por cierto, fue bastante gracioso el número de los antiguos ingenieros de software que surgieron durante la fase de requisitos y dijeron que no estábamos trabajando porque no había ningún código escrito. Definitivamente evidencia de un viejo enfoque de "asiento de los pantalones" que era evidente cuando mirabas algo del código. (-:
HTH
aclamaciones,
Generalmente obtienes un conjunto de requisitos y comienzas a diseñar una arquitectura. Con base en algunos modelos de estimación de costos, puede hacer una oferta, si tiene el negocio (está bien en su caso, lo tiene y le pagan miserablemente, :-D), entonces puede continuar con el diseño detallado. La codificación real puede ser hecha por monos codificados ... Pensar y diseñar el sistema correctamente es la clave del éxito: los requisitos se cumplen y los costos dentro del presupuesto.
En mi opinión, el diseño no define las condiciones previas y posteriores, que son detalles, sino más paquetes de definición y distribución / división de los requisitos en ellos. Además de definir los grandes componentes en su sistema y cómo están interactuando. Tienes que pensar en acoplarlos libremente para mejorar la capacidad de prueba (diseño para pruebas) entre otros: así que el enfoque no está claramente en algunas condiciones pre y post en proyectos de gran escala de la vida real ...
Esto es más un enfoque de arriba hacia abajo en el que me estoy enfocando aquí, que a menudo es la forma en que debe ir si obtiene un conjunto de requisitos.
Una vez que el proyecto se ejecuta, no se hace, surgen algunos problemas y algunos de ellos justifican un rediseño. El proceso de desarrollo casi nunca (excepto en casos simples) es lineal, sino un proceso iterativo.
La arquitectura, si se considera suficientemente bien, se mantendrá bastante estable en general, pero se necesitarán muchas iteraciones a través del diseño detallado.
Hay quienes en la profesión de codificación que creen que el diseño lo es todo, y hay quienes creen que es mejor codificar y abordar los problemas de diseño a medida que surgen. Estos son dos extremos opuestos del espectro, y como suele ser el caso con dos extremos, la respuesta se encuentra en algún lugar en el medio.
Cierta cantidad de diseño basado en cierta comprensión de cuáles son los requisitos es inevitable. Los requisitos le dicen qué construir; el diseño te dice cómo construirlo. En el mundo real (o al menos en mi experiencia), si hace los requisitos / diseño de manera formal se basa en gran medida en la organización para la que trabaja, es decir, si la organización exige que se siga un determinado proceso de software. Pero incluso si la organización no ordena un proceso formal, el hecho es que usted, como desarrollador, medirá algunos requisitos / diseño, incluso si no está formalizado. En cada paso del camino, usted toma decisiones sobre cómo se informarán los errores al usuario, sobre qué unidades de medida se mostrarán, etc. Todos estos factores son factores que se resolverían en un proceso de requisitos / diseño formal, pero incluso en ausencia de eso, todavía son decisiones que deben tomarse.
Trabajé para organizaciones que usan mucho el software y las que no, y para ser honesto, no veo mucha diferencia en el producto final.
Personalmente, no creo que haya ningún sustituto para las personas de calidad. Es decir, el proceso no es una bala de plata . Si tiene programadores marginales, el mejor proceso del mundo no va a salvar su proyecto.
La cascada de IMHO se está volviendo menos relevante y más ágil debido a la evolución de los lenguajes de programación modernos. Anteriormente, llevaría mucho tiempo codificar incluso la cosa más simple (consulte la sintaxis de COBOL si desea ver cómo no ser delgado y expresivo), por lo que tiene mucho sentido escribir documentos que expliquen lo que usted quiere. programa para hacer, y luego ir a implementarlo. Hoy en día, el proceso de doc es mucho más corto porque la forma más fácil y natural para que un programador exprese su diseño es (¡asombroso!) En el código mismo.
Veo esto todo el tiempo: me siento con una idea en mi cabeza pero no una idea clara de cómo quiero implementarla, así que esbozo posibles implementaciones en el código mismo . Eso es mucho más rápido y más fácil que crear diagramas UML para demostrar la arquitectura, y luego tener que hacer la implementación después de eso. Los lenguajes OO modernos (y los marcos disponibles que se encuentran en la parte superior) son tan dinámicos y expresivos que, en su mayoría, podemos omitir el paso intermedio.
Dicho esto, sigue siendo importante aprender todo ese diseño desagradable. Después de hacerlo varias veces, es más natural y automático pensar en términos de diseños en su cabeza, por lo que todavía está pasando por un proceso de diseño real, aunque puede que no lo haga por escrito. . Por lo tanto, a pesar de que me encogí cuando describiste meses de diagramación UML, quédatelo y reza para que nunca encuentres un trabajo donde eso todavía se hace.
¡Buena suerte!
Los diseños iniciales, por ejemplo, los modelos UML, son hipótesis que se prueban y generalmente se prueban incorrectas durante la codificación. En resumen, la codificación no es análoga a "constrction"; más bien la codificación es diseñar.
Utilice un breve proceso de diseño arquitectónico (estratégico) para identificar, aislar y mitigar los riesgos. Pero use una refactoring disciplinada y recocido ocasional para evolucionar el diseño del sistema, de abajo hacia arriba.
Los entrenamientos académicos formales usualmente (hasta donde yo sé) ponen mucho énfasis en el diseño y muchas otras cosas antes de que empiece la codificación de la producción real (sin incluir la creación de prototipos).
Tiene sentido, no lo haces bien (o casi a la derecha) para empezar, estarás jodido.
Sin embargo, en la práctica, pocos tienen el lujo de tiempo y recursos. Peor aún es que los tipos no tecnológicos (especialmente los que están allá arriba) quieren ver cosas (UI, prototipo) para sentirse realmente seguros de que se han logrado progresos.
Para mí, se trata de equilibrio, las diferentes organizaciones tendrán que trazar su propia línea y presentar las mejores prácticas. También varía según la naturaleza de los proyectos / recursos, etc.
En cuanto a UML, aquí hay algunos mensajes interesantes sobre SO:
¿Es UML práctico?
¿Todavía se ve UML como una forma viable de documentar un diseño de software?
¿Debo usar UML al diseñar nuevos códigos y algoritmos?
Si no diseñas en UML, ¿en qué diseñas?
No me sorprenden muchos de los comentarios de la pregunta.
El propósito de la vida académica es aprender el "proceso de pensamiento" en la escuela que es muy importante en la vida real.
He visto a muchos niños solo querer comenzar a codificar y no escribir especificaciones. La capacidad de escribir una especificación clara te lleva mucho camino. Brinda claridad sobre lo que se ha manejado y lo que no.
Debido a todos los procesos modernos de IDE / Debug, las cosas se han vuelto más de prueba-error-google-trial-¡puede funcionar ahora! ¿Terminó?
Si bien puede ser espantoso al principio al final de haber desarrollado el sistema, usted entiende mucho mejor dónde ayudó su especificación y dónde ayudó su codificación y luego, en la vida real, usted sabe cómo hacerlo mejor.
¡Después de todo, todavía estás en la escuela!
Buena suerte.
No quiero salir como un disco roto (he estado usando mucho esta cita últimamente), pero esta cita de John Gall es realmente relevante para muchos aspectos sobre la construcción de software. (a pesar de que estaba hablando de sistemas biológicos)
"Se encuentra invariablemente que un sistema complejo que funciona ha evolucionado a partir de un sistema simple que funcionó. La proposición inversa también parece ser cierta: un sistema complejo diseñado desde cero nunca funciona y no se puede hacer funcionar. con un sistema simple de trabajo ".
Es decir, si está diseñando, diseñe algo pequeño y alcanzable al principio. Un gran diseño frontal complicado está destinado a fallar.
Puede abordar grandes tareas dividiéndolas en partes más pequeñas. Construya lo más pequeño posible que pueda pensar que podría funcionar. No solucione todo el problema de una vez.
Una de las razones por las que un diseño grande y complicado podría estar destinado al fracaso es que el problema que está resolviendo podría ser un problema malvado, o alguna otra clase de problemas irresolubles donde los subcomponentes del problema son mutuamente exclusivos. Esos son realmente difíciles de detectar por adelantado sin algún tipo de experimentos de trabajo para actuar como evidencia de la solvencia de un subproblema.
La mayoría de la evidencia que he visto sobre el asunto parece predecir que cuanto mayor sea el diseño inicial, más probable será que supere el presupuesto y probablemente no resuelva ningún problema. En resumen, el diseño es necesario, pero su objetivo debe ser mantenerlo lo más pequeño y simple posible, y tenga en cuenta que sus primeros 20 borradores probablemente fallarán debido a los factores que encuentre durante la fase de codificación real.
Pregúntele a su profesor si alguna vez han tenido un trabajo no académico. Luego pídales que describan el sistema más grande que hayan escrito; cuál es el equipo más grande en el que alguna vez han participado; si alguna vez facturaron o enviaron o lanzaron un sistema.
Si nunca han tenido un trabajo no académico, o nunca han escrito un sistema grande, ni facturado, ni enviado, ni liberado, entonces se dan cuenta de que vas a tener que soportar algo horrible para obtener una calificación y hacerlo como con gracia como puedas. Quizás todo lo que aprenderá es que odias UML y cómo superar algo doloroso con una sonrisa.
Todo depende del equilibrio entre el tiempo y la importancia del proyecto. Un proyecto de gran interés tendrá partes interesadas de alto nivel que exijan mucho diseño antes de poder hacer la codificación. Smaller projects can enjoy some freedom from over design and depending on developers they can be iterated very well between coding and design.
The key problem is not making the design first time, it is keeping the design document up to date with every decision change that happens during coding.
A divide and conquer approach can work pretty well if a big project can be broken to several smaller parts which are understood better than overall big picture. Those smaller tasks, coded well can act as building blocks or apis towards completing the bigger tasks. So basically in a top-down approach the division of a large task can be made, and then in a bottom-up fashion those small chunks can be completed and tested separately.
en la vida real, si te pagan por diseñar, entonces diseñas. Si está trabajando en su propio proyecto y realmente necesita hacerlo, entonces adopta un enfoque iterativo diferente basado en pequeños éxitos y refactorización constante.
En la vida real, probablemente no tenga lujo para hacer un diseño elaborado que describa completamente lo que va a construir. Además, puede ser contraproducente, ya que ese diseño envejecerá y se romperá el primer día de codificación (en obsoleto el 2). Seguir la metodología Agile es mucho más seguro con la construcción iterativa de prototipos y el factoraje y refinamiento constantes. En este escenario, usted (o su equipo) puede comenzar a codificar casi de inmediato. Hay algunos buenos libros sobre Xp y Metodología ágil como El arte del desarrollo ágil que pueden dar una mejor idea
Dijo eso: no tener un diseño no es una buena idea. Siempre necesitas un plan. Es solo que los planes de Agile cambian "a medida que avanzas"
I think you want us to tell you that your professor is wrong. Here''s some ammunition: http://www.developerdotstar.com/mag/articles/reeves_design_main.html I have yet to discover if reeves is 100% correct but so far it is.
I''m just in the middle about learning how to best implement coding projects, planning/coding to iterate or not to iterate. How long to spend on the plan etc..
I found a fantastic article online by a guy called. you can find it here . He goes through the reasoning and thought process behind a functional project plan. The functional project plan concentrates on the user''s experience and interaction with the code. And getting this down first is going to be the most important part of the design process. once you have gone through this one you can do a technical project plan which will tackle the specifics of how to implement each problem the user will face when using the code. I think that OP is right when he says one of the major benefits of project plans is not in having them to code from. but in having done them once. so that when you go back to write the code you have a reference to the work you have already done. So you only have to concentrate on the work of coding.
This may all sound like common sense to you, but... Bottom line: write you''r project plan with the intention and idea that you are already doing some/most of the work. Half the work is knowing what to code.
It depends on the particular project and the particular customer. Some people need to be able to visualise a system to be able to understand it and what they want from it. Other times, you may be designing a system where the customer presents you with an inch thing requirements specification, for a system where the quality processes must be higher. Also, some customer require formal agreement to a list of requirements.
In the cases where the customer is unclear on requirements, an agile methodology is more suited. This way the developer can quickly implement new features and get feedback from the customer, reducing the probability of deliverying something not wanted. This contrasts to trying to establish a list of set requirements and only building what has been agreed on contractually, only to deliver something that isnt'' accepted by the customer.
My company has recently hired two new developers both of whom have had many years in the software development industry, but never worked at a company where requirements where written, or design documents produced, or a set SDLC of any kind followed; the typical shop where the developer is given a piece of paper with some requirements and told to "build this". Once both were forced to sit down and iteratively complete design documents (more for their own learning than anything else) they both came to me saying how much more beneficial an upfront design has been in realising thing they would never have thought about until the application was well and truely implemented (badly). Shortly after, they started writting Unit Tests upfront (before implementation) and while for the first few weeks, found it very strange and saw it as a waste of time, each day they come to me and espouse how much more they''d learnt and beneficial unit tests are.
Rushing straight in to coding the actual implementation (as opposed to tests) is a rookie mistake that we''ve probably all made.
Probably the most relevant thing to your situation: consider that some large projects are difficult to start small. You should always start as small as possible, but often that razor won''t cut fine enough; awful though it may be, your project is presumably intended to walk the class through the basic steps.
Design time spent before coding always has great potential for being well-spent -- but only if you know how to spend it well! As you have noticed, it is very easy to overengineer, make bad design systems early, and so forth. Just chalk your current project up to experience -- when you do a real-world project, you''ll know what design pitfalls to avoid!
Prototyping also has great potential for being time well-spent -- but only if you have the balls to throw out the prototype and begin again from scratch, having learned from the experience. If you''ve ever had to wrangle sendmail, you know the pain of dealing with software that grew from a small project to a horrific monster without starting over...
Finally, note that there are a wide range of methodologies out there; for better or for worse, as a software guy, you may need to deal with any of them. Most of them can be made to work in some reasonably useful way, so even if a particular instance is dysfunctional, you should not let that poison you agains methodology in general.
You don''t need to do any design work, unless you are hoping to produce software products that will be used and enjoyed by people other than yourself.
It''s very difficult (if not impossible) to create a decent software product without understanding the goals of your potential users. You can''t understand the goals of your users without research, and you can''t apply research without design.
Los profesores académicos nunca han hecho proyectos del mundo real :). Ellos son los responsables de este espíritu cascada. También UML Tools no es conveniente hoy en día, aunque Visual Studio 2010 Ultimate se acerca.