Paul's Software Development 101

It has been a while since I have been an actual line manager for a Software Development organization but I have had several directors and managers who work for me now or have recently worked for me who always want to know what I think works as a software development process. I think that people make this task so difficult where it is really simply 10 steps that need to be done and refined. Each organization has different requirements when it comes to communication and development process but over the years I have found that this is what works best.

1. Requirements: In every scenario that I can think of you always need to start with a core set of requirements and then try to refine the requirements into enough detail to make sure you can describe the project and what will need to be accomplished.
2. Functional Specification: This is one of the most difficult things to explain to people how much detail needs to be specified in this document (or wiki which is what my current company uses). Here I like to see state flow and use cases to support the requirements. This is where we start to document the extremely high level flow of the project or program. Also external interfaces are described here and articulated. This document is typically used by QA and Documentation staffs to begin their jobs writing test cases and documentation.
3. High Level Design (HLD): This is the next layer of the onion. Start actual design work on how the program will be written. A lot more detail here. This document will actually break down the functional spec into tasks that will need to be performed to get the project completed. The developers also develop what dependencies are needed for each task at this time. The level of design work depends on the project, requirements and the "newness" of the code. For a brand new project the HLD will most likely look differently than a maintenance or new features on top of an existing project. Typically I like the programmers who are working on a given feature to work on the HLD for that feature.
4. Sizing: In my opinion this is the hardest item to have developers work on. A good manager lets his programmers come up with the time it will take to get all tasks that they are slated to work on and then ask questions on why they chose those times. Most managers who have worked for me in the past struggle with this but it should be done. Not all programmers are able to manage their times correctly. If this is done right it allows for a certain amount of buy in on the tasks and drives accountability down to the programmer. I've noticed that the more I work with a team of developers I learn who is optimistic and who is pessimistic and I arrange my questions for the different type of estimators.
5. Generate Schedule: Next is to get the overall schedule generated for the project. Take the tasks, dependencies, resources and times and map them out either in a product like MS project or even on a white board (which is sometimes easier the first time around).
6. Develop the code: This is what most developers want to start on first. Not always the best solution. All of the work above should be done first.
7. Integrate: Integration of tasks needs to be done. I prefer to have development handle the integration testing. The use cases from the Functional Spec should be used to perform these tests.
   
8. System Test Drops: When specific functionality is completed it should be packaged up and sent to a QA System Test group so that they can run their test plans against the completed code. Early on not all functions will be complete but a build report should be sent from development letting QA know what areas of the product are to be tested. I will typically have this all pre-built during the scheduling phase above so system test knows ahead of time what tests to set up for.
9. Fix bugs: There will always be bugs to fix. Dev should stick some time in the schedule to fix bugs after each drop to System Test. Typically this is a cyclical process so #'s 6, 7, 8 and 9 happen until all code is written and then a cycle of #'s 8 and 9 until the product is ready to release.
   
10. Release: Whoo Hoo, we are almost done. I will typically make sure at this point that all code has been properly documented along the way but I always go back at about this time and evaluate if there is any additional documentation we need to create for the project before tackling the next project.
    

So why bring all of this up??? My current teams seems to struggle with some of these aspects. Also the level of detail at each does vary based on requirements, size of development group and complexity of the project and people always seem to go do deep or not nearly deep enough. I actually am not a big fan of long drawn up processes but I know that in general if you follow these steps it makes development much faster and allows other support organizations get the data they need sooner (like Tech Pubs, System Test, Training, Customer Support, Sales, etc).