SDLC Overview Of Team Foundation Server Project Management System

We have already seen, how we can use Team Foundation Server for source control. I have also mentioned that, TFS itself is a much more big combining almost all software development tools like project/task management, source control, bug tracker, build management etc, making itself as a revolutionary all in one software tool for software development life cycle with visual studio. Here, in this article, my goal is to get you familiar with team foundation server project management system in brief. Also, I am assuming, you have some basic idea and adapted yourself with the source control management already. Managing it all can be tiresome, a systematic 30 60 90 day plan is an ideal way to go.

The Team Foundation Server Project Management SDLC Steps:

Well, team foundation server comes up with some default software development life cycle steps, that can be used as a standard. Following are the steps given by default:

1. New Work Item: First, a new work item need to be created by business representative or analyst. Nobody is assigned in this state.
2. Requirement Gathering: Once decision has been made to proceed for a ‘New’ task/work item, it is assigned to underlying person (BA). The Assignee collects all the needs, create a detailed FRS document and attach those file(s) to the corresponding work item. Now, he/she will assign it to proper person for review (such as Team Coordinator).
3. Requirement Review Ready: TC will review the requirements and try to identify all possible issues and questions(if any). Then, he/she will add those comments in requirement document. If there are any significant information missing, TC can move the task state back to ‘Requirements Gathering’ with assigning back to BA. If OK, TC will assign a person in the SQA group, who will review it.
4. Requirements SQA Review Ready: SQA member will review requirements to prepare the pre- analysis to test this work item. If there is any fault, he/she can turn back this item to ‘Requirement Gathering’ or ‘requirement Review Ready’ state by assigning to appropriate person, if needed. If approved, the next state will be ‘Designing’ and can be assigned to TC or a development member of the development team.
5. Designing: All the design documents should be completed (there can be PoC, sample Code diagrams etc). If there is any major flaw in the requirements, it can be moved back to ‘Requirement Gathering’ until get resolved. All the documents should be added as ‘File Attachment’, associated with the work item. Once designing is done, it should be moved to ‘Design Review Ready’ without starting the implementation.
6. Design Review Ready: The reviewer will check the document and may contact the designer for scenario clarifications/issues. If there are any flaws, he can put it back to ‘Designing’ state. If approved, he will move it to ‘Design SQA Review Ready’.
7. Design SQA Review Ready: This step is just to make the SQA guy(s) be aware of the design. If there is any question from SQA, he can ask the designer of the document. He will generally approve it and assign it to TC/developer with ‘Coding and UT’ state.
8. Coding & UT: Need to get latest code from TFS source control repository with shared lock. Developers themselves will do the necessary UT. When done with this state, the developer will create a shelve-set and put it into TFS with referring to this item and move to next state fore review the implementation.
9. Coding & UT Review Ready: Reviewer will review the code-base. Feedback, questions, concerns, changes, corrections etc go through the history messages. There can be several times of interactions between the reviewer and developer. When the reviewer is satisfied, he will move to state ‘Coding & UT Approved’ with assigning back to the developer.
10. Coding & UT Approved: Developer will get the latest changes from TFS, merge the his/her changes, build solution/project and finally check in working code to TFS. While check in, it must need to be ensured that, code can be built in another developer work station. Now, developer will set the next state to ‘Checked Into Prod’ by assigning to a SQA person for testing.
11. Checked Into Prod: SQA will test the item with UT, mock, regression etc. Then, he/she will create ‘New’ bug item with the issues he found against this item.
12. Closed: The work item is being closed after following all the procedures above properly.

Customizing The SDLC Steps:

Well, for several reasons, many companies may not afford to or want to follow all these steps or have their own rule for other kind of project management which they want to reflect on <abbr=”team foundation=”” server”=””>TFS project management as well. A TFS project management system do have support for it. It’s totally customizable and you can revise the system as per your own needs. I will, share some such customized steps for SDLC which are followed by a world’s renowned company I know of. This can be an example how you can modify/simplify the TFS system for your own needs. lets see the steps:</abbr=”team>

• Requirement Phase: All requirement gathering/review process are done in single stage, just by switch assignee from one to another.
• Design Phase: Design, design review ready, design SQA review ready, all steps are combined together into one stage.
• Implementation Phase: Coding and UT, Code and UT review and checked Into production stages are joined together.
• System Testing Phase: The phase where SQA does the test. Notice that, the previous workflow doesn’t include this stage. Because for SQA workflow, team foundation server has a separate architecture itself. But, for small projects/team, instead of such vast SQA process, we can combine that into here.
• Closed: After SQA complete the testing, item goes to closed stage.

Well, I will like to add that, in the customized version as well, its possible to keep track whether an item is reviewed or not, ready or not etc. For that, check-box/drop-downs can be used on a simplified window (we will see such examples on my future article).

After a work item get closed, it doesn’t mean that, it’s fully featured/bug fixed. Bug fixing has its own separate life cycle, which I will like discuss sometime in the future. But, just to let you know, the above process are just complete a work items life cycle, without bugs fixed.

References:

Microsoft released free Visual Studio Team Foundation Server Express 2012, which is free and may help you practice/explore at home.

I have discussed the basic theoretical concept how you will go ahead as a team member working under team foundation server project management system. I am planning to work on a separate tutorial, where I will explain about some hand on exerciser with screenshots etc so that you can have the advanced practical overview. You can subscribe via email/Facebook/twitter to get notified. Lets help the world to follow some good software development methodology. Happy coding 🙂