bachelor project: development project management using ...etd.dtu.dk/thesis/276032/dip10_56.pdf ·...

Development Project Management using SharePoint

Bachelor Project, Diplom IT, DTU

Project implemented at

&

Handed in: 28-03-2011

Name: Michael Meldgård Thornberg

Student no.: s050424

DTU Project no.: IMM-B.Eng-2010-56

Development Project Management using SharePoint IMM-B.Eng-2010-56

2

Table of Contents 1 Introduction .......................................................................................................................................... 4

1.1 Problem and Project Definition ...................................................................................................... 4

1.2 Development Process .................................................................................................................... 4

1.2.1 Using UP ................................................................................................................................ 4

1.3 Report Outline ............................................................................................................................... 5

2 Requirements Specification ................................................................................................................... 6

2.1 Expected Functionality .................................................................................................................. 6

2.2 Scoping.......................................................................................................................................... 7

2.3 Concise Conclusion ........................................................................................................................ 8

3 Analysis ................................................................................................................................................. 9

3.1 Use Cases ...................................................................................................................................... 9

3.1.1 Use case: Add Module ......................................................................................................... 10

3.1.2 Use case: Upload Document ................................................................................................ 10

3.1.3 Use case: Create Task .......................................................................................................... 10

3.1.4 Use case: Assign Task ........................................................................................................... 10

3.1.5 Use case: Approve Task........................................................................................................ 11

3.2 System Domain ........................................................................................................................... 11

3.3 User Authentication .................................................................................................................... 12

3.4 Workflows ................................................................................................................................... 12

3.4.1 Custom Workflows .............................................................................................................. 13

3.4.2 Choosing an implementation approach ................................................................................ 13

3.5 Choosing SharePoint.................................................................................................................... 14

3.5.1 SharePoint Editions .............................................................................................................. 14

3.5.2 SharePoint as Platform ........................................................................................................ 14

3.5.3 SharePoint 2010 as Framework ............................................................................................ 17

3.6 Concise Conclusion ...................................................................................................................... 17

4 Design ................................................................................................................................................. 18

4.1 Entity Relations ........................................................................................................................... 18

4.2 SharePoint Site ............................................................................................................................ 19

4.2.1 Site Structure and Contents ................................................................................................. 19

4.2.2 Security ............................................................................................................................... 21

4.2.3 Custom Workflow ................................................................................................................ 22


3


5 Implementation and Test .................................................................................................................... 25

5.1 Development Environment .......................................................................................................... 25

5.2 SharePoint site ............................................................................................................................ 25

5.2.1 Site Structure ....................................................................................................................... 26

5.2.2 Site Contents ....................................................................................................................... 26

5.2.3 Custom Workflow ................................................................................................................ 26

5.3 Test ............................................................................................................................................. 28

5.3.1 Test Case: Add Module ........................................................................................................ 28

5.3.2 Test Case: Create Task ......................................................................................................... 29

5.3.3 Test Case: Custom Workflow ............................................................................................... 31


6 Conclusion .......................................................................................................................................... 32

6.1 Future Implementation ............................................................................................................... 32

6.1.1 Authentication ..................................................................................................................... 33

6.1.2 SharePoint Site Structure ..................................................................................................... 33

6.1.3 Data Model .......................................................................................................................... 33

7 References .......................................................................................................................................... 34

8 Appendix............................................................................................................................................. 35

8.1 Questionnaire.............................................................................................................................. 35

8.2 Use Case Descriptions.................................................................................................................. 36

8.2.1 Use case: Add Module ......................................................................................................... 36

8.2.2 Use case: Upload Document ................................................................................................ 37

8.2.3 Use case: Create Task .......................................................................................................... 38

8.2.4 Use case: Assign Task ........................................................................................................... 39

8.2.5 Use case: Approve Task........................................................................................................ 40

8.3 Entities ........................................................................................................................................ 41

8.4 Development Environment .......................................................................................................... 43

8.4.1 Users available for login ....................................................................................................... 43

8.5 SharePoint site ............................................................................................................................ 44

8.6 Source Code ................................................................................................................................ 45

8.7 Custom Workflow Diagram .......................................................................................................... 46


4

