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

28 5.3 Test As a result of the many problems that have occurred during this project period, the documented DPM system tests have been limited to two of the initial use cases: Add Module Create Task Also tested is the basic functionality of the custom workflow. The tests will be covered with a brief process description, combined with a table of steps in the current test. For each step there is a short description, the expected result and the actual result. For the use case tests, the steps are those of the detailed use case descriptions in the appendix, section Test Case: Add Module In this test the user ACCOSP2010\User2 will create a module called Test Module. Table 5.1: Test 1a Step Expected result Actual result Navigate to Modules list Access granted. Access granted. Click Add new item A dialog box for entering information is presented to the user. A dialog box for entering information is presented to the user. Enter information (N/A) (N/A) Click Save Information is saved. Information is saved. When ACCOSP2010\User2 accesses the Modules list all options should be available, since the user is a member of a SharePoint group having the permission set Full Control assigned for this list. The test is then repeated for the user ACCOSP2010\User5. Table 5.2: Test 1b Step Expected result Actual result Navigate to Modules list Access granted. Access granted. Click Add new item The link is not present. The link is not present. When a logged in user not having permission to create new items in a given list, navigates to said list, it should not be possible for the user to create a new item. The test showed that this works correctly for the Modules list. 28

29 Another test repeat is performed for user ACCOSP2010\User2, without entering the required information. Table 5.3: Test 1c Step Expected result Actual result Navigate to Modules list Access granted. Access granted. Click Add new item A dialog box for entering information is presented to the user. A dialog box for entering information is presented to the user. Enter information (N/A) (N/A) Click Save Information is not saved. Error is highlighted. Information is not saved. Error is highlighted. This test showed that the list configuration correctly reacts when data for a required property has not been entered. The module cannot be saved and the user is presented with a highlighted error message, indicating what required information is missing. In this final test, the user ACCOSP2010\User2 attempts to create a module with a name that already exists. Table 5.4: Test 1d Step Expected result Actual result Navigate to Modules list Access granted. Access granted. Click Add new item A dialog box for entering information is presented to the user. A dialog box for entering information is presented to the user. Enter information (N/A) (N/A) Click Save Information is not saved. Error is highlighted. Information is saved. The result in test 1d shows that it is possible to create two modules having the same name. This is not a true error however. It is only an error in this case since the version number for both the existing and the new module were left blank, thus making the modules identical, when considering a module as a pair of module name and a version number Test Case: Create Task In this test the user ACCOSP2010\User4 attempts to create a new task, called Test Task. Table 5.5: Test 2a Step Expected result Actual result Navigate to Tasks list Access granted. Access granted. Click Add new item A dialog box for entering information is presented to the user. A dialog box for entering information is presented to the user. Enter information (N/A) (N/A) Create the task Information is saved. Information is saved. (automated) Custom workflow does not start. Custom workflow does not start. In compliance with the expected outcome, the custom workflow does not start. This is because it has not yet been configured to start automatically upon creation of a new list item, in this case a task. 29

30 The test is then repeated for the user ACCOSP2010\User5. Table 5.6: Test 2b Step Expected result Actual result Navigate to Tasks list Access granted. Access granted. Click Add new item The link is not present. The link is not present. When a logged in user not having permission to create new items in a given list, navigates to said list, it should not be possible for the user to create a new item. The test showed that this works correctly for the Tasks list. Another test repeat is performed for user ACCOSP2010\User4, without entering the required information. Table 5.7: Test 2c Step Expected result Actual result Navigate to Tasks list Access granted. Access granted. Click Add new item A dialog box for entering information is presented to the user. A dialog box for entering information is presented to the user. Enter information (N/A) (N/A) Click Save Information is not saved. Error is highlighted. Information is not saved. Error is highlighted. This test showed that the list configuration correctly reacts when data for a required property has not been entered. The task cannot be saved and the user is presented with a highlighted error message, indicating what required information is missing. In the following task the user ACCOSP2010\User4 tries to create a task, having a name that already exists. Table 5.8: Test 2d Step Expected result Actual result Navigate to Tasks list Access granted. Access granted. Click Add new item A dialog box for entering information is presented to the user. A dialog box for entering information is presented to the user. Enter information (N/A) (N/A) Create the task Information is not saved. Error is Information is saved. highlighted. (automated) (N/A) Custom workflow does not start. As with the result in test 1d, the result in test 2d shows that it is possible to create two tasks having the same name. This is not a true error here as well. Only in this case it is, since only the title field was filled in, for both the existing and the new module, thus making the tasks identical, when considering a task as a pair of module and a task title. 30

