Project Management in Team
Software Projects
“The primary challenge of project
management is to achieve all of the
goals of the project charter while
adhering to the four classic project
constraints – scope, time, cost, quality”
Introduction

Leeds Source-IT

Version Control for Software Development

Infrastructure for Agile Project Management

Group Project Management
Leeds Source-IT
“Leeds Source-IT is a consultancy service staffed by high
calibre Computing student programmers and managed by
experienced staff. We undertake self contained projects on
a fixed price basis. All projects are tightly specified up
front and undertaken using Agile Programming
techniques, monitored on-line with dedicated project
management software and client sign off stages”
Version Control for Software
Development

Using Subversion (SVN)

Making Changes

Deleting Files

Managing Conflicts
Retrieving from SVN


Initial check out of an existing project. The following
command will check out a working copy of an existing
project:
svn checkout <repository URI>
This will check out the project into the current directory.



A particular revision can also be specified with “revision”
number. ‘checkout’ can also be ‘co’.
You are now ready to work using SVN. Subsequent
commands require entry from the root of the checked
out project directory.
Notifying Subversion of local modifications
Adding to SVN



Modifications to existing files will be automatically
detected by Subversion and included in future commits
(and updates).
Adds file to Subversion (to be included in the next
commit). If file is a directory, file is added recursively,
including all subdirectories and files.
svn add <file>
commit your changes now.
Deleting to SVN



Subversion must be notified of changes to the directory
structure including notifications of additions, deletions,
copies and moves:
svn delete <file>
Deletes file from the working copy and informs
Subversion to delete the file from the repository at the
next commit
commit your changes now.
Pushing Changes to SVN


To share changes made to the local copy with other
developers, the changes must be uploaded to the
central repository:
svn commit [-m “Explanation of changes”]
Wait for other users to commit their files.
Pushing Changes to SVN II


Updating the local copy with the latest changes in the
repository. To update a local copy:
svn update
This command fetches the HEAD version of each file
from the repository and lists each file with a prepended
flag specifying the state of the file in relation to the
current working copy.
Flag Description
Flag
Description
U
The file has been updated with changes fro the server.
A
The file or directory has been added
D
The file or directory has been deleted
R
The file or directory has been replaced (an existing file was deleted,
then a new file of the same name was created)
G
The file has been changed locally and remotely, but the changes did
not conflict and have been automatically merged by subversion.
C
The file conflicts with changes from the server.
Reference: c/files/documents/15/177/svn-ref.ps
Managing Conflicting Changes

Subversion will merge multiple changes to the project
so that subsequent checkout commands will retrieve
the latest version of each file in the repository.


What happens if a file has been modified by multiple
users since the last checkout/commit cycle?
Subversion cannot know which version is correct





informs the user there is a conflict
prevent further changes until this conflict is resolved
Conflict needs to be resolved manually
Usually this will require a discussion between the
authors of the changes.
The file can then be edited to the correct state.
Managing Conflict II


Once a conflict has been resolved, Subversion must be
informed of this resolution before the working copy is
allowed to be committed
svn resolved filename
Marks the conflict on filename as resolved. The file can
now be committed to the repository. Perform these
steps again, so your partner can resolve a conflict.
Managing Conflict Task

In groups discuss the following questions:
1. Who decides which changes are kept and which is deleted?
2. What impact do you see during code development?
3. What mechanisms would you put in place to ensure the correct
decisions are made?
4. What are the different scenarios causing conflict (consider
different orders of checkout, update, resolve and commit)
File A
User 3
SVN
File A
User 2
File A
User 1
Tools and Infrastructure of
Software Development
This section of the workshop demonstrates how
to set up the Eclipse IDE for use with Leeds
Source-IT infrastructure.
Installing an Eclipse Subversion
plug-in

Two Eclipse plug-ins exist for Subversion:




Subclipse from the original Subversion
developers, and
Subversive, from the Eclipse foundation.
Both offer the same functionality and are
presented in a similar way.
This workshop discusses installing
Subversive, but the steps are similar if your
prefer Subclipse.
Installing Subversive


In Eclipse, navigate to:
Help | Software Updates...
On the panel that appears, click the Add Site... button on the right
and enter the following URL in the location field that is displayed:
http://www.polarion.org/projects/subversive/download/eclipse/2.0/update-site/


Select the following:
 Subversive SVN Connectors
 SVN Team Provider
 SVN Team Provider Localization
 SVNKit (either version)
Then click the Install... button.
Checking Out an Existing
Project