1 Introduction With this project and accompanying report, an approach for an implementation of a Development Project

Management (DPM1) 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.

1.2.1 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.


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.


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.


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.

Development_Managers Development_Leads

Developers

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.


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.


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

Developer

Development Manager

Development Partner

Add Module

Development Lead Create Task

Approve Task

Assign Task

UploadDocumentation

<<actor>>DPM

system

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.


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.

3.1.2 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.


3.1.3 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.


3.1.4 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.


11

Primary actor(s): Development Lead, Development Manager.


3.1.5 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

e-mail 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 e-mails are

sent to the appropriate people. If the task is approved, both the task creator and all developers receive

notification e-mails, however if the task is rejected only the task creator receives an notification e-mail.

Primary actor(s): Development Manager.


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 2.1.

1*

0..*

0..*

0..*

0..*

0..1 1..* 0..* 0..* 0..*

0..*

0..10..*

1..*0..*

CustomerContact Customer

Core Module Task User

Document DocumentLibrary Group

Development Manager

Development Lead

Development Partner

Developer

*

1

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


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.

Internal Forest External Forest(for external users)

External Users

Internal User 1

Internal User 2

(Domain Trust)

Internal Users

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


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].

3.4.1 Custom Workflows

Implementing custom workflows can be done using one of two applications:

SharePoint Designer 2010

Visual Studio 2010

3.4.1.1 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 GUI1 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.

3.4.1.2 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.

3.4.2 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.


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 2010.

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.

3.5.1 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 CALs1 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 2010.

3.5.2 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 LOB2

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.

3.5.2.1 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 Directory3.

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]


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.

3.5.2.2 Structure

A SharePoint deployment consists of one or more servers providing for SQL Server and IIS1, 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 2

Site 1Site 1

Site 2

Site 3

Figure 3.4: Principle of a SharePoint structure

3.5.2.3 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 Codeplex2 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 (http://www.codeplex.com)


16

Web Parts

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

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.

Libraries

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

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.

Workflows

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


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 Silverlight1 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.


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.

-CustomerName-CustomerContacts-DeployedCoreEditionRelease-DeployedModules-DeployedDate-ServerVersionWindows-ServerVersionSQL-ServerVersionSharePoint-UserCount

Customer

-ModuleName-ModuleVersion-ModuleRelease-ModuleType-Silverlight-WebPart-Customization-PublicDocumentation-InternalDocumentation

Module

CustomerContact

-CoreEditionName-CoreEditionVersion-CoreEditionRelease-Modules-Public Documentation-Internal Documentation

Core

-Module

Task User

-CoreEditionRelease-ModuleRelease

Document

Documents

1

*

0..* 0..*

*

1

0..1

0..*

0..* 0..*

1..*

0..*

0..1 0..* 0..* 0..*

0..*

0..*

SharedDocuments

1

*

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 8.3.


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.

4.2.1 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

Modules

Customer Contacts

Customers

Approval workflow (custom)

Tasks

Core Releases (editions)

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”

Documents

Figure 4.2: SharePoint site structure design


20

Shared Documents

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

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.

Tasks

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.

Customers

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

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.

Modules

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.


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.

4.2.2 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.


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 column1 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


Write:Development_Leads;Development_Managers

Read:Developers (+ edit);Development_Partners

SharePoint Group Permission LevelDevelopment_Managers: ContributeDevelopment_Leads: Full ControlDevelopers: Read (Edit)Development_Partners: ReadCustomer_Managers: (N/A)

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.

4.2.2.1 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 each2 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].

4.2.3 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 e-mail 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.


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 e-mail 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.

Assign approval task

Notify developers by e-mail

Nofity task creator by e-mail

Task is created

Task approved

Awaiting task state change

Nofity task creator by e-mail

Task rejected

Stop workflow and log outcome

Task has been processed

Assign assignment task

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


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.


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 e-mail

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 FQDN1. The full path will be http://s050424.accobat.com/2.

1 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.


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 4.1.

5.2.2 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.

5.2.3 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.


27

In the first step an approval task will be assigned to all members of the Development_Managers group. A

notification e-mail 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 e-mails, depending on the new

approval status.

Should the task have been rejected an e-mail 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, e-mails are sent out to all members of the