31 5.3.3 Test Case: Custom Workflow As described in section 5.3, the basic functionality of the workflow will be tested here, meaning that only the primary success scenario will be documented here. This is due to the current state of the project, as further elaborated in section 6. When the workflow is initiated for a given task, the approval process for that particular task starts. The main steps in the workflow are noted in Table 5.9, noted with the expected state and whether the custom workflow completed the step as expected. Table 5.9: Test 3 Step Expected result Actual result Create approval task Task created and assigned to Pass ACCOSP2010\User1 Approval status changed Workflow continues Pass (User1 approved task) Notify developers Members of Developers user groups Pass in both domains receive Notify creator Creator receives Pass Create assignment task Task created and assigned to Pass ACCOSP2010\User2. Task created and assigned to <internal_domain>\mmt. Task assignment changed Task for user ACCOSP2010\User2 is Pass (User2 assigned task) marked as completed. Task for user <internal_domain>\mmt is marked as cancelled. Stop workflow and log Workflow is marked as completed. Pass 5.4 Concise Conclusion Implementing the DPM system proved to be a significantly more challenging process than expected, primarily due to the issues concerning the general infrastructure composition. It took quite some time to adapt the implementation, to make it fit into the changing environment. Apart from these issues, the implementation process caught some minor bugs from the analysis and design phases. The following tests concluded that there still is room for improvement in the design. Handling these improvements must be part of future implementation. Some of the areas are discussed in section 0. The current product is considered acceptable when compared to the initial expectations and requirements, and when seen in the light of the course of the development process. 31

32 6 Conclusion With the current implementation of the DPM, for which SharePoint 2010 proved to be a well suited implementation platform, it is now possible for Accobat A/S to perform basic management of development projects, including coverage of a following customer deployment support phase. The system can also contain documents relevant to the development process, as well as the end product being managed. The DPM has with the current implementation become a bit more structured than initially planned. However, it has not yet been put into production at Accobat A/S, which is why it is still unclear whether the DPM, with the current implementation, properly supports the business processes used at Accobat A/S. Looking at the product compared with the initial user expectations and implementation requirements, some elements are not at their full potential, as described in section 0. This result of this project only scratches the surface of the possibilities that SharePoint provides for, and has potential to be a key component in a larger system implementation. The desired approach of implementing one use case at a time was not followed completely. This did not have a noteworthy impact on the development process, primarily because the implementation on the target platform quickly results on them intertwining with each other. While stepping through inception and elaboration, the domain and ER models were iteratively modified to adhere with realizations made when implementing in SharePoint. These realizations were generally related to properties found lacking from entities or a required fundamental re-work of a connection between two objects in the domain. Discovering shortcomings in the design, such as these, through the use of iterations has proved the importance of using this process oriented approach in development projects. It provides for a very flexible yet structured process. Due to insufficient server resources, for hosting the virtual machine containing the development environment, at a late stage of this project, it proved very difficult to implement the custom workflow as this requires access to a smart host SMTP server located at the company premises, while the virtual environment was privately hosted. The virtual environment therefore had to maintain a VPN connection, thus further complicating routing the traffic, while still making the implementation externally available. Should a workaround, such as a new dummy domain combined with an additional AD DS have been implemented instead, it would have taken more time to prepare than available, as well as required further hardware resources. In general there has not been spent enough time on preparing and implementing this project. There has simply been too much focus on other simultaneous projects. This becomes apparent when looking at the composition of the result, compared to the initial requirements. Learning to use this gained project process knowledge when doing multiple projects in the future, can prove to be a valuable asset. As time became short, implementation of the custom workflow was performed using the SharePoint Designer 2010 application, striving to have a working custom workflow included. In the 11 th hour of the project period, implementation of the custom workflow using Visual Studio 2010 as development environment was commenced, in an attempt to salvage this essential functionality of the DPM system. 32

