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

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

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

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

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

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 email messages or meetings

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?

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.

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

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

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

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

Version control

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

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;

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!

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)

Concurrent Development

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

Merge Conflict

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

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.

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

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, …

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

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

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

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

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)

Example JIRA

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) …

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

Programming Knowledge vs Age

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

Next class UI designer