requirements - resumen - ¿Por qué tantos sitios discuten la programación en lugar de describir los sistemas que están tratando de producir?
sistemas del cuerpo humano wikipedia (12)
Hay muchos sitios que enseñan a las personas a construir un mejor software, pero ¿por qué hay muy pocos sitios que realmente brinden descripciones detalladas de los dominios que nosotros (como programadores) debemos crear? Uno solo puede construir tantos sistemas de inventario, contabilidad y ERP antes de que un patrón de requisitos comunes comience a emerger entre los diferentes tipos de sistemas. Lógicamente hablando, si los programadores pasan tanto tiempo intentando crear componentes reutilizables en sus arquitecturas, ¿eso implica que deberían tener algún "modelo" reutilizable que describa los sistemas que se supone que deben crear? En otras palabras, parece que el enfoque del desarrollo de software se ha centrado demasiado en "cómo" se debe construir el software en lugar de catalogar y especificar con precisión (con requisitos detallados) "qué" debería usarse en primer lugar.
Así que mi pregunta es esta: ¿se ha hecho algún trabajo para catalogar todos los diferentes tipos de especificaciones del sistema en un solo lugar, todo en un solo sitio? Si carecer de los requisitos adecuados al inicio del proyecto es una de las banes del desarrollo de software, ¿no tendría más sentido poder ''reutilizar'' las especificaciones de requisitos de sistemas anteriores del mismo tipo que ya se han escrito?
Consulte el Libro de recursos del modelo de datos de Len Silverston:
Se acerca al diseño reutilizable desde el punto de vista del modelo de datos, a diferencia de los requisitos del usuario final o los diseños OO. Sin embargo, considero que es muy útil: una vez que tienes una buena comprensión del modelo de datos, tienes un gran salto en los requisitos y las entidades que eventualmente se modelarán como clases.
En mi experiencia en la que se desmorona, los casos de uso abarcados por la interfaz de usuario. De hecho, he diseñado y construido un sistema de inventario que se ha aplicado en una amplia variedad de organizaciones e industrias (telecomunicaciones, productos alimenticios, cuidado de la salud, fabricación y distribución de productos electrónicos, productos de consumo, indumentaria, aeroespacio, entre otros). Después de la primera mitad docena, surgió un buen modelo de datos que ha servido con poca variación (extensión, pero no variación) para todos ellos.
Pero incluso dentro de una industria, por una serie de razones (naturaleza del producto, variaciones de volumen, tamaño promedio de entrada y salida, requisitos contables, motivación de los empleados, etc.), la forma en que el trabajo es realizado por personas reales varía enormemente: por buenas razones
Tenga en cuenta que los ejemplos sobre todo parecen referirse a niveles de abstracción más profundos, específicamente modelos de datos, donde los programadores podemos hacerlo a nuestra manera, en nuestro beneficio. Mientras más cerca del usuario nos movemos, más nuestros intereses necesitan ser secundarios a los suyos.
Ejemplo del peor de los casos: ¿Alguien más ha notado el patrón en los sistemas de programación de empleados e informes de horas de trabajo para mostrar una semana por pantalla y formularios de entrada de datos en varias pantallas?
Estoy completamente de acuerdo, ¿dónde está la ''Guía del Maniquí para inventariar las TI'', el modelo de datos acreditado para clientes, direcciones y detalles de contacto, etc. He descubierto que estoy implementando el mismo código en muchos lugares diferentes, con campos sutilmente diferentes y lógica, pero básicamente lo mismo. Hace unos años, encontré un sitio de modelos de datos precocinados, un pequeño paso en la dirección correcta, pero no la historia completa Modelos de datos universales (sin conexión). Notarás que no han tenido mucho interés en su producto.
También trabajé en un par de organizaciones que estaban desarrollando su propio modelo de datos ''universal'' como un producto vendible. Una estaba en el dominio de los servicios financieros, y llegaron a más de 1500 tablas de DB2 y se rindieron. Las organizaciones se enorgullecen de ser únicas, mientras que nosotros (los técnicos) nos damos cuenta de que bajo la sombra la mayoría están haciendo cosas muy similares. Creo que podría ser demasiado dañino para el ego corporativo fingir y admitir que son iguales a todos los demás. usando UniversalCustomer (TM) 1.7. También eso hace madurar a estas empresas por un poco de SAP, Peopleware, etc.
Como reflexión final, aquí hay muchas cosas que los empresarios no quieren decir. Un conjunto decente de libros cortos que describen dominios comunes. Me refiero a cosas súper simples, nombre de personas, dirección, teléfono, etc., con todas las pequeñas debilidades como el título en diferentes culturas y el diseño del número de teléfono manejado, ahora hay un libro / wiki que mucha gente podría usar.
Hay un sitio de Respuestas a la base de datos que intenta proporcionar soluciones para diseños de bases de datos comunes. Eso no es lo mismo que una solución completa como la que está describiendo, pero es un paso en la dirección correcta.
Comenta que "[o] ne solo puede construir tantos sistemas [...] antes", lo común se vuelve obvio. Sin embargo, aquellos que han construido suficientes sistemas de este tipo para detectar las características comunes, intentan beneficiarse creando su versión del sistema común y luego lo venden. No es (se percibe que sea) en su interés darles una mano a otras personas que podrían hacer lo mismo.
Hay varios esfuerzos de los gobiernos para tratar de estandarizar los modelos de datos para permitir el intercambio entre diferentes agencias, pero estos tienen poca o ninguna adopción fuera de donde se requiere. En Canadá, por ejemplo, tenemos CPSIN .
Hay, pero generalmente son administrados por proveedores que desean venderle una solución. : - /;
Sería inviable. La primera afirmación que inevitablemente recibes de alguien que distribuye una RFQ para un sistema es: "No somos como otras compañías. Nuestros requisitos son únicos". (Y nunca lo son en realidad)
Si va a reutilizar los requisitos, también podría reutilizar el código. Pero en un nivel inferior, creo que lo que estás buscando serían "patrones de requisitos", en la línea de "patrones de programación".
Ahora, aquí hay un libro de Microsoft sobre el tema, pero como con todos los patrones de dominio, la idea es que crezcan orgánicamente y se ajusten a las necesidades de los usuarios y expertos del dominio. Si quieres la verdadera fuente de la idea, echa un vistazo al libro seminal sobre patrones , aunque es de Arquitectura y no de programación, sorpresa sorpresa :)
Es posible que desee verificar los Patrones de arquitectura de aplicaciones empresariales de Martin Fowler: aunque no son especificaciones, parece tratarse del tipo de cosas que busca.
Descargo de responsabilidad: no lo he leído, solo sé de su existencia.
Hubo un gran movimiento de "reutilización de software" en los ''80 y principios de los 90. Había una considerable industria de personas que creaban y ajustaban catálogos de componentes de software. Fue visto por muchos como el futuro del software. Una buena descripción general es Will Tracz "Confesiones de un vendedor de software usado"; términos de google "Brad Cox Software IC", "Martin Griss". Según recuerdo, se declaró la victoria y todos pasaron a otros problemas.
Veo que la "Revolución industrial del software de Brad Cox" está en línea:
http://www.virtualschool.edu/cox/pub/PSIR/
Sería bueno tener un repositorio central de patrones de código, toda la variedad de idiomas. Entonces podemos mostrar nuestro increíble código, hacer que sea más fácil aprender el uno del otro, y también mejorar la calidad general del código al tener buenos ejemplos de servicios / productos xyz.
Quiero decir, ¿cuántos de nuestros proyectos de codificación son tan únicos que nadie más lo ha hecho?
Mi suposición aproximada es que el 98% de nuestro trabajo es material que ha sido realizado por otras personas en muchas compañías diferentes, industrias similares, necesidades funcionales similares.
Quiero decir, este es el tipo de cosas que debería tener detrás. No solo compartir y hablar sobre problemas, sino también aprender de los códigos de los demás.
¿Quién crearía tal cosa? ¿Quién lo usaría ?
Cerca de lo que puedo decir, estás hablando de una biblioteca de diseños de aplicaciones. Las personas dispuestas a compartir esos diseños detallados ya lo están haciendo, en forma de especificaciones abiertas o de código abierto. El primero tiende a atraer principalmente a personas y organizaciones que ya participan en la creación de productos que implementan tales especificaciones, o productos que interactúan con sistemas que sí lo hacen. El último ... bueno, ¿por qué molestarse en volver a implementar el diseño cuando puedes piratear la fuente?
Como señala Mark Harrison , hay muchas empresas dispuestas a promocionar sus diseños para sistemas comerciales comunes. "Compre nuestro sistema y únase a la funcionalidad necesaria para su organización", le dirán; "¿Por qué perder tiempo re-implementando algo que ya hemos hecho?" Realmente hay muy poca motivación para que compartan las especificaciones detalladas de implementación, ya que realmente no quieren que usted vuelva a implementar lo que están tratando de venderle.
Finalmente ... Estas cosas realmente no son tan complicadas. O más bien, lo son ... pero la complejidad nace fuera de la miríada de combinaciones de requisitos arcanos que cualquier organización dada podría imponer al sistema. El verdadero trabajo viene al interpretar estos requisitos, construirlos en el sistema base, y por tedioso que sea, es inevitable.