¿Cuál es la mejor manera de diseñar software?

Has hecho una pregunta muy ambigua y casi sin respuesta.

Para diseñar casi cualquier cosa, debe responder las siguientes preguntas:

1. ¿Qué se necesita?
2. ¿Cómo se juzgará la calidad?
3. ¿Qué tecnologías hay disponibles?
4. Si lo que se va a diseñar es grande y complejo, ¿qué tecnología se debe utilizar para qué piezas?
5. Si la cosa que se va a diseñar es grande y compleja, ¿cómo se puede organizar en cosas más pequeñas que sean fáciles de entender y reparar?
6. Si el rendimiento es un problema de calidad, ¿cuáles son las posibles deficiencias de rendimiento y cómo se pueden corregir?
7. ¿Cuáles son las expectativas y la experiencia de las personas que lo usarán?

Estas preguntas pueden responderse en cualquier orden o en paralelo. Cuanto mejor pueda responderlas, mejor será su diseño. Pedirle a otros que revisen su diseño desde diferentes perspectivas lo ayudará a pulir su diseño.

Al igual que la forma en que construiría una casa, necesitaría un arquitecto para dibujar la impresión azul para asegurarse de saber dónde colocar la puerta / ventanas / pilar / pared o lo que sea que le gustaría tener.
Entonces necesitaría un ingeniero civil para calcular y asegurarse de que la casa no se descomponga bajo ciertas condiciones, como tornados, terremotos, etc. Luego, construya de acuerdo con las especificaciones establecidas por el ingeniero y el arquitecto, ladrillo por ladrillo.

Para el software, necesita una interfaz que un diseñador necesitaría diseñar como un plano de dibujo arquitectónico. Entonces necesitaría un ingeniero de software para decidir sobre la plataforma y el entorno y cómo codificarlo para asegurarse de que el software se construye de acuerdo con la interfaz diseñada y funcionará incluso en condiciones específicas. Luego, depende del ingeniero de software elegir la herramienta y configurar el entorno para su software.

Al menos así es como se debe diseñar y construir un software adecuado.

Hoy en día, las personas tienden a comenzar a codificar, luego prueban e iteran el proceso hasta que tienen algo que funciona, luego reescriben todo nuevamente para el entorno de producción.

Esto es como preguntar: ¿cómo puede un gramático escribir una buena historia? Requiere un conjunto de habilidades diferente. Además, ¿a qué tipo de diseño te refieres?

Así que puedes ocuparte de los detalles de implementación. Ese es un buen comienzo. Si su proyecto es muy pequeño y tiene una idea bastante buena de lo que quiere lograr, puede intentar el método del codificador de vaquero: comience a escribir el programa, refactorizar, extender, refactorizar lo más simple posible. Este método (o falta de) tiene la virtud de ensuciar las manos del programador. Aprenderás algo. Construirás algo. Puede ser monstruoso. Al menos, evitará la parálisis del análisis y, posiblemente, la ingeniería excesiva.

Tradicionalmente, el diseño en ingeniería de software significa que debe intentar mapear cómo pretende hacer que todo funcione en conjunto, incluso antes de escribir una sola línea de código. Ahí es donde intervienen el diseño orientado a objetos y otros métodos similares; vea la publicación de Keith Ensign para ver algunos enlaces sobre el tema. Las metodologías ágiles no son una excusa para omitir este paso, pero pueden servir como un recordatorio para mantener su proyecto inicial simple y evitar el diseño de futuras extensiones demasiado pronto. La etapa de diseño de la ingeniería comienza con buenas especificaciones y un buen diseño tiende a surgir de los conocimientos extraídos de la experiencia práctica más que mediante la aplicación de metodologías conocidas. Tiene poco que ver con el diseño del producto, ya que requiere saber qué construirá primero y responder adecuadamente a estos requisitos.

También se diseñan buenas especificaciones. La decisión de qué hará su software y cómo servirá para su propósito se basa en varias experiencias. La gente de la vieja escuela (ingenieros de software) lo llama la etapa de análisis. Otros hablarán sobre diseño de servicios. Esta actividad puede variar según el tipo de software que vaya a construir. La experiencia en el dominio del conocimiento, los conocimientos sobre el comportamiento del usuario y la capacidad de adaptar los procesos organizacionales son buenas cualidades para comenzar antes de intentar escribir historias de usuarios y pruebas de aceptación. El lápiz y el papel también pueden hacer maravillas en esta etapa, ya que pueden ayudarlo a explorar soluciones basadas en sus observaciones con pocas limitaciones.

Una tercera categoría de diseño es el diseño de las imágenes y de la experiencia del usuario. Un buen toque final puede marcar una diferencia considerable en su producto final. Una vez más, su experiencia no se puede resumir tan sucintamente …

