CoreObjects - We build the software that builds companies™

CUP takes a radical approach to solving several aspects of the software life cycle, including managing change requests, ensuring quality code at all times by enforcing code reviews, tracking and managing issues, generating artifacts to assist in clean code, automating builds and deployment and more. In summary, CUP keeps things simple, ensures clean code and increases productivity by making the process repeatable and adaptable.

A repeatable and predictable process, while it may not always eliminate delays, will dramatically reduce them.

The biggest problem with most projects is the initial estimate. Collecting pages of details does not make your initial estimate anything other than an educated guess. Focus on estimating the overall scope of the project and get that right instead of creating large documents. Consider taking the time you would have invested in creating a detailed specification and spending it instead on executing a couple of early development cycles. Measure the project velocity during these initial explorations and make a much better guess at the project's total size.

The project velocity is a measure of how much work is getting done on your project. To measure the project velocity you simply add up the estimates of the tasks that were taken up during the iteration, and subtract the total of the actual time spent completing those tasks. That number becomes your velocity. If it is a positive number, you’re on track, and the higher the better. If it is negative and getting more so, that is a sign that you need to re-evaluate your overall project estimate.

Document work not just for the sake of documentation. Develop artifacts that assist in the development and keep it up to date.

Developing artifacts helps enforce clean code. To ensure consistent documentation, a set of core templates has to be created along with sample documentation. CUP recommends that the following artifacts be developed during the course of the project.
Use Case document (user stories)

HTML mockups/wire frames/proofs-of-concept
High level system architecture
Class design, sequence and collaboration diagrams
Java docs
Entity-relationship diagrams
Test cases
Performance and scalability bench marking
Build scripts
Release notes
Deployment scripts

Code Review is not just a “best practice.” It’s integral to high quality software development.

The objective of the Code Review is to ensure that best practices are followed and that coding standards are adhered to, resulting in clean and extensible code.

To begin with, each developer needs to pick a source file he has worked on and the team will review it.

Any issues found during the review should be tracked and taken up in the next iteration.

The source file to be reviewed will be randomly picked once the process becomes predictable and consistent.

Integrate often. Manage integration by making builds & deployment easier.

CUP emphasizes iterative development and it is very important to automate wherever possible to make the process repeatable. It is a good practice to do builds as often as possible and integrate the functionality on a regular basis to avoid issues at a later point of time. CUP recommends the following activities to be automated:

Daily Build -- Automated builds should be set up using build tools (e.g., Ant). The purpose of the automated build is to ensure that the code in the repository can be compiled at any time during the development of the application. The builds will have to be done everyday at a specified time. All check-ins for the day should be done prior to the scheduled build. Before checking in any code, it is the developer’s responsibility to ensure that the code does not break the build. The developer will have to get the latest code from the repository, compile it on the development machine, and verify the build.

Deployment Scripts -- The purpose of Deployment scripts is to ensure easy deployment to any target location. It should be possible to deploy the application on a clean box with just the basic runtime requirements like Application Server or VM in place without any manual intervention. Different techniques can be used to achieve seamless deployment. The deployment should include the database deployment scripts. After running the deployment scripts, the complete application should be set up, including a blank database with the required pre-loaded data.

Smoke Test Suite -- Smoke Test suite is a set of test cases, includes functional test cases, automated test cases, unit test cases and others, that needs to run against each build to ensure that the build is stable and is of high quality. Ideally, smoke test suite should be made a standard part of the auto-build and deployment process. The team lead, along with QA lead and other team members should identify the test cases that need to be incorporated into the smoke test suite and iteratively add the test cases every development cycle.

Smoke test suite at a minimum should including the following:

Common scenarios including registration/account creation/login
Core features
Features affecting performance (e.g., search takes more than 20 seconds to return the result set)
Bugs that have resurfaced as a result of changes to the other parts of the code (regression)
Backend functionality (e.g., work flow, email alerts) that cannot be verified by UI
Integration with external sub systems (e.g., the system may be talking to the MapQuest server or an index server and the smoke test suite needs to ensure that these integration points were not broken by the new build)

Smoke test suite execution should include:

Manual verification of test cases
Running of automated functional test scripts generated using tools like Mercury, Silk, Rational Robot
Execution of unit test cases using Junit, Nunit, Cactus, HttpUnit and others
Regression using tools like Grinder
Performance testing, including review of output logs
Execution of custom tools to verify backend functionality

Requirements – you know they will change. Know how to manage it.

Change Management is a key aspect of CUP that needs to be executed well to keep the project on schedule. Change Management is the process of determining which tasks need to be considered as Change Request (CR), deciding where they need to be prioritized in the development cycle, and tracking the tasks as such. For instance, if a task was estimated to take 16 hours to complete and the client (whether internal or external) asks for changes after the task is completed, the extra effort needed to satisfy the client's new requirements should be considered as a separate task and classified as a Change Request. If, on the other hand, the change request was made before the task was taken up for development, then the same should be reviewed and taken as part of the original task with a revised time estimate, if necessary. It's the Product Manager's responsibility to decide, in consultation with the client, whether a task should be considered a Change Request. The following are some examples:

Add User” functionality was originally implemented taking First Name, Last Name, and Login as inputs. The customer comes up with a request to include address field as well and this may include change to the presentation tier, business tier and schema changes.
The customer requests for email to be sent out whenever a new user is added. The functionality was not explicit in the requirements document nor it was made clear when the task was taken up for development.

The above 2 examples could be a very simple extension of existing functionality. But, if they are not tracked as Change Requests and the effort is not estimated properly, they can contribute to significant project overruns.

Issues will always come up. The challenge is promptly recognizing them and managing them effectively.

Every project will have it's own set of issues that need to be managed. Typically, issues are discussed on chat, email or phone, making them difficult to track. Before going into the details, it's important to understand what constitutes an issue in our context. The following are some examples: