1. Santosh Shindhe Sr. Architect | Cognizant Technology Solutions

2. Agenda Software development is not easy Expectations Development model Feature Driven Development Model Cognizant’s FDD Cognizant’s FDD and VSTS

3. Agenda Software development is not easy Expectations Development model Feature Driven Development Model Cognizant’s FDD Cognizant’s FDD and VSTS

4. Software development is not easy 1950-60 code and fix (developer demands tools) 1970 water fall – upfront design (teams demand process) 1980 personal computers and reduced cost (teams demand tools again! Along with software distribution) 1990 internet and increased communication with iterative approach (teams demand development tools and process improvements) 2000 – iterative and agile development with increased complexity and geographical spread (team demand process tools, infrastructure, process adoption and familiar environment)

5. Software development is not easy Software development organization Many development methodologies Various infrastructure and tools Project management Changing and unclear requirements Communication challenges Effort variation Involves people

6. Agenda Software development is not easy Expectations Development model Feature Driven Development Model Cognizant’s FDD Cognizant’s FDD and VSTS

7. Product Manager or Client I would like to see progress constantly & frequently I would like to know what can be shipped tomorrow My budget might allow me to do work for next 6 months My current requirement is different than what I had earlier

8. Project Manager I have to provide status How can I show constant progress? Can I be more accurate when it comes to estimation? Can I adopt change in requirements? Let me be ready in case developer A is not in office for next 3 days Who can tell me exact status of a feature?

9. Architect Can we check the response time for application, at least for a scenario? Are the coding guidelines for security standards met? Let me check the code complexity Adhere to the architecture and design guidelines, here is the reference document

10. Developer When did this requirement come, I did not know I have already performed unit testing, it’s just that I don’t know how can I show it Well, I feel it may take 4 days, not sure though Was I suppose to do it?!!! It may impact component A and B, can I tell you tomorrow?

11. Tester Every time I have to customize the test report, it’s a along process Wish there was easy way for me to generate test data Wish I could trace this bug to a feature easily Can I automate testing?

12. Team How can we get better at what we do? Can we repeat the same process again, it has produced good results earlier? I think there are many people and changes in plan and status is not reaching to all. It would be good if I can see the status every day or regular interval without waiting for one to prepare it.

13. Agenda Software development is not easy Expectations Development model Feature Driven Development Model Cognizant’s FDD Cognizant’s FDD and VSTS

14. Ingradiants of Model Process People Tools Infrastructure Technology Budget

15. Inefficient model

16. Good model

17. Essentials of good model Can blend well with organization process Allows customization Focuses on repeatability, consistency and predictability Designed for people and project Can act as early litmus test to identify failure Allows correction based on recent on- project experience

18. Agenda Software development is not easy Expectations Development model Feature Driven Development Model Cognizant’s FDD Cognizant’s FDD and VSTS

19. Feature Driven Development Uses small client-valued functions called “features” Can be implemented in 2-3 weeks Enables inspection, tracking & reporting, course correction

20. FDD - Model Consists of model for the productConsists of model for the product Has requirements, use cases and story board at largeHas requirements, use cases and story board at large Consists of model for the productConsists of model for the product Has requirements, use cases and story board at largeHas requirements, use cases and story board at large

21. FDD – Feature list Requirements are translated into featuresRequirements are translated into features The features are ordered and prioritized for realizationThe features are ordered and prioritized for realization Related features can be grouped in feature-setRelated features can be grouped in feature-set Requirements are translated into featuresRequirements are translated into features The features are ordered and prioritized for realizationThe features are ordered and prioritized for realization Related features can be grouped in feature-setRelated features can be grouped in feature-set

22. FDD – Plan Delivery plan is based on featuresDelivery plan is based on features Teams are formed based on feature and technology needTeams are formed based on feature and technology need Delivery plan is based on featuresDelivery plan is based on features Teams are formed based on feature and technology needTeams are formed based on feature and technology need

23. FDD – Design Features are designed progressivelyFeatures are designed progressively Design has to ensure existing implementation is not tarnishedDesign has to ensure existing implementation is not tarnished Features are designed progressivelyFeatures are designed progressively Design has to ensure existing implementation is not tarnishedDesign has to ensure existing implementation is not tarnished

24. FDD – Build Development happens based on featuresDevelopment happens based on features Progress is reported based on featuresProgress is reported based on features Development happens based on featuresDevelopment happens based on features Progress is reported based on featuresProgress is reported based on features

25. FDD – Delivery It is iterative process involving delivery of feature in 2-3 weeks span of intervalIt is iterative process involving delivery of feature in 2-3 weeks span of interval Delivery aims at shippable product consisting of a feature or a feature set consisting of featuresDelivery aims at shippable product consisting of a feature or a feature set consisting of features It is iterative process involving delivery of feature in 2-3 weeks span of intervalIt is iterative process involving delivery of feature in 2-3 weeks span of interval Delivery aims at shippable product consisting of a feature or a feature set consisting of featuresDelivery aims at shippable product consisting of a feature or a feature set consisting of features

26. Agenda Software development is not easy Expectations Development model Feature Driven Development Model Cognizant’s FDD Cognizant’s FDD and VSTS

