Project Management in Team Software Projects

1
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

2
Introduction

• Leeds Source-IT
• Version Control for Software Development
• Group Project Management

3
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

4
Version Control for Software Development

• Leeds Source-IT
• Version Control for Software Development
• Group Project Management

5
(No Transcript)
6
Informing the Version Control

• Version control systems must be notified of
  changes to the directory structure
• including notifications of additions, deletions,
  copies and moves
• svn add ltfilegt git add ltfilegt
• svn rm ltfilegt git rm ltfilegt
• svn mv ltfilegt git mv ltfilegt

7
Pushing Changes

• 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
• git commit -a Explanation of changes
• Updating the local copy with the latest changes
  in the repository. To update a local copy
• svn update
• git pull

8
(No Transcript)
9
(No Transcript)
10
Managing Conflicting Changes

• Version control systems 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?
• Version control systems 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.

11
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.
• See man git-merge-file for resolving changes to
  the same file

12
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)?

SVN
File A User 3
File A User 1
File A User 2
13
Group Project Management

• Leeds Source-IT
• Version Control for Software Development
• Group Project Management

14
Leeds Source-IT Group Project Management

• What is Project Management?
• Sequence of tasks
• Consumes resources
• Achieves an objective
• Results in something new
• Golden Rules of Project Success
• 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

15
Project Stages

• 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).

16
Software Requirements Specification (SRS)?

• Well-designed, well-written SRS accomplishes four
  major goals
• 1. It provides feedback to the customer.
• An SRS is the customers 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.

17
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
• 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
• 3. External Interface Requirements

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 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 6. Other
Requirements Appendix A Terminology/Glossary/Def
initions list Appendix B To be determined
18
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 left 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.

19
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?

20
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

21
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

22
Redmine and Requirements
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.
23
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.

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

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

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

27
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

28
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 youd
  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

29
Testing

• Software testing is an empirical investigation
  conducted to provide information

30
Finding Faults Early

• It is commonly believed that the earlier a defect
  is found the cheaper it is to fix it.

31
Testing Methods

• Specification Based Testing
• aims to test the functionality according to the
  requirements. (verify that for a given input, the
  output value or behaviour)?
• 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.
• 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.

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

33
Source-IT Project Feature Process for a Consultant
34
Source-IT Project Milestone Process for a
Consultant
35
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).

36
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 weeks 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

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

38
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

39
Homework

• Home work task
• Familiarise yourself with Redmine when put on a
  project
• http//pm.leeds-source-it.com
• Other sandbox management applications for Trac
  Bugzilla etc. (search the web)?
• 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

40
Any Questions????
41
Further Information

• Literature
• Baars, Wouter (2006). Project Management Handbook
  (open source), version 1.1, Edita-KNAW.
• External Links
• 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...