Cómo planificar un nuevo software (diagramas de flujo o simplemente archivos de texto o utiliza papel)

¡Esto es increíblemente emocionante de responder!
Su pregunta no es tan específica, así que tengo que considerar todos los casos.
Es aún más emocionante que estés en Ubuntu , más emocionante que implica tanto el uso de una computadora como material físico.

El propósito de planear
En primer lugar, pasamos por alto lo más obvio:

  1. La planificación es una herramienta para lograr un conjunto de objetivos. Entonces, por ejemplo, si su objetivo es “hacer un seguimiento de la imagen más grande, porque me pierdo en la codificación”, entonces necesita muchas hojas con puntos como características colocadas en una pared, para que pueda verlo todo el tiempo. así que dibuje diagramas que necesite en función de su objetivo (sepa por qué lo necesita), ¡no solo haga 1000 diagramas!
  2. la planificación es personal: herramientas como UML han sido diseñadas por personas con experiencia, úselas, pero no tenga miedo de “piratear” y personalizarlas para sus propias necesidades. entre UML puede colocar nubes y cuadros según sus necesidades; no tiene que conformarse con un modelo. ¡El modelo es simplemente una referencia para su beneficio!
  3. deje que la planificación evolucione: cambie su estrategia de planificación a medida que evolucione la necesidad. Básicamente, puede comenzar con hojas A4 que dibujan diagramas aleatorios y enumeran características que algún día evolucionarán a algo tan complejo como SRS, db Schema, DFD, etc.
  4. Mira lo que el mundo piensa de los documentos de diseño: ¡amo y vivo los documentos de diseño! pero solo el 11% de los programadores usan diagramas de diseño más del 75% de las veces. Lea este documento: http://t.co/dWjW8sPKVw [Sobre el uso de modelos de diseño de software en la práctica de desarrollo de software: una investigación empírica por Tony Gorschek, Ewan Tempero, Lefteris Angelis]

¡Ahora vamos a ensuciarnos con las herramientas!

  1. Comience con http://trello.com! ¡Este producto es simplemente INCREÍBLE! Puede planificar y rastrear su boda, compras de comestibles hasta iteraciones de software. Sea creativo y aprenda a usarlo. ¡y sobre eso puedes agregar personas y colaborar! Su arquitectura es tan increíble, ¡todo es casi instantáneo!
  2. I <3 Ubuntu – Use dia. Esta herramienta es tan simple y tan rápida. Simplemente no puedo tolerar todos los productos de Windows FAT como smartDraw. dia carga GRANDES diagramas rápidamente, y me permite administrar cosas enormes sin desorden, ¡ y le permite modelar todos los diagramas de flujo y UML!

¡Ahora vamos a obtener un software específico!

  1. Necesitas modelar tus datos : como eres nuevo, te sugiero que modeles un RDBMS y luego evalúes el uso del modelado desnormalizado (como NoSQL) cuando eres un profesional. Un buen modelo de datos captura todos sus requisitos, mantiene las cosas sensatas, construye la base de su producto. Usa dia y dibuja el modelo ER. Recomiendo encarecidamente el modelo EER (dia no es compatible con EER, así que improvisé usando flechas rojas para la inercia). Existe una técnica específica para convertir ER a db-Schema (aprenda de un libro DBMS o contácteme).
  2. UML 2.0: es un método brillante para expresar el diseño que abarca mucho: estudia y usa lo que necesites. Lo más importante es usarlo como lo necesite.

Modelos a codificar!
Convierta su ER a dbScema en MySQL workbench para Ubuntu. ¡La mejor y más emocionante parte de esto es que convierte tu modelo visual en código SQL que puedes implementar directamente! Si va a realizar una programación orientada a objetos desde cero, aprenda a diseñar diagramas de clase y las herramientas están disponibles para convertirlas en código tropezado. Es posible que no necesite esto si está utilizando un marco

GRAN planificación:
La planificación es una cosa, pero la creación de software involucra a clientes, partes interesadas, iteraciones, errores, personas y Dios sabe qué. Siempre que su software se vuelva grande de todos modos, necesita un plan más completo que (extrañamente) se llama “ingeniería de software“.

