T106'3100 Team work, project planning

1
T-106.3100Team work, project planning version
control

• Jari Vanhanen/SoberIT
• 21.2.2006

2
A Software Development Scenario

• A highly experienced coder develops software
• alone
• as a passionate hobby
• for his own needs
• without external time pressure
• with unlimited available effort
• without major consequences of bugs
• without delivering the sw to be developed further
  by others

3
Another Software Development Scenario

• Average sw developers develop software
• as a team
• as their daily work
• for an external customer/users
• who pay for the software
• where the management wants to follow the project
• within a strict schedule and budget
• where every hour costs money
• where bugs may cause major consequences
• where the maintenance responsibility must be
  successfully transferred

What should we pay attention to when we develop
sw in this scenario?
4
Challenges in this scenario

• Average sw developers develop software (skills)
• as a team (communication, coordination, team
  spirit)
• as their daily work (motivation)
• for an external customer/users (understanding
  real needs)
• who pay for the software (economic importance of
  the project)
• where the management wants to follow the project
  (visibility)
• within a strict schedule and budget
  (predictability)
• where every hour costs money (efficiency,
  prioritization)
• where bugs may cause major consequences (quality)
• where the maintenance responsibility must be
  successfully transferred (maintainability, tech.
  documents, training)

Fortunately the course project is much simpler
than this!
5
A story of four people...
This is a story about four people named
Everybody, Somebody, Anybody and Nobody. There
was an important job to be done and Everybody was
sure that Somebody would do it. Anybody could
have done it, but Nobody did it. Somebody got
angry about that, because it was Everybodys job.
Everybody thought Anybody would do it, and Nobody
realized that Everybody wouldnt do it. It ended
up so that Everybody blamed Somebody when Nobody
did what Anybody could have done.
6
Special Challenges in T-106.3100 Project

• Physical distribution
• the group is not likely to have a common work
  place
• special care for communication
• communication practices, reporting, risk
  management
• Temporal distribution
• only one of several on-going projects for all
  participants
• long duration, part time work
• difficult to remember all necessary things
  (documentation?)
• Team has no existing development culture
  (process)
• and people are not necessarily even familiar with
  each other
• process must be planned and adopted from scratch

7
Is project planning difficult?

• Probably, but it should provide answers to fairly
  simple questions

- Why? - What? - When? - Who? - Where? - How? -
How much? - Assuming?
Goals
Work Products and Milestones
Responsibilities, Coordination
Approach, Practices, Tools
Resources
Risks, Beliefs, Priorities
8
Project Control Variables

• Scope - fixed
• see project guidelines
• Quality - fixed
• high quality recommended
• Effort - flexible
• as much as it takes

9
Effort distribution in large student projects
10
Plan the Phases

• Split the project into phases
• schedule and rough content is defined by the
  course
• Make a plan for each phase
• a tentative plan for each phase in the beginning
  of the project
• refined/updated plans later
• Plan
• deliverables
• tasks
• schedule

11
Plan the Phases - Deliverables

• What needs to be produced in this phase?
• sw features
• documents

12
Plan the Phases - Tasks

• What tasks are needed for producing the
  deliverables?
• design, coding, testing, documenting
• dont forget non-development activities that also
  take effort
• project management, meetings etc.
• Divide tasks to the developers
• who takes the main responsibility of each task
• Estimate task efforts
• splitting a large task into smaller ones helps
  estimation
• Have I done something similar before?
• Have the others done something similar before?
• measure now, and the next time you know!

13
Plan the Phases - Schedule

• Identify possible dependencies between tasks
• Schedule tasks
• leave buffer
• Set internal milestones
• controlling and ensuring progress
• work often gets done just before the deadlines

14
Plan Practices and Tools

• Project management
• planning
• progress control
• risk management
• Design
• understanding the existing system
• strategy for implementing the new features
• certainly an iterative activity
• how it is done (together/by a lead architect?)
• some design decisions must be know by the whole
  team
• Coding
• development environment(s)
• assigning coding tasks
• minimizing dependencies between coders
• managing simultaneous work
• version control
• Testing (lecture on Thursday)
• planning, doing, reporting (how, what, when,
  who,)
• defect management

15
Plan Communication

• Challenging for a distributed project team
• Information to share
• design decisions
• problems
• coding tips
• project status
• general feelings

• Communication channels
• co-located team
• pair programming
• face-to-face meetings
• irc
• phone
• e-mail lists/discussion forums
• shared directory/version control system
• white board in common workspace/Wiki
• documents (design, project status, )
• change log in version control
• code comments

Having a common vocabulary for the project helps
communication
16
Hints

• Arrange a kick-off
• Get to know each other
• Find out each others commitments and personal
  interests
• Agree on your teams goals
• Agree on practices and practicalities
• Start work immediately in the beginning of the
  phases
• more calendar time to react to unexpected
  situations

• Try one-day group sessions
• work together as a team
• peer pressure as booster for productivity
• problems can be addressed immediately
• prepare well
• hw sw
• pizza coke

17
Project Retrospection

• Analyze the project in order to learn for the
  future
• what worked well, what didnt work
• consider the context of the project
• Estimated and realized effort
• Teamwork
• Design, coding, testing

Discuss these already during the project!
18
Version Management
19
Shared Data Problem

• File in one place
• only one person is allowed to work with the file
  at a time

