Development Project Management using SharePoint

Transcription

1 Development Project Management using SharePoint Bachelor Project, Diplom IT, DTU Project implemented at & Handed in: Name: Michael Meldgård Thornberg Student no.: s DTU Project no.:

2 Table of Contents 1 Introduction Problem and Project Definition Development Process Using UP Report Outline Requirements Specification Expected Functionality Scoping Concise Conclusion Analysis Use Cases Use case: Add Module Use case: Upload Document Use case: Create Task Use case: Assign Task Use case: Approve Task System Domain User Authentication Workflows Custom Workflows Choosing an implementation approach Choosing SharePoint SharePoint Editions SharePoint as Platform SharePoint 2010 as Framework Concise Conclusion Design Entity Relations SharePoint Site Site Structure and Contents Security Custom Workflow

3 4.3 Concise Conclusion Implementation and Test Development Environment SharePoint site Site Structure Site Contents Custom Workflow Test Test Case: Add Module Test Case: Create Task Test Case: Custom Workflow Concise Conclusion Conclusion Future Implementation Authentication SharePoint Site Structure Data Model References Appendix Questionnaire Use Case Descriptions Use case: Add Module Use case: Upload Document Use case: Create Task Use case: Assign Task Use case: Approve Task Entities Development Environment Users available for login SharePoint site Source Code Custom Workflow Diagram

4 1 Introduction With this project and accompanying report, an approach for an implementation of a Development Project Management (DPM 1 ) system will be investigated. A primary aim is to investigate whether it is feasible to utilize the Microsoft product called SharePoint as a platform for this system. If confirmed, such an implementation will also be performed. Throughout this report all references to SharePoint, as well as other Microsoft products mentioned, will be on the 2010 releases, unless stated otherwise. Specific user references have either been masked or left out for the purpose of this report. 1.1 Problem and Project Definition During the process of a development project there will be many tasks, documentation and information in general involved. For any development team it is desired to manage these artifacts in an easy to use management system, preferably enabling external collaboration partners to participate. This is also the case at Accobat A/S, where development projects have recently received an increased amount of allocated resources. Therefore a management system, such as the one covered in this report, to handle these development projects is much desired. Because most of the software developed at Accobat A/S is targeted customer deployment, it will be opportune to ensure an easy to manage integration of relevant components contained in a single product, as well as providing means of keeping track of versions built and deployed at customers. Having this information stored in a common location, which is accessible to all relevant parties will also ease both the development process and the support phase following a deployment. Currently no system as the proposed is being used. This means that the normal practice is to store documents in one of a few common locations, and no information about which specific version has been deployed at a given location exists today. Given the current situation, and the fact that an internal SharePoint deployment already is in place, the author of this report has proposed that a system is conceived to streamline management of the properties and artifacts described above. 1.2 Development Process When developing software there are a number of approaches concerning how to structure the development process for it to be optimal, in terms of development efficiency and the quality of the product. Throughout the current project the development process commonly known as UP has generally been applied Using UP Using the UP approach involves the four phases Inception, Elaboration, Construction and Transition [1]. The latter phase called Transition does not apply in the context of the current project. The first three phases however, have been used as foundation for the development process used in this project. 1 Henceforth called DPM, within the scope of this report. 4

5 The development process commonly referred to as UP seems very popular, apparently due to its iterative nature. Using iterations in software development makes the process more natural for the developer, as it is natural human behavior to, when looking at things from a grander perspective, do things iteratively. When a task is completed it is instinctively evaluated to some extent. The next time the same task, or one related to it, is to be carried out again, the evaluated outcome from the prior execution will influence how the task is completed this, the following time. An alternative to UP could be using Agile Processes, as the focus is more on the dynamics ad performance of the development team, as opposed to the individual tasks. However, as the current project is carried out as an individual performance, this approach will not be best suited. 1.3 Report Outline 2 Requirements Specification: In this section the initial expectations and requirements to the product will be uncovered. A primary tool for this will be a questionnaire handed out to users who can be considered representative for people using a system as the one covered in this report. 3 Analysis: Once the expectations and requirements have been uncovered they will be analyzed in this section. The purpose of this step is to specify an approach for designing the system. This will include the choice of platform to which the system will be targeted. 4 Design: Before the DPM system can be implemented a general system design we have to be prepared. Using the information gathered in the previous section the design targeted the chosen platform will be composed. 5 Implementation and Test: The implementation itself follows the design laid out and ultimately takes care of providing the functionality requirements defined within the scope of this project. 6 Conclusion: Finally the project and the resulting system will be summed up in a concluding section. Covered here will be what knowledge was gained throughout the project, as well as how well the development process ended up performing. 5