33 This report has been made available at the development SharePoint site, stored in the document library Documents. Additionally, a number of tasks have been created to represent parts of this report and the project as a whole, solely for demonstrational purposes. Also available for download from the SharePoint site is the source code and a complete diagram of the custom workflow, as implemented using Visual Studio Future Implementation There are several aspects of this system that can be extended to add wanted functionality and add support for remote hosting Authentication To facilitate further integration of the system with an existing Active Directory environment, an obvious path to choose would be to implement support for Active Directory Federation Services (AD FS). This makes it possible for users located in external environments to logon to this system, using their existing credentials in the remote environment. Another option is to implement Forms Based Authentication. This, however, is potentially less secure. A side effect of using this type of authentication is that at present SharePoint Online does not support Forms Based Authentication SharePoint Site Structure Concerning content within the SharePoint site it would be ideal to create document templates for some of the key document types. Related to templates are content types. Defining and implementing these will streamline the system even further, by, in effect, making content management tightly integrated with the DPM process. The design decision to split the Shared Documents into two separate document libraries Documents and Shared Documents, defining the contents of those as implementation documentation and general documentation respectively, could have been avoided by implementing another workflow. This workflow should trigger upon upload of a document, and then reset the user permissions for the new item (the new document). Afterwards new user permissions should be set to a given security context, i.e. the SharePoint group Developers [2] Data Model The way modules and versions are handled can be optimized by separating these into two entities. This will provide for a more regular relational data structure, which, in this context, seems reasonable to apply. The current implementation has the design flaw that when a module is to be chosen upon creating a new task, there will inevitably be multiple instances of a module name. At this stage where a task is created, is can be uncertain which version the task ultimately will be a part of, and selecting a random module name from a list without versions denoted does not make much sense. 33

34 7 References [1] UML Distilled Third Edition (2004) by Martin Fowler [2] Configure Item Level Permissions for Document Libraries Part 2 SharePoint 2010 edition (blog post) [3] How does Audience Targeting in a List / Document Library work? (blog post) [4] How to Set Quick Launch Item User Access Permissions (TechNet forum post) 69fdd8867c1d [5] Create list relationships by using lookup and unique columns (SharePoint 2010) (blog post) [6] Calculated Field Formulas (MSDN article) [7] Create a custom approval workflow in SharePoint 2010 (blog post) [8] Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization (MVP article) [9] Installing SharePoint without Active Directory (blog post) [10] User Profile service overview (SharePoint Server 2010) (TechNet article) [11] Create, edit, or delete a User Profile service application (SharePoint Server 2010) (TechNet article) [12] Workflows in SharePoint Server 2010 (MSDN article) In addition to the references listed above, previous knowledge has been gained through experience, in combination with miscellaneous blog and forum posts and articles, primarily located at either MSDN or TechNet. 34

35 8 Appendix 8.1 Questionnaire 35

36 8.2 Use Case Descriptions Use case: Add Module USE CASE 1: Add Module Goal Preconditions Success end condition Failed end conditions Primary, secondary actors To add information about a module that is or will be part of a development project. Implementation of a new module has been decided, and the user has successfully logged in. The information on the module has been added to the SharePoint site. Adding the information on the module to the SharePoint site failed. Primary: Development Lead, Development Manager. Offstage actor: SharePoint platform. Description Step Action 1 User navigates to the module list in SharePoint. 2 A new item is to be created. 3 Information is entered. 4 The information entered is saved. Extensions Step Action 1a 2a 4a 4b The user does not have access to the list. The user does not have permission to perform this action. Some required information is not entered. A system error prevents item creation. Priority High Performance Expected 2-3 minutes to perform Frequency Infrequently References 1 36