27. Why FDD? Development model can be used along with Agile or classic life cycle process Allows incremental, repeatable and progressive outcomes Can be applied for small to large scale development teams Allows traceability of feature against a requirement Can be customized for custom business software development

28. Cognizant FDD Extension The design and implementation of a feature should not upset the overall structure Component are also based on design, layers, tiers apart from model. These should focus on NFRs as well. Large scale development teams are usually role based. In ideal scenario developer need not understand the business extensively (most scalable model)

29. Cognizant FDD Extension… Solution more often requires integration with other systems that may not be based on ideal model Provided a model is defined first, the subsequent development can be iterative and better predictable Change management and bug reporting is part of development Additional support for CMM-5 process support and roles

30. Cognizant FDD Extension…

31. Definition phase activities

32. Cognizant FDD Process Flow

33. Cognizant FDD Process Flow… Requirements: Functional and non- functional requirements are gathered and used as input for next stage Definition: Functional requirements as input for model, NFRs as input for architecture definition. Together result in architecture and high level design. Fundamental framework is ready. Feature List: Domain model and functional requirements are the key drivers. Related features may be grouped in to feature-set Plan by feature: Similar to any project management, only difference is it’s focused on features

34. Cognizant FDD Process Flow… Design by feature: Details requirement analysis and expansion. Detailed design including method signature and contracts is defined. 1.Component outside feature are not touched or modified by feature owner 2.On need basis stubs might be created 3.Marks the iterative process Build By Feature: Developer writes code using detailed design along with unit test cases Certify By Feature: QA certifies again functional, NFRs and integration with earlier developed features

35. Cognizant FDD Process Flow… Release: Multiple features are grouped and are ready for release based on project plan Client Valued Functions: A potentially shippable product, not a prototype. Change Request: Unforeseen requirements. These go back to design to ensure integrity Bugs: Goes back to design similar to change management except the requirements have not changed.

36. Cognizant FDD and users Architect – define architecture and high level component model definition Domain expert – conduct domain walkthrough and guide developers Feature owner – translate features to requirements and interact with developers to complete feature Designer – preparation of high level design for all services and detailed design for features along with code reviews

37. Cognizant FDD and users… Developer – implement the application and unit testing Tester – assess requirements testability, create/manage test plan and test cases. Certify feature qualification for release Project manager – planning, scheduling, monitoring progress and reporting. Will prioritize requirements based on customer interaction

38. Agenda Software development is not easy Expectations Development model Feature Driven Development Model Cognizant’s FDD Cognizant’s FDD and VSTS

39. Why VSTS and TFS? Infrastructure for development Easy process and tools blend Familiar set of tools Increased Transparency Collaboration platform Support for distributed teams Real time reporting & Risk analysis End-to-end ALM process customization possibilities including builds and quality

40. Key technical reasons Source code manage Unit testing Code profiling Code coverage Static analysis Database testing Test data generation Manual testing Web Testing Load testing

41. Cognizant FDD on VSTS

42. Cognizant FDD on VSTS… Methodology database – repository of all databases Work items database – work items of Cognizant FDD and attributes Reports – out of the box common FDD related reports Team portal – customized process guidance along with templates like architecture, design for reference. Visual Studio – templates for role based process workflow and messages

43. New project and Cognizant FDD Initial tasks Work item types and behavior (states and transition) Groups and permissions Queries Reporting site Team portal with document templates, process guidance & web parts for reports Source control repository

44. State transition - feature work item

45. State transition – Change work item FromToTransitionRoles involved NewAwaiting approvalNew change request is raised Project manager Awaiting approvalApprovedChange is approvedProject manager ApprovedImpact analysis completedImpact on architecture and design is analyzed Project manager, Architect, Feature owner, Designer Impact analysis completedDesign Changes Completed Project manager, Designer Design Changes CompletedDesign Changes Inspected Architect certifies changesProject manager, Designer, Architect Design Changes Inspected Code completeConstruction is completeProject Manager, Developer Code completeCode reviewedCode is reviewedDesigner, Developer Code reviewedUnit test completeUnit test cases are modified and executed Project manager, Developer Unit test completePromote to buildReady for testingProject manager, Feature owner Promote to buildCertifiedChanges are successfulProject manager, Tester CertifiedClosedChange is completeProject manager, Feature owner

46. Work items - Code profiling - Code complexity - Build - Feature work item - Change work item - Reports

47. VSTS inherent features & FDD Shelving – in general helps in backing up of code on server without check-in. Used along with FDD can help in reviews by shelving feature code. Build – automation enables keeping builds ready for verification as well as to create potentially shippable product Multiple solution files – help in getting only what is required by a feature team Team project – helps in isolating focused development groups

48. References Cognizant FDD http://www.cognizant.com/html/content/microsoft/techfddvsts. asp Customizing process templates http://msdn.microsoft.com/en-us/library/ms243782.aspx TFS Guide http://www.codeplex.com/TFSGuide

49. Feedback / QnA Your Feedback is Important! Please take a few moments to fill out our online feedback form Use the Question Manager on LiveMeeting to ask your questions now!

50. Contact Email Address santosh.shindhe@cognizant.com

51. © 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.