6 2 Requirements Specification Before the analysis and design stages can commence, it will be necessary to establish the requirements specification for the DPM system to be implemented. 2.1 Expected Functionality To establish the initial expectations that the target audience had for the DPM system, a survey was conducted by gathering information through a questionnaire. The questions asked aims to cover the following aspects of the system when used in a production environment: Safety o External partner access o Customer access Contents o Task management Task creation Approval o Customer information Customer management Properties The information collected from the completed questionnaires is summed up in a spreadsheet, and using this listing the aggregated requirements are set up. This approach has been necessary as the responding users cover a wide range of the roles to be implemented, and will therefore have different views as to what the possibilities should be. Some of the functionality expected by the respondents has been decided not to be included as part of this project, however it has been noted as a possible extensions on the system. The aggregated result set of this survey can be summed up as follows: Customer properties should include: o Name o Contact person (including contact information) o Deployed core version o Deployed modules o Deployed module version o Server version (Windows + SQL) o SharePoint version o Date of deployments o User count External users (partners) should be able to access: o Information on tasks o Status for a task o The person responsible for a task, including contact information o Non-technical, non-sensitive documentation Only users with the appropriate role should be able to manage customer information. 6

7 Customer read access to tasks related to them, alternatively access to product documentation. New tasks should be approved by select users, before commencing work Select users not having the approver role should be able to assign users to tasks. 2.2 Scoping Much of the expected functionality described in the previous section is vital for the system to function correctly. However, some aspects can be opted out while others can be implemented in a more straightforward way. Additionally, some of the functionality expected by the users, expressed in the survey, has been opted out due to the necessity of scoping this project. One major part of this is the option of giving customers direct access to the documentation. Such customer access has been postponed to a later version, due to the authentication complexity it potentially would add. Ideally, to make this implementation as good as possible, the system should be implemented as a generic template. Doing so would greatly enhance the distribution potential to other scenarios, as well as opening an opportunity for considering distribution outside the organization. Should the system be implemented as a template, however, it would take a considerably greater amount of time and effort than allocated for this project. It will therefore mainly be manually implemented, using GUI tools as a primary surface. Developers Development_Managers Development_Leads Development_Partners Customer_Managers Figure 2.1: Security context to be implemented. To support approval of tasks a custom automated workflow must be implemented. This should trigger upon creation of a new task, sending a notification to available approvers. As this procedure is important for the task management section of the DPM system, it is considered a necessity to include this in the current scope. Because both internal users and external users should be able to login to the system, while maintaining a management hierarchy, all users must each be assigned to appropriate groups depending on their general role on projects. 7

8 To maintain the desired separation of the users into roles, a structure as the one proposed in Figure 2.1 is considered a required part in the scope of this project. 2.3 Concise Conclusion At this point the fundamental expectations and requirements, considered important for a system such as the one proposed, have been uncovered. While evaluating the expectations and requirements, a subset of these has been identified as essential to a working implementation. These are now collectively defined as part of the scope for the current implementation of the DPM system. The project scope covers most of the expected functionality, which therefore at this stage is planned to be included in the resulting implementation, as part of this project. 8

9 3 Analysis Performing an analysis of the requirements specification is a first step in identifying key components. These can then be used to define the composition of the product to implement. 3.1 Use Cases As a step in creating the product design, a handful of use cases have been constructed. According to the requirements specification, these use cases cover key functionality to be implemented in the final product. The five use cases are: 1. Add Module 2. Upload Document 3. Create Task 4. Assign Task 5. Approve Task In this section each use case will be covered briefly, to provide insight into the mechanics and interaction of each of them. For more elaborated use case descriptions for the above mentioned use cases refer to the appendix, section 8.2. SharePoint Upload Documentation Developer Assign Task Add Module Development Lead Create Task Development Manager Approve Task <<actor>> DPM system Development Partner Figure 3.1: Diagram showing handled use cases When defining these use cases, it became clear that defining the overall system security is an important factor to consider during the design phase. This is illustrated in Figure 3.1, showing the each role as an actor in all the use cases. 9