37 8.2.2 Use case: Upload Document USE CASE 2: Upload Document Goal Preconditions Success end condition Failed end conditions Primary, secondary actors To add a document to a document library. The user has prepared a document, and is logged in. The document is uploaded to the library. The document was not uploaded to the library. Primary: Developer, Development Lead Offstage actor: Development Project Management system. Description Step Action 1 User navigates to the library. 2 A document is to be uploaded. 3 User selects the document from local file system. 4 Document is uploaded. 5 Document properties are entered. 6 The information entered is saved. Extensions Step Action 1a The user does not have access to the list. 2a 4a 6a 6b The user does not have permission to perform this action. A system error prevents document upload. Some required information was not entered. A system error prevents document properties update. Priority Performance Frequency References High Expected 2-3 minutes to perform Frequently 37

38 8.2.3 Use case: Create Task USE CASE 3: Create Task Goal Preconditions Success end condition Failed end conditions Primary, secondary actors To create a new task to be carried out. Related module has been added, and the user is logged in. The task is created. The task is not created. Primary: Development Partners, Development Lead, Development Manager. Offstage actor: Development Project Management system. Description Step Action 1 User navigates to the task list. 2 A new task is to be created. 3 Information is entered. 4 Task is created. Extensions Step Action 1a 2a 4a 4b The user does not have access to the list. The user does not have permission to perform this action. Some required information was not entered. A system error prevents task creation. Priority High Performance Expected 2-3 minutes to perform Frequency Frequently References 1 38

39 8.2.4 Use case: Assign Task USE CASE 4: Assign Task Goal Preconditions Success end condition Failed end conditions Primary, secondary actors To assign a user to a task. The task has been created and approved, and the user is logged in. A user has been assigned to the task. No user is assigned to the task. Primary: Development Lead, Development Manager. Offstage actor: Development Project Management system. Trigger Description Step Action 1 User navigates to the task list. 2 A task is to be edited. 3 The user to be assigned is selected. 4 Changes to the task are stored. Extensions Step Action 1a The user does not have access to the list. 2a 3a 4a 4b The user does not have permission to perform this action. No users are available for selection. Some required information was not entered. A system error prevents task creation. Priority High Performance Expected 1-2 minutes to perform Frequency Frequently References 1, 5 39

40 8.2.5 Use case: Approve Task USE CASE 5: Approve Task Goal Preconditions Success end condition Failed end conditions Primary, secondary actors Trigger To approve or reject a new task. A task has been created and not reviewed, and the user is logged in. The task is approved or rejected. The task approval status has not been modified. Primary: Development Manager. Offstage actor: Development Project Management system. A task has been created and not reviewed. Description Step Action 1 User receives an about the new task. 2 User navigates to the task list via link in the . 3 A task is to be edited. 4 The approval status of the task is modified. 5 Changes to the task are stored. Extensions Step Action 1a The is never sent. 1b The is never received. 2a 3a 5a 5b The user does not have access to the list. The user does not have permission to perform this action. Some required information was not entered. A system error prevents task creation. Priority High Performance Expected 1-2 minutes to perform Frequency Frequently References 1, 3 40

41 8.3 Entities Document Property Datatype Purpose CoreEditionRelease Lookup Links document to related core edition release (name and version) ModuleRelease Lookup Links document to related module release (name and version) Module Property Datatype Purpose ModuleName Text Name of the module ModuleVersion Text Version of the module ModuleRelease Calculated Concatenation of ModuleName and ModuleVersion ModuleType Choice Type of module Silverlight Boolean Denotes a Silverlight module WebPart Boolean Denotes a web part module Customization Boolean Denotes a customized module PublicDocumentation Hyperlink URL to location of public documentation InternalDocumentation Hyperlink URL to location of internal documentation Core Property Datatype Purpose CoreEditionName Text Name of the core edition CoreEditionVersion Text Version of the core edition CoreEditionRelease Calculated Concatenation of CoreEditionName and CoreEditionVersion Modules Lookup Links core edition to the related modules (name and version) Public Documentation Hyperlink URL to location of public documentation Internal Documentation Hyperlink URL to location of internal documentation Customer Property Datatype Purpose CustomerName Text Name of the customer CustomerContact Lookup Links customer to the related contacts DeployedCoreEditionRelease Lookup Links customer to the related core edition release DeployedModules Lookup Links customer to the related modules DeployedDate Date Date of deployment ServerVersionWindows Choice Version of Windows on the server ServerVersionSQL Choice Version of SQL Server on the server ServerVersionSharePoint Choice Version of SharePoint on the server UserCount Number Number of users on deployment 41