El desarrollo de ingeniería de software tiene bastante historia, y simplemente odio la forma en que los libros lo describen. Antes de leer algo sobre ingeniería de software, lea este hermoso documento técnico : [GESTIÓN DEL DESARROLLO DE GRANDES SISTEMAS DE SOFTWARE – Dr. Winston W. Royce] – Este es el modelo en cascada (aunque el propio Royce nunca lo llamó así – jajaja ).

El historial de código también es parte de la planificación: sin duda, use git en github / bitbucket, etc.

Al diablo con todo esto!
Si nada de esto tiene sentido o es desalentador. Omita la planificación y comience a codificar, y cuando se dé cuenta de que está perdido (aunque en unas pocas horas), deténgase y planifique gradualmente. esa es una forma de aprender también. La idea es obtener ideas de esta publicación y otras, y desarrollar un estilo de planificación personal para usted y sus necesidades. ¡Empezar! o git inició – si comienzas en github 🙂

Además, nunca abandones ubuntu 😀
EDITAR: me refiero a no salir del ecosistema GNU / Linux 😀

No he ejecutado ni planeado un proyecto de software importante en algún tiempo. Así que no soy necesariamente una buena persona para preguntar sobre esto. El último software con el que estaba jugando fue la investigación. Todavía no he congelado esas ideas como quiero. El problema es que en esos casos estoy escribiendo software de paralelismo, por lo que los diagramas de flujo no tienden a funcionar tan bien. Funciona bien para programas simples.

Así que la mayor parte de mi planificación son archivos de texto. Una técnica anterior (no recomiendo esto, pero la uso como un ejemplo alternativo) se llamaba diagramas de Nassi-Schneidermann (para ramas).

Cuando está escribiendo software para otras personas, personas no técnicas en particular, su expectativa es una solución directa. Una gran cantidad de computación logra sus respuestas mediante algoritmos iterativos / solución. Esas personas no entenderán esto.

La ramificación y el manejo de excepciones son los problemas más problemáticos. Mantenga su trabajo lo más modular posible.

Prototipos y bancos de pruebas: parecen ser los mejores. Haz que algo funcione rápido. Recuerde la advertencia de Dave Clark: consenso general y código de ejecución.

Desearía poder darte mejores detalles, pero sería un desarrollador más exitoso si lo hiciera.

Sin embargo, querrá comenzar; es más conveniente para usted tener sus ideas en “papel”, clima que las escriba a mano, usando diagramas de flujo o cualquier proceso que desee. Pero después de hacer eso, y antes de comenzar un desarrollo serio, debe tener dos cosas: documentos de requisitos que combinen texto y diagramas de flujo simples para describir exactamente lo que desea que haga su software, y UML (diagramas de flujo) para el diseño de software deseado que muestra cómo vas a implementarlo. La falta de documentación es un asesino de proyectos para cualquier proyecto grande, especialmente si alguna vez habrá más de uno o dos desarrolladores. Puede resolver muchos problemas en papel que habrían sido muy costosos si hubiera alcanzado la mitad del desarrollo antes de descubrir.

Puede usar la aplicación Draw (and Writer) de LibreOffice para cosas simples, pero si desea los estándares de la industria, debe buscar aprender un poco de UML y buscar un editor UML gratuito (algo así como Modelio Page en modelio.org).

No soy un experto en este tema, pero compartiré mi método ingenuo.

  • Tome el problema y descomponga a un nivel conocido, módulos atómicos. Esos son los módulos que no se pueden descomponer más y sabemos cómo codificarlo. El problema puede ser complejo, sin embargo, este enfoque ascendente funciona para resolverlo desde el nivel conocido hasta esta complicación.
  • Encuentre la forma de probar cada uno de estos módulos. Dado que si pasamos por alto algunos flujos de los módulos básicos iniciales, eso puede ser tan difícil de ver hasta niveles superiores.
  • No he usado la prueba de unidad dinámica, pero siempre sé cómo probar el módulo que codifico. Luego pruebe el módulo escrito para todos los casos extremos que pueda encontrar.
  • Vaya a niveles superiores combinando sus módulos y aplique lo mismo a medida que resuelve el problema en su conjunto.

Hay un ciclo completo de desarrollo de software que se utiliza para desarrollar un proyecto. Hay muchos libros que pueden darte una idea.