10 3.1.1 Use case: Add Module When a new module as part of a project is decided, it needs to be added to the DPM system to be handled therein. In this use case a module is added to the DPM system. To identify the module as part of a specific project, some basic information will need to be entered. Additional information, such as a version number, can also be entered at this stage, however this is optional. After being saved, the module will be available to the other sections of the DPM system, i.e. for association with a core edition or a task. Primary actor(s): Development Lead, Development Manager Secondary actor(s): DPM system Use case: Upload Document During a development project a number of documents will need to be shared amongst the development project participants. These documents can be of any kind, from detailed implementation documentation to end user manuals. To share a document with collaborators it will need to be uploaded to the DPM system. In this use case a document is uploaded to a given Document Library. Immediately after the upload has been completed, the user will automatically be required to fill in some basic information about the document just uploaded, to uniquely identify it and make it easier for others to locate. Primary actor(s): Developer, Development Lead, Development Manager. Secondary actor(s): DPM system Use case: Create Task All tasks must be added to the DPM system to be managed as part of a development project. A task can be of any size, but can be limited to some extent of work. In this use case a user creates the new task. There is a property set of required information that will need to be entered, before the DPM system will allow the task to be created. This property set includes i.e. a name and the parent module. Once the task is created, it will need to be approved by a user having the role of Development Manager. Therefore the task approval status is automatically set to Pending, and the task cannot be commenced until it has been approved. Primary actor(s): Development Partner, Development Lead, Development Manager. Secondary actor(s): DPM system Use case: Assign Task Once a task has been approved by a Development Manager, it must be assigned to a developer. This person should be the one primarily working on completing the task. In this use case a user will assign a task to another user, who is then considered the person performing the task. To be eligible for assignment the task must have been approved but not yet assigned. Assignment is performed by either selecting a user from a list of users, or simply entering the user s initials. 10

11 Primary actor(s): Development Lead, Development Manager. Secondary actor(s): DPM system Use case: Approve Task Before a new task can be assigned to a developer and therefore be carried out, it must be approved by a user with the approver role. In this use case a user will evaluate a task and decide whether it should be performed or dismissed, based on the information entered for the task. Following Use Case: Create Task the users having the role of Development Manager will be informed by that a new task has been created. A user then navigates to the task to evaluate its relevance. After making a decision the user then indicates this by changing the approval status of the task to either Approved or Rejected. Depending on the value of the updated approval status, one or more s are sent to the appropriate people. If the task is approved, both the task creator and all developers receive notification s, however if the task is rejected only the task creator receives an notification . Primary actor(s): Development Manager. Secondary actor(s): DPM system. 3.2 System Domain A first step in the system design is to define the boundaries and content of the domain in which the system will be operating. From the requirements described in section 2 the domain model depicted in Figure 3.2 a model of this domain can be constructed. Also included in this, is the proposed security structure as defined by the diagram in Figure * 0..1 CustomerContact Customer 0..* Development Manager Development Partner Development Lead Developer 0..* 0..* 1..* Core Module Task User * 0..* 0..* 0..* 0..* 1 * 0..* * 1 Document DocumentLibrary Group 0..* Figure 3.2: Domain model for the collaboration system In the domain model the User object represents an aggregation of the user roles Development Manager, Development Lead, Developer and Development Partner. The user role Customer Manager is not 11

12 represented as it is a composition of the user roles Development Manager, Development Lead and Development Partner, in accordance with the fore mentioned security structure diagram. 3.3 User Authentication Due to the nature of the preexisting need for the DPM system to be implemented, the natural choice of authentication will be to use an on premise Active Directory (AD) authentication infrastructure. (Domain Trust) Internal Forest External Forest (for external users) External Users Internal User 1 Internal Users Internal User 2 Internal User 1 Internal User 3 Internal User 3 Figure 3.3: Conceptual AD structure To separate internal users from external users, a new AD domain, dedicated to the DPM system and holding the external users, can be prepared. By configuring a one-way trust between the two forests, select internal users can be able to login using their existing credentials. An authentication environment as the one described here, is depicted in Figure 3.3. When assigning rights to users located in the internal domain it will necessary to be logged in as a user from that remote domain, having the proper rights assigned in the domain. As a side effect this indirectly ensures that only users in the internal domain can manage user associations from that domain. Assignment of the proper SharePoint permissions to each of the AD groups, the user role contexts will be defined in AD, making it simple to assign these groups the respective section permissions within SharePoint to an AD group. 3.4 Workflows Generally speaking workflows are organized series of tasks, collectively performing a given business process. In IT systems they have been implemented as an automated sequential series of tasks. Relevant to this project Microsoft provides Windows Workflow Foundation (WWF) as part of the.net framework. Using this, workflows can be implemented into applications using code. In this context the DPM 12