Developers group, letting them know that a new task is available. An e-mail 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. E-mails 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 e-mail 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.


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 8.2.

5.3.1 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



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.


29

Another test repeat is performed for user ACCOSP2010\User2, without entering the required information.

Table 5.3: Test 1c






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







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.

5.3.2 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


Navigate to “Tasks” list Access granted. Access granted.




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.


30

The test is then repeated for the user ACCOSP2010\User5.

Table 5.6: Test 2b



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







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






Create the task Information is not saved. Error is highlighted.

Information is saved.

(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.


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


Create approval task Task created and assigned to ACCOSP2010\User1

Pass

Approval status changed (User1 approved task)

Workflow continues Pass

Notify developers Members of Developers user groups in both domains receive e-mail

Pass

Notify creator Creator receives e-mail Pass

Create assignment task Task created and assigned to ACCOSP2010\User2. Task created and assigned to <internal_domain>\mmt.

Pass

Task assignment changed (User2 assigned task)

Task for user ACCOSP2010\User2 is marked as completed. Task for user <internal_domain>\mmt is marked as cancelled.

Pass

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.


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 “11th 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.


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 2010.

6.1 Future Implementation There are several aspects of this system that can be extended to add wanted functionality and add support

for remote hosting.

6.1.1 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.

6.1.2 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].

6.1.3 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.


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)

http://www.endusersharepoint.com/EUSP2010/2010/04/09/configure-item-level-permissions-for-

document-libraries-%e2%80%93-part-2-%e2%80%93-sharepoint-2010-edition/

[3] How does Audience Targeting in a List / Document Library work? (blog post)

http://blogs.technet.com/b/nishants/archive/2009/12/21/how-does-audience-targeting-in-a-list-

document-library-work.aspx

[4] How to Set Quick Launch Item User Access Permissions (TechNet forum post)

http://social.technet.microsoft.com/Forums/en/sharepointadmin/thread/8aabc283-a3bf-467f-aa8b-

69fdd8867c1d

[5] Create list relationships by using lookup and unique columns (SharePoint 2010) (blog post)

http://sharepoint.microsoft.com/Blogs/GetThePoint/Lists/Posts/Post.aspx?ID=316

[6] Calculated Field Formulas (MSDN article)

http://msdn.microsoft.com/en-us/library/bb862071.aspx

[7] Create a custom approval workflow in SharePoint 2010 (blog post)

http://sharepoint.microsoft.com/Blogs/GetThePoint/Lists/Posts/Post.aspx?ID=420

[8] Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization (MVP article)

http://www.harbar.net/articles/sp2010ups.aspx

[9] Installing SharePoint without Active Directory (blog post)

http://social.technet.microsoft.com/Forums/en-US/sharepointgeneral/thread/2f61d621-08ae-4a57-a4d9-

16ba27354658/

[10] User Profile service overview (SharePoint Server 2010) (TechNet article)

http://technet.microsoft.com/en-us/library/ee662538.aspx

[11] Create, edit, or delete a User Profile service application (SharePoint Server 2010) (TechNet article)

http://technet.microsoft.com/en-us/library/ee721052.aspx

[12] Workflows in SharePoint Server 2010 (MSDN article)

http://msdn.microsoft.com/en-us/library/ms549489.aspx

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.


35

8 Appendix

8.1 Questionnaire


36

8.2 Use Case Descriptions

8.2.1 Use case: Add Module

USE CASE §1: Add Module

Goal To add information about a module that is or will be part of a development

project.

Preconditions Implementation of a new module has been decided, and the user has

successfully logged in.

Success end condition The information on the module has been added to the SharePoint site.

Failed end conditions Adding the information on the module to the SharePoint site failed.

Primary, secondary actors 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 The user does not have access to the list.

2a The user does not have permission to perform this action.

4a Some required information is not entered.

4b A system error prevents item creation.

Priority High

Performance Expected 2-3 minutes to perform

Frequency Infrequently

References §1


37

8.2.2 Use case: Upload Document

USE CASE §2: Upload Document

Goal To add a document to a document library.

Preconditions The user has prepared a document, and is logged in.

Success end condition The document is uploaded to the library.