To check out an existing project:
File | New > Project...
In the displayed dialog select SVN | Projects from SVN
A new dialog will be displayed containing existing SVN repositories that
Eclipse is aware of. Select a repository if it in the list, otherwise select
the ‘Create a new repository location’ and click next. If a new repository
is selected, enter your username and password and enter the URL to
retrieve the SVN
Each project will be running its own SVN and you will be provided with
the correct URL to access the SVN for a project
A list of directories will be displayed (corresponding to available projects
if a project name was not specified in the URL). Select the appropriate
directory and click Finish to check out the project into an Eclipse project
of the same name (Next will allow this default name to be changed).
Working with a Shared Project


Eclipse greatly simplifies using Subversion when compared to the
command line approach.
To update or commit a project right click the project name in the
Project Explorer view and choose
 Team | Commit... to commit changes (and a commit message)
 Team | Update to get the latest changes.
 Team | Synchronise with Repository does a commit and
shows any conflicts.



Double clicking the conflicts opens an editor displaying the local
copy and the latest repository copy side by side
Once all conflicts have been resolved, the project will need to be
recommitted (conflicts prevent the first commit from completing).
As well as easing the conflict resolution task, Subversive handles
changes to the directory structure by automatically performing the
correct svn command for moves, deletes and copies.
Introduction to Mylyn

Mylyn extends the Eclipse SDK with sophisticated
mechanisms for keeping track of tasks.



A task is any unit of work that you want to recall or share with
others, such as a user-reported bug or a note to yourself
about improving a feature.
Mylyn lets you store tasks locally in your workspace or work
with tasks stored in one or more task repositories.
Leeds Source-IT uses Redmine as a task repository and to
coordinate all aspects of project management.

To connect to the Leeds Source-IT task repository, you must
have installed a Mylyn connector for a web based repository.
Installing Mylyn

To install Mylyn for your version of Eclipse, use the Eclipse Update
Manager:
Help > Software Updates > Find and install > Search for new features to install

The Mylyn web connector is currently in the Eclipse incubator, so will
need to be added to Eclipse’ list of sites to search for updates. Click on
Add Site and enter the following URL:
http://download.eclipse.org/tools/mylyn/update/incubator


Click OK
Now select the Mylyn Connector: Web Templates (Advanced) and click
on Install.
Connecting Mylyn to a Redmine
Task Repository

Open the task repository view in Eclipse:




Window > Show View... > Other...
The select Task Repositories under the Mylyn folder and click OK.
In the Task Repositories window, right click and select Add Task
Repository.
In the dialog, select Web Template (Advanced) and click Next.
For the server, enter the following URL, id, passwd:
 http://sourceit.leeds.ac.uk and provide an appropriate label.
 Enter your user id and password and click the Advanced Configuration
arrow.
 Enter the following:
Task URL: ${serverUrl}/issues/show/
New Task URL: ${serverUrl}/projects/<projectName>/issues/new
Query Request URL: ${serverUrl}/issues [GET]
Query Pattern: <td class="subject">.*?<a
href="/<projectName>/issues/show/(\d+)">(.+?)</a></td>
Login Request URL: ${serverUrl}/login?username=${userId}&password=${password} [POST]

Click Finish
Group Project Management
Leeds Source-IT Group Project
Management

What is Project Management?





Golden Rules of Project Success







Sequence of tasks
Consumes resources
Achieves an objective
Results in something new
Develop a comprehensive, realistic plan and keep it up-to-date
Gain consensus on project outcomes
Make reasonable resource requirements
Build the best team you can and take care of them
Keep the stakeholders informed
Be willing to change or to try new things
The Source-IT infrastructure provides all the necessary tools
available to achieve these points if used correctly.
Project Members need to keep the project information current
Project Stages
Initiate
Plan
Set goals and objectives Define Project Scope
Implement
Close
Appoint project manager Sequence Tasks
Conduct post-project
review
Lead team
Prepare final
deliverables
Maintain communication Shut down operations
Select team members
Evaluate change requests Disband team
Identify expectations

Identify tasks
Define resource needs
Obtain resources
Contract Set-up Phase




(LSIT managers) liaise with clients to understand their requirements
and agree the Specification.
Price for the work will be derived from this, based on the agreed
Skills List and estimated times.
Hourly rates or a task based rate will be agreed and formalised
within the Client Contract.
We will use standard templates provided by University of Leeds
Consultancy Ltd (ULCL).
Software Requirements
Specification (SRS)

Well-designed, well-written SRS accomplishes four major goals:
1. It provides feedback to the customer.
 An SRS is the customer’s assurance that the development organization