13 is considered an application, which is why the WWF will be a suitable choice for implementing a workflow to support the task approval process [12] Custom Workflows Implementing custom workflows can be done using one of two applications: SharePoint Designer 2010 Visual Studio SharePoint Designer 2010 Using SharePoint Designer 2010 enables implementation of workflows which, by default, will be bound to a specific site. The application provides a simple GUI 1 for constructing each section in the workflow as conditions or actions. These are defined within any number of contextual blocks, which are called steps. The options provided with SharePoint Designer 2010 are roughly the same as those provided in Visual Studio 2010, though they are targeted SharePoint specific scenarios Visual Studio 2010 Compared to SharePoint Designer 2010, this application provides an interface where it is possible to implement enhanced customization into the workflow, by utilizing the entire Windows Workflow Foundation (WWF) framework base. A primary motivator for using this, commonly considered an advanced users choice, application for workflow implementation, is that is enables the developer to utilize custom code in the workflow, to make the workflow support more advanced actions. Another motivator is the fact that a workflow implemented here potentially can be deployed to any site with ease. Whether this will be possible for a given workflow simply depends on whether the developer configures this Choosing an implementation approach Provided with SharePoint 2010 is a set of built-in workflows, such as the Approval SharePoint 2010 workflow. When first inspecting the process of this workflow, it seems like a reasonable choice for the current implementation. However, using this built-in workflow poses some questions concerning restrictions to further implementation. The requirements for current implementation can be fulfilled by the built-in workflow, but should it be decided to extend the business process which this workflow is meant to implement, it will be more convenient to extend a custom workflow, as to add specialized functionality. As it seems very likely that further steps will need to be put into the workflow later on, a custom workflow will be a reasonable choice. Based on the two implementation options as described in section 3.4.1, the optimal choice for this project will be to use Visual Studio 2010 to implement the custom workflow. This is because of the expected need to extend the business process coverage of the workflow. 1 GUI: Graphical User Interface. 13

14 3.5 Choosing SharePoint Building a project management system like the one covered in this report, is a huge task should it be built from scratch. To avoid doing this, an existing platform can be programmatically extended to support the desired functionality, while preserving and utilizing other common functionality therein. One such existing platform is Microsoft SharePoint Technologies, of which the current release is commonly referred to as SharePoint Throughout all prior editions and still present as an essential part of the platform in the current release is the concept of lists. Bearing close resemblance to database tables they provide the means of creating a data structure that can be used for multiple purposes. In this project SharePoint lists can be used to maintain a management hierarchy of data resources, specifically the tasks, documents and customers SharePoint Editions When developing for SharePoint it is necessary to be observant, regarding which edition will be required for the implementation to be supported. SharePoint comes in three flavors: SharePoint Foundation 2010 (free to download) SharePoint Server 2010 Standard SharePoint Server 2010 Enterprise Of these editions only the SharePoint Foundation 2010 is free to download, while the two Server editions each require both a server license and either Standard or Enterprise CALs 1 as well. As it is now clear that the system to be implemented will make use of custom workflows, the minimum required SharePoint edition will be SharePoint Server 2010 Standard, as custom workflows are not supported in the free SharePoint Foundation SharePoint as Platform Microsoft SharePoint can be considered a platform on which various business applications can run. When developing for the SharePoint platform the potential to connect and interoperate with other LOB 2 applications. These may or may not also run on SharePoint, but the means of establishing a connection with them and thereby using SharePoint as a common denominator can prove useful, and potentially provides an opportunity to create a fully integrated business management application for an entire organization Security Being a part of the Microsoft product portfolio, SharePoint 2010 is able to integrate with a multitude of Microsoft products. A catalyst for this is the requirement to be installed on the Windows Server OS, and the implicit default to be integrated with Active Directory 3. 1 CAL: Client Access License 2 LOB: Line Of Business A term that covers applications which are typical in business processes 3 Using Active Directory is not a requirements for installing SharePoint 2010; further information is provided at [9] 14

