In this video, we are going to talk about how the attribute-driven design process can be integrated in the larger software development process that is happening at a company. There are a couple of stages in the software development process that all projects go through. It doesn't matter which project management method they are using. All projects go through a requirements or analysis phase, where the project is defined and you analyze what a customer needs. In the design phase, you design the software you are going to make which can include graphical design or architectural design with also a network or hardware design. In the implementation phase, stuff gets built, and code is written that will be used for the end products. Of course, we need to verify whether the product made fulfills the requirements, so we have a verification phase, in which several checks, automated or not, happen. And in the last phase, the product is delivered and in production, and some maintenance needs to happen to keep it up and running. The difference between several software development processes is the way the project goes through all these different phases. One way to do this is going through the steps in a sequential order. This is how the waterfall development process works. Just like a waterfall, you only go down the line to the next step. Waterfall development was a default way of developing software in the early days of programming. Nowadays, it is mainly used in very big projects with very high stakes and clear requirements. Such as aerospace projects. When using waterfall development, all the requirements from the different stakeholders are gathered in the requirement phase before continuing to the design phase. When the design phase is started, these requirements are final and you can start to attribute driven design or ADD process knowing that they will not change anymore. You can design the whole system in detail by going through all the iterations of the ADD process until all the requirements are met. In some projects, this strict waterfall process is not needed and you can allow going back and forward between subsequent phases. In that case, the requirements can still change and you might execute ADD process on the higher level but only dive into the details once the requirements are somewhat fixed. If you go back and forth between different stages, watch out for inconsistencies and the design. Changing one module of the system can have an impact on other modules, as well. And if you don't do a double check on the system as a whole, you might end up with a messy architecture. In the last years, Agile development has gained a lot of popularity when it comes to developing software projects. Agile software development is a group of methods that promotes adaptive planning, incremental development, early delivery, and flexible response to change. It is particularly popular in startups since they need to go to market fast to validate their assumptions on the users wants and wishes. This first changes are not possible with a waterfall process. Agile software development processes follow the Agile Manifesto which contains four basic general rules out of which more specific guidelines are created for the different sets of methods like extreme programming or scrim. The Agile Manifesto values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan. While the items on the right are still valued, the items on the left are valued more. Many people conclude that the ADD process is the opposite of what the Agile Manifesto is saying. But that is not true. If you apply ADD as you would in the waterfall model, which is as a sequential process that needs to be followed completely before going to the next phase, it is true, but there are other ways to apply it, as well. Software architecture design can help Agile developers to make the changes that are needed, without impacting other parts of the software. If the software would be one big block of code without structure, it would be a cumbersome task to make changes frequently. A good architecture does support this agile process. When applying ADD in an agile process, you won't go over the design process several times. They will not be only be loops inside the ADD process but also over the total design process of requirements, design, implementation, and testing. The architecture will be build and elaborated incrementally base on the new or change requirements. When software architects create a software architecture in a well-defined development project, their goal is to create a detailed architecture for the whole system, to reduce the risks as much as possible. But there is not always a need to reduce all the risk. Sometimes a trade off needs to be made between the amount of effort that goes into the process that changes that might happened later on and reducing the risks on design problems. In that case you need just enough architecture to reduce that risk. But how much architecture is just enough? That depends from project to project. Let's make the analogy with building a house. If you want to build a skyscraper, you need a detailed design of the structure of the building. Otherwise, problems can occur that make the building unstable. The structure needs to be figured out fairly well which results in many documents like technical drawings and calculations. But if you want to build the dog house, you probably don't need that much detail. You make a back of the envelope drawing of the structure and the measurements, and that might be enough already. If the structure fails, no real harm is done. For each of your projects, you should consider how much architecture is needed, at what point, and apply the ADD process up until that point. Together with just enough architecture principal, we want to talk about the YAGNI principle. You Ain't going to Need It, which relates to the documentation. Only make as much documentation as needed. Since there is no need in losing time overwriting documents that are never going to be read anyway. Or the change so often that they are hard to keep up to date. Documentation can be as simple as a diagram with blocks or some bullet points that is some responsibilities of a component. You don't always need an elaborate document. So remember, that software architecture design fits in many project management processes and can be adapted to your own needs and wishes.
