News & Insights

Our Development Methods

Development Methodology

Connamara uses development techniques drawn from the agile software development methodologies of Extreme Programing, Scrum, and Lean. Mainly, Connamara employs the disciplines of Test Driven Development, Continuous Integration, and Automated Testing.

Test Driven Development

At the heart of our development methodology is Test Driven Development. Before implementation begins, a Connamara Business Analyst will gather requirements, which we call “features”, for the project at hand. These features are simple statements, from the user or system perspective, describing what the user or application can and cannot do with the system. From these features, the Business Analyst will create an automated test that describes scenarios that can occur as a result of the feature.

Example of a Feature and an associated Scenario

 Feature:  As a user, I can login to the system.    Background:Given the following users:| username | password || jcdowns  | abcd1234 |
   Scenario: User enters valid username but invalid password.Given I am not logged inWhen I login with username “jcdowns” and password “bogus”Then I should see “Invalid username or password”And I should not be logged in

The feature and associated scenarios are expressed as a Feature Test via a human-readable language, similar to the example above, called Gherkin.  Feature Tests are executed using the Connamara Testing Framework. The Connamara Testing Framework is based on the Cucumber testing framework. It must be noted that the Feature Tests are written before the code implementing the feature is written.

Once a test passes in our automated test environment, it is considered a regression test and must pass every time the application is built and tested.  The major advantage to this approach is that a suite of system level regression tests are created as the system is being developed, and not as an afterthought once the system is “code complete”.

Continuous Integration

Continuous Integration (CI) is the development practice of merging all developer changes to the source code of a project several times during the day. This practice eliminates the “integration hell” experienced when development teams wait till the last minute to commit their individual changes to the main source code branch of a project.

Connamara utilizes the Jenkins CI platform. Jenkins monitors the Connamara source code repository of a project. Once Jenkins detects a change in the code base for the project (a developer commit of a change), the source code is automatically checked out to a build server, built, and deployed. At this point, all the developer-written unit tests are run.  All Feature Tests (written by business analysts) describing the system features are then executed.  A test report is then produced and emailed to all interested parties.

A build is considered successful if all unit tests and feature tests that are identified to be “regression” have passed. At this point Connamara considers the application to be deployable to a production environment and able to deliver the features described by the passing regression tests.

Automated Testing

As mentioned previously, as part of the Connamara Continuous Integration Environment, the developer created unit tests and the business analyst feature tests are run automatically with each developer commit to the source code repository. The benefits of this approach is that testing is done “early and often”. This catches defects before they can make their way into production and eliminates the need for manual, error-prone, and lengthy manual testing.

Project Management

Connamara uses typical agile methods for project management. At the beginning of the project, features are estimated by the development team and assigned a point value based on their perceived complexity relative to other features. The development effort is broken into iterations (typically, an iteration lasts one to two weeks). At the end of an iteration, the total number of feature points completed (completed means that all scenarios for a feature are passing in the CI environment – no partial credit) are summed. This sum represents the development velocity for the implementation team– points per iteration. Using this velocity (or rather the average of all previous velocities) as an assumption for the future velocity provides an estimate of the time to complete the remaining features.

This velocity and the estimated completion date is reported to our clients at the end of each iteration.

What Connamara Brings to a Project

Connamara has seventeen years of experience delivering quality software to our clients. Our record of success is a direct result of the development methodology we employ, as described above, and our discipline to stick to it.

Related Reads

Embracing the Remote Revolution: Our Journey as a Remote-First Company

Labor Day Special: Celebrating a Work Culture That Knows No Boundaries As we gather around the virtual breakroom on this.

25 Business Lessons from 25 Years in Business

We reached out to our team members for timeless lessons learned in 25 years in business.

Unveiling Our Next Chapter: Discover Connamara’s Revamped Website and Brand Identity, Celebrating 25 Years of Excellence 

You may have noticed that we recently changed our look. After months of designing and planning, we’re excited to unveil.

Behind Connamara’s Code: Mike Gatny, Part 2

In Part One of our interview with Mike Gatny, VP of Engineering & Head of Sales Engineering at Connamara, Mike detailed what.

Tips from a Work-From-Home Hipster

I’ve been posting silly GIFs and videos on an internal Slack channel at the beginning of every week for I.

Why Connamara Supports Recovery on Water (ROW)

There is no such thing as a bad time to give back to your community. But with October being Breast.

Why We Chose Our Company Values — and How We Live Them

The term “values” is overused and frequently misused in business today. While values are certainly crucial to any company, too.

Get Your FIX: Why (and How) Connamara Supports QuickFIX

The QuickFIX open source project is an important part of what we do at Connamara, and has been for nearly 20 years.

The Connamara Client Engagement Philosophy – Part 6

Philosophy 5: Decline projects when the client can’t grasp the concept of iterative releases (no big bangs) Some of our.

The Connamara Client Engagement Philosophy – Part 5

Philosophy 4: Identify and explain project risks to the client before accepting a project All software projects entails risk. Be.