15 Defining security contexts is best done using SharePoint groups, configured at the site level. Members of these groups are linked from an external authentication resource, such as i.e. Active Directory or an SQL database. The most apparent restricted is that there is no such thing as an internal SharePoint user. All user objects are created from some other resource, and utilized in SharePoint using the external object name when referring to a user or group. Permissions for a SharePoint resource are given to users and/or groups. They can be defined at a granular level if required, however it is best practice to use permission inheritance throughout a site Structure A SharePoint deployment consists of one or more servers providing for SQL Server and IIS 1, both of which are requirements for installing SharePoint. The server serving as a web server is called a Web Front End (WFE). On this a web site called Central Administration is accessed to manage the SharePoint environment. SharePoint sites are divided into site collections, each acting as parent to one or more sites. These sites can then be used for different purposes, or be interconnected if necessary. Site Collection 1 Site Collection 2 Site Collection 3 Subsites Subsites Subsites Site 1 Site 1 Site 1 Site 2 Site 2 Site 3 Figure 3.4: Principle of a SharePoint structure Content Planning to use SharePoint as a platform provides several benefits, both to the developer and end user, but also to administrators and managers in the organization. It has many built-in features to support important business processes, provides tight integration with the organization s security management system. SharePoint can to a wide extent be tailored to suit the organization requirements, and should it lack a desired functionality it is easy to acquire this through a solution provider or finding free implementations online, i.e. browsing the Codeplex 2 site. When using SharePoint to store i.e. shared content, it is important to keep in mind that the data is essentially stored in a database, which is why it is best practice not to store large files, such as installers, in a SharePoint deployment. 1 IIS: Internet Information Services - It is the web server built-in as part of the Windows Server operating system 2 Codeplex is a Microsoft hosted developer driven site containing open source software ( 15

16 Web Parts Lists Libraries The extent of web parts concept is so vast, that it is not covered here in its entirety. Using web parts it is possible to embed extended functionality into SharePoint. The functionality contained can be implemented using a variety of programming languages, including VB.NET and C#. They can be placed on individual pages, or they can be manually integrated into the site itself. Web parts are easily packaged for distribution and can, if required, be considered as encapsulated applications deployable to a SharePoint site. Lists in SharePoint are like tables in a database, or sheets in a spreadsheet workbook. As such they can contain any type of information, structured as required by the context. Included with SharePoint is a set of pre-defined lists, such as a contact list, a calendar and the more complex task list. The library entity in SharePoint is best thought of as a folder to store documents, images and in principal any other type of file. Storing documents in SharePoint provides an opportunity to utilize the versioning capabilities, included in all SharePoint editions, as well as the integrated security layer, making it easy to filter documents based on the user security context. Content Management Workflows SharePoint is an ideal platform to use for content management, as it by default provides functionality such as versioning and approving. These management mechanisms can be applied to items as the context demands, and are customizable to suit any specific requirements an organization might have for their deployment. As SharePoint builds upon the.net framework it has the means to provide a SharePoint-specific implementation of a workflow engine. This can be used i.e. to automatically manage item properties, permission assignments and the organization of stored content. It can utilize external systems, should this be relevant for an implementation. Workflows can be implemented using one of three approaches: SharePoint built-in workflows o Limited to a few common uses SharePoint Designer o Better customization, but workflows are immediately site-bound Visual Studio o Best when manually coding the workflow, and can be deployed to multiple sites 16

17 3.5.3 SharePoint 2010 as Framework With the 2010 release of SharePoint the framework and platform has grown even stronger. A variety of built-in features have been included, that previously required custom implementations. This makes it a very interesting product to investigate further, when doing development projects in the future. A strong motivation for specifically using the most current version (2010) of SharePoint for development projects where a data model, resembling that of a relational database, is used can be the extended support for database-like relationship handling, such as the option to configure Restrict Delete and Cascade Delete for new column created as a Lookup type [5]. When developing products targeting SharePoint it has become a lot easier with the current release, in combination with Microsoft Visual Studio 2010, as integration tools are now provided built-in. Theses make debugging very easy, and at the same time motivates extending development with Silverlight 1 objects. 3.6 Concise Conclusion At this stage use cases have been identified and described, making the functionality to be implemented more transparent. The domain in which the system will operate has been uncovered, and the security approach has been considered and revised as part of the analysis phase. Based on these findings SharePoint has been evaluated as a well suited platform for implementing the DPM system, and considerations concerning how to utilize the concept of workflows to automate processes have been taken into account. This will be further covered in the following design section. 1 Silverlight is a Microsoft application framework, with which a developer can implement rich visual applications targeting both the Internet and desktop. 17

18 4 Design The design diagrams have been revised a few times, to update them according to changes in the system design. Those versions included below are the final which therefore best reflect the current implementation state of the system. 4.1 Entity Relations Most of the objects in the domain model can be represented in the system implementation as entities in a classic ER diagram, as depicted in Figure 4.1. The contents of the diagram depicted in Figure 4.1 bears some resemblance to a relational database structure. This data structure could, with some modifications, just as well be implemented as a database on an SQL server instance, however this would introduce further complexity, as external data connections would have to be configured and the authentication be carefully revised. As described in section 3.5.2, one of the advantages of implementing this into SharePoint, using lists in a fashion analogue to tables in a database, is that the authentication is already available and tightly integrated with the framework itself. Customer -CustomerName -CustomerContacts -DeployedCoreEditionRelease -DeployedModules -DeployedDate -ServerVersionWindows -ServerVersionSQL -ServerVersionSharePoint -UserCount 0..* 0..* Module -ModuleName -ModuleVersion -ModuleRelease -ModuleType -Silverlight -WebPart -Customization -PublicDocumentation -InternalDocumentation Task * -Module 0..* 0..* 0..* 0..* User * 0..* Document -CoreEditionRelease -ModuleRelease * 0..* * * 0..* CustomerContact Core -CoreEditionName -CoreEditionVersion -CoreEditionRelease -Modules -Public Documentation -Internal Documentation 0..* 1 Documents 1 SharedDocuments Figure 4.1: ER model for the collaboration system (most important properties included) Descriptions of the entity properties as illustrated in Figure 4.1 are elaborated in the appendix, section

19 4.2 SharePoint Site Before creating the SharePoint site it is necessary to ensure that a proper security structure is ready for implementation. Equally important as this, is having defined the SharePoint site structure to be created Site Structure and Contents The relations between each of these entities shown in Figure 4.1 are modeled in a structural diagram of a SharePoint site. This is done in accordance with the requirement specification. Following this, a number of sections are to be included in the SharePoint site. These include: Shared Documents Documents Tasks Modules Core Releases Customers Customer Contacts Each of these require specific customized configuration to comply with the requirements for the security structure and the entity relations, as described in the previous sections. The sections are to be configured as described below. Site Shared Documents Documents Tasks Approval workflow (custom) Customers Customer Contacts Modules Shared Documents: Lookup in Modules Lookup in Core Releases Documents: Lookup in Modules Lookup in Core Releases Tasks: References items in Modules Customers: Lookup in Customer Contacts Core Releases: Lookup in Modules Core Releases (editions) Figure 4.2: SharePoint site structure design 19

20 Shared Documents Documents Tasks Customers This document library is meant for documents that can be accessed by non-developers, thus it should not contain any technical implementation documentation. Versioning is enabled to ensure traceability throughout the process of a development project. Both major and minor notation is enabled for use. To align with the security design only users with permission to edit items can view draft (minor) versions. Also it should be required to check out a document before editing it, as to keep track of who is responsible of changes made to a document. Since this is a semi-public library approval will be required for items to be generally available within this library. Documents stored in this document library are generally expected to be some sort of implementation documentation, that initially only should be accessed by developers. Settings concerning versioning, drafts and editing controls are as described for "Shared Documents" above, except for the approval requirement as the documents in this library are for internal use. Module development potentially consists of multiple tasks. In this list tasks are created by users having the required permissions. Basic information is entered upon creation, preferably including a reference to the relevant module. Tasks cannot be started (be publicly visible) before they are approved. A custom workflow handles this process, automatically triggering when a new task is created. For each customer in this list, information about the remote environment can be entered. This includes i.e. windows server version and SharePoint version. Also referenced in this list are contacts for each customer. These are referenced to the Customer Contacts list. Customer Contacts Modules A customer can have more than one contact person. Each of these should be entered into this list, and associated with the customer from within the Customer list. This SharePoint list is enabled with item versioning, to be able to roll back to a previous version of the properties if a module definition is reverted. Each item in this list has an associated link to module documentation stored in the Documents library. 20

21 Core Releases Given sets of modules are collectively perceived as a core edition that is released as a bundle. In this list all such core editions are listed, each with information on which modules are included. Version numbers are tied together with the core editions, making it possible to facilitate a proper support for customer deployments, by simply using the correct core edition and version as a reference. Because module and core names respectively, and version numbers will be stored in separate columns, it will prove useful to aggregate paired values from these into a third column which can be used when referring to a version of either a module or core release. To do this calculated field values are employed [6]. With this technique field values can be constructed as calculations, which in the current context effectively are string value aggregations Security Designing how to implement the security at a granular level is an important step to complete before starting implementing the site, as grouping and rights assignment using groups will make the rest of the project more accurate, and less prone to require major adjustments. When designing a SharePoint site permissions infrastructure it is best practice to use permission inheritance for lists, libraries and sub-sites if possible, to minimize overall administration complexity. For this system, however, it is almost a necessity to use granulated permission assignments for all sections used in the site. This is due to the shifting roles each user has, depending on the context of each section in the SharePoint site. Initially using audiences was considered a viable option, however as the project progressed it proved to be insufficient, as it does not differentiate on the user's security context [3]. This differentiation is required in this implementation to make implementation documentation available to only those with the proper permissions. To resolve this, a design change was made to separate the implementation (or otherwise restricted) documents from the general documentation documents. Looking at the site structure in Figure 4.2, considerations regarding actions permitted based on each user role in the DPM system. These carefully considered, and complex, permissions covers i.e. read/write access to the task list, detailed on differencing on having permission to create a task and having permission to edit an already existing and approved task. In Figure 8.1 in the appendix the individual findings from these considerations are each boxed with the related site section. Included in SharePoint are some default permission levels which preferably should be utilized. To best align with this practice, the permissions established found required, according to the considerations described above, are formally defined by extending the default permission levels. Due to the granular user permission differences between the SharePoint sections a few custom permission levels are created, simply to add a usage permission setting. 21

22 Looking at the permissions for the module and core releases lists as illustrated in Figure 4.3, the granularity differences in the permission level requirements. In both these lists users having the Development_Leads role will be able to control the list completely. This can be necessary to give these users the possibility of modifying the list i.e. to add a column 1 missing in the current context. Users having the role Development_Manager can add new modules and core releases (editions), using the existing list composition. Modules Core Releases (editions) SharePoint Group Development_Managers: Development_Leads: Developers: Development_Partners: Customer_Managers: Permission Level Contribute Full Control Read (Edit) Read (N/A) Write: Development_Leads; Development_Managers Read: Developers (+ edit); Development_Partners Figure 4.3: Permission requirements for the Modules and Core Releases lists. Permissions for a user having the role Developer are a special case for these lists. These users will not be able to add new modules or core releases; however they should be able to edit those already existing in either list. This can prove useful so they can update a module or a core release with missing or updated information at a later stage. Using these permission definitions the responsibility of maintaining a valid set of existing modules and core editions is kept with the users in charge. The full resulting SharePoint site permission structure is also illustrated in Figure 8.1 in the appendix Promoting Sections A user logged in on a SharePoint site has direct access to a number of sections by means of the quick launch, which is located in the left-hand side of each 2 page. Given the security context of user, only link to those sections that the user has access to should be displayed. To handle this, SharePoint automatically hides quick launch links exactly like that. If a user does not have access to i.e. a document library there will not be a link visible in the quick launch, when that user is logged in. For any other user who does have access to the document library the link will be visible [4] Custom Workflow When a task is created it must be approved before a developer can be assigned to it, and the implementation can start. To handle this required procedural step a custom workflow is implemented. The structure of the workflow is illustrated in Figure 4.4. The workflow is automatically initiated upon creation of a task in the associated task list. When starting, an will be sent out to all users having adequate permissions, effectively those users who are members of the Development_Managers SharePoint group, as indicated on Figure 8.1Figure 2.1 located in appendix, section 8.5. The workflow then pauses, waiting for a change in the approval status for the current task. 1 Columns are to be considered as properties for items contained in the list. 2 Depends on whether further customization to the SharePoint site has been done, causing the quick launch to be hidden. 22

23 When a user having the approval permission changes the approval status the workflow continues. Depending on whether the task was approved or rejected, an is then sent both to all developers and the creator of the task, or only to the creator, respectively. If the task was approved, a new task is created. This task concerns assignment of a developer to the newly approved project task. This task is itself assigned to members of the Development_Leads group. Upon completion of this assignment task, the workflow stops itself and logs the output. Task is created Assign approval task Awaiting task state change Task approved Task rejected Notify developers by Nofity task creator by Nofity task creator by Assign assignment task Stop workflow and log outcome Task has been processed Figure 4.4: Approval workflow schematic This custom workflow can be implemented using either the SharePoint Designer application or using Visual Studio. Using Visual Studio provides for better customization options, as opposed to SharePoint Designer 23

24 through which declarative workflows are typically created. To enable support for specialized extensibility, Visual Studio 2010 has been opted for the current project. 4.3 Concise Conclusion Based on the findings in the analysis section perception of the system boundaries have been refined further. The resulting relational model has been used to define a structure suitable for implementation as a SharePoint site. For this site the elaborated security structure established in this section will be applied, in combination with a custom workflow, integrated management of task approvals, as initially defined by the requirements, has been prepared in design. Preparations for implementing the DPM system have been concluded, and in the following section the implementation and test will be covered. 24

25 5 Implementation and Test The implementation of the DPM system covered in this report is carried out within a virtual machine, using an Active Directory domain created solely for the purpose of this project. 5.1 Development Environment Complete details on the specifications of the development environment used, including user credentials for performing a login, can be found in the appendix. Because this system is based on SharePoint technologies best practices thereof will be applied, as best as possible. One best practice is to install SharePoint 2010 regardless of edition on a server that does not have the Active Directory Domain Services (AD DS) installed. When reading about this it has not been clear what the actual reason for this is, however experience gained through the process of this project has shown that a key difference between using a server with AD DS and one without, is that it is not possible to add a user as a local administrator for the server. This specifically becomes relevant when installing and maintaining a SharePoint installation, as the user executing the install I recommended to be assigned as a local administrator. This will not be possible if the AD DS role is installed on the server. The following is valid for most of the project period duration. Very late in the process a more suitable setup could be prepared, thus leaving a sparse amount of time to complete the project. In the current context it proved necessary to use a single server setup, implying that the AD DS role would be installed the server. This was caused by the need to establish a trust with a domain, which is not accessible externally. Using a VPN connection can resolve this, but as the initial domain controller (the server having the AD DS role installed) was deployed as a so-called core installation, wherein VPN connections are not supported. The domain was then quickly migrated to the main server, not running said core installation. This is done by installing the AD DS role, setting it as a secondary domain controller and afterwards correcting some references, thus making it possible to use this server alone. The DNS server was handled in an analogous fashion. To make SharePoint still work in this modified environment the service user must be added to the AD group Domain Admins, as the pre-existing Local Administrator is no longer present, as described above. The final server configuration, salvaged from the semi-broken initial environment, made it possible to successfully configure the User Profile Service (UPS) [9][10][11], which is needed to utilize user addresses stored in AD DS. To support execution of workflows on SharePoint 2010 the State Service was configured as well, using the SharePoint built-in Configuration Wizard. 5.2 SharePoint site To provide a simple path the SharePoint site will be created as the root site of a site collection, located at the root of an FQDN 1. The full path will be FQDN: Fully Qualified Domain Name 2 This is a temporary A record that will be removed after activities part of this project have been concluded. 25

26 5.2.1 Site Structure To create the SharePoint site the standard site template Team Site was used as a starting point. This template includes the items, relevant to this project: Shared Documents Tasks Contacts (renamed and used as Customer Contacts ) A SharePoint site created using the "Team Site" template contains a number of libraries and lists. Because some of these will not be directly implicated in this project, they have been hidden from the left hand side Quick Launch menu. They include: Calendar Site Pages Team Discussion Though each of them can prove useful they would, in the context of this project, seem excessive and not directly needed, as described above. To complete the designed site structure, all lists and libraries as defined in Figure 4.2 have been created and configured in accordance with the relational model depicted in Figure Site Contents Construction of the field value calculation to be used as the aggregated value, representing a module or core version in a readable format is done using a standard syntax [6]. The aggregated value must include both a module or core edition name and an associated version number. =[Module Name]&" "&"("&[Module Version]&")" Figure 5.1: Calculated field value for modules and core editions Such a calculated field value is constructed as shown in Figure 5.1. The strings encapsulated by brackets denote the names of the columns containing the value to be inserted. A resulting string from the example in Figure 5.1 could be Our Web Part (1.6). Fundamentally this approach is the same for both modules and core editions Custom Workflow As inspiration for how to implement a custom workflow using SharePoint Designer, a demonstrational video located at [7] was reviewed. Implementation of a custom workflow using SharePoint Designer first requires the configuration of a list where the workflow can create any tasks necessary, as well as a history list to maintain a log. To build the workflow each step is created as a block. All the actions to perform are entered into each of such steps. Refer to Figure 4.4 for all actions part of the custom workflow. Figure 5.2 shows the approval part, which is vital to the process of the custom workflow being implemented. 26

27 In the first step an approval task will be assigned to all members of the Development_Managers group. A notification will automatically be sent out to those assigned. Figure 5.2: Part of the custom workflow, as implemented In Visual Studio 2010 Step two starts with an instruction for the workflow to wait for the approval status to change from Pending. Once this happens the workflow will send out one or more s, depending on the new approval status. Should the task have been rejected an is sent to the creator of the task, to notify that the task was rejected by a project manager. If the new status indicates that the task has been approved, s are sent out to all members of the Developers group, letting them know that a new task is available. An is also sent to the creator of task to notify that the task was approved by a project manager. After the mails have been sent, a new task is created for each of the members in the Development_Leads group, for them to assign the project task to a developer. s are sent to each of the users involved. Upon completion of any of these assignment tasks, all remaining of these are marked as cancelled. This makes it possible to identify who performed the assignment. An is sent to developer being assigned to the project task. Finally, the workflow is marked as completed, and the end result is logged to the associated history list. 27