Failed end conditions The document was not uploaded to the library.

Primary, secondary actors Primary: Developer, Development Lead

Offstage actor: Development Project Management system.


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.




4a A system error prevents document upload.

6a Some required information was not entered.

6b A system error prevents document properties update.

Priority High


Frequency Frequently

References


38

8.2.3 Use case: Create Task

USE CASE §3: Create Task

Goal To create a new task to be carried out.

Preconditions Related module has been added, and the user is logged in.

Success end condition The task is created.

Failed end conditions The task is not created.

Primary, secondary actors Primary: Development Partners, Development Lead, Development Manager.



1 User navigates to the task list.

2 A new task is to be created.

3 Information is entered.

4 Task is created.





4b A system error prevents task creation.

Priority High



References §1


39

8.2.4 Use case: Assign Task

USE CASE §4: Assign Task

Goal To assign a user to a task.

Preconditions The task has been created and approved, and the user is logged in.

Success end condition A user has been assigned to the task.

Failed end conditions No user is assigned to the task.

Primary, secondary actors Primary: Development Lead, Development Manager.


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.




3a No users are available for selection.



Priority High



References §1, §5


40

8.2.5 Use case: Approve Task

USE CASE §5: Approve Task

Goal To approve or reject a new task.

Preconditions A task has been created and not reviewed, and the user is logged in.

Success end condition The task is approved or rejected.

Failed end conditions The task approval status has not been modified.

Primary, secondary actors Primary: Development Manager.


Trigger A task has been created and not reviewed.


1 User receives an e-mail about the new task.

2 User navigates to the task list via link in the e-mail.

3 A task is to be edited.

4 The approval status of the task is modified.

5 Changes to the task are stored.


1a The e-mail is never sent.

1b The e-mail is never received.





Priority High



References §1, §3


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


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


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


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


42

CustomerContact


CustomerName Lookup Reference to customer item

Task


Module Lookup Links task to the related module (name and version)


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 RAM1

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

8.4.1 Users available for login

The SharePoint site created in the development is accessible externally.

It can be reached at http://s050424.accobat.com2.

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 e-mail 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; s050424_Development_Managers; Domain Admins

Development_Managers

ACCOSP2010\user2 Passw0rd1 Development_Leads; s050424_Development_Leads

Development_Leads

ACCOSP2010\user3 Passw0rd1 Developers; s050424_Developers

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.


44

8.5 SharePoint site

Site

Documents

Modules

Customer Contacts

Customers

Approval workflow (custom)

Tasks


Write:Developers

Read:

Write:Development_Leads;Development_Managers (+approve)

Read:Developers (+ edit);Development_Partners (+ create)

SharePoint Group Permission LevelDevelopment_Managers: (N/A)Development_Leads: (N/A)Developers: ReadDevelopment_Partners: (N/A)Customer_Managers: Contribute

Write:Development_Leads;Development_Managers

Read:Developers (+ edit);Development_Partners

Write:Customer_Managers

Read:Developers

SharePoint Group Permission LevelDevelopment_Managers: ContributeDevelopment_Leads: Full ControlDevelopers: Read (Edit)Development_Partners: ReadCustomer_Managers: (N/A)

SharePoint Group Permission LevelDevelopment_Managers: Full ControlDevelopment_Leads: ContributeDevelopers: Read (Edit)Development_Partners: Read (Create)Customer_Managers: (N/A)

SharePoint Group Permission LevelDevelopment_Managers: (N/A)Development_Leads: (N/A)Developers: Full ControlDevelopment_Partners: (N/A)Customer_Managers: (N/A)

Write:Developers;Development_Managers

Read:Development_Partners (audience)

SharePoint Group Permission LevelDevelopment_Managers: ContributeDevelopment_Leads: (N/A)Developers: ContributeDevelopment_Partners: ReadCustomer_Managers: (N/A)

Shared Documents

Write:Developers

Read:Development_Managers;Development_Partners

SharePoint Group Permission LevelDevelopment_Managers: ReadDevelopment_Leads: Full ControlDevelopers: ContributeDevelopment_Partners: ReadCustomer_Managers: (N/A)

Figure 8.1: SharePoint site and permission structure


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 8.4.1.


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 8.4.1.