Cada uno de estos esfuerzos de diseño viene con sus muchas prácticas. Muchas de estas prácticas tienen como objetivo guiar o estructurar las ideas del diseñador. Cuanto más sepa sobre sus usuarios, sus objetivos y los materiales con los que trabajará, más cerca estará de proponer una solución satisfactoria. Su experiencia en programación debería guiarlo en la línea del diseño de ingeniería. Podría ayudarlo a imaginar nuevas posibilidades en el frente del diseño del servicio. Sin embargo, es posible que deba dejar a un lado la tecnología y aprender desde diferentes perspectivas para imaginar un producto que cumpla su propósito.

Recientemente hemos hablado de esto en Code Podcast. La conclusión principal para mí personalmente fue: depende del propósito del software. Diseñamos sistemas empresariales de manera diferente en comparación con los marcos de código abierto. Utilizamos diferentes técnicas de trabajo en startups en comparación con las de las grandes empresas.

Es útil definir qué significa diseñar software. Podemos dividirlo en:

• Definir el problema y las posibles limitaciones de la solución.
• Identificando soluciones
• Implementar la solución que satisfaga todas las restricciones.

Cada parte de este proceso tiene su propio conjunto de técnicas. La mayoría de ellos figuran en otras respuestas a esta pregunta. Por ejemplo:

• Técnicas para definir el problema y las restricciones.

• Método de escribir preguntas y respuestas en papel
• Maquetas de dibujo
• Hablar con el cliente (duh!)
• Identificación del problema mínimo viable

• Dibujar diagramas UML
• Desglosando la solución en bloques y definiendo su propósito y API
• Par de diseño

• TDD
• Programación en pareja
• Implementando partes críticas primero
• Implementando el sistema de extremo a extremo con algunas partes burladas

No confíes en mi palabra. Hemos hablado con diferentes expertos sobre esto en el podcast:

Code Podcast

Pasos simples para diseñar una aplicación de software:
1: ¡¡Ten una idea !!
2: Obtenga los requisitos (SRS)
3: Elija un IDE (Entorno de desarrollo integrado) ex-Eclipse, Visual studio y un lenguaje de codificación de su elección.
4: Comience a desarrollar en función del proceso de desarrollo de software como (cascada, creación de prototipos, etc.) según sus necesidades.
Por último, pero no menos importante … DISFRUTA … diviértete

No creo que haya una sola respuesta a esto.

La forma en que se diseña el software está estrechamente relacionada con la cultura organizacional y, a menudo, incluso con la estructura organizacional.

En general, necesita una buena comprensión de sus requisitos y estos deben traducirse en los artefactos de software necesarios. Una buena arquitectura ayudará a mantener su sistema mantenible

Comience con un programa simple.
El primer programa “real” que hice fue un dado que usaba GUI. Lo escribí con Java.

Primero fui directamente a la programación real sin pensar realmente en ello. Al final, el código resultó realmente desordenado y el proceso de desarrollo tardó más de lo que realmente debía ser.

Hace unas semanas decidí intentar hacer un intérprete Brainfuck (usando Java nuevamente).
Lo había pensado mucho y tenía una idea general de lo que tenía que ser. Fue suficiente para comenzar a desarrollarse de todos modos. Cuando comencé la programación, me encontré con un montón de problemas que no había pensado que aparecerían antes. Estoy seguro de que no importa cuánto lo haya pensado, aún habría una increíble cantidad de problemas que no había previsto.
Esto no cambia el hecho de que debe prepararse de antemano. Entonces, realmente, no hay una buena manera de prepararse para el desarrollo de software. Solo asegúrate de tener todo lo planeado y preparado para la etapa de desarrollo de la manera que más te convenga.

Una vez que conozca y comprenda los entregables, y las partes interesadas hayan acordado, y haya definido los cronogramas iniciales de sprint, la mejor manera de diseñar la UX / UI del software, los algoritmos, etc., es trazar cada detalle de lo que se va a construir . Esto es lo que hacemos en cada proyecto … los clientes no tienen la opción de decir que no, y por mil buenas razones más allá de esta respuesta rápida.

Como la pregunta es tan general:

Un lápiz, papel, una serie de preguntas sobre la aplicación.
Haga un diagrama de flujo general y atomícelo progresivamente.
Haz dibujos de maquetas.
Código, prototipo, iterar.
Prueba.

Esta es una guía simple o una forma de pensar para hacer un software increíblemente simple,

lo hemos hecho en dapulse y funciona increíblemente bien por ahora más de 4000 compañías que pagan
Diseño de producto físico: herramientas de software de próxima generación

Realmente no existe el “mejor”, solo lo que funciona para usted.

Es importante para mí comprender las necesidades que el software está cubriendo, que es diferente a una especificación. Conozco a otras personas que no se moverán sin un documento UML, mientras que no veo ningún beneficio en construir el mismo modelo de objeto dos veces, pero funciona para ellos. También conozco a muchas personas que se sumergen y limpian las cosas a medida que avanzan.

Todo lo que puedo decir es que no debes descartar nada. Pruébalo todo y conserva lo que sea que te ayude a concentrarte. A veces, es tan estúpido como escribir una lista de características.