understands the issues or problems to be solved and the software behaviour
necessary to address those problems.
 SRS should be written in natural language, in an unambiguous manner that may
also include charts, tables, data flow diagrams, decision tables, etc.
2. It decomposes the problem into component parts.
 The simple act of writing down software requirements in a well-designed format
organizes information, places borders around the problem, solidifies ideas, and
helps break down the problem into its component parts in an orderly fashion.
3. It serves as an input to the design specification.
 SRS serves as the parent document to subsequent documents, such as the
software design specification and statement of work.
 SRS must contain sufficient detail in the functional system requirements so that a
design solution can be devised.
4. It serves as a product validation check.
 SRS also serves as the parent document for testing and validation strategies that
will be applied to the requirements for verification.
SRS – IEEE Standard 830-1998

Adaptation and Extension of the Standard
1. Introduction
1.1 Purpose
1.2 Document conventions
1.3 Intended audience
1.4 Additional information
1.5 Contact information/SRS team members
1.6 References
4. System Features
4.1 System feature A
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature B
2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design/implementation constraints
2.7 Assumptions and dependencies
5. Other Nonfunctional Requirements
5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation
3. External Interface Requirements
3.1 User interfaces
3.2 Hardware interfaces
3.3 Software interfaces
3.4 Communication protocols and interfaces
6. Other Requirements
Appendix A: Terminology/Glossary/Definitions list
Appendix B: To be determined
Specification Task
Sort yourself into groups and
complete the following
specifications and requirements.
Specifications:

Create a picture with geometrical shapes
of various colours. The picture will

have a red star, a blue circle and a green
triangle not overlapping with two

diagonal black lines crossing at the
centre.
Requirements:
1. Diagonal lines
1.1 lines are black and straight
1.2 lines are drawn to intersect in the
centre of the page
1.3 First line is from the top left (below the
corner) to bottom right
(above the corner)
1.4 Second line is from top right corner to
bottom right corner
2. Red star
2.1 Start is red and colour filled
2.2 Star is a six pointed star
2.3 Star is positioned on the upper right
section of the page
2.4 Star is small in size
3. Green triangle
3.1 Triangle is green bordered with no fill
3.2 Triangle is positioned on the top left
below the line from top left to bottom right
3.3 Triangle is large in size
4. Blue circle
4.1 Circle is blue with no fill
4.2 Circle is position at the bottom of the
page
4.3 Circle is not touching the black lines
4.4 Circle is medium in size
Draw the picture to the specification
and requirements.
Specification Task II

Discuss any differences in the image and the
specification.



How does it differ?
What specifications needed to be added to make it an
exact replica.
Question:

What impact would differences here have on the
development of software?
Issues: Features, Documents
and Bugs

Using the Source-IT infrastructure and online
software for project management (Redmine).


Issues are used to define features, documents
and bugs needed for development and new
versioning.
Issues == Requirements == Features
Identifying and Linking
Requirements to Source

Requirements (or issues in
Source-IT) for development
require the following fields:
Requirement Number
Unique Identificaiton
Requirement Type
Type as defined by the project and
Source-IT
Specification Numbers
To map the requirement to the client
specification
Description
One sentence statement of the
requirement
Originator
Who created the requirement
Fit Criterion
The measurement of the requirement
to test is the solution matches the
requirement
Priority
Rating of the customer value
Supporting Material
Pointers to documents that explain
this document (probably the
specification document)
History
Creation, changes, deletions etc.

In the Source-IT infrastructure, the
requirements are added as Issues
labeled Features within the Software
Application. A unique ID is already
allocated. Fields within the
application.
 Low
 Normal
 High
 Urgent
 Immediate
Redmine and Requirments
New
Specification for Milestone
Issues/Feature set in system
Assigned
Resolved
Assigns issue to consultant
Issue status as completed
Feedback
Closed / Rejected
Requirements
Need to be mapped to Source-IT
specifications
Who
Client / Manager / Consultant
Manager / Consultant
Consultant
Code committed to SVN and
revision number added. Code
passes all unit tests
Issue requires acceptance testing All issues related to the milestone Manager / Consultant
from client
are completed. Issue titled
“Feedback”•created and assigned
to client and manager contacts
client.
Issue status set as completed. If Issue “feedback”•closed by client. Manager / Consultant
rejected, can be reopened or new Client required to sign of Milestone
issue/feature set to pass
as “accepted”•
During the team kick off meeting for a project. Clients, Source-IT management and
consultants will discuss and set the specification requirements to create a Source-IT
requirements specification document (technical document) to be signed off by the
client and management. Each specification will have a unique id and allocated to a
milestone agreed by the kick-off team and setup as an issue/feature within the
Source-IT infrastructure. The above table specifies the process to create, implement
and sign off a specification.
Penny Queue Exercise:
Waterfall and Agile


