Home → Software Development

Since 1998, Equesense has been providing software development expertise worldwide from our home in Ottawa. The company believes in a practical approach to providing the right information to the right people at the right time in the right way to make the right impact on business operations. We do this by following an agile unified process with a strong belief in consumption based process improvement through evolution.

We also are aware that every organization has unique constraints. Industry standard principles of software development such as object-oriented design, services oriented architectures, may prove to be valuable to these organizations. We can help realize the benefits of best practices in a way that works for you and your team.

Powered by UNIVOLV.

Getting Started

If you believe that an investment in software development may be warranted to meet your business goals, contact Equesense.

If you have a project underway but are concerned about being able to sign off on requirements, contact Equesense.

If you have a software development project underway and are having configuration management problems or are concerned about the project meeting the objectives, contact Equesense.

If you think, “building software should not be this hard,”; we can make it easier. Contact Equesense.

Usually Equesense works very closely with clients to ensure the best customer service. However, if you are not in the Ottawa area but believe that we can help, it may be possible to help your organization remotely if you have people willing to champion the effort locally. Contact Equesense by email to arrange a good time to connect and talk about the possibilities.

• Equesense can evaluate the effectiveness
• of your meetings
• and your ‘hard’ communications,
• conduct training in
• Use Cases
• Process Improvement
• Unified Process
• Object-Oriented Design
• The Unified Modeling Language (UML)
• Agile Teamwork
• Model-Driven Development
• and provide several other UNIVOLV services.

Our Philosophy

Software development is team work.

Taken from a Customer Service model, we strive to know how everything we do provides value to other members of the team and ultimately to the goals of the project. We believe that efficient value is timely, and satisfying. We solicit periodic feedback on the usefulness of all our work products to know how we can become more at your service.

We believe that effective processes are first and foremost best worked out between practitioners to solve real problems.

We believe in process evolution through the replication of successful practices that are proven to provide solutions within the organization. We created UNIVOLV for the efficient capturing of process information to increase the visibility and replication of these process assets.

Start with quality requirements.

We believe in a valuable separation of concerns between the solicitation and analysis of business requirements and vetting design.

Quality requirements are testable, feasible, specific, and complete but they must also describe a problem without prescribing the solution.

The best requirements invite alternative solutions, usually with widely different characteristics.

Competing designs should be weighed against each other so that the best possible solution may be discoverable and implemented. If the requirement is prescriptive, it will certainly inhibit innovation.

There is a lot of value in getting this right as requirements form the basis for a great deal of work, and these are highly reusable assets when they are defined correctly.

Doing Use Cases wrong can be frustrating. Our experience with Use Cases has proven very valuable to soliciting requirements that are of excellent quality because we do Use Cases right with our proven “Use Cases for Use Cases” methodology.

Design is a business concern.

We believe in vetting competing designs with the business stakeholders.

If requirements have been defined correctly, then a good architect will be able to dream up many possible solutions. Some of these solutions will be more expensive than others. Some of these solutions will no doubt be much easier to work with than others. In our experience, a good design will be cheaper than what the stakeholders originally envisioned and more useful. That might sound like a wild claim, but taking the time to work out a good process based on our proven methodology leads to the evolution of an architecture that supports faster work instead of getting in the way down the road.

We believe in design solutions that out-compete the status quo and alternatives.

The vetting of solutions produces a different set of concerns that the project must accommodate. These include but are not limited to:

• design preferences and requests,
• system constraints,
• enterprise architecture,
• reference architectures,
• process assets,
• tool constraints,
• environmental concerns,
• standards and principles of design,
• availability of assets and components,
• assumptions,
• maintenance and life-cycle constraints,
• and client preconceptions.

Many of these concerns can be noted and accommodated without necessitating meeting with stakeholders, and some are only a product of direct communication.

It is important for the designers to work directly with the stakeholders to make sure that the design is acceptable and meets the requirements in the best way for the business now and in the future.

This work creates highly reusable assets for the organization as many of these concerns persist between projects and over time in the organization. See the Care and Feeding of Process Assets on our UNIVOLV page.

Furthermore, the design itself becomes a highly reusable asset. Not only does a clearly delineated design make the code more reusable, the design itself offers patterns that become assets for the organization and for enterprise architecture.

Configuration management is a team issue.

Managing the configuration of source, tools, third party components, initialization files and hardware specifications can be a real hassle, but much more so if proper care is not taken by the architect to make this part of the job. Everyone needs to be part of managing the configuration and keeping the myriad units of software development organized.

A specialized Configuration Manager is likely an invaluable person to ensure that this concern is dealt with appropriately from a planning perspective on large projects. If a person dedicated to configuration management can not be afforded, then this concern must be added to the work of the Architect and the Project Manager. Thankfully, much of this should be replicated from successful practices recorded in the process assets. See the Care and Feeding of Process Assets on our UNIVOLV page. If these process assets are not available, get started using UNIVOLV as a guide.

The responsibility for quality is tiered

There is a correlation between quality and the relationship between specification and testing. The more direct the relationship between specification and testing, the better the quality.

There are many ‘quality’ concerns, so a Quality Manager is often essential to ensure that quality concerns are not missed, but consider making it everyone's job to ensure quality for their areas of concern.

• Consider making the people responsible for describing the requirements describe and perhaps perform acceptance testing.
• Require that the architect who designs the system has a plan for and ensures that the organization of the software is reviewed and complies with architectural concerns,
• Ensure that programmers verify that individual algorithms work as they should including proper testing of each interface.