SharePoint Development Requirements and Process

The governance for who can do what, magento for small businesses and when via SharePoint Designer is out with the scope of this document. This can usually be found in the overarching SharePoint governance document.

This document has been created to focus on the process of developing via visual studio for solutions that require to be more technically encoded.

It is widely recognised that the difference between sandboxed and full trust is fairly academic. The choice is directly related to the solution that is being written and once again this is normally covered in a technical specification.

Under normal circumstance the developer should receive a detailed Functional Specification document. The developer will prepare a full technical explanation of the solution with further detailed explanations of how things work and which technologies have been utilised, more specifically a full description of the security model.

This document, TAD (Technical Architecture Document) is to be kept on a shared drive and deemed to be organic, as in the document to be updated on a daily basis.

The developer should keep a task list and a risk log also shared and once again updated daily. This is a feed into the Project Managers reports and not a substitute.

The source code should also be checked-in daily. The developers should on a daily basis update the full documentation and implement a test build on the integration server.

Once the development is complete and has been signed off. The developers should provide a hand over workshop to the internal development team. This is to ensure that the client has assimilated the development understanding.

It is more efficient for all developers, including external partners to develop within the client environment.

This is critical as the main source of errors and deployment issues often centres around the permissions model. Many solution user experiences benefit from deep user personalisation.