Let me take you into my world and show you, dear reader, what it means to have an architecture. That is to say, a software application architecture that is associated with a framework based on simple development patterns. (Design patterns are fine for IT organizations that wish to justify their own existence. Development patterns are for getting the heavy lifting done.)
Richard: Business Analyst
Myles: Senior Developer
Noah: Junior Developer
Kelley: Quality Assurance and Testing
There are others but they mostly just count the beans and bullets.
Richard has completed his first draft of the business and functional requirements. These are passed off to Chuck who goes into a cave to read them unimpeded. When he returns, he has lots of questions, mostly about implementation of specific requirements or the delta of one part of the requirements to another. These questions answered, he tracks down Myles for some design session madness. By the way, if Richard is worth is salt, he has provided Chuck with some prototypes as well to show off what the client expects the application to look like. Chuck and Myles go to town with:
- Their existing architectural patterns
- The overall understanding of the system parameters
- The prototypes
- A listing of the most difficult (or complex) challenges the application must address
Step 1 is determining the patterns. Chuck and Myles have patterns for listing data, searching data, editing single record entities, editing lists, navigation control, business rule validation, state management, security and a short stack of other things. Each of these development patterns has its inputs, outputs, event model and templates defined so they know exactly what each is used for and, more importantly, what each is NOT used for.
Chuck and Myles go through the requirements and categorize each screen or section of the application into the development patterns it will use. Anything that does not fit an existing pattern is the 20 side of 80/20 and is set aside for independent address later on.
Step 2 is the decision-making process to decide what to do with the 20% non-pattern entities. Each is evaluated to determine if it is truly a one-off or if the solution may generally happen again in another system. If the former, the item is assigned to Myles for development. If the latter, Myles and Chuck perform an independent design session to determine a new pattern to be added to the list. Myles codes the piece according to the pattern and his work becomes version 1 of the template for that pattern.
Step 3 is the review with Richard, Chuck and Myles. In this session, Myles and Chuck review how each interface will actually work with Richard. Richard can then either determine that a particular methodology will not work or adjust requirements to support the design. Richard can now flesh out the business and functional details of the rest of the application knowing how each piece will interact with others and how they will function as a unit.
Step 4 is the "final" requirements review with Chuck, Richard and Myles. At this time, all portions of the application will have been completely discovered and the functionality expected will be recorded. Chuck and Myles will go back into the cave to finalize the details of all interfaces. Everything must be covered.
Step 5 is assignment. Chuck divides sections of the application by pattern between Myles, Sharon, Mike and Noah. Patterns are assigned based on their inherent complexity compared to the experience of the developer. When a developer has not encountered a pattern they are responsible for, they will review the design documentation and templates for that pattern based on the platform (win/web) and proceed.
Step 6 is initial development. This stage of the application is more about data gathering than getting work done. Each team member is tasked with estimating how long an item of a specific pattern will take. He then actually develops and internally tests it until it is complete. When complete, he reports back to Chuck with the time it took. That developer should also understand the +/- factor of how long a more or less difficult implementation should change that base time estimate. It should also be expected that as the developer works more items, he will become more proficient at it. Sort of a software factory (heh).
Step 7 is real development. Chuck has baselines for all patterns for all developers. He can now plan how long the development phase will take with reasonable accuracy and granularity. Each developer knows how to do their job and only the skyline issues are raised to Chuck or Myles for decision making. When complete, each task is reported back (with development times) to Chuck who adjusts the schedule as appropriate. When a task is reported complete, Chuck will also review the average time that developer is taking to do that job and determine if the base estimates are still reasonable.
Step 8 is QA. Kelly understands the requirements and the patterns. She knows that there are very specific rules as to how the parts of the system can interact. Therefore, her first task is to smoke test the entire application looking for things that do not conform to known patterns. When she finds something, she tests this as early as possible in her cycle. This allows the highest risk portions of the application to get back to the developers for bug fixes as early as possible.
Kelly then continues to test the application in logical fashion and, when defects are found, they are directed to the developer who worked each one. The time to bug fix an item is added to the time estimate to perform the development of that pattern. Then, in future versions of that architecture, Chuck can raise a flag when a developer finished a given interface of a specific pattern much too early and QA it in development himself. The result may be that a developer is just that good or it may be that he is lazy.
Simple, no? Looks good on paper. The real trick here is getting everyone singing the same music at the same time. Well, that and figuring out what to do when you start with no development patterns at all...