This simple simulation exercise helps people to understand
the efficiency that can come from moving away from a
waterfall or large batch process. The exercise can be done
with 20 pennies, 5 people and a clock with a second hand.
The exercise simulates processing work in the form of
flipping pennies from heads to tails and back. Four people in
the Team sit at a table or other hard surface in a line beside
each other. The surface must allow for easily sliding the
pennies. The fifth person, the Manager, starts the process
and times it.
Penny Queue Exercise:
Waterfall and Agile II
First Pass - Waterfall Large Batch
1. The Manager gives all the pennies to the first person in the
Team and notes the start time. The pennies should be in a
big jumble.
2. The first Team member chooses a side (heads or tails) and
flips all the pennies onto that side.
3. The person with the pennies passes the whole pile of
pennies to the next person. That person then flips all the
pennies to the other side.
4. Repeat step three until the last person on the Team has
flipped them.
5. The manager notes how long this took.
Penny Queue Exercise:
Waterfall and Agile III
Second Pass - Waterfall Small Batch
1. The Manager gives all the pennies to the first person in the
Team and notes the start time. The pennies should be in a
big jumble.
2. The first Team member chooses a side (heads or tails) and
flips all the pennies onto that side. As each penny is flipped,
the Team member passes it along to the next person.
3. Each person flips their pennies as quickly as possible and
immediately passes them on to next person.
4. Do this until they are all flipped.
5. The manager notes how long it took for the first penny to go
through all four Team members, and how long it took for all
of them to finish.
Penny Queue Exercise:
Waterfall and Agile IV
Third Pass - Parallel Small Batch
1. All the pennies are in a random jumble in the middle of the
table.
2. One Team member calls heads or tails and the manager
notes the start time.
3. Each person grabs a penny at a time from the pile.
4. All working at the same time as quickly as possible, each
person flips the pennies first so they are all the same as the
original call if needed, and then three more times
5. As each penny is finished 3 or 4 flips (as appropriate) it is
pushed into a separate done pile in the middle of the table.
6. The Manager records the time for the first penny to be put
into the done pile and for all of them to be completed.
Milestones


Milestones are arranged by Leeds Source-IT managers,
you (the project team) and the clients.
Develop An Overall Model - goal is to identify and
understand the fundamentals of the domain that your
system is addressing
 Build Features List, grouping them into related sets and
Subject areas. These first two steps map to the initial
envisioning effort of AMDD .
 Plan By Feature, the end result being a development, the
identification of class owners (more on this in a minute),
and the identification of feature set owners.
 Design By Feature, design feature
 Build By Feature, complete client values function
Milestones II


The majority of the effort on an FDD project,
roughly 75%, is comprised of the fourth and fifth
steps Design By Feature and Build By Feature.
These two activities are exactly what you’d expect,
they include tasks such as detailed modeling,
programming, testing, and packaging of the system.
FDD also defines a collection of supporting roles,
including: Domain Manager; Release Manager;
Language Guru; Build Engineer; Toolsmith; System
Administrator; Tester; Deployer; Technical Writer
Milestone and Features
Allocation Task




Set yourself into groups of 5 (appoximately).
From a set of tasks handed out,
 sort the task into a features list
 allocate who will do which task.
 Finish the tasks and write down your results for X.
Question:
1. What were your milestones?
2. What problems did you encounter?
3. Who ensures the issues and features have passed to
close a milestone?
Discussion adding requirement from tasks into Redmine.
Think about allocation, completion and testing
Testing
“Software testing is an empirical investigation
conducted to provide information”
Finding Faults Early

It is commonly believed that the earlier a defect is found the
cheaper it is to fix it.
Time Detected
Requirements Architecture Construction System Test Post-Release
1
3
5–10
10
10-100
–
1
10
15
25-100
–
–
1
10
10-25
Testing Methods


Specification Based Testing
 aims to test the functionality according to the
requirements. (requires thorough test cases to be
provided to the tester who then can simply verify that for
a given input, the output value or behavior)
Black Box Testing
 treats the software as a black-box without any knowledge
of internal implementation. methods include:

equivalence partitioning, boundary value analysis, all-pairs
testing, fuzz testing, model-based testing, traceability matrix,
exploratory testing, specification based testing, etc.
Testing Methods II


White Box Testing
 when the tester has access to the internal data structures
and algorithms (and the code that implement these)
Grey Box Testing
 involves having access to internal data structures and
algorithms for designing test cases, but testing at the
user, or black-box level.
Non Functional Software
Testing

Special methods exist to test non-functional aspects of
software.

Performance testing checks to see if the software can handle
large quantities of data or users. Generally referred to as
software scalability.

Usability testing is needed to check if the user interface is
easy to use and understand.

Security testing is essential for software which processes
confidential data and to prevent system intrusion by hackers.

Internationalization and localization is needed to test these
aspects of software, for which a pseudolocalization method
can be used.
Source-IT Project Feature
Process for a Consultant
Task
Allocated feature
SVN
Checkouts code from the
project
Redmine
Update – set “Status” and
“Assigned to”
Implements test code for
TDD
Commits test code
Logs time as Activity Testing
Implements code
Logs time as Design /
Development
Test feature
Update – log results in notes
Submit completed tested
code
Commits test code
Update – log revision number
in notes; update “Status”
Source-IT Project Milestone
Process for a Consultant
Task
Allocated Milestone
Action
Allocated by Management and the project team
Checks and runs test code for Commits test code
features
Reports results in Redmine
Informs team members of issues and problems; sets new
bugs and features to fix problem
Create deliverable
Package code for deliverable, tag revision number in the
SVN
Client sign off
Work with management for client sign off
Source-IT Project Finalisation



Once the project is internally signed off, it will be presented
to the Client who will externally sign off.
 Note that this may be a staged process, depending on
the contract, as Clients may wish to sign off each part of
the work (see milestones).
Once the Client has fully approved the work, they will be
asked to sign a formal written Acceptance Form and the
project will be terminated.
Financial payments and invoicing will be carried out by
ULCL (including debt chasing if necessary).
Risk Assessment for Student
Consultants
1. Students failing to complete work on time (for instance due to abilities,
illness)





Careful recruitment and selection
Clear guidance and briefing of terms of work
Support in the case of lack of skills
Students required to file work at least weekly, so that at most one week’s
work (ie. 5 hours) will be lost
Students paid only on satisfactory completion of work
2. Students unable to do work and withdrawing from all or part of a project
As (1).


Work allocated to another student asap.
Client advised and extra time requested if necessary.
3. Students making errors in work



Test plan to be part of each project
Students check each others’ work
Weekly monitoring
Risk Assessment for Student
Consultants II
4. Clients dissatisfied


Agree very tight specification, to form part of a signed agreement
Clients involved in sign off at each stage of process
5. Clients refusing to pay

Refer to ULCL for standard debt chasing procedures
6. Clients taking us to court

Refer to ULCL
7. Clients not providing sufficient support to process (eg. not attending
project management meetings or providing details for specification)


Support to project management procedures part of contract with client
They need to agree either decisions made without them, or project delay.
Risk Assessment for Student
Consultants III
8. Hardware failures (particularly on student computers)



Appropriate guidance on backing up
Encourage students to use SoC facilities including SVN
Provide 1-2 LSIT machines in dedicated LSIT office
9. Software problems - delays due to need to install libraries or plug-ins for
specific projects


Support asked to give priority to LSIT when there are deadlines
Investigate software requirements as part of specification and start up
process
10 Not enough work coming in


Students only paid if work available.
Some costs of pilot phase could be covered by start up funding
11. Too much work coming in



Manage client expectations
Look for appropriate partners who we could pass work to in busy times
Consider running a modified scheme based on vacation working
And that’s it!
Homework

Home work task for accepted Consultants

Familiarise yourself with Redmine
 http://sourceit.comp.leeds.ac.uk/
 Other sandbox management applications for Trac; Bugzilla
etc. (search the web)

Skill: Please complete the Skills section in Redmine when you
have an username

PDP: Please think what you wish to obtain from Source-IT
(other than money)


Select the categories and during your time on Source-IT add
examples on work you are doing.
If you wish to add any categories to the PDP, please contact a
member of management
Any Questions????
Further Information

Literature


External Links:





Baars, Wouter (2006). Project Management Handbook (open
source), version 1.1, Edita-KNAW.
The Project Management Institute
IPMA - The International Project Management Association
The Australian Institute of Project Management
SVN, subversion.tigris.org/files/documents/15/177/svn-ref.ps
Search the Web

Prince 2; Agile; SVN; Eclipse, etc...