the software pattern most example course choose books architectural appropriate architecture design-patterns

architecture - software - ¿Se está adaptando para cumplir con los cambiantes requisitos comerciales?



software architecture example (9)

¿Ideas sobre cómo desarrollar software que sea capaz de adaptarse para cumplir con los cambiantes requisitos comerciales? Cualquier patrón, arquitectura, etc. Posiblemente algunos ejemplos anecdóticos serían geniales. Esto es más una encuesta que una pregunta concreta. Gracias

(casi) todos los programas tienen requisitos comerciales cambiantes. Tratar de negociar con el cliente (el gerente de marketing o de producto también son clientes) es importante, pero nunca lo suficiente. los requisitos siempre cambian Scrum tiene muchas técnicas para gestionar los cambios en los requisitos. esta es una excelente introducción al video de scrum. vale la pena tu tiempo

Considere a qué escala están cambiando los requisitos del negocio:

  • si los requisitos a pequeña escala cambian frecuentemente, es decir, las personas cambian de opinión sobre lo que quieren, pero lo que deben hacer realmente no ha cambiado, adopten prácticas ágiles y mantengan sus iteraciones muy cortas (tan cortas como iteraciones de 1 característica, si es necesario) para llegar a completar algo!)
  • si los requisitos a gran escala cambian a menudo, es decir, qué infraestructura se necesita para dirigir el negocio, esto puede ser un reflejo de los cambios en los caprichos de la administración (lo que yo considero el "síndrome del último vendedor"). Del futuro). Si participa en estas decisiones, intente reducir los problemas técnicos a los fundamentos (comunicación, almacenamiento, computación, interacción, acceso, ...) y no se distraiga con campanas y silbatos de nivel de producto. Recuerde que no es probable que nada encaja al 100%, pero el costo de cambiar de parecer con demasiada frecuencia puede ser mayor que el beneficio de cambiar de plataforma o arquitectura. Si no has participado en estas decisiones, no hay mucho que puedas hacer al respecto, excepto aprender rápidamente y gentilmente alentar un compromiso más profundo cuando puedas ;-)
  • Si la naturaleza del negocio cambia a menudo, es decir, se necesitan nuevas líneas de negocio cada pocas semanas, líneas antiguas consolidadas, etc., y usted participa en las discusiones en este nivel, puede intentar anticipar los cambios futuros investigando más profundamente en el planes de la compañía Si no participas en este nivel, intenta ser flexible e invaluable hasta que encuentres trabajo en una empresa más estable ;-)

Me parece que el código específico es mucho más variable que el código generalizado y abstracto . Entonces, si desea un código que sea modificable, adhiérase a un código específico y evite la metaprogramación.

Dentro de 6 meses es probable que nadie comprenda el caso de uso real de esos métodos generalizados y abstractos y tenga miedo de cambiarlos.

Querrá utilizar un proceso de desarrollo Agile si este es su entorno de desarrollo.

Como parte de este proceso, es probable que desee tener continuamente un sistema que funcione para mostrarle a su cliente para que pueda hacer las correcciones de curso en el camino. Les ayudará a comprender qué progreso se está logrando y dónde se encuentra. Pero lo más importante es que les dará una mejor comprensión de cómo funciona el sistema con los requisitos comerciales actuales y cuáles serán los impactos de sus nuevos cambios.

Solo tenga cuidado de no hacer que su prototipo sea visualmente atractivo. Si un prototipo se ve pulido de forma gráfica, existe una buena posibilidad de que la gente de desarrollo empresarial piense que el software es mucho más completo de lo que realmente es. En su lugar, recomendaría intentar que se vea menos pulido y centrarse más en las características. Por ejemplo, si está trabajando en Java Swing, hay una gran apariencia que se llama Servilleta que ayuda con esto. TI le permite construir tanta funcionalidad como desee, pero la pantalla se ve como dibujada en una servilleta. Entonces la atención y el enfoque de las personas están en la funcionalidad, no en los detalles gráficos.

Tratar de diseñar un sistema genérico que se pueda adaptar fácilmente a las necesidades cambiantes simplemente no funciona. Como Mark sugiere, todo el movimiento ágil surgió al darse cuenta de que el código específico simple es más fácil de adaptar que el código genérico, siempre que esté bien escrito y sea fácil de mantener.

El Diseño Dirigido por Dominio es un buen enfoque para esto, con un buen libro para ayudarlo a ponerse en marcha.

Un gran enfoque de este enfoque son los circuitos de retroalimentación ajustados entre el modelo de dominio en desarrollo utilizado en el software, y el "mundo real" real que está modelando, por lo que un mundo real cambiante está bien.

Considere un motor de reglas de negocios. No siempre es apropiado, pero puede ayudar a separar la lógica de negocio y los requisitos de su arquitectura / solución técnica. Por ejemplo, imagine que tenía un requisito para establecer la clasificación de seguridad de un automóvil en función de un conjunto de resultados de prueba. Las pruebas realizadas en el automóvil podrían cambiar, al igual que los criterios de clasificación (incluido el número real de clasificaciones, por ejemplo, de un sistema de 5 estrellas a un sistema de 10 estrellas). Dado este escenario, un motor de reglas de negocios podría ser una buena forma de clasificar un automóvil.

El motor de reglas se suministraría con reglas basadas en texto o XML que, al menos en teoría, podrían ser escritas y mantenidas por personal que no sea de programación (por ejemplo, un analista de negocios). Esas reglas se aplicarían a un objeto Car (suponiendo que el objeto Car contenga una referencia a un objeto TestResults ). El motor de reglas / reglas analizaría los resultados de la prueba y configuraría la propiedad SafetyClassification de SafetyClassification del objeto Car consecuencia.

Las reglas reales podrían residir en una base de datos o ubicación compartida, o incluso suministrarse al sistema a través de una infraestructura de mensajería o llamada de servicio web. Se podrían suministrar nuevas reglas al sistema y activarlas sin recompilar / redistribuir el sistema.

Las diferentes tecnologías tienen motores de reglas diferentes disponibles. E, g, .Net tiene Drools.Net, el motor de reglas de WWF, y algunos otros. Java tiene reglas de JBoss y muchas otras.