1. Hao Zhong Shanghai Jiao Tong University
Project manager
Hao Zhong
Shanghai Jiao Tong University

2. Last class Debugging Automatic program repair Delta debugging
Stub, Fake object
Mock
Automatic program repair
A recent hot research topic
Cons and Pros
Latest progress
State of the art

3. Role
A project manager is a professional in the field of project management. Project managers have the responsibility of the planning, procurement and execution of a project, in any domain of engineering.
Bosses
Developer
Ambitious goals
No Surprises
Schedule
Budget
Project
Manager
Customer
Bugs
Quality engineer
Inconsistent requirements
Bad designs

4. Goal
The art of managing projects to a successful completion.
Scope
Time
Cost

5. Cost estimation COCOMO Requirement-based estimation
Function points
Use cases
Design-based estimation
Class diagram
Analogy-based estimation
Past projects

6. Planning Determine needed resources for each task
People
Computers, testing system
Develop a time line with milestones
Describe deliverables
Assign deliverables to specific people
Associate Milestones with Deliverables
Schedule tasks
Some tasks depend on others
Some tasks compete for resources
Monitor progress
Status reports can be messages or meetings

7. Planning Program Evaluation and Review Technique (PERT)
Represent tasks and their dependencies
Estimate amount of time for each task
Compute the time for entire project
How to compute the critical path?

8. Planning
Start to Start (SS): The task cannot start until the predecessor starts, although it may start later.
Finish to Finish (FF): The task cannot end before the predecessor ends, although it may end later.

9. Risks Problem harder than we thought Developers get bored and quit
Developers like new technology. It doesn’t work
System is too slow
Customers don’t know what they want
Customers run out of money and kill the project

10. How to handle the risks Process should address biggest risks
Wrong requirements
Constantly changing requirements
Inadequate schedule

11. How to handle the risks Process should address biggest risks
Wrong requirements
Iterative development
Work closely with customer
Constantly changing requirements
Design
More budget
Inadequate schedule
Increase resource
Reduce scope

12. Risk management
Risk assessment: a document listing risks, their likelihood, and their severity
Decide whether you are going to try to avoid this risk or just to monitor it
Go through requirements with domain experts
Go through designs with developers
Balance budget and delivers with your boss
Know your team members
Know how to replace members.
communication

13. Version control

14. Version control
A repository to store all staged versions (actually a base version and differences for many version control systems)
A local copy for the user (or local copies for users) to edit
A user can fetch a staged version from the repository or commit a local copy as a new staged version to the repository
fetch
commit

15. Diff
A Diff is a description of the difference between two versions of a document (source file)
The difference is described as how to change one version to make it become the other
Version 1: Version 2:
x = 0; x = 1;
Y = 1; y = 1;
Diff:
- x = 0;
+ x = 1;

16. Version Control Client
Record the revision information of each file
The repository version
The time of last checkout / pull
When update / commit, files can be
Unchanged, current – no change in LC and Repo
Changed, current – only changes in LC
Commit will apply changes to repository
Unchanged, outdated – only changes in Repo
Update will apply change to LC
Changed, outdated – both LC and Repo changes
Need to merge!

17. Concurrent Development
Assume that we have 2 developers
They use a repository on a server
They have their only local copies, LCA and LCB
When update, repository is changed to a new version (v13)

18. Concurrent Development

19. During the update/pull
Find common ancestor (v12)
Compute Diff(v12, v13): replace line 20 with
“void g(int i)”
Apply Diff(v12, v13) to LC

20. Merge Conflict

21. Merge Conflict Happens
Merge will leave a partially merged file
Your change and repo change will both appear in the file
Edit the file and commit the manually merged file
Must update before commit

22. Merge is textual Code may not work after merge Merge problems
Developer A makes the change:
f (int x, int y) -> f(int x, int y, int z)
Developer B makes the change:
insert f(a, b)
Merge problems
Code will not compile
It is lucky that it does not compile!
Communication: notify the people who may be affected
Auto test suite and Regression testing!!
M. Tufano, F. Palomba, G. Bavota, M. Di Penta, R. Oliveto, A. De Lucia,
and D. Poshyvanyk. There and back again: Can you compile that
snapshot? Journal of Software: Evolution and Process, 2016.

23. Branch Users report bugs for a released version
Bug fixes are applied on this specific version
Programmers are developing to next version (branch)
Need to merge before the next release

24. Other reasons for branches?
Temporary versions
Implement new features (tentative)
Isolate changes to have a stable trunk
Eventually merge back to the trunk
Snapshot for testing
Development continues
Fixes eventually merge back to the trunk
Separate branch for different release
Different OS, …

25. Merge Branches Merge changes of a branch to the trunk
Done on a local copy
Find the common ancestor(v12)
Find changes fro v12 to v16branch
Apply changes to v15trunk

26. Merge Branches: tracking
Branch may continue after a merge
Goes to v18 and v20
Branch records the last merge (v16)
Apply Diff(v16branch, v20branch) to v19trunk

27. Version control: tips Small commits Avoid commit noises
Place every logically separate change as a commit
Allows more meaningful commit messages
Reverted independently
Avoid commit noises
Make sure the code build before commit (especially after merge)
Unit test or if possible an automatic test suite

28. Version control: tips Write clear commit messages
Better structured with some styles
Issue number!!!

29. Issue tracking system
A platform for developers to communicate with each other
Like a forum
People can register and raise an issue
The one who raise the issue will describe the issue in details
More structured for describing issues
Component, assignees, schedules, status, resolution
Customizable
Change the contents while progress is made (status, resolution)

30. Example
JIRA

31. Type of issues Bug report (e.g., system shows wrong message)
About a bug of the software
Should include:
Step to reproduce
Expected behavior
Actual behavior
Stack trace or error message if any
New feature (e.g., add sorting to results)
About add a new feature, e.g., add sorting by modify time
Improvement (e.g., replace with a better sorting algorithm) …

32. Process of an issue States
Open
Assign
Invalid
Fixed
Closed
Won’t fix
Duplicated
Reopened …
Explain and record how open source manages its development 
Why do programmers write issue number to commit messages?
ERP for your team

33. Programming Knowledge vs Age

34. This class Project manager Responsibility Cost estimation Planning
Risk
CVS
Issue tracker (open source)

35. Next class
UI designer