Fabricación vs Desarrollo de Software [cerrado]

10

A menudo se dice que la industria del software es inmadura en comparación con la fabricación. Específicamente con respecto a ser impulsado por el proceso.

Pregunta : ¿Podemos nosotros, como desarrolladores, aprender de los procesos de la industria manufacturera? ¿La adopción de sus procesos puede aumentar la tasa de éxito del desarrollo de software?

Mi opinión : en la fabricación, la creación de un producto depende en gran medida del proceso. Puede tener una fábrica donde cada persona tiene un conjunto específico de tareas que sigue. Un trabajador (o robot) puede apretar un tornillo todo el día. Luego, la siguiente tarea en el proceso la realiza el siguiente especialista. Los trabajadores (y los robots) no disuaden del proceso ni inventan algo "sobre la marcha". Las partes se mueven durante todo el proceso y la salida es un producto terminado. Funciona bien y las empresas logran 99.99966% de productos libres de defectos. Las empresas resuelven las ineficiencias con el tiempo. Esto es impresionante y muy bien puede ser el signo de una industria madura.

En la fabricación, un proceso definido puede crear literalmente el producto terminado. No creo que este sea el caso en el software. Es posible que tengamos procesos para el control de la fuente, la revisión del código, las hojas de verificación, la recopilación de requisitos, el SDLC, etc. Pero ejecutar esos procesos no crea en sí mismo un producto terminado. Estos procesos pueden ser beneficiosos, pero son ortogonales a la creación real.

Supongamos que su empresa está contratada para crear un software que buscará millones de imágenes para encontrar los rostros de los delincuentes. A pesar del pesado entorno impulsado por el proceso, el desarrollador debe participar en la creación de cosas "sobre la marcha". Hacer cosas sobre la marcha va en contra del espíritu de fabricación. Un buen proceso de fabricación puede ejecutarse sin pensarlo un robot.

Para la creación de algoritmos complejos que aún no se han concebido en la mente de un humano, es una necesidad crear cosas sobre la marcha. El desarrollo de software no es el seguimiento de un proceso, sino la creación de un proceso para ser ejecutado por una computadora. Esa es una diferencia fundamental. No importa cuántos procesos ortogonales realizamos en torno al desarrollo, siempre recurriremos a hacerlo "sobre la marcha" cuando se trata de la creación.

Todos con los que hablo parecen estar de acuerdo con la mentalidad de fabricación. ¿Estoy solo en mis pensamientos?

Lord Tydus
fuente
1
FYI: Lo que me motivó a hacer esta pregunta fue un libro de CMMI. Comparó la creación de software con la fabricación y concluyó el Soft.Ind. Era inmaduro.
Lord Tydus
3
Yo diría que una analogía más precisa en el mismo campo sería la ingeniería involucrada en el diseño y la instalación de su fábrica. Ahí es donde suceden las partes creativas / difíciles. El resto son solo tuercas y tornillos, al igual que para nosotros el resto son solo 1s y 0s.
Benjol
1
La ingeniería de software no se compara con la fabricación. Se compara con la artesanía. Esto no puede reducirse a un proceso industrial.
mouviciel
1
Hay una razón por la que se llama desarrollo de software . No es la fabricación de software . Piense en el desarrollo de productos versus la fabricación de productos.
tehnyit
¿No intentaron los japoneses precisamente eso: crear software en un proceso más orientado a la fabricación de bienes físicos? Según recuerdo, es ampliamente considerado como un fracaso total y absoluto, aunque, por supuesto, hay algunos títulos de software desarrollados con éxito en Japón (pruebe Sonic the Hedgehog como ejemplo).
un CVn

Respuestas:

36

La diferencia fundamental entre el desarrollo y la fabricación de software es que para el software, la fase de diseño es prácticamente todo. La producción real (parte de la línea de ensamblaje en la fabricación tradicional) es una cuestión de copiar algunos archivos. En software, el diseño del producto es el producto.

Entonces, sí, podemos aprender de los procesos de fabricación, pero solo si tenemos en cuenta que tenemos que mirar la fase de diseño, no la fase de producción, y que muchos procesos de fabricación están diseñados para hacer frente a las limitaciones específicas de una cadena de producción costosa. , que simplemente no se aplica al software.

Un ejemplo de un modelo de proceso que funciona muy bien en software, pero que a menudo falla horriblemente en el diseño del producto, es el diseño iterativo: comienza con un prototipo mínimo y agrega características con cada iteración. Construir un prototipo de automóvil para ver cómo se ve el nuevo diseño del pomo de la ventana trasera es ridículo, pero en el software tiene sentido (simplemente presione F5 y espere unos segundos, listo, listo para probar).

