Our Key Areas
Working Methods
Methodology
Our project management methodology is a combination of rigor, agility and methodologies from PRINCE2, Rational Unified Process and agile development.
Here’s a summary of the key strategies and tactics we employ for delivering high quality software on time.
Schedule to succeed. Delivering software on time starts with a well-defined and realistic schedule. We set small frequent deliverables, which makes it easier for the project leaders to track progress and detect slippage early. We also schedule the “big rocks first”, and aim to get the most important and possible most risky features done early in the project.
We’re diligent about tracking progress on a daily basis over a project extranet, and on a weekly basis in status meetings, so that both our team and our customer are in tune with the schedule.
Functional specifications in iterative development.The key to keeping everyone in the loop and making sure the product is something stakeholders will actually buy is creating a solid functional specification. In new product development, the functional specification is a living document that can change with customer feedback or market demands, and must be kept up to date and made available to every team member.
Common development environment. For every project, we define a common environment, so that all members of the development team are using the same platform, the same tools, and a common set of coding standards. In addition to our own coding standards and tools, we also have the ability and the experience to integrate our customers’ coding standards, toolsets, and methodologies in order to ease the knowledge transfer at the end of the project.
Avoiding the code and fix trap with unit testing, code reviews, and early bug fixing. Once development is underway, we avoid getting caught in the endless churn of bug fixing that often results in missed deadlines by fixing bugs and defects as we go. We are zealous about unit testing and code reviews – every team member is responsible for their own smoke testing, limit testing, and unit testing of their code, and we create automated test frameworks that test the application during the nightly build.
Every line of code is inspected by a peer and by the lead developer before it is committed to the source tree. Our experience has been that code reviews greatly increase software quality, predictability, and greatly decrease the chances of releasing hard-to-find defects and performance bugs.
If You Build It… Complete daily builds put everyone on the team, including the customer, on the same page. Daily builds give a visible record of progress. We believe in getting the product to a working state as soon as possible, so that QA is able to test early, and so that the customer is always aware of the state of the project.
One of our first steps before beginning construction is to set up an automated build. Before a build, we clean the whole source tree to prevent legacy errors from popping up on new builds. Builds are run nightly, so that development and QA have access to the binaries at the start of each development day.
Quality. Software quality starts with a comprehensive test plan that verifies functionality, performance, reliability, and compliance with requirements. We believe quality is the responsibility of the entire development team, not just the QA team. Software components and overall architecture are verified through unit testing and peer reviews to catch defects early. We aim to have a working build as early as possible in the project and keeping the application in a working state as we add features. This way, the software testers and our quality assurance team can start verification early in the process. We use industry-standard issue tracking systems to track change requests and defect reports throughout the lifecycle of the project.
Communicate. One of the biggest issues in software development is communication. We designate a single-point of contact with the customer, and use a secure extranet so that everyone involved has access to the latest documentation and latest build for the project.
We also make extensive use of our collaborative intranet, so that the whole company can benefit from every team member’s knowledge and research. Tracking project knowledge in a collaborative portal also helps track the legacy of decisions, and eases the knowledge transfer at project delivery.
Transition. Some of our projects transition to the customer’s engineering team for maintenance. We begin transferring knowledge early in the project by involving the customer’s team in design and architecture and through regular status meetings. Towards the completion of the project, we transfer knowledge of system architecture through training, and through careful code documentation and comprehensive design documents.
Project management
Our PRINCE2 based project management practices aim to create a tight feedback loop between our customer and the project team, to provide transparency with the client in the development process, and to ensure the project is on schedule and on budget through frequent milestones and consistent follow up.
Day-to-day project management
• Weekly team meetings to coordinate activities of the team members and bring everyone up to speed on current project status,
• Communicate the “big picture” to the team so that everyone is motivated towards the common goal
• Automated web-based timesheet system so that project managers have daily status reports from team members
• We set measurable targets and specific objectives
Meeting contractual commitments
• We set small, frequent milestones and deliverables so that we have regular, measurable updates on project status and can correct small slips quickly
• Weekly review of the project schedule to ensure that the project is on schedule and on budget
• We will flag to the client as soon as we see something going ‘out of bounds’ for whatever reason – changing requirements, slipping dates, etc
Change and configuration management
Our software configuration management (SCM) system is a combination of tools, process, and teamwork. The following describes how our change integration procedures help deliver higher quality software and help our developers work together effectively.
Source code control and version control
For source code and version control we use a mixture of Visual Source Safe and Subversion, a highly reliable and flexible source code and version control system. We are also versed in a number of other source-code control systems.
All inputs to the project that are not static are version controlled, including:
• Source files
• Test scripts
• Makefiles
• Design documentation and requirements documents
• End-user documentation
• Graphics
Issue and Defect Tracking
For issue and defect tracking we use Autotask, a highly configurable defect tracking system. We also have experience working with a number of other defect tracking systems including Bugzilla and ClearQuest, and can adapt to a customer’s environment when needed.
Build management
For every project we implement a system of daily builds and smoke tests. The daily build is the heartbeat of the project, as it gives the team a daily update on progress, and synchronizes the development team on a daily basis. The goal of every project is to reach a working build with a minimum of features as early as possible, so that development becomes a process of adding features to an already working build. Some of the benefits of having a working build early in development include:
• Testing begins early, so that defects are found early in the development cycle. Many studies have proven that the earlier a bug is found in the cycle, the cheaper the bug is to fix.
• The development team sees progress early, and on a daily basis, so everyone is motivated towards the same goal.
• Integration risk is minimized. Rather than trying to integrate large chunks of code together at the end of the project, which is expensive and risky, new functionality and new code is added incrementally on a daily basis.
The daily smoke test is a framework that tests the main functionality of the application every time a build is run. It is not exhaustive and is not by any means a replacement for the test plan, but it gives an early warning of what functionality may have been broken on a daily basis.
Quality management
Our quality assurance strategies combine both black box (manual) testing performed by the quality assurance team, and white-box testing performed by the development team. Our process dictates that it is the responsibility of the developer to produce defect-free code, so that the QA team can focus on assessing the state of the product.
We perform both white box and black box testing because we believe that neither method will uncover all defects. For example, while unit testing and peer code reviews can discover potential vulnerabilities or performance bugs that would be nearly impossible to trace with black-box testing, black box testing can uncover defects such as inconsistencies in the user interface, compatibility bugs, unanticipated error conditions, and timing related bugs that can only be uncovered by manual human testing.