Blog

How to Write an Effective Design Document Why write a design document? A design document is a way for you to communicate to others what your design decisions are and why your decisions are good decisions. Don’t worry if your design is not UML compliant and don’t worry if you didn’t use a special modeling tool to create it. The biggest factor that determines if your design document is good is whether or not it clearly explains your intentions. This presents a problem, however. In order to convey design decisions, you have to consider the audience that you are writing for. A peer developer will understand why a well-crafted class abstraction is a good design, however your manager will probably not. Because your peer developers and your manager have different concepts of what makes a design good, there is a need for two design documents; one for peer developers and one for managers. Each document serves a different and equally valuable purpose as you begin your project development. I

Technical design document template   1. General 1.1. Project general description 1.2. Solution general description 1.3. Guidelines from the functional design 1.4. Development guidelines. 1.4.1. Best Practices. 1.4.2. Standards. 2. Architecture 2.1. Physical architecture          2.1.1. Diagram 2.2. Logical architecture          2.2.1. Application server architecture          2.2.2. Services server architecture          2.2.3. SharePoint / Web architecture 3. Database 3.1. General description 3.2. Tables list 3.3. Database diagram 3.4. Views 3.5. Stored procedures 3.6. Triggers 3.7. Jobs 4. Infrastructure 4.1. General 4.2. Logging handling 4.3. Auditing and tracing handling 4.4. Exception handling           4.4.1. General           4.4.2. Custom Exceptions 4.5. Monitoring 4.6. Data Access           4.6.1. General           4.6.2. Typed Datasets 4.7. Common           4.7.1. Common Enums           4.7.2. Common Objects

Architecture Requirements are Ilities The business analyst(s) will collect the functional and system requirements. The architecture has other requirements. It is the job of the software architect to find and talk to the right people about them -- the system "ilities." An "ility" is a characteristic or quality of a system that applies across a set of functional or system requirements. So, performance is an "ility" because it is applied against some of the functional or system requirements. Anything that can be expressed in the form "for a set of functional or system requirements, the system must fulfill them this way (this fast, this reliable, etc.)" is an "ility." It is not always easy to help the users find all of the ilities that they are assuming apply to their current system or will apply to the new system. You might try using this list of ilities that commonly come up to jump start the conversation. Review i

Introduction Me and my wife had some interesting conversations on Object Oriented Design principles . After publishing the conversation on CodeProject, I got some good responses from the community and that really inspired me. So, I am happy to share our next conversation that took place on Object Oriented Design Patterns. Here it is. What is a Design Pattern? Shubho : I guess you already have some basic idea about Object Oriented Design principles. We had a nice talk on the OOD principles (SOLID principles), and I hope you didn't mind that I published our conversation in a CodeProject article. You can find it here: How I explained OOD to my wife . Design Patterns are nothing but applications of those principles in some specific and common situations, and standardizing some of those. Let's try to understand what Design Patterns are by using some examples. Farhana : Sure, I love examples. Shubho : Let's talk about our car. It's an object, though