42 CustomerContact Property Datatype Purpose CustomerName Lookup Reference to customer item Task Property Datatype Purpose Module Lookup Links task to the related module (name and version) 42

43 8.4 Development Environment The development environment in running as a virtual machine, and VMWare Player is used as virtualization engine. 2 cores (@ 2.4 GHz) 2 GB RAM 1 Windows Server 2008 R2 Standard (x64) Microsoft SharePoint Server 2010 Standard Visual Studio 2010 Premium SharePoint Designer 2010 Domain: AccoSP2010.local Domain Trust: <internal_domain> Server: SP2010DevServer.AccoSP2010.local Users available for login The SharePoint site created in the development is accessible externally. It can be reached at 2. To log on to the SharePoint site, the users listed in Table 8.1 can be used. The AD user groups prefixed with s050424_ are enabled global security groups, while the rest except for Domain Admins are local security groups. All SharePoint memberships are established indirect, though an AD group memebership. Table 8.1: Existing domain users Username Password Domain group membership SharePoint group membership ACCOSP2010\user1 Passw0rd1 Development_Managers; Development_Managers s050424_development_managers; Domain Admins ACCOSP2010\user2 Passw0rd1 Development_Leads; Development_Leads s050424_development_leads ACCOSP2010\user3 Passw0rd1 Developers; Developers s050424_developers ACCOSP2010\user4 Passw0rd1 Development_Partners Development_Partners ACCOSP2010\user5 Passw0rd1 Developers; s050424_developers Developers 1 Initially 4 GB was allocated, to conform to the SharePoint Server 2010 hardware requirements, but the change in hosting scenario required the reduction. 2 This is a temporary A record that will be removed after activities part of this project have been concluded. Also, this connection sometimes is a bit unstable, due to the currently necessary complex setup. A fix for this should be in effect by the time this report will be evaluated. 43

44 8.5 SharePoint site Site SharePoint Group Development_Managers: Development_Leads: Developers: Development_Partners: Customer_Managers: Permission Level Contribute (N/A) Contribute Read (N/A) Write: Developers; Development_Managers Read: Development_Partners (audience) Shared Documents SharePoint Group Development_Managers: Development_Leads: Developers: Development_Partners: Customer_Managers: Permission Level Read Full Control Contribute Read (N/A) Write: Developers Read: Development_Managers; Development_Partners Documents SharePoint Group Development_Managers: Development_Leads: Developers: Development_Partners: Customer_Managers: Permission Level (N/A) (N/A) Full Control (N/A) (N/A) Write: Developers Read: Tasks Approval workflow (custom) SharePoint Group Development_Managers: Development_Leads: Developers: Development_Partners: Customer_Managers: Permission Level Full Control Contribute Read (Edit) Read (Create) (N/A) Write: Development_Leads; Development_Managers (+approve) Read: Developers (+ edit); Development_Partners (+ create) 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 Customers Customer Contacts SharePoint Group Development_Managers: Development_Leads: Developers: Development_Partners: Customer_Managers: Permission Level (N/A) (N/A) Read (N/A) Contribute Write: Customer_Managers Read: Developers Figure 8.1: SharePoint site and permission structure 44

45 8.6 Source Code The source code for the custom workflow, as implemented in Visual Studio 2010, has been made available for download from the development SharePoint site. Valid user credentials are listed in this report, in section

46 8.7 Custom Workflow Diagram A complete diagram of the custom workflow, as implemented using Visual Studio 2010, has been made available for download from the development SharePoint site. Valid user credentials are listed in this report, in section