How does Team System work in a real-world scenario? To best demonstrate the tools in action, we'll run through a typical scenario with a fictional software development company called eMockSoft. eMockSoft has recently signed a partnership with a distributor to release their catalog of products. The distributor has requested a secure web service to transmit inventory and pricing information over the web. We will look at the scenario as it applies to the software development life cycle and the Team Systems tools.
Figure 2 illustrates the basic phases of the software development life cycle.
The project leads meet with the sponsor to obtain requirements for the project. From these requirements, the project management team creates a list of specifications and templates. In Team Foundation Server, the project lead creates a new project using a variant of the MSF for Agile Software Development process. The Team Portal, reports, and templates are auto-generated on the server. In Microsoft Project, the lead creates a checklist of work items and assignments. The infrastructure architect receives his or her first work item.
Based on the client specifications, the infrastructure architect uses the Logical Datacenter Designer tool to define the new external service. He needs to open ports on the server to allow outbound web service. The requirements include enabling SSL on port 443. The experts on the operations team conduct a security analysis and approve the changes. The architect then adds the appropriate endpoints and boundaries to allow outbound communication for the service. Finally, he assigns a work item to the solutions architect.
The solutions architect uses the Application Connection Designer to create a model of the secure web service and validates against the network topology using the Deployment Designer. In the past, she would have used Visio for her modeling tasks. Team System enables her to change the design and system in real time and facilitates communication with the infrastructure architects, developers, and project lead. Using the Class Designer, the solutions architect visually sets up the required objects and methods and resolves her work item.
Behind the scenes, the project lead can track the progress of design, including the diagrams that were generated. Based on the specs, he can send tasks to the developers on the team. The project lead has created a project plan on the Team Portal, which reduces the number of required status meetings.
The developer receives his work assignments and the class diagrams that were designed by the solutions architect. The required classes have already been auto-generated as class templates—all the developer has to add is the business logic. He checks the specifications on the Team Project Portal Site: This application requires a secure web service using WSE 2.0. The developer writes the necessary code and does some preliminary testing. At the end of the day, the developer checks his code into Team Foundation version control.
The tester checks her nightly builds and automated tests. She performs Web and load testing, which reveal a few minor coding defects in the developer's work. The tester then fills in a bug work item that is returned to the developer to alert him of the problem.
All the bug reports and work items are tracked by the project lead, who can then provide status reports to eMockSoft's management team. The project lead can instantaneously provide attractive visual reports and metrics thanks to SQL Server 2005 Reporting Services.
Once the project is completed, the solution is deployed. From its initial stages, the solutions architect has already tested the application against the constraints within the target infrastructure. It now falls on the hands of the release manager to deploy the application. The deployment occurs smoothly and in record time.