Si observamos los procesos de diseño de productos, las mejores industrias a considerar se dividen en dos categorías:

  • aquellos en los que la producción puede realizarse a tasas de productos básicos; por ejemplo, la industria discográfica (el 1% o menos del precio de un CD es hornear e imprimir), medios gráficos, etc.
  • aquellos donde las cantidades son tan bajas que la fase de diseño es el factor de costo más destacado (artículos de lujo, productos altamente personalizados, nichos de mercado ...)

Es un error fundamental intentar y aplicar procesos desde la fabricación física hasta el desarrollo de software: el desarrollo de software no es repetitivo (si es en su trabajo, vaya a buscar otro trabajo), solo es parcialmente predecible, solo hay muy pocas limitaciones físicas ( la velocidad del hardware es una), y tanto el enfoque adoptado como los resultados pueden ser muy personales. La aplicación de filosofías de línea de ensamblaje a lo que es básicamente una cuestión de pensamiento analítico y creativo puede (y a menudo lo hace) tener efectos devastadores.

tdammers
fuente
2
Gran respuesta. ¡En el desarrollo de software todo es un prototipo!
James Anderson
1
Es un buen punto, pero creo que el aspecto del diseño es exagerado. Escuchas números arrojados, como "el 60% del costo del software es mantenimiento" y "el último 10% de un proyecto de software requiere mucho más del 10% de la programación". Los números no importan tanto como la idea aquí, y tanto el mantenimiento como el pulido ocurren mucho después de que se haya finalizado el diseño. El diseño es sin duda un aspecto importante del producto, pero también es posiblemente la parte más fácil y barata.
Caleb
3
@Caleb: Excepto el mantenimiento, especialmente para un producto bien diseñado, no se trata principalmente de corregir errores en el producto actual, sino de agregar características, en otras palabras, agregar y cambiar el diseño.
Marjan Venema
@Caleb: probablemente esto también sea cierto para configurar una línea de producción y procesos de producción. La configuración de la línea de producción es uno de los aspectos más costosos y largos del proceso de fabricación.
James Anderson
2
@Caleb: Creo que entendiste mal mi analogía aquí. Cuando hablo de 'diseño', hablo de diseño de producto, es decir, el proceso que precede al inicio de la línea de montaje. Tanto las fases de diseño como de implementación de un producto de software son 'diseño' en este sentido, mientras que la parte de fabricación se reduce a cargar binarios en un servidor o hornear DVD-ROM para su envío. Como programador, todo lo que entregas es un prototipo; así que todo lo que haces, incluido el trabajo de mantenimiento, es el "diseño" en la analogía de la cadena de producción tradicional.
tdammers
10

Si desea escribir el mismo software exacto una y otra vez (en lugar de simplemente copiarlo), puede hacerlo de manera muy eficiente a través de una línea de montaje.

Pero la creación de software no es una tarea repetitiva, cada módulo es único. Es por eso que la comparación con la fabricación no es válida.

Imbéciles
fuente
Tomar lecciones de fabricación no significa construir una línea de ensamblaje de software. La fabricación tiene mucho que decir sobre la mejora de procesos, y hay mucho en el proceso de desarrollo de software que podría mejorar.
Caleb
@Caleb: ¿Qué lecciones quieres decir entonces? Eso es exactamente lo que pensé que querías decir.
sevenseacat
1
@Karpie, la mejora del proceso puede ocurrir incluso cuando estás produciendo cosas que no son idénticas. ¿Cuántos errores escribimos este mes? ¿El mes pasado? ¿Hace dos meses? Si ese número cambia significativamente de un mes a otro, debe averiguar por qué. Este es el tipo de cosa que funciona para cualquier proceso, ya sea que esté produciendo widgets idénticos en una línea de ensamblaje o películas en un proceso altamente creativo.
Caleb
2

Creo que la respuesta que está buscando es aplicable o realista aquí. Lo que siento que quieres saber es cómo podemos configurar nuestros procesos para que se parezcan más a la industria manufacturera. En cambio, creo que la verdadera pregunta se convierte en "Saber qué hacen la fabricación y otras industrias para construir productos de calidad, ¿qué podemos aprender?" o "¿Qué puede hacer la industria del software para mejorar la calidad?"

Lamentablemente, la respuesta a esto no está clara porque la industria del software en sí aún no sabe la respuesta. Para poder responder a esto, la industria del software debe investigar qué funciona y por qué. Por ejemplo, se han realizado estudios que demuestran que el diseño de prueba de manejo (TDD) conduce a una mejora en la calidad. Aunque la cuestión de la productividad todavía parece no tener respuesta o al menos aún no se comprende completamente. En cuanto a lo que la evidencia muestra hasta ahora:

  • Las revisiones de código son excelentes, y se muestra que encuentran la mayoría de los errores, pero la efectividad de una revisión cae bastante bruscamente después de la primera hora de revisión. Dado que la persona promedio solo puede leer unos cientos de líneas de código por hora, sugiere que los desarrolladores deberían dividir los cambios en partes más pequeñas.
  • Cuanto más tiempo tarde en encontrar un error, más costoso (tiempo y dinero) será solucionarlo. Entonces, si un desarrollador lo encuentra mientras escribe el código, decimos que el costo es 1. Si una unidad de prueba lo encuentra más tarde, el costo es 10, si EVT lo encuentra, el costo es 100 y así sucesivamente.
  • Existe alguna evidencia que sugiere que cuanto más complejos son los requisitos, más compleja es la solución y cuanto más compleja es la solución, más probable es que haya errores.

