Final delivery

In addition to your final presentation and demonstration of the completed system, you must prepare a handover package to deliver to your client. The package consists of a brief report reflecting on the final development session, the source code for the software itself, and an index to other deliverables (which may be stored in your code repository or its associated GitHub Wiki).

Report

Much like previous reports, you should discuss your team’s progress during the final session: how did work proceed compared with your most recent project plan, and which risks (if any) were manifested and how were they managed. Unlike previous reports, however, you cannot revise your plan and push tasks to the future. Therefore, you must include a detailed summary of which originally-requested features were delivered, which were revised (with client approval) over the course of the project, and which could not be delivered. If there is unfinished work in progress, clearly describe its location, status, and remaining tasks. You should also note any takeaways from your final presentation and acceptance testing/deployment.

Handover package

A software system is more than just the code itself. Over the semester you produced a large body of work related to your project, and now is the time to edit and organize it to ensure it provides value to the client, users, and future maintainers. For internal projects, the contents of your handover package should either be committed to your code repository or uploaded to its associated GitHub Wiki; for external projects (especially those not using Cornell’s GitHub), check with your client about how they’d like the package delivered.

Every project is different, so the exact contents and format of the package are up to you. What is important is that the contents are carefully edited and suitable for handing off to your client. You may choose to collect most of these deliverables into a single document, or you may link to dedicated files from an index document (such as a wiki page). Do not link to documents on Google Drive or other cloud services (unless they are owned by the client).

For internal projects, your delivered code must be merged to the trunk branch; code on other branches will not be considered “delivered.” (Do not push this off until the last minute—merge conflicts with other teams are possible and must be resolved.) All GitHub issues related to delivered features should be closed.

Aside from your code, your handover package should include at least the following:

• A comprehensive user’s manual documenting how to interact with your new capabilities in order to accomplish various tasks (i.e. each of the use cases you modeled)
  • Be sure to provide documentation for all user roles (e.g. reviewers, authors, administrators, etc.)
• A comprehensive maintainer’s manual documenting system design, test facilities, and deployment procedure. (When discussing test facilities, be specific about how future developers can run or reproduce your tests in order to avoid regressions.) It would probably be helpful to include some documentation elements from your previous reports (revised for accuracy), such as:
  • Requirements analysis and specification
  • Architectural diagrams
  • Class diagrams
  • Final user interface designs
  • Style guide and developer workflow
  • Test plan and results
• A signed license agreement. Internal project teams should either agree that your joint work can be published under the host application’s open-source license or that your contributions should remain private to this course. External project teams should have reached an agreement with your client during the project planning phase (see copyright for external projects).