Kako praviti dobre SharePoint aplikacije ?

1. Kakopravitidobre SharePoint aplikacije? (Development Cycle na SharePoint način) Adis Jugo PlanB. GmbH

2. Perception of SharePoint applications

3. Agenda

4. Requirements management

5. A day in life of a SharePoint architect / dev “We are shooting at a moving target while wearing blindfolds, without knowing what the target looks like, where it is, or what type of ammo we need to use. In fact, we don’t even know if we’re in the right shooting range.” BjørnFuruknap, SP consultant and blogger

6. Requirements management

7. Requirements document Contains detailed explanation of all use cases (scenarios) Contains descriptions of all user roles (and permissions) Contains description of all inputs and outputs Contains descriptions of all processes Contains predicted extensity of use and concurrency situations Describes what can be implemented as a “no code solution”, and what has to be developed

8. Requirements document Ensures that all the people involved in the process really understand the process Ideally done by a business analyst and an architect Contains yours and customer’s signature

9. NO SPECS – NO CODE SharePoint empowers users to do things alone ->NO SPECS - NO CODE Customer’s processes are at very best loosely described -> NO SPECS - NO CODE Customers don’t understand the complexity of the solution they require -> NO SPECS – NO CODE But we have agreed that you will do that…NO SPECS – NO CODE If we kick off immediately, we will save time…(yes, and Elvis is still alive) -> NO SPECS – NO CODE Protect yourself AND your customer

10. Time and Costs estimation

11. Time and Costs estimation First 80% of the project consumes 80% of the budget Last 20% of the project consumes another 80% of the budget Bill Gates

12. Time/Budget consumption according to Gates

13. Some questions to think about How long do you need for the development? Break the requirements document down to deliverables and blocks. Do you have everything in requirements doc? How long did you write the requirements doc? Who did the architecture? When? How about some testing? You have bugs? When are you going to fix them? Who is going to deploy the solution? To which server? When? Do you practice code reviews? Who is going to the meetings? How often?

14. Making a Time / Costs estimation

15. Making a Time / Costs estimation Event receiver? Can be done in 1h. (Best case) Maybe in 2h (Most Likely) Or sometimes in a day (Worst case)

16. Making a Time / Costs estimation

17. Change Management

18. Change Management I have deleted that field. We didn't need it anymore.

19. Change Management I have deleted that field. We didn't need it anymore. We have changed the workflow - process description was wrong

20. Change Management I have deleted that field. We didn't need it anymore. We have changed the workflow - process description was wrong I've just changed the list name, why is the event receiver not working?

21. Change Management I have delete that field we didn't need it anymore We have changed the workflow - process description was wrong I've just changed the list name, why is the event receiver not working? THEY CAN DO THAT!

22. Change Management

23. Architecture of SharePoint solutions

24. Architecture of SharePoint solutions

25. A SharePoint Solution

26. What is wrong with this web part?

27. Solution Architecture InPage Event Rcv. Workflow Timer Business Logic Layer Service(s) – WCF, ASMX, REST I Data Access Layer Core Functions(Logging, Exceptions) RIA NET Office !Net DA Common Functions SP DATA

28. Solution Architecture InPage Event Rcv. Workflow Timer Business Logic Layer Service(s) – WCF, ASMX, REST I Data Access Layer Core Functions(Logging, Exceptions) RIA NET Office !Net DA Common Functions SP DATA

29. Solution Architecture: InPage

30. Solution Architecture: Client Side

31. Solution Architecture: Client Side

32. Solution Architecture: Client Side People want a good looking and good performing application Increase performance: • Async calls • Client Side Caching • Predictive Loading Reachability as an issue HTML Reach AJAX Silverlight Capability

33. Error Handling and logging

34. Demo: Logging in ULS

35. Configuration No Hard-Coded configuration Web.Config only in life threatening situations Or…

36. SPG Configuration Manager

37. Multilingualism

38. Multilingualism – OOB features

39. Multilingualism – user preferences

40. Multilingualism – ML configuration list

41. Other architecture considerations Architecture documentation Standard Design Patterns Avoid 3rd Party libraries Solution Technical Documentation

42. SharePoint development

43. Development Standard coding conventions (Microsoft) Define standard core libraries (reuse standard functionality) – own or SPG Use standard VS 2010 SharePoint project templates Follow the SharePoint rules of game – field names, required fields, descriptions, translations Follow architecture guidelines – logging and exception handling Use a very defensive approach – you never know when will somebody delete a field

44. Development Use SharePoint tools (SharePoint Manager, ULS Viewer, SPDiag) Don’t use 3rd party components if you don’t really have to Use Linq – SPMetal is good

45. Testing SharePoint Solutions

46. Unit Testing, Integration Testing First line of defense Not possible OOB with Visual Studio 2010 Unit Testing Custom Unit testing solutions Moles Framework Custom Console App Continuous Integration Testing(TFS Team Build, Cruise Control)

47. UI, |Stress and Load Testing Coded UI Tests Load Tests Stress Tests

48. Manual tests Still the most important tests Test cases document Microsoft Test Manager -> Helps with Problem reproducing fight

49. Quality Assurance

50. Quality Assurance StyleCop DisposeChecker