Hay un hombre llamado Greg Wilson que dio una excelente charla sobre esto hace unos años. Aquí hay un enlace a la charla: Greg Wilson Talk

Además de esto, diría que revises tu propio trabajo y encuentres los temas con los tipos de errores que introduces y con qué partes luchas. Compile estos resultados y luego cree una lista de verificación para insertar en su proceso en diferentes lugares para ayudarlo a hacer un mejor trabajo. Personalmente, eché un vistazo a los últimos años de mi trabajo y descubrí que hay algunos temas comunes a los problemas que presento. Específicamente he encontrado que

  • No recuerdo a menudo construir todas las variantes que me llevan a romper la construcción.
  • Muchas veces no pienso en lo siguiente para cada cambio. El buen caso, el mal caso y los casos excepcionales.
  • Todos los escenarios posibles que podrían suceder. Tenga en cuenta que esto es realmente difícil porque hay muchos de ellos.

Dado que he encontrado algunos temas para mis errores, he creado listas de verificación que uso automáticamente, debido a su inserción en mis scripts, que me ayudan a solucionar estos problemas. Había un libro escrito sobre esta llamada, el "Manifiesto de la Lista de Verificación", que detalla cómo se les puede dar un buen uso. Personalmente lo encontré muy perspicaz.

barrem23
fuente
2

No se trata de adoptar "sus" procesos. Se trata de adoptar "algunos" procesos, que no tienen los inconvenientes habituales y bien apreciados de usar procesos de línea de ensamblaje para esfuerzos creativos. Lo más importante a tener en cuenta aquí es la idea de que la calidad de los procesos se traduce directamente en la calidad del producto.

Los mejores procesos, o productos para el caso, son los que se ajustan al escenario de uso previsto como una mano en el guante. Lo que hay que pensar es que la parte de escritura de código real es la única que es, al menos a nivel macroscópico, no repetitiva. Todas las demás facetas, como el control de versiones, el seguimiento de errores, la planificación, las estimaciones, las mediciones, etc., y el uso de un proceso estándar, personalizado y probado pueden ayudarlo al menos en estas áreas.

Entonces, no, el proceso de desarrollo de software no puede compararse con la producción de la línea de ensamblaje y, como tal, "sus procesos" no están bien, pero la fase de diseño de producción / diseño de producto del producto en una industria manufacturera puede ser la fuente de inspiración.

Vaibhav Garg
fuente
1

Pregunta: ¿Podemos nosotros, como desarrolladores, aprender de los procesos de la industria manufacturera? ¿La adopción de sus procesos puede aumentar la tasa de éxito del desarrollo de software?

Respuesta: sí, por supuesto. Hay muchas lecciones que los desarrolladores de software pueden aprender de la fabricación a pesar del hecho de que el desarrollo de software es un proceso creativo. El desarrollo de software es en sí mismo un proceso e incluye muchos otros procesos. Cuanto mejor pueda definir y controlar esos procesos, mejor podrá controlar el proceso de desarrollo de software en general. Eso no significa que deba prescribir cada pulsación de tecla que haga un desarrollador; solo significa que, como desarrollador, naturalmente realiza tareas en un cierto orden, y esas tareas a menudo se pueden administrar. Aquí hay unos ejemplos:

  • seguimiento de defectos: cuando se observa o informa un error, ¿qué le sucede? ¿Lo escribes en un trozo de papel y lo pegas en una espiga de 'investigar'? ¿Luego eliminas esos restos de uno en uno, los investigas y eventualmente los mueves a la espiga 'resuelta'? Si lo hace sin falta cada vez que recibe un informe de error, tiene un proceso bien definido y medible, y probablemente esté mucho mejor que alguien que tenga un sistema de seguimiento de defectos elegante y de alta tecnología que es tan oneroso que algunos miembros del equipo rastrean errores de otras maneras, o no lo hacen en absoluto.

  • Control de versiones: existe una buena posibilidad de que use el control de versiones donde trabaja, y el control de versiones es obviamente mucho más útil cuando todos lo usan de la misma manera.

  • diseño del producto: ¿Decide qué características implementar al lanzar dardos en una pared cubierta con notas adhesivas? Si es así, tienes un proceso. No creo que nadie pueda argumentar que es un gran proceso, pero al menos es un punto de partida. Si cambia el proceso, ¿cómo puede saber con certeza que su cambio fue realmente una mejora a menos que mida antes y después? No puedes

  • revisiones de código: ¿sería útil una revisión de código si el proceso de revisión y los criterios de codificación cambiaran para cada revisión? Por supuesto no.

  • ciclo de vida de desarrollo de software: todo el análisis -> diseño -> implementación -> prueba -> ciclo de mantenimiento es un proceso que debe definirse claramente.

En cada uno de estos casos, tener un proceso en funcionamiento le permite medir entradas y salidas y determinar si los cambios que realiza tienen el efecto deseado. No tener procesos establecidos significa que solo estás adivinando cuando intentas mejorar tu forma de trabajar. Esto es realmente de lo que se trata la fabricación, y solo tiene sentido tomar prestadas las sucesivas herramientas de refinamiento de la fabricación cuando son apropiadas.

Hay un campo completo dedicado a definir y mejorar los procesos utilizados para crear y mantener software; Se llama ingeniería de software . No sorprende que tenga preguntas sobre el proceso de desarrollo mientras lee sobre CMMI: CMMI es un producto del Software Engineering Institute .

El desarrollo de software ya ha adoptado muchos conceptos de fabricación:

  • Es difícil no ver la influencia de las partes intercambiables de Eli Whitney en OOP y el desarrollo basado en componentes .

  • Las técnicas de gestión de proyectos utilizadas en el desarrollo de software no son muy diferentes de las desarrolladas para la fabricación. Como solo dos ejemplos, el mundo del software adoptó recientemente el concepto Kanban que se desarrolló hace décadas en Toyota, y los gráficos de Gantt se utilizaron en la fabricación mucho antes de que se construyera la primera computadora electrónica.

  • Las metodologías de gestión de calidad como Six Sigma que se desarrollaron para la fabricación se han adaptado al desarrollo de software.

A pesar del pesado entorno impulsado por el proceso, el desarrollador debe participar en la creación de cosas "sobre la marcha".

¿Me está diciendo que alguien decidirá por sí mismo agregar un parche al paquete de reconocimiento facial, y lo agregará a la compilación de producción sin crear primero un problema en el sistema de seguimiento, teniendo el diseño revisado, ¿Verificando el código en el control de versiones, o haciendo que la gente de prueba lo vea primero? Nuestro proceso requiere esas cosas por muy buenas razones. Si por "sobre la marcha" quieres decir "fuera del proceso", eso es inaceptable.

Hacer cosas sobre la marcha va en contra del espíritu de fabricación.

Nuevamente, si "sobre la marcha" significa "fuera del proceso", tiene razón. Pero si cree que la fabricación no requiere pensar rápidamente y desarrollar soluciones creativas a los problemas, está equivocado. En el proceso de fabricación surgen todo tipo de problemas: los bizcochos no tienen suficiente relleno de crema, las superficies pintadas dejan de pasar la prueba de rayado de QA, el 20% de las piezas terminadas carece de un anillo de retención importante, el sistema de mezcla de la masa se ha roto parte critica...

Caleb
fuente
+1. Exactamente mis pensamientos. Pero me temo que esta podría no ser una respuesta popular, porque en un estado de ingeniería de software inmaduro, la codificación de vaquero es lo que se hace. Incluso dentro de CMMI, en L1, los héroes son adorados como deidades.
Vaibhav Garg
@ Vaibhav Garg: Creo que a largo plazo, el proceso que funciona mejor, en el sentido comercial , gana. Si el "proceso de ingeniería de software" controlado da como resultado una relación calidad / velocidad / costo de mayor calidad, entonces gana. Sin embargo, a veces la codificación de vaquero parece producir resultados molestos.
Joonas Pulakka
1
@JoonasPulakka. Estoy de acuerdo, que a veces la codificación de vaqueros parece producir buenos resultados. Pero la clave aquí es "a veces". Si su objetivo es la repetibilidad en el rendimiento, debe ser repetible en lo que hace. ¡Piensa en la P en SIPOC!
Vaibhav Garg
1
@ JoonasPulakka- Citando textualmente del Estándar CMMI para organizaciones de nivel 1: El éxito en estas organizaciones depende de la competencia y heroicidad de las personas en la organización y no del uso de procesos probados. A pesar de este caos, las organizaciones de nivel de madurez 1 a menudo producen productos y servicios que funcionan; sin embargo, frecuentemente exceden sus presupuestos y no cumplen con sus horarios.
Vaibhav Garg
2
"El éxito en estas organizaciones depende de la competencia ... de las personas" No creo que ningún proceso pueda cambiar eso.
Kevin Cline