
We have already seen how to use Team Foundation Server for source control. I have also mentioned that TFS is much bigger, combining almost all software development tools like project/task management, source control, bug tracker, build management, etc., making itself a revolutionary all-in-one software tool for software development life cycle with Visual Studio. I aim to familiarize you with the team foundation server project management system in this article. Also, I assume you already have some basic ideas and have adapted yourself to source control management.
The Team Foundation Server Project Management SDLC Steps:
The team foundation server has some default software development life cycle steps that can be standardized. Following are the steps given by default:
- New Work Item: A business representative or analyst must create a new work item. Nobody is assigned in this state.
- Requirement Gathering: Once the decision has been made to proceed with a ‘New’ task/work item, it is assigned to the underlying person (BA). The Assignee collects all the needs, creates a detailed FRS document, and attaches the file(s) to the corresponding work item. Now, he/she will assign it to the proper person for review (such as the Team Coordinator).
- Requirement Review Ready: TC will review the requirements and identify all possible issues and questions(if any). Then, he/she will add those comments to the requirement document. If significant information is missing, TC can move the task state back to ‘Requirements Gathering’ and assign it back to BA. If OK, TC will assign a person in the SQA group to review it.
- Requirements SQA Review Ready: An SQA member will review the requirements to prepare the pre-analysis to test this work item. If there is any fault, he/she can return this item to the ‘Requirement Gathering’ or ‘Requirement Review Ready’ state by assigning it to the appropriate person, if needed. If approved, the next state will be ‘Designing’ and can be assigned to TC or a development team development team member.
- 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 it is resolved. All the documents should be added as ‘File Attachment’ associated with the work item. Once the design is done, it should be moved to ‘Design Review Ready’ without starting the implementation.
- 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 in the ‘Designing’ state. If approved, he will move it to ‘Design SQA Review Ready’.
- Design SQA Review Ready: This step is just to make the SQA guy(s) aware of the design. If SQA has any questions, he can ask the document’s designer. He will generally approve it and assign it to TC/developer with the ‘Coding and UT’ state.
- Coding & UT: We need to get the latest code from the TFS source control repository with a shared lock. Developers themselves will do the necessary UT. When done with this state, the developer will create a shelf set and put it into TFS, referring to this item, and move to the next state for review of the implementation.
- Coding & UT Review Ready: The reviewer will review the codebase. Feedback, questions, concerns, changes, corrections, etc., go through the history messages. There can be several interactions between the reviewer and the developer. When satisfied, the reviewer will state ‘Coding & UT Approved’ and assign it back to the developer.
- Coding & UT Approved: The developer will get the latest changes from TFS, merge his/her changes, build the solution/project, and check the working code for TFS. While checking in, it must be ensured that the code can be built in another developer’s workstation. The developer will set the next state to ‘Checked Into Prod’ by assigning it to an SQA person for testing.
- Checked into Prod: SQA will test the item with UT, mock, regression, etc. Then, he/she will create a ‘New’ bug item with the issues he/she found against this item.
- Closed: The work item is being closed after correctly following all the procedures above.
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 does have support for it. It’s customizable, and you can revise the system to suit your needs. I will share some customized steps for SDLC, followed by a world-renowned company I know of. This exemplifies how you can modify/simplify the TFS system to fit your needs. lets see the steps:</abbr=”team>
- Requirement Phase: All requirement gathering/review processes are done in a single stage by switching assignees from one to another.
- Design Phase: Design, design review ready, design SQA review ready, all steps are combined into one stage.
- Implementation Phase: Coding and UT, Code and UT review and check into production stages are joined together.
- System Testing Phase: The phase where SQA does the test. Notice that the previous workflow didn’t include this stage. Because for SQA workflow, the team foundation server has a separate architecture itself. But, for small projects/teams, instead of such a vast SQA process, we can combine that here.
- Closed: After SQA complete the testing, the item goes to the closed stage.
Well, I would like to add that, in the customized version, it’s possible to keep track of whether an item is reviewed, ready, etc. For that, checkboxes/drop-downs can be used in a simplified window (we will see such examples in my future article).
After a work item is closed, it doesn’t mean it’s fully featured or bug-fixed. Bug fixing has a separate life cycle, which I want to discuss later. But just to let you know, the above process just completes a work item’s life cycle without bugs fixed.
References:
Microsoft released Visual Studio Team Foundation Server Express 2012, free and may help you practice or explore at home.
I have discussed the basic theoretical concept of how you will proceed as a team member working under the team foundation server project management system. I plan to work on a separate tutorial, where I will explain some hands-on exercises with screenshots, etc, so that you can have an advanced practical overview. You can subscribe via email, Facebook, or Twitter to get notified. Let’s help the world follow some suitable software development methodologies. Happy coding 🙂
Discover more from CODESAMPLEZ.COM
Subscribe to get the latest posts sent to your email.
Hi bro. I just want to know if you can publish hard copy for this post? and everything that might be of use in my paper. Thanks.
For more references and detailed journal check out Software Development Life Cycle
Brilliant article!! I appreciate your blog. You have explained it very well. Thanks for sharing this post.