Development Methodology
Our software development page gives an overview of how we develop customised software. Here we explain in more detail some of our development methodology.
Our methodology incorporates the following principles:
| Principle | Features and Benefits |
|---|---|
Model Based |
We use a model based approach to software design, building a graphical model of your business requirements using the industry standard Unified Modeling Language (UML) notation. As well as aiding our communication with you, this is the basis for the actual construction of your system. The modeling tool we use – ModelMaker – provides us with a seamless transition from design, through implementation, to system documentation. This allows us to concentrate more on design and system architecture - i.e. solving your business problem - rather than our technical ones. |
Object Oriented |
Historically, computer software has been viewed as a logical procedure that takes input data, processes it, and produces output data. In contrast, Object-Oriented (OO) programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors, down to the little widgets on your computer desktop (such as buttons and scroll bars). In other words, objects whose properties can be described and controlled. Features and Benefits of an Object-Oriented approach include:
|
Test Driven |
One of the problems of traditional software development methodologies
has been that quality is one of the last tasks to occur – and is often cut short because the project timelines are under pressure. Test-Driven Development (TDD) completely turns traditional development around. Instead of writing functional code first and then the testing code as an afterthought – if it gets written at all – instead the test code is written before the functional code. This results in significantly better code testing than traditional techniques – because quality is built in from the start. We use an Open Source testing framework called DUnit– which automates much of the process. By making the process easy, DUnit ensures it happens. |
| Design Patterns | Why reinvent the wheel ? Christopher Alexander, an architect, wrote a book "A Pattern Language" 30 years ago. According to Alexander: "A pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice".Patterns occur in everyday life in many situations. In software engineering, a design pattern is a proven solution for a general design problem. The usefulness of the solution given in the pattern has been proven in many designs. As such it captures design experience of experienced programmers and makes it easier to reuse successful designs and architectures. Put simply, design patterns help a designer get a design 'right' faster. This is another reason we use ModelMaker, because support for patterns is built right in. |
| Data Driven | At an early stage of development we take a sample of your existing data. We use this for two purposes:
|
Feel free to ask us any questions you may have after reading this.
