The software architecture has always been known as "the physical design of the software system to be developed" with a great deal of emphasis on the structure of the components and the technology that will be used, at least where I have worked. However, this article mentions some important points that I would like to highlight:
1. It must be understandable for all the people involved in the development of the system, thus becoming the highest level abstraction understandable by the entire work team. This makes it easier for everyone to know where they are digested and make a better work plan.
2. The software architect must be involved with the process and follow up the people involved, serving as a guide for the project.
3. The architecture is based on the most important aspects of the system and this depends on the context, therefore the architecture of a system A can differ greatly in the aspects that it considers with respect to the architecture of a system B.
Finally, the idea of eliminating architecture by reducing the difficulty of changing components at late stages seems interesting to me. Personally I am involved in the agile paragidma of project development, so this idea I think can be implemented not only in software projects but in others that, as mentioned in the same article, are not limited by physical laws but only for imagination, creativity and human capacity. I believe that, although making the systems easier to modify in the future implies an increase in complexity, it allows for better maintenance, selecting the technologies and decisions that best fit the progress of the project and ending with a better final product . That is, to involve the agile paradigm not only in the way in which the project is developed (activities, meetings, changes, etc.) but also in programming (components, classes, methods, etc.).
No hay comentarios:
Publicar un comentario