He estado pensando en la diferencia entre un producto y una pieza de software por un tiempo. En mi puesto actual, estoy bailando continuamente entre el mundo de la ingeniería de desarrollo de software y el mundo de los productos de negocios. Si me lo hubieras preguntado hace un año, probablemente habría tenido una opinión muy diferente sobre qué es el software y qué es el producto. Pero a medida que mi experiencia con ambos crece, estoy ganando un mayor sentido de las diferencias.
Hace tiempo que quería escribir sobre este tema … No dejaba de decirme que necesitaba darle más tiempo. Pero ahora creo que estoy listo para saltar y darle un giro. No es que sepa todo aquí. En parte, este blog me ayuda a procesar mi propia comprensión de temas que creo que son importantes (escribir una idea es la segunda evolución de la comprensión después de pensarla).
Tendré que trabajar sobre este tema en el transcurso de varias publicaciones. Mis pensamientos no siempre son lo suficientemente claros como para arrojarlos a todos de una vez. Este es un caso clásico de eso. Así que vuelve y mira lo que pienso en el resto de la historia.
Para comenzar, haré la declaración “El software y los productos son diferentes”.
Creo que debo revelar que al escribir sobre esto, estoy pensando principalmente en productos de software. En el caso de un producto físico (como un lápiz), esta distinción no tiene sentido.
El software y los productos son diferentes. Cuando empiezo a pensar en ello, supongo que tendría que decir que “Producto” es lo de orden superior, y el software es una cosa de orden de componentes. Con esto quiero decir que el Software puede ser un componente de un Producto . Al decir esto, quiero decir que un producto tiene muchos más atributos con los que debe preocuparse además de la calidad o el diseño del software que lo integra.
El software suele ser una preocupación de ingeniería. Como estoy en el departamento de ingeniería, es algo a lo que gravito. Me importa mucho la arquitectura y el diseño de software. Sobre las metodologías de construcción. Cosas como el lenguaje de programación y otros marcos son muy convincentes y cosas que considero muy importantes.
Irónicamente, cuando salgo de la ingeniería y hablo con otras personas, no les importan mucho estas cosas. Se preocupan por otras cosas … como cómo instalarlo, o cómo implementarlo en un entorno redundante, o en qué tipo de hardware se ejecuta. De alguna manera, estas son cosas que a la ingeniería le importan, pero a otras les importan de manera más profunda y diferente. Pero se vuelve aún más extraño algunas veces. Cuando hablo con otras personas, ellos hablan sobre cómo el software será utilizado por los clientes reales, cómo los problemas que enfrentan parecen cambiar rápidamente, y qué es probable que hagan con el software que no fue parte de las discusiones personales de la persona. . Guau. Eso es parte de este producto también.
El software funciona muy bien en un laboratorio de ingeniería de software … donde todas las características y factores ambientales están bien controlados. Los productos salen al mundo real y tienen que enfrentar situaciones y desafíos inesperados. Esa es una diferencia clave.
Lo dejaré allí hoy y pensaré en algunas diferencias específicas que son particularmente relevantes. Estoy seguro de que algunos ingenieros de software comentarán que “el diseño de software adecuado tiene en cuenta todas estas cosas”. Seguro. En cierto nivel estoy de acuerdo contigo. La definición adecuada de los requisitos trataría de encontrar todos los factores ambientales que influyen en cómo se construye el software. Pero a menudo estoy bastante seguro de que estos requisitos son vagos o que faltan, y dejo que se gestionen algunos desafíos … ya sea por omisión o por comisión.
Interesado en tus pensamientos. ¿Qué piensas?
Fuentes: Dennis Stevenson