FILE.C
20
Double Maintenance Problem

• Multiple copies of a file
• when one is changed, all must be updated

FILE.C
FILE.C
FILE.C
21
Simultaneously Update Problem

• A master copy and personal work copies of a file
• if two work copies are changed simultaneously,
  the latter changes overwrite the former changes

FILE.C
Work Copy
FILE.C
FILE.C
Master Copy
22
More problems

• Old versions are needed sometimes
• fixing previous releases
• finding out what change broke the system
• reverting to the latest working version
• Some versions of the files are compatible with
  each other and some versions are incompatible

23
What needs to be under version control?

• Preferably everything
• requirements
• design documents
• source code
• scripts
• test material
• instructions
• program builds (executables)
• used external files (reused libraries)
• used development tools (compiler)

Instead of files, some tools support managing
logical items such as requirements, classes, test
cases
24
Two Types of Versions

• Version
• An instance of an item that in some way differs
  from other instances of the same item
• Variant
• a version that is customized for a specific
  purpose
• platform, customer
• an alternative to another variant
• branch
• Revision
• a different version of one and the same variant
• replaces the previous revision

25
Two Types of Variants

• Permanent variants
• the changes are not intended to be merged
• e.g. for many operating systems
• Temporary variants
• the changes made in variants are merged later
• bug fixes
• parallel development versions

26
Configuration

• Certain versions of the items having some purpose
• e.g. a product release

tagging
Display
Newkey
Main
Logo
Release 3.00
1
4
4
3
Release 2.00
1
2
2
Release 1.00
27
Merging Variants
4
3
Branch 2 revision where the changes are merged
2
2.1
Branch1 revision which changes are merged
Base the last common ancestor
Bugfix
1
Main
28
Support for Merging Variants

• Version management tools can usually handle ASCII
  files
• showing the differences between versions
• merging versions
• Binary files typically require application
  specific tools

29
Textual Merging

• Versions are compared line by line to a common
  ancestor
• a change can add/delete/change a line
• Tool merges the changes and suggests a result
• physical and logical conflicts possible
• check results carefully

30
Managing Variance

• Localizing variance to as few items as possible
• e.g. design a common interface for operating
  system specific calls and implement variants
  based on that interface
• Minimizing duplicated code between variants of a
  file
• Storing many variants within one source file
• preprocessing IF macros
• variance is not localized
• variants are not separated, independent
  development hard
• files become unreadable

31
CVS
32
CVS - Concurrent Versions System

• Open source
• Available for all common operating systems
• Simple version control tool with some support for
  team work, product structure, and customization
• Client/server support
• a single repository used by all clients
• Limited functionality, but free and simple to
  deploy
• Commands
• cvs -cvs_opts cmd -cmd_opts cmd_args

33
CVS Architecture
CVS client
Work File
Work Station
Server
CVS Server
Check-out check-in (commit)
CVS repository
Archive Files
Metadata Files
34
Archive File
The most recent version as full
The changes from previous versions (deltas)
The version label (tag) indicating the versions
of the application that the file version belongs
to
Information concerning the version (what is
changed in this particular version)
Information concerning the archive file
(description, establishing date)
Archive file
Work file
35
Repository

• CVSROOT directory contains administrative files
• Other directories contain history files (,v)
• a history (RCS) file contains all versions of a
  file and metadata
• Location specified by -d option or CVSROOT
  variable
• CVSROOTextuser_at_vipunen.hut.fi/.../mycvs/
• CVS_RSHssh
• Creating a repository
• (mkdir /.../mycvs)
• cvs init

36
Starting a project with CVS

• Plan the file organization
• Two alternatives for starting
• import existing files
• cd wdir
• cvs import myproj vendor start
• start from scratch
• create an empty directory structure and import it
  to CVS
• add files later using cvs add command

37
Basic usage

• cvs checkout myproj
• cd myproj
• ls
• CVS Makefile backend.c driver.c
  frontend.c parser.c
• emacs backend.c driver.c
• cvs commit m Implemented feature xxx

• Agree on check-in policies
• commit files after finishing a logical change
• write understandable change log comments
• avoid committing broken code
• disturbs the work of others
• must compile, must pass unit tests,
• Use Log keyword to show change logs in
  files

38
Multiple developers

• cvs commit fails if any of the committed files
  has been changed in the repository
• someone else has committed changes first
• cvs update merges recent revisions in the
  repository to those in the working directory
• conflicts are marked and must be solved before a
  new commit
• cvs diff shows the differences between two
  versions

39
Tagging

• Typically file versions dont match with product
  version numbers
• different amount of versions of different files
• cvs tag rel-1-0 .
• assigns a tag to the current revision of all
  files in ./
• cvs checkout -r rel-1-0 myproj
• retrieves the rel-1-0 of module myproj
• sets rel-1-0 to be the default branch in this
  work directory

40
Branches and merging

• Creating a branch
• cvs rtag -b -r rel-1-0 rel-1-0-bugfixes myproj
• Merging
• cvs checkout myproj
• cvs update -j r1-0-bugfixes filescvs commit -m
  Included r1-0-bugfixes

41
Problems

• Renaming/changing directories in the repository
• Binary files
• turn off keyword substitution

42
More information

• http//en.wikipedia.org/wiki/Concurrent_Versions_S
  ystem
• See also Subversion
• http